Development process
Development is done using Kanban with cadences for planning and reviewing. Cadences have two purposes: Provide transparency and make it clear when work is planned and reviewed Add trust between "business team" and development team by continuously adding and demonstrating value Visioning, planning, and reviewing is done using two week cadence.
Period is divided into two weeks. The only difference between weeks is that Friday's meeting agenda will change biweekly:
- Week1 Friday meeting will concentrate on demonstrating implemented features
- Week2 Friday meeting will concentrate on visioning and grooming the backlog and seeing what functionality will be implemented next
All code that we work on must reside under https://github.com/HSLdevcom. Repositories should be either:
- Forks from other repositories (e.g. OpenTripPlanner)
- Our own work (e.g. OpenJourneyPlanner)
Forks from projects that are not controlled by us are done for two reasons:
- It enables us to use our own issue management for every software component
- If we must, we can deploy new versions even when our pull requests are not accepted to upstream repositories
It is high priority to keep our version of forks in sync with original repository. This means:
- All our changes should be made available to original repositories as pull requests. Hopefully they are accepted.
- We should periodically merge upstream repositories to our local copy in order to get updates made by 3rd party project
Basically, visioning and planning meetings concentrate on the beginning of the Kanban board while review meetings concentrate on end of the Kanban board
- Visioning: Checking backlog and splitting it into milestones. Making clear what work will start in one month.
- Planning: Checking status of selected items and replenishing selected queue from top of the backlog. What will be worked on during next week
- Daily: What is currently being worked on
- Review: What has happened during last two weeks
