diff options
Diffstat (limited to 'pm.mdwn')
| -rw-r--r-- | pm.mdwn | 62 |
1 files changed, 62 insertions, 0 deletions
@@ -0,0 +1,62 @@ +[[!meta title="Project management"]] + +This page describes the lightweight project management process for +development of vmdb2. Participation is voluntary. + +Iterative development process +============================================================================= + +Iterative development seems to be the only thing that makes sense in +order to produce working software that fills what users actually need. +Otherwise, you don't get any feedback until at the end of the +development period, when things should already be mostly finished. +With iterations, you do a little bit of work, show that to relevant +people, get feedback, and incorporate the feedback to future work as +seems most sensible. + +There's a ton of methodologies to do iterative development. Scrum is +currently popular. However, vmdb2 needs to be fun, and Scrum seems too +heavy-weight for fun. Instead, this nearly informal process is what +[[people/liw]] wants to use. + +* Iterations are a calendar week. + +* Start iteration with a short planning meeting, where goals are + discussed and decided upon, and tasks outlined, and everything's + written down. The tasks should be specified with a clear scope, and + with enough detail to estimate that they can be done. Large tasks + should be split down into small tasks, preferably into tasks less + than an hour each. + + Only allocate enough tasks that they can all be completed with a + high likelihood. It's always OK to do more, but it's de-moralising + to never complete everything. + +* End the iteration with a short retrospective meeting, to summarise + what was done (from the planned list of tasks or otherwise), and + reflecting on the process to improve it, as necessary. + +* Write down decisions, in a meeting note in the intrawiki blog. + +* Estimates are done by the person who'll be doing the work. They + should not be optimistic. + +Development workflow +============================================================================= + +* Work should be done in feature branches, but merged frequently to + master. Unfinished features should be disabled, via some sort of + feature toggle. Merging branches only after a long time means + there's more pain during merge, and it takes longer until there's + feedback on the changes in the branch from, say, CI, actual use, or + code review. + +* Work for Heat/Ansible stuff should also be merged frequently, and + any affected production systems (`infra-*` stacks) should be + deployed after merge is done. The master branch and what actually + runs in production should never be far apart. + +* Merging should ideally involve review. However, as there's only the + one actually working on vmdb2, review would slow things down too much. + Thus, we'll probably not have review for the time being. (Hint: + contributing reviews would be a useful thing to do.) |