Patterns of successful software projects (part 1)

转载 :Patterns of successful software projects (part 1)

A short introduction to my framework for successful projects, using terminology from the pattern literature. Future posts will expand on these topics.
Definition of “successful“
There are five basic truths that make a successful software project: regardless of what development environment or programming language is used, no matter whether it is managed using an “agile“ or a waterfall process, OO, SOA, AI or punch cards.
They are:
The customer/user has a reason for the project (based on their need, a demonstrated ROI, “it sounds cool“, etc) The developers know what they are building (there is some mechanism for requirements specification) The developers know how they are to do it (knowledge and usage of tools and “process“) The development team will know when they are done (there exists some “exit“ milestone criteria) The customer/user agrees (they accept or purchase it)
My claim is that all software project “failures” can be traced back to a violation of one or more of these.
Forces on software projects
There are a number of “forces” on a software project.
These include (but are not limited to):
Level of business/customer satisfaction—functionality, usability Time-to-market—deadlines, milestones, marketplace, competition Development team self sufficiency—technology/knowledge, resources Expected return on investment (and timeframe)—value, tangible, intangible Developer's community of understanding—shared knowledge, sharing mechanism Need for efficiency and predictability—estimate accuracy, resource usage Development organization's culture—risk tolerance, “learning” organization
Control
Finally there are various elements that the development team can control. They include:
Development technology/tool (team's familiarity with, effectiveness of, appropriateness for solution) Technical support for technology/tool (mentors, training, collaboration) Team size/composition and geographical locality (includes skill sets, team organization, and management) Iteration length (of any defined milestone, e.g., including release schedule; for continuous hacking, Length = 0, for waterfall, Length = Infinite (or “all of it“, there is no iteration) Formality (artifacts, models, documentation, process mechanisms)
I propose that:
Software development must balance the forces using the control mechanisms There are a number of patterns that “solve“ the balance Different tools and technologies can make this easier or harder A particular “balance point“ for a given project may “move“ in the force space as the project progresses Different tools and technologies can help or hinder balance control