Traditionally, software release is considered to be a handshake between engineering and business. Engineering passes on the tested code to business, which in turn promotes it to the market, thereby completing the cycle. However, with Agile, software release could be bucketed into two categories of internal and external releases. This helps in creating a loose coupling between the two. Internal releases are made by engineering and business has the option of using one of them as an external release.

In a recent article on the Cutter Consortium (download code RELEASEMYTH), Israel Gat of BMC makes an interesting argument for separating the “two” releases in the software world. According to him the internal and external release should be viewed as two faces of the same coin,

A body of code that delivers certain features and functionalities is one thing. The use of this body of code by marketing and sales to accomplish business results is quite another. Not only do the two activities differ, but they do not necessarily need to be tied together through a 1-to-1 relationship.

He gave an interesting metaphor example of a water pool with two pipes, one for inlet and the other for outlet. He compared engineering to the inlet pipe and business to the outlet pipe.

Think of the in-pipe in this example as engineering and the out-pipe as the business. Engineering can post releases at its own pace. The business can selectively choose from the posted releases. In this paradigm, marketing is not obligated to promote a release upon its completion. Marketing might do so in three months; it might choose to promote the current release with another release due at a later time; it might choose to make a release available on a limited basis; or it might choose never to promote a release.

Israel mentioned that since engineering is now loosely coupled with business, they can move towards a fluid release concept in which the software becomes alive and continuous. Engineering can churn out internal releases at a pace suitable to them and business can make a decision on which release gets to the customer as an external release and when.

Commenting on the article, Ryan provided some additional insights that Israel’s team ran three internal releases to one external release. He suggested that the benefit is to get valuable feedback and business can market the external release better. According to Ryan,

It worked great! As a result, I coach most agile teams to start by making sure their "internal release" cadence is twice as fast at marketing, operations and the market is used to. In this way you get a release where you can gain feedback and steer the "external release" to market better.

According to Israel, with Agile, frequent and faster internal releases make the software more alive and fluid. This renders the traditional release process obsolete. The separation of releases helps both engineering and business to work according to their release patterns without disturbing the release frequency of each other.

Jakob Nielsen, usability guru and author of Usability Engineering, raises the concern that Agile methods are a threat to traditional approaches to designing usability. He says that Agile’s greatest threat to usability is that “it's a method proposed by programmers and mainly addresses the implementation side of system development”. Alistair Cockburn counters that this claim just isn’t true:

1. It doesn’t matter who proposed a good idea, only whether the idea is good.
2. This sets up an “us versus them” split in the community instead of an “us plus them” coming together.
3. Unlike the other threats Nielsen names, he doesn’t offer a solution, so he leaves us with his “us versus them” unsolvable problem, which is unacceptable.

Proposed solution: Just use good ideas – don’t worry about where they come from. As Kurt Morris posted on the agile usability list, “It’s amazing what can get accomplished once you get past the artificial “us v them” mentality.”

Nielsen goes on to raise the issue that the Agile habit of breaking the stories down into smaller tasks threatens to obscure the total user experience, allowing features to be developed in an inconsistent manner. At its worst, he says: “the user interface can end up resembling a patchwork.”. Nielsen’s solution:

• Perform Usability testing quickly and repeatedly. He says “Weekly tests are completely feasible and give you a surefire way to integrate several user feedback rounds within even the shortest sprint.”
• Parallel Tracks allow the usability work to be done just one step ahead of the development work.
• Use low fidelity prototypes (such as paper) that don’t require coding minimizing the time spent upfront.

Jeff Patton has distilled 12 usability best practices (echoing several of Nielsen’s):

1. Drive: UX practitioners are part of the customer or product owner team
2. Research, model, and design up front - but only just enough
3. Chunk your design work
4. Use parallel track development to work ahead, and follow behind
5. Buy design time with complex engineering stories
6. Cultivate a user validation group for use for continuous user validation
7. Schedule continuous user research in a separate track from development
8. Leverage user time for multiple activities
9. Use RITE to iterate UI before development
10. Prototype in low fidelity
11. Treat prototype as specification
12. Become a design facilitator

