Xp Questions From Journey
Xp Questions From JourneyAlexStockdale asks: The following questions may be addressed in the XP book. If so, I apologize, and will make an effort to RTFM. JourneyOftheSoftwareProfessional by LukeHohmann, identifies the following (potential) benefits of a methodology:
Clearer conceptual understanding -- How does XP improve understanding of the problem domain? CRC cards don't seem like an appropriate vehicle for problem domain modeling, although I think I see their value in analysis and design.
XP relies on the customers to know what the problem is. It does not then do a "deep" translation of the problem into objects. Instead, XP builds a SystemMetaphor and an ArchitecturalSpike: a high-level model of the system, and a working prototype. Those are evolved, based on working on high risk items early (WorstThingsFirst) and on high business value.
Better factoring of work -- XP seems like a reasonable approach for small to medium size projects. How does it assist in the decomposition of a large problem into smaller sub-problems, and how does XP assist the coordination of multiple teams?
XP does not address large teams at this time. Many of the XP practices are of course valuable in projects of any size. Testing comes to mind ...
Improved communication -- How do the XP artifacts aid the developer in communicating with the customer? The customer can't read the code. How does one indicate that something have been left out because YAGNI?
The CRC process is wonderful for customer/developer communication. Humans can understand CRC much better than UML. The AcceptanceTests tell the customer whether the developer has done what has been asked for. What other specific communication concerns might you have?
YAGNI never leaves out any functionality: it only leaves out things that are not asked for. Perhaps a different statement of the question will better get at your concern.
Improved maintenance -- Am I right in thinking that XP's attitude to maintenance is that those responsible will read the code to figure out what needs changing/fixing? Based on my past experience with maintenance (of admittedly non-XP systems), I have often found it helpful to have high-level design documentation to help me pinpoint the areas that need changing. Are artifacts other than code (e.g., CRC cards) passed on to maintainers? How are design decisions documented?
XP is a process for development, and the practices are directed at the flow of the rapid development process. During that process, communication practices are used to keep the design in the heads of the developers, where it is always needed before anything can really be accomplished.
When the project transitions to maintenance, it is probably time to create some high-level documents of some kind, leading the maintenance people into the system. Remember that the code is very clear, and that there is a very full complement of tests to explain as well as test the system. We have not yet defined what we'd leave behind - it's only that we don't think it should be created while the system is under rapid development.
I'm not sure what you mean by documenting design decisions. The things we do are in the code. Are you asking how we document what we didn't do? Again, perhaps a more specific question would be helpful.
On the project I am currently working on, we document changes to design decisions by keeping the 'old' story cards around - if a story is eliminated or rewritten due to a change in requirements or after discussion with the customer about technical difficulties, we mark the original version of it as 'not required' and put it in a pile. (We also have these in a database so we can print reports of them ... we have a LOT of stories, quite possibly too many.) This way, we can go back if someone says "weren't we gonna ..." and have the documentation (very brief, usually one sentence) of how the decision was made to eliminate that piece. Does that help? -- Lonna
EditText of this page
(last edited November 15, 2014)
or FindPage with title or text search