This repository has been archived by the owner on Mar 1, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 12
Development Process
Matthias Benkort edited this page Feb 27, 2019
·
13 revisions
The team follows a methodology known as extreme programming which can be summarized as follows:
- The project is divided into iterations of 1 week
- Releases are small and occur often (every 4 weeks at most)
- User stories are specified, understood, estimated and agreed upon upfront during a release planning
- An iteration planning starts each iteration:
- bugs or failing tests to be fixed from previous iteration become tasks
- one or more user stories are selected and broken down into tasks
- tasks are estimated and prioritized; tasks that are too big are broken down further
- At the end of an iteration, there should be no tasks left
- Project velocity is measured for each iteration
- User stories, Tasks and Bugs all have a dedicated GitHub template:
- [User Story Template][User Story Template]
- [Task Template][Task Template]
- [Bug Template][Bug Template]
- User Stories, Tasks and Bugs move across the following board:
|***********| |**********| |*************| |********| |**********|
| Backlog | | Selected | | In Progress | | QA | | Closed |
|-----------| |----------| |-------------| |--------| |----------|
| | | | | | | | | |
| ... ----> ... ----> ... ----> ... ----> ... |
|___________| |__________| |_____________| |________| |__________|
- We work in pairs, each pair member reviewing the work of the other
- The code is collectively owned, everyone is knowledgeable about every part of the code
- Code is following an agreed standard and style
- Code is integrated and tested daily to the main branch (
master) through PR - The main branch should be releasable at any time and not contain broken features
- Any user-facing change (API change, Documentation, New Feature) should have be integrated with a corresponding entry in the CHANGELOG
- No unplanned optimizations, features or unneeded abstractions are implemented
- We favor simple unbloated code and use refactoring techniques to add features
- We favor test-driven and type-driven development
- High-level code API is written first with dummy or placeholder implementation
- Tests are written using the API, ajusting when necessary and iterating until satisfaction
- Tests fail (it's important to see test failing, to make sure they're actually testing something)
- The source implementation is completed
- Tests pass (giving confidence that we have useful tests with a correct implementation)
- All code should be covered by tests (either unit, integration or manual)
- Issues are closed by QA, once convinced by developers that the added code works and is covered
- When a bug is found, tests are created to illustrate the failure, prior to fixing it
- Tests are ran daily in a integration environment
- We have daily written, asynchronous, stand-up on Slack on a separate channel
- A blackboard page on our Wiki is dedicated to keep track of ideas and thoughts
- We have a weekly meeting every Friday to plan the next iteration
- We have release meetings between release to
- Plan the next release (i.e. create or refine User Stories)
- Restrospect on the previous release looking at past User Stories
- Discuss idea an thoughts gathered on the blackboard
- Discussions happen on Slack, decisions are documented on GitHub as comments on issues
- Our GitHub wiki can be extended at any time with insights and details about the software
- Reports and metrics about the project are available to anyone
- A report is produced as a result of each iteration which contains:
- A brief non-technical summary of the week overview
- A list of the completed user stories and their business value
- A list of known issues or debt accumulated during the iteration
- A refined estimated end-date of the project