The RITE (pdf) method that Jeff describes comes from Microsoft’s Games Studio: “RITE differs from a “traditional” usability test by emphasizing extremely rapid changes and verification of the effectiveness of these changes.”. Specifically, practitioners make changes to the UI (prototype or application) as soon as the problem is found and the solution spotted. Changes such renaming buttons, changing the text of menu items often happen before another participant arrives. More complicated, but obvious changes are made as rapidly as possible. This way the change can be tested as quickly as possible.

In addition, Jeff finds his role has changed: “As I've begun to work within Agile teams, my approach has changed to favor collaborative design. More and more I find myself acting as facilitator to harvest and model information from large groups of people. I find myself working with groups of users and developers to write user scenarios, and sketch user interface design.”

Finally, Alistair says (in reference to the developer/usability divide): “Just remember, ‘There’s only us."

The nice thing about software development methodologies is that they are just like standards. There are so many to choose from! Come to think of it... some of them are standards (which more or less proves my point). Unfortunately, despite a lot of searching I haven't found any page with a list of all major software development methods. So I decided to create one myself.

Here it is... and I hope you will let me know what you think of it.

Terminology

In the various descriptions of methods on Wikipedia I have noticed many different terms being used, like method, process, model, framework, etc.. In an effort to be more consistent than the Wikipedia authors I have tried to redefine the methods using the following definitions:

• methodology (or method) - one specific collection of principles and/or practices
• methodology family - a set of alternative methods that exist alongside each other
• framework - a skeleton (for methods) that must be customized/augmented before use
• model - a description (for methods) that must be implemented by a method, family or framework

For the software developers among us: A methodology is like a class that can be instantiated for a specific project. A methodology family is like a namespace of different but comparable classes. A methodology framework is like an abstract class that cannot be instantiated itself and must be inherited and extended first. A methodology model is like an interface that is just a description of something that must be implemented by one or more classes.

Methodology Leaders

I consider the following methods to be the "leaders" in the crowd. Each of them has achieved a status as a "standard" in a significant part of the IT industry.

Scrum
Scrum is an agile project management methodology, created by Ken Schwaber andJeff Sutherland. It is a skeleton that includes a small set of practices and predefined roles. Scrum is becoming a de facto standard for managing agile software development projects. One reason for Scrum's popularity is that it consists of only a few common sense practices that can be applied in many situations. This also means that Scrum by itself is never enough, and that development teams have to shop in other methods (usually XP) for additional practices.

Extreme Programming
Extreme Programming (or XP) is an agile software engineering methodology, created by Kent Beck. It is a set of best practices of which some are taken to an "extreme" level. As with other agile methods, XP regards ongoing changes to requirements as a natural and desirable aspect of software development. In the selection of its practices XP leans towards the daily software engineering activities of developers. XP is often seen as complementary to Scrum, filling most of the holes that Scrum leaves wide open.

Lean Software Development
Lean Software Development (LSD ?) is an agile project management framework, translated from lean manufacturing to the software development domain. Originally promoted by Mary Poppendieck and Tom Poppendieck, Lean Software Development is adapted from the Toyota product development system, and it is the embodiment of the "lean" subculture that exists within the agile community (and that has by now become big enough not to be able to call itself lean anymore). It is said that the lean and agile concepts form a perfect match.

Unified Process
The Unified Software Development Process (USDP) is a software engineering framework, created by Ivar Jacobson, Grady Booch and James Rumbaugh. The USDP is an extensible framework that should be customized for specific organizations and projects. It aims to be a complete solution, which means that the full framework is far too big for all but a few projects. However, stripping the framework to its bare essentials is like turning a plane into a bicycle. It might be easier simply to select another more lightweight method.

Rational Unified Process
The Rational Unified Process (RUP) is a software engineering framework, created and maintained by the people at Rational Software (now owned by IBM), includingPhilippe Kruchten. It is a commercial product delivered as a more detailed version of the Unified Software Development Process (which is presented as a generic public domain process). This also means that the RUP suffers from the same problem as the USDP, being bloated and too costly to customize for small projects.

