In extreme programming methodology, what artifacts/ can be used to document the implementation?
I have used an activity diagram to document the design steps for each activity. I have read that for XP, the implementation chapter is the code itself.
I am developing an android application which consists of the GUI and java coding.
The unit/acceptance tests are stronger documentation on how the system works than any piece of paper could ever be.
However, document the design any way that works for you; XP does not tell you that you cannot 'think on paper' or generate supporting documentation as you see fit, it just does not require such things
Documentation is something that is as important as database design, UI's and any number of other things that I've heard developers deride. The trick that agile is trying to teach people is to learn what is necessary and what is cruft. In the past, a lot of documentation was cruft. That's why companies would spend millions of dollars generated specifications that were promptly thrown out by the developer teams. Overly detailed, and often as over engineered as the code that was generated from it. Lately some people have gone the other extreme and say thing like all code should be self documenting and "Just go read the code". Just as silly.
The code you are writing is there to solve a problem, so consider the documentation as also needing to solve a problem. Ask yourself - why do I need this documentation? and ... following agile practices ... whats the simplest solution that will solve the problem in the clearest way? But most importantly - who am I writing this for? and what level of understanding am I going to assume they have?
There is no hard and fast rules either in programming or writing documentation. Each must fit the problem and the context of the problem. Treat all the available options as a palette of solutions you can pick and choose from to apply to your project. Choose the best options as you see them, and don't be afraid to change that at a later date.
By core definition of XP methodology, there is a lack of design specification or documentations. Reference below is from Wiki - Extreme programming.
Critics have noted several potential drawbacks,[5] including problems with unstable
requirements, no documented compromises of user conflicts, and a lack of an overall
design specification or document.
This approach has a number of critics and one of them:
Can increase the risk of scope creep due to the lack of detailed requirements documentation
Supporters of XP stress the following: Coders like coding, not documenting, and coders like seeing code they've written work.
We are creating some documentation (UML snippets, method signatures and other remarks) and include some of them in unit tests. However, project have to document the code at some time, because it's how customers actually use those features that you thought up. It'd be selfish just to code and never document or comment on how the software works.
Any documentation is tough for a programmer since he can never explain the software in less than ten hundreds of words. Thus, option of having Video documents that records design approach and use cases, as well as diagrams to show interaction between components can be done with less time and more fun.