About 6 months ago, I started trying to create a set of success factors that were synthesized from the experts. I have since completely revamped my thoughts. What I ultimately want, for my own purposes, is a "Reference Model" (e.g. the OSI 7-Layer Model) that provides some structure with which I can I can think and talk about the various factors that lead to success--independent of any specific methodologies. I hope to be able to say things like "Reflection Workshops in Crystal are one technique to Continuously Learn and Optimize," or "XP provides a system for Iterative Development and Proven Practices, focused on smaller Project Teams."
I have now spent some more time thinking, and included some more popular, respected sources. The following slide is my Reference Model, a 30,000 ft. view of software success.
In future posts, I will provide more details on the individual success factors and how they relate to the work of industry luminaries. So, how did I arrive at this model? I started by taking the most important, highest-level principles and factors from the following excellent resources:
- The Standish Group's CHAOS study [CH1..9]
- The Unified Process or RUP [RUP-1..6]
- The SCRUM meta-process (web, book) [SC-1..4]
- Alistair Cockburn and Crystal methods (web, book, book) [AC-1..7]
- eXtreme Programming (web, web, book) [XP-1..5]
- My own experience on dozens of successful projects [JT-1..6]
Comments are most welcome.
3 comments:
Hi John,
Looks interesting, but the images are small and hard to read. Could you post, or email me, them in a larger size so I could print them out?
Also, I'd be interested in your thoughts on how to balance the trade-offs between the apparent contradictions of "Manage for Agility" and "Build Rich Specs."
Thanks,
--Mike Rutter
mrutterX@yahoo.com
Thanks Mike. I have updated the post in response to your comments.
I'll try to post more on this soon. For now, my concept of "Manage for Agility" means that Management (external to the Team) really buys in to Iterative Development--They recognize that requirements are dynamic and don't demand Big UP Front Analysis or Design. I'm not saying that this is easy or common, just that it is often key to success.
"Use More Realistic Specification" is about defining the system with something, anything, more "real" than paragraphs of text. Wireframes, mockups, UML models, or best of all, working code. 37 Signals' "Getting Real" approach, for example, argues for very aggressive prototyping in lieu of documentation.
Hi,
I have been asked to develop a reference model for an application which is under development. So far, I have done SRS, Design document (LLD & HLD) only. I have no clues on this Reference Model.
Any help would be appreciated.
Post a Comment