??? ??? ??? ??? ??? ???
Understanding the Problem
[ 12 ]
The principle we applied to task management can also be used here??”we don't
need to prepare for and document every eventuality, we just need to provide solid
enough foundations for our developers to build on. We must seek not to weigh our
developers down with unnecessary rules, but rather provide just enough to guide
them to maximal productivity.
We will also apply the review activity from task management to our
documentation??”it needs to evolve with our project, not constrain it. As our
developers use our system, things may change to suit the project in question, which
is a good thing. Our documentation needs to be a living thing, not a dusty set of rules
locked away in a library.
We also need to provide documentation of our software to the users, and ideally
this will be written as the software develops. Some projects may be lucky enough
to have a dedicated technical author, but even those will benefit from writing the
documentation alongside the software. If a dedicated resource for documentation is
not available then we will certainly find it easier to write the documentation with the
software, not afterwards.
Everything Is a Task
Every aspect of software development, from writing documentation through
implementing a new feature and fixing bugs to packaging for a release, needs to
be considered as a task.
Pages:
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