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

画流程图是程序设计的基本功，但又似乎属于各有各的高招的一个领域。那么到底用什么标准评价流程图的好坏呢？从事用户体验设计咨询的丁宇在博客上分享了他“画Web流程图的一点心得” 。除了给出他自己的一套形状，还逐一说明注意事项，很有爱心：

作为整张流程图的头和尾，必须标清楚到底具体指哪个页面，以免日后出现歧义。
[……]
所有从形状出来的线条，都具有和此形状边框一样的颜色。这样的做法不仅看起来漂亮，在复杂的流程图中还能轻易地标明各形状的关系。
[……]
几乎总是让‘是’的分支往下流动，让‘否’的分支向右流动。因为流程图一般都是从上向下、从左到右绘制的，遵循上述规则一方面可以让绘制者不用为选择方向操心，另一方面也方便了读者阅读。
[……]
并非所有后台动作都绘入流程图中（否则流程图就会变成庞然大物了），只有需要特别强调的后台动作（和用户体验直接相关的）才使用此形状。
[……]
可以利用跳转点来分割篇幅巨大的流程图
[……]
分割篇幅巨大的流程图，更好的办法是用子流程。
[……]

在团队合作中，图例是必须的，否则没人知道你画出来的东西到底是什么。

除了确保别人能看懂你的流程图，评价流程图的好坏，还要谨记“流程图是要指导UI设计的，是UI设计的参照物”，必须“覆盖了各种可能的情况和细节”，“考虑到系统的设计和承受能力”。

支付宝交互设计师Joycce总结得更加扼要：

1. 简单易懂
2. 表达正确全面，有重点、有细节
3. 形像生动

丁宇也发起了一个征集活动，邀请大家一起分享自己的心得，各位达人请不吝赐教，InfoQ中文站将继续跟踪报道。

如果想了解流程图的一般用法，Arky Tan翻译了Jesse James Garrett撰写的“描述信息结构和交互设计的图示词汇表 ”。顺便一提，流程图这东西是有标准的，在发明自己的一套图形之前，不妨先翻一下ISO 5807:1985 。