A bit of quick feedback (I don't have time to read the whole thing right now -- sorry about that).
- You have UAT (User Acceptance Testing) in the phase after integration. This seems to be done to meet the philosophical desire to link it with "Meets Reality". However, I have found that moving acceptance testing higher in the process is very beneficial. While the sign off that the software is accepted is after integration, the activity for preparing the tests ideally starts just slightly after the start of specification. Do you have any ideas for staggering the some of these activities?
As an example, I once was handed a QA group for my XP team. At first I wasn't sure what to do with it. But then I got the idea to have a QA member write acceptance tests at the same time that the developers were writing the unit tests and code. The developers were not allowed to finish their story until the acceptance tests passed (which in this project was mostly manual acceptance tests). Then after integration (at the end of our sprint), the QA team ran all of the acceptance tests again to ensure that integration was successful. Frequently XP teams also write automated acceptance tests at the same time that they do unit tests and coding.
- There is a statement that Kent Beck advocates "Do the simplest thing that could possibly work", but this is only half a quote and the missing half is actually crucial. "Do the simplest thing that could possibly work and then refactor". "Simplest thing" without refactoring leads to incredibly fast degradation in design. In XP, design is just as important as it is in other methodologies, it's just that you distribute the activity across the development phase instead of having a dedicated phase. It is incredibly important to understand (and often forgotten) that you must be refactoring all the time. You are not finished your story until you are happy with the overall design (and not just your bit of it). Again, without this activity, your code will very quickly degrade -- especially if you are pushing to do things "the simplest way".
I didn't read much past that point, so I'm probably missing it, but what design activities do you see in this methodology and how does it integrate with the development phases you've laid out?
Thanks so much for your feedback. Addressing each point in turn:
1. UAT/Integration: this was just an "example process", one that you _might_ follow. YMMV and you could get better results doing things in a different order or with extra steps. The point was to show that each step on your process (whatever it is) is meeting reality and managing risk. I'm with you on this: you should _totally_ prepare for UAT ahead of doing it, because that preparation actually manages risk too - the risk of the users not knowing what to test, or not being available, or not understanding the functionality, or the data not being right etc.
2. On "Do the simplest thing... and refactor": this (and YAGNI) are great "rules of thumb" about how to develop. What I'm trying to do here is explain _why_ they are great. That is, explain how they attempt to manage risk on software projects. On the refactoring point, I cover this in a lot more detail in the section on "Complexity risk", which I'd really appreciate your feedback on.
I like the gist of this approach. A few years ago, I read about some books of the legendary (non-software) engineering projects in the past. Engineers were very cognizant of risk and costs, far more than I see in software practice. With some reflection, I think that's just a defect on our field's part, not and not only because the software game is different.
I think a lot of it has to do with the lack of understanding non technical people have with the relative difficulty of software tasks. Building a 10 foot bridge is clearly much easier than building a 100 foot bridge, but in software it's murkier.
Write a program that checks the rank of a poker hand: okay, give me an hour or two. Now can you change it so that it checks the rank of a photo of a poker hand? That should only take you like 2 or 3 times longer, right? Oh, more? Well I'll give you a week, that should be plenty.
Maybe add a definition of 'risk' in the quick summary. It tends to man different things to different people, and linking back to a definition (e.g. the effect of uncertainty on objectives) helps keep discussions on track.
Feel free to ask anything.
thanks