Commits

Herbert Breunung committed 05a9a30

rewrote planning

  • Participants
  • Parent commits fbe6737
  • Branches sp3

Comments (0)

Files changed (1)

File doc/CompleteProgramming.pod

 
 =head3 Planning
 
-As said here is not much planning involved because of reasons already stated.
-Nontheless there are severel things to be decided at start.
+Initial planning in CP is mostly metaplanning. Of course you have to think about
+the classic five questions:
 
    * general vision of the program with use cases
+   * approx. feature list
+   * small roadmap (what featture into what stage)
    * on which technology to rely (with fallback alternatives)
    * what team we need (especially in corporate setting)
-   * small roadmap
 
-Write that down (except point 3) by the rules given in the next chapter.
-In CP that is already considered coding since you write documentation.
-The development cycles have already began. So please don't overdo it,
-since everything can be overwritten when other information become available.
-You might protest that your boss (that needs to read the summary of that newly
-proposed undertaking) requires a different style or format. But you both work
-on the same project and have to form a complete whole. Documentation should
-be written so clear that even business people can understand it and the manager
-can make much better decisions when he knows what you actually do.
-Duplication leads to unproductive work and enbles miscommunication.
-Managers usually understand such arguments.
+Take your time and write down answers in a structured and well readable manner,
+because this gets already shipped into the repository as user docs. In a sense -
+development has already started. Of course these docs will be presented to your
+boss as the project proposal. CP minimizes overhead and forces people to find a
+common language and hopefully a common understanding.
 
-One last, but very important thing during that phase - adapt complete programming.
-First you might commit this text as part of the developers documentation,
-that should reflect briefly all the processes involved. Than you alter details,
-because your program maybe has no GUI, or config, or you will need more branches.
-Maybe want to tweak the role of tests - by all means these are not the ten
-commandments. And please give us a feedback when your tweaks seem to work well.
+Please don't overdo your first plan, since most information you will gather along
+the way.  CP means that new information will get stored quickly in the appropriate
+places - not that work targets change every week. CP knows a lot of well defined
+workflows which spares some agreements people call planning. Some planning will
+be replaced by asynchronous interactions with results that are immediately visible
+to all project member. But still there are meetings, a boss and something similar
+as sprints.
+
+After the rough goal is set and before any "real" coding begins - its time for
+the announced metaplanning. Adapt this document, which is part of the programmers
+documentation, to the needs of the project. Maybe your team is smaller and several
+roles will be played by one person or maybe your program has no GUI and you have
+to redefine completeness of a feature. Maybe you have to tweak the role of tests -
+by all means these are not the ten commandments.
+And please give us a feedback when your tweaks seem to work well.
+
+Savor the magic of a new beginning and avoid the trap of doing things as usual.
 
 
 =head3 Documentation
 to the building blocks of a program like computing a formula or writing a file.
 Because it doesn't make sense to plan on details if we don't know if it can be
 built or how. I mean experienced programmer know a lot, but there are far too
-many fast changing libraries, techniques and domains to know it all. And docs
-can be unclear, missing, lying or simply out of date. So only when you built it
-and it's running you can be sure it runs. Therefor we do functional prototypes (FP).
+many fast changing libraries, techniques and domains to know them all. And even
+if you use other peoples work - code can be buggy and docs might be unclear,
+missing, lying or simply out of date. So only when you built it and it's running
+you can be sure it runs. Therefor we do functional prototypes (FP).
 
 A FP has only one file and should be as short as possible. It can be used to
 check out how third party libraries work, but none of the projects libs should