How to use templates with agile methods?
By Mitch on Friday, 3 August 2012, 22:01 - Templates - Permalink
All templates I have written are listed in my templates repository page. I already explained in that page and some other articles how to use them with waterfall development process.
But their use is not obvious with agile methods. Here are a few explanations.
The concepts used in this post: reflexion, iteration and consolidation are explained in another post.
Very simple project: All in one template
The all in one template is made for very simple projects (a team of 2 or 3 people, 6 months of development including tests, class A software). It is made of:
- First two chapters about organization,
- Next four chapters are specification, architecture, tests and tests results.
With agile methods, the document is updated at each iteration:
- Beginning of project: fill chapter 1 & 2
- First iteraton (reflexion): fill chapter 3 & 4
- Next iterations: update chapters 3 to 6
- Consolidation: Redo chapter 6.
To have things simple, increment the revision number of the document at each iteration:
- Revision 1 at the beginning of iteration 1
- Revision 2 at the beginning of iteration 2
- and so on until Revision n at the beginning of iteration n
- Revision n+1 at the end of iteration n, before consolidation
- Revision n+2 at the end of consolidation
Project with agile method
Let's see now a project with more standard metrics. Even if it's possible to change everything in your software from one iteration to another, not all documents have to be updated.
Beginning
The beginning of the project is the right time to write documents about the organization and the structure of your project:
- Project Management Plan
- Software Development Plan
- Software Configuration Management Plan
- Risk Management Plan
When you have these documents you can begin your real technical work! They shouldn't change. Perhaps you may update the project management plan with a new planning if the initial planning was too short (real life) or too long (dream).
Reflexion
Reflexion is the first iteration where concepts and ideas are cast in a first sketch of software. You will probably know most of the functionalities of your software at the end of the reflexion phase. And you will know more or less how to develop it. Thus you initialize the following documents:
- Software Requirements Specifications: the functionalities,
- Usability Specifications Document: the man machine interface,
- Risk Analysis Report: Risks and mitigations of known functionalities,
- System Architecture Document: General architecture of your software,
- Software Test Plan: Organization of tests and resources needed to test it.
The creation of the software test plan may be delayed to a further iteration, when you are close to the consolidation.
All documents above shouldn't be 100% complete at the end of reflexion phase. They only should be filled with what you know of your future software, so far.
Iterations
Your software becomes more and more mature at each iteration. The documentation shall reflect this maturity. Thus you update documents intialized during reflexion:
- Software Requirements Specifications: update the list of functionalities,
- Usability Specifications Document: update the man machine interface,
- Risk Analysis Report: update risks and mitigations of known functionalities,
- System Architecture Document: Update and stabilize the general architecture of your software,
- Software Test Plan: Update organization of tests and resources needed to test it.
And as the software becomes more and more mature, you create new documents that are relevant of this maturity:
- Software Detailed Design: when design is stabilized,
- Software Test Description: when software functionalities don't change,
- Software Test Report: when functionalities are testable,
- User Guide: as soon as you can (it is the poor relation in the documentation).
Not all of these documents should be updated at each iteration. It depends on the content of the iteration:
- If an iteration contains new functions without change in architecture (because your architecture is smart and uses design patterns!) , you update the SRS but not the SAD,
- If an iteration is all about refactoring (to make it smart!), you update the SAD but not the SRS.
It's up to you to decide what document should be updated in each iteration.
Consolidation
The consolidation is a phase with tests and bugs fixes, not new functions. The following documents shall be ready to do tests.
Af the beginning of consolidation:
- User Guide: how to use your software,
- Software Test Description: how to test it,
- Version Description Document: a revision before tests.
At the end of consolidation:
- Software Test Report: the results of tests
- Version Description Document: a revision after tests.
There should be more fixed bugs in the revision of VDD after consolidation than the VDD before consolidation.
Conclusion
No need to create new templates to document your software development with agile methods. The only thing to know is when creating and updating documents! Q.E.D.
