1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
[[!meta title="Project management"]]
This page describes the lightweight project management process for
development of Ick. 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, Ick 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 Ick, 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.)
|