Dynamic Systems Development Method
Dynamic Systems Development Method (DSDM) is a agile project management methodology, created and maintained by the UK-based DSDM Consortium, which includes both vendors and experts. It was originally based upon the concepts ofRapid Application Development. DSDM finds itself on the same level as Scrum, meaning that it lists a small number of practices for project management of software development, while leaving the details of the real work (building a product) to be filled in by the development teams.

Prince2
Projects in Controlled Environments (Prince2) is a project management methodology, developed by the UK’s Office of Government Commerce (OGC). Prince2 describes many processes and activities covering the management, control and organization of projects, and is deliberately not restricted to IT projects. Even though Prince2’s popularity makes it a de facto standard for project management (particularly in Europe), it is criticized (by many including me) for being too prescriptive, too big and not easily customizable.

Project Management Body of Knowledge
The Project Management Body of Knowledge (PMBOK) is a project management methodology, developed by the US-based Project Management Institute (PMI). It is an internationally recognized standard providing the fundamentals of project management, not limited to IT-projects. Similar to Prince2, the PMBOK describes many processes and activities, though the PMBOK can be seen as being descriptive (what), while in contrast Prince2 is more prescriptive (how). Their main similarity is that both are criticized for not being agile.

Capability Maturity Model Integration
The Capability Maturity Model Integration (CMMI) is a software engineering model, originally developed by Watts Humphrey. The CMMI aids in the definition and understanding of an organization’s processes and was originally intended as a tool for assessing the maturity of an organization’s processes. These days it is also used as a roadmap for process improvement. The CMMI is heavily criticized for focusing on processes rather than people, and it may lead organizations down the road of bureaucracy.

Methodology Followers

I consider the following methods to be the "followers", because they trail the leaders in their number of references, users and implementations.

Feature Driven Development
Feature Driven Development (FDD) is a software engineering methodology, devised by Jeff De Luca and influenced by Peter Coad’s approach to object modeling. FDD is a model-driven process, distinguishing itself from some other agile methods by explicitly allowing time for the creation of an up-front design. It also applies a refreshingly nonconformist approach to code ownership and several other development practices.

Microsoft Solutions Framework
Microsoft Solutions Framework (MSF) is a software engineering framework, created by Microsoft. As always, Microsoft has its own alternative stance on the subject of developing software. MSF provides a metamodel of descriptive components, and it contains two out-of-the-box templates as prescriptive implementations: MSF for Agile Software Development and MSF for Capability Maturity Model Integration.

Open Unified Process
The Open Unified Process (OpenUP) is a software engineering methodology family. Part of the Eclipse Process Framework (which includes OpenUP/Basic) it embraces a pragmatic and agile philosophy, meaning that the creators have preserved the essential characteristics of the RUP/Unified Process, while having thrown out a lot of stuff to make the original framework actually usable.

Essential Unified Process
The Essential Unified Process (EssUP) is a software engineering framework, invented by Ivar Jacobson. It was created as an improvement on the RUP and identifies practices (most of them borrowed from the RUP and agile development methods) that you can choose and combine to create your own method. This is considered an improvement, because with the RUP all practices are intertwined and cannot be seen in isolation.

Agile Unified Process
The Agile Unified Process (AUP) is a software engineering methodology, created byScott Ambler. It presents yet another attempt at simplifying the RUP, describing an easy to understand approach to developing business application software using agile techniques and concepts. Yet it still aims to remain true to the ideas behind the RUP.

Enterprise Unified Process
The Enterprise Unified Process (EUP) is yet another software engineering methodology, created by Scott Ambler. It is an extension of the Rational Unified Process, adding several new phases and disciplines to a process that was already quite big in the first place.

Crystal
Crystal is a software engineering methodology family, created by Alistair Cockburn. It is called a self-adapting family of human-powered software development methods, of which Crystal Clear is its most prominent member (being the only one with a Wiki entry and its own book).

Evo
Evo is a project management methodology, created by Tom Gilb. Even though Evo is one of the older (and least-known) methodologies, according to some critics it has proven to be one of the most successful evolutionary methods available.

And that's it. I'm sure lots of people will not agree with some of my terminology, classifications or descriptions. And that's good! I love to learn and improve my thinking. So please feel free to add your thoughts...

 转发自: http://www.noop.nl/2008/07/the-definitive-list-of-software-development-methodologies.html