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
See our real Kanban board here
Backlog contains all upcoming work as features, stories, bugs, etc. In general, one work item is called "Backlog item". Backlog is prioritised so that work on top represent next upcoming work. Backlog is also divided into milestones. Milestones gather upcoming work into an entities which bring value to stakeholders. Backlog is groomed continuously so that large Backlog items are splitted into smaller ones.
During planning meetings development team goes through top of the backlog with Product Owner (PO) one by one so that is has enough work for one week. PO explains each selected Backlog item so that the development team understands it.
- Development team must understand Backlog item from business perspective
Development team decides when is the proper time to design technical solution for a selected backlog item. When the time is right, development team splits backlog item to one or more tasks. Task can be anything development team sees necessary.
- Backlog item is split into tasks
Each task is worked on by the development team. We try to use GitHub tasks as much as possible.
Task not ready = No check
Task ready = Check
Once all tasks are ready, new functionality will be deployed to test environment for testing and reviewing.
- Features can be tested by the development team and the Product owner
- All code is committed to some branch and is available for review
Once new functionality is ready, someone else than original implementor will do review for it. In case of HSL controlled software component this "someone" is from the development team. If software component is not controlled by HSL, review is done when Github pull request is accepted. Once review is done and required fixes are done, new functionality is merged into correct git branch.
- Code & documentation adhere to coding standards.
- Code is merged into original repository into correct branch
Production deployments are made by considering transaction costs of new features. When PO and development team see fit, reviewed functionality is released into production. Releases should match to backlog milestones if possible. As a general guideline we try to continuously reduce size of deployments and achieve continuous flow of value.
When new functionality is in production it should be communicated to all stakeholders. Once required communication is done Backlog item will get moved into this stage.
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
