Development process
Development is done using Kanban with one week cadence for planning and reviewing. This has 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.
- Tuesday 10:00 - 11:00; Planning
- Friday 14:00 - 16:00; Review and visioning
- Every Day 10:00 - 10:15; Daily
Friday agenda is crafted during the week. Everyone can suggest agenda topics in "team chat application".
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
If task or feature is blocked or waits for something it is put to this column
Each task is worked on by the development team. We use GitHub tasks as much as possible. Task not ready = No check, Task ready = Check.
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 by upstream project. Ideally:
- Features should be available for testing in test enviroment
- All code is committed to some branch and is available for review
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 for the 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. Digitransit UI)
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