|
|
|
|
|
|
by mikekchar
2742 days ago
|
|
|
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.
It's here: https://github.com/risk-first/website/wiki/Complexity-Risk
I'll invite you to the project on github too
thanks, Rob