|
|
|
|
|
by bobm_kite9
2741 days ago
|
|
Hi Mikekchar, 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 |
|