Tag Archives: Agile

[repost ]Agile software development

original:http://en.wikipedia.org/wiki/Agile_software_development

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight interactions throughout the development cycle.

The Agile Manifesto[1] introduced the term in 2001. Since then, the Agile Movement, with all its values, principles, methods, practices, tools, champions and practitioners, philosophies and cultures, has significantly changed the landscape of the modern software engineering and commercial software development in the Internet era.

 

 

History[edit]

Predecessors[edit]

Martin Fowler, widely recognized as one of the key founders of the agile methods.

Incremental software development methods have been traced back to 1957.[2] In 1974, a paper by E. A. Edmonds introduced an adaptive software development process.[3] Concurrently and independently the same methods were developed and deployed by the New York Telephone Company’s Systems Development Center under the direction of Dan Gielan. In the early 1970s, Tom Gilb started publishing the concepts of Evolutionary Project Management (EVO), which has evolved into Competitive Engineering.[4] During the mid to late 1970s Gielan lectured extensively throughout the U.S. on this methodology, its practices, and its benefits.

So-called lightweight agile software development methods evolved in the mid-1990s as a reaction against the heavyweight waterfall-oriented methods, which were characterized by their critics as being heavily regulated, regimented, micromanaged and overly incremental approaches to development.

Proponents of lightweight agile methods contend that they are a return to development practices that were present early in the history of software development.[2]

Early implementations of agile methods include Rational Unified Process (1994), Scrum (1995), Crystal ClearExtreme Programming (1996), Adaptive Software DevelopmentFeature Driven Development (1997), and Dynamic Systems Development Method (DSDM) (1995). These are now collectively referred to as agile methodologies, after the Agile Manifesto was published in 2001.[5]

The Agile Manifesto[edit]

In February 2001, 17 software developers (see below) met at the Snowbird, Utah resort, to discuss lightweight development methods. They published the Manifesto for Agile Software Development[1] to define the approach now known as agile software development. Some of the manifesto’s authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto’s values and principles.

Agile values[edit]

The Agile Manifesto reads, in its entirety, as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.[1]

Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick

© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

The meanings of the manifesto items on the left within the agile software development context are:

  • Individuals and interactions – in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
  • Working software – working software will be more useful and welcome than just presenting documents to clients in meetings.
  • Customer collaboration – requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
  • Responding to change – agile development is focused on quick responses to change and continuous development.[6]

Introducing the manifesto on behalf of the Agile Alliance, Jim Highsmith commented that the Agile movement was not opposed to methodology:

The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker.

—Jim Highsmith, History: The Agile Manifesto[7]

Agile principles[edit]

The Agile Manifesto is based on twelve principles:[8]

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Working software is the principal measure of progress
  5. Sustainable development, able to maintain a constant pace
  6. Close, daily cooperation between business people and developers
  7. Face-to-face conversation is the best form of communication (co-location)
  8. Projects are built around motivated individuals, who should be trusted
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances

Evolutions[edit]

Later, Ken Schwaber with others founded the Scrum Alliance and created the Certified Scrum Master programs and its derivatives. Ken left the Scrum Alliance in the fall of 2009, and founded Scrum.org to further improve the quality and effectiveness of Scrum.

In 2005, a group headed by Alistair Cockburn and Jim Highsmith wrote an addendum of project management principles, the Declaration of Interdependence,[9] to guide software project management according to agile development methods.

In 2009, a movement spearheaded by Robert C Martin wrote an extension of software development principles, the Software Craftsmanship Manifesto, to guide agile software development according to professional conduct and mastery.

Overview[edit]

This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (December 2012)

Pair programming, an agile development technique used by XP. Note information radiators in the background.

There are many specific agile development methods. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Iterative, incremental and evolutionary

Agile methods break tasks into small increments with minimal planning and do not directly involve long-term planning. Iterations are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a cross-functional team working in all functions: planning, requirements analysisdesigncodingunit testing, and acceptance testing. At the end of the iteration a working product is demonstrated to stakeholders. This minimizes overall risk and allows the project to adapt to changes quickly. An iteration might not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[10] Multiple iterations might be required to release a product or new features.

Efficient and face-to-face communication

No matter what development disciplines are required, each agile team will contain a customer representative, e.g. Product Owner in Scrum. This person is appointed by stakeholders to act on their behalf[11] and makes a personal commitment to being available for developers to answer mid-iteration questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment (ROI) and ensuring alignment with customer needs and company goals.

In agile software development, an information radiator is a (normally large) physical display located prominently in an office, where passers-by can see it. It presents an up-to-date summary of the status of a software project or other product.[12][13] The name was coined by Alistair Cockburn, and described in his 2002 book Agile Software Development.[13] A build light indicator may be used to inform a team about the current status of their project.

Very short feedback loop and adaptation cycle

A common characteristic of agile development are daily status meetings or “stand-ups”, e.g. Daily Scrum (Meeting). In a brief session, team members report to each other what they did the previous day, what they intend to do today, and what their roadblocks are.

Quality focus

Specific tools and techniques, such as continuous integration, automated unit testingpair programmingtest-driven developmentdesign patternsdomain-driven designcode refactoring and other techniques are often used to improve quality and enhance project agility.

Philosophy[edit]

Comparing with traditional software engineering, agile development is mainly targeted at complex systems and projects with dynamic, undeterministic and non-linear characteristics, where accurate estimates, stable plans and predictions are often hard to get in early stages, and big up-front designs and arrangements will probably cause a lot of waste, i.e. not economically sound. These basic arguments and precious industry experiences learned from years of successes and failures have helped shaping Agile’s favor of adaptive, iterative and evolutionary development.[14]

Adaptive vs. Predictive[edit]

Development methods exist on a continuum from adaptive to predictive.[15] Agile methods lie on the adaptive side of this continuum. One key of adaptive development methods is a “Rolling Wave” approach to schedule planning, which identifies milestones but leaves flexibility in the path to reach them, and also allows for the milestones themselves to change.[16] Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team cannot report exactly what tasks they will do next week, but only which features they plan for next month. When asked about a release six months from now, an adaptive team might be able to report only the mission statement for the release, or a statement of expected value vs. cost.

Predictive methods, in contrast, focus on analysing and planning the future in detail and cater for known risks. In the extremes, a predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive methods rely on effective early phase analysis and if this goes very wrong, the project may have difficulty changing direction. Predictive teams will often institute a Change Control Board to ensure that only the most valuable changes are considered.

Risk analysis can be used to choose between adaptive (agile or value-driven) and predictive (plan-driven) methods.[17] Barry Boehm and Richard Turner suggest that each side of the continuum has its own home ground, as follows:[18]

Home grounds of different development methods
Agile methods Plan-driven methods Formal methods
Low criticality High criticality Extreme criticality
Senior developers Junior developers(?) Senior developers
Requirements change often Requirements do not change often Limited requirements, limited features see Wirth’s law
Small number of developers Large number of developers Requirements that can be modeled
Culture that responds to change Culture that demands order Extreme quality

Iterative vs. Waterfall[edit]

One of the differences between agile and waterfall is that testing of the software is conducted at different stages during the software development lifecycle. In the Waterfall model, there is always a separate testing phase near the completion of an implementation phase. However, in Agile and especially Extreme programming, testing is usually done concurrently with coding, or at least, testing jobs start in early iterations.

Code vs. Documentation[edit]

In a letter to IEEE Computer, Steven Rakitin expressed cynicism about agile development, calling an article supporting agile software development “yet another attempt to undermine the discipline of software engineering” and translating “Working software over comprehensive documentation” as “We want to spend all our time coding. Remember, real programmers don’t write documentation.”[19]

This is disputed by proponents of Agile software development, who state that developers should write documentation if that’s the best way to achieve the relevant goals, but that there are often better ways to achieve those goals than writing static documentation.[20] Scott Ambler states that documentation should be “Just Barely Good Enough” (JBGE),[21] that too much or comprehensive documentation would usually cause waste, and developers rarely trust detailed documentation because it’s usually out of sync with codes,[20] while too little documentation may also cause problems for maintenance, communication, learning and knowledge sharing. Alistair Cockburn wrote of the Crystal method:

Crystal considers development to be a series of co-operative games, and the provision of documentation is intended to be enough to help the next win at the next game. The work products for Crystal include use cases, risk list, iteration plan, core domain models, and design notes to inform on choices…however there are no templates for these documents and descriptions are necessarily vague, but the objective is clear, just enough documentation for the next game. I always tend to characterize this to my team as: what would you want to know if you joined the team tomorrow.[22]

—Alistair Cockburn[attribution verification needed]

Agile methods[edit]

Well-known agile software development methods and/or process frameworks include:

Software development life-cycle support[23]

The agile methods are focused on different aspects of the Software development life cycle. Some focus on the practices (e.g. XP, Pragmatic Programming, Agile Modeling), while others focus on managing the software projects (e.g. Scrum). Yet, there are approaches providing full coverage over the development life cycle (e.g. DSDM, IBM RUP), while most of them are suitable from the requirements specification phase on (FDD, for example). Thus, there is a clear difference between the various agile methods in this regard.[23]

Agile practices[edit]

Agile development is supported by a bundle of concrete practices suggested by the agile methods, covering areas like requirements, design, modeling, coding, testing, project management, process, quality, etc. Some notable agile practices include:

The Agile Alliance has provided a comprehensive online collection with a map guide to the applying agile practices.[24]

Method tailoring[edit]

In the literature, different terms refer to the notion of method adaptation, including ‘method tailoring’, ‘method fragment adaptation’ and ‘situational method engineering’. Method tailoring is defined as:

A process or capability in which human agents determine a system development approach for a specific project situation through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments.[25]

Potentially, almost all agile methods are suitable for method tailoring. Even the DSDM method is being used for this purpose and has been successfully tailored in a CMM context.[26] Situation-appropriateness can be considered as a distinguishing characteristic between agile methods and traditional software development methods, with the latter being relatively much more rigid and prescriptive. The practical implication is that agile methods allow project teams to adapt working practices according to the needs of individual projects. Practices are concrete activities and products that are part of a method framework. At a more extreme level, the philosophy behind the method, consisting of a number of principles, could be adapted (Aydin, 2004).[25]

Extreme Programming (XP) makes the need for method adaptation explicit. One of the fundamental ideas of XP is that no one process fits every project, but rather that practices should be tailored to the needs of individual projects. Partial adoption of XP practices, as suggested by Beck, has been reported on several occasions.[23] Mehdi Mirakhorli proposes a tailoring practice that provides a sufficient road-map and guidelines for adapting all the practices. RDP Practice is designed for customizing XP. This practice, first proposed as a long research paper in the APSO workshop at the ICSE 2008 conference, is currently the only proposed and applicable method for customizing XP. Although it is specifically a solution for XP, this practice has the capability of extending to other methodologies. At first glance, this practice seems to be in the category of static method adaptation but experiences with RDP Practice says that it can be treated like dynamic method adaptation. The distinction between static method adaptation and dynamic method adaptation is subtle.[27]

Comparison with other methods[edit]

This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (August 2010)

RAD

Agile methods have much in common with the Rapid Application Development techniques from the 1980/90s as espoused by James Martin and others.[citation needed] In addition to technology-focused methods, customer-and-design-centered methods, such as Visualization-Driven Rapid Prototyping developed by Brian Willison, work to engage customers and end users to facilitate agile software development.[citation needed]

CMMI

In 2008 the Software Engineering Institute (SEI) published the technical report “CMMI or Agile: Why Not Embrace Both”[28] to make clear that the Capability Maturity Model Integration and Agile can co-exist. Modern CMMI-compatible development processes are also iterative. The CMMI Version 1.3 includes tips for implementing Agile and CMMI process improvement together.[29]

Measuring agility[edit]

While agility can be seen as a means to an end, a number of approaches have been proposed to quantify agility. Agility Index Measurements (AIM)[30] score projects against a number of agility factors to achieve a total. The similarly named Agility Measurement Index,[31] scores developments against five dimensions of a software project (duration, risk, novelty, effort, and interaction). Other techniques are based on measurable goals.[32] Another study using fuzzy mathematics[33] has suggested that project velocity can be used as a metric of agility. There are agile self-assessments to determine whether a team is using agile practices (Nokia test,[34] Karlskrona test,[35] 42 points test[36]).

While such approaches have been proposed to measure agility, the practical application of such metrics is still debated. There is agile software development ROI data available from the CSIAC ROI Dashboard.[37]

Experience and adoption[edit]

[hide]This section has multiple issues. Please help improve it or discuss these issues on the talk page.
This article is in a list format that may be better presented using prose. (November 2013)
This section may require cleanup to meet Wikipedia’s quality standards. The specific problem is: too many reference tags(November 2013)
This section requires expansion with: more information to reflect the status quo of the industry. (November 2013)

Surveys[edit]

One of the early studies reporting gains in quality, productivity, and business satisfaction by using Agile methods was a survey conducted by Shine Technologies from November 2002 to January 2003.[38] A similar survey conducted in 2006 by Scott Ambler, the Practice Leader for Agile Development with IBM Rational’s Methods Group reported similar benefits.[39] Others claim that agile development methods are still too young to require extensive academic proof of their success.[40]

Large-scale and distributed Agile[edit]

Large-scale agile software development remains an active research area.[41][42] Agile development has been widely seen as being more suitable for certain types of environment, including small teams of experts.[18][43]:157 Positive reception towards Agile methods has been observed in Embedded domain across Europe in recent years.[44]

Some things that may negatively impact the success of an agile project are:

  • Large-scale development efforts (>20 developers), though scaling strategies[42] and evidence of some large projects[45] have been described.
  • Distributed development efforts (non-colocated teams). Strategies have been described in Bridging the Distance[46] and Using an Agile Software Process with Offshore Development.[47]
  • Forcing an agile process on a development team.[48]
  • Mission-critical systems where failure is not an option at any cost (e.g. software for avionics).

The early successes, challenges and limitations encountered in the adoption of agile methods in a large organization have been documented.[49]

Agile offshore[edit]

In terms of outsourcing agile development, Michael Hackett, senior vice president of LogiGear Corporation has stated that “the offshore team … should have expertise, experience, good communication skills, inter-cultural understanding, trust and understanding between members and groups and with each other.”[50]

Criticism[edit]

Agile methodologies can be inefficient in large organizations and certain types of projects. Agile methods seem best for developmental and non-sequential projects. Many organizations believe that agile methodologies are too extreme and adopt a hybrid approach that mixes elements of agile and plan-driven approaches.[51]

The term “agile” has also been criticized as being a management fad that simply describes existing good practices under new jargon, promotes a “one size fits all” mindset towards development strategies, and wrongly emphasizes method over results.[52]

Alistair Cockburn organized a celebration of the 10th anniversary of the Agile Manifesto in Snowbird, Utah on February 12, 2011, gathering some 30+ people who’d been involved at the original meeting and since. A list of about 20elephants in the room (“undiscussable” agile topics/issues) were collected, including aspects: the alliances, failures and limitations of agile practices and context (possible causes: commercial interests, decontextualization, no obvious way to make progress based on failure, limited objective evidence, cognitive biases and reasoning fallacies), politics and culture.[53] As Philippe Kruchten wrote in the end:

The agile movement is in some ways a bit like a teenager: very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times cocky and arrogant. But I have no doubts that it will mature further, become more open to the outside world, more reflective, and also therefore more effective.

Applications Outside of Software Development[edit]

Agile methods have been extensively used for development of software products and some of them use certain characteristics of software, such as object technologies.[54] However, these techniques can be applied to the development of non-software products, such as computers, motor vehicles, medical devices, food, and clothing; see Flexible product development.

Agile development paradigms can be used in other areas of life such as raising children. Its success in child development might be founded on some basic management principles; communication, adaptation and awareness. Bruce Feiler has shown that the basic Agile Development paradigms can be applied to household management and raising children. In his TED Talk, “Agile programming — for your family”, these paradigms brought significant changes to his household environment, such as the kids doing dishes, taking out the trash, and decreasing his children’s emotional outbreaks which inadvertently increased their emotional stability. In some ways, agile development is more than a bunch of software development rules; but it can be something more simple and broad, like a problem solving guide.

[repost ]新方法学

original:http://www.uml.org.cn/softwareprocess/rjgc.12052003.htm

最近一次主要修改: 2003年4月

过去几年中兴起的敏捷型(agile〕(也被称之为“轻量型”,lightweight) 的软件开发方法,以矫正官僚繁琐过程、许可对过程进行自主调整为特征, 在软件业引起了极大的兴趣。在这篇文章里,我将探索敏捷型方法的合理性, 着重点并不是放在其“轻重”上,而是于它们的适应性(adaptive〕性质 和以人优先的理念。我在本文也简要介绍了一些敏捷型方法并给出了进一 步的参考材料。另外,我还提出了一些你在决定是否要走这条刚踏出来的 敏捷之路时需考虑的因素。

从无、到繁重、再到敏捷

多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改” (code and fix〕。设计过程充斥着短期的、即时的决定,而无完整的规划。 这种模式对小系统开发其实很管用,但是当系统变得越大越复杂时,要想加 入新的功能就越来越困难。同时错误故障越来越多,越来越难于排除。一个典 型的标志就是当系统功能完成后有一个很长的测试阶段,有时甚至有遥遥无期 之感,从而对项目的完成产生严重的影响。

我们使用这种开发模式已有很长时间了,不过我们实际上也有另外一种选择, 那就是“正规方法”(methodology〕。这些方法对开发过程有着严格而详 尽的规定,以期使软件开发更有可预设性并提高效率,这种思路是借鉴了其他 工程领域的实践 - 因此我把它们称为工程方法(engineering methodologies)

工程方法已存在了很长时间了,但是没有取得令人瞩目的成功,甚至就 没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐, 要是按照它的要求来,那有做太多的事情需要做,而延缓整个开发进程。

作为对这些方法的反叛,在过去几年中出现了一类新方法。它们在一段时间里 被称为“轻量型”(lightweight)方法,但现在有了一个广为接受的的名称, 敏捷型方法(agile methodologies)。对许多人来说,这类方法 的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程 中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。

敏捷型与工程型方法有一些显著的区别。其中一个显而易见的不同反映在文档 上。敏捷型不是很面向文档,对于一项任务,它们通常只要求尽可能少的文档。 从许多方面来看,它们更象是“面向源码”(code-oriented〕。事实上,它们 认为最根本的文档应该是源码。

但是,我并不以为文档方面的特点是敏捷型方法的根本之点。文档减 少仅仅是个表象,它其实反映的是两个更深层的特点:

  • 敏捷型方法是“适应性”而非“预见性”。 工程方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划, 然后依计划进行开发。这类方法在一般情况下工作良好,但(需求、环境等) 有变化时就不太灵了。因此它们本质上是拒绝变化的。而敏捷型方法则欢迎 变化。其实,它们的目的就是成为适应变化的过程,甚至能允许改变自身来适 应变化。
  • 敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 工程型方法的目标是定义一个过程,不管是谁用都工作。而敏捷型方法 则认为没有任何过程能代替开发组的技能,过程起的作用是对开发组的 工作提供支持。

在以下各节中,我将详细地探讨这些差别,这样你可以了解适应性和 以人为中心的过程是什么,它们的好处与不足,以及你作为软件开发 人员或用户时是否应该使用它们。

预设性与适应性

将设计与建造分离开来

传统的软件开发正规方法的基本思路一般是从其他工程领域,如土木工程, 借鉴而来。这类工程实践中,在实际建造之前,通常非常强调设计规划。 工程师首先要画出一系列的图纸,这些图纸准确地说明了要建造什么以 及如何建造(包括部分和整体〕。许多设计决定,如怎样处理一座桥梁 的负荷,在画图纸时就会作出。然后,这些图纸分发给另外一组人员, 通常是另外一个公司,去建造。这种方式其实已假定了建造过 程将按图纸而来。当然,施工中也会碰到一些问题,但这些都是次要 的。

图纸其实就是一个详细的建造计划,它说明了一个项目中必须 完成的各个部分,以及如何把这些部分装配成整体。这样的计划可以 进一步定出需要完成的各项任务,以及这些任务之间的依赖关系。 这样,能较为合理地制订出生产进度表和项目预算。这种模式实际上 也规定了建造者如何做(施工〕,这也隐含着建造者不须是高智能型的, 尽管他们可能都有非常高超的手上功夫。

在此,我们看到的是两类非常不同的活动。设计是难于预见的,并且 需要昂贵的有创造性的人员,建造则要易于预设。我们有了设计之后, 便可对建造进行计划了。而有了建造计划后,我们进行建造则可以是非常可 预见性的了。在土木工程中,建造不论在经费上还是在时间上的成本都要比 设计和计划大得多。

所以,软件工程方法的途径是象这样的:我们想要可预见的生产进度计划, 以便能使用技能较低的人员。要达到这一点,我们必须得把设计与建造分离 开来。因此,在软件开发中,我们得想法作出这样的设计,使得计划一经完 成,建造将会是直接而明确的。

那么,计划应该采用什么形式呢?对许多人来说,这是设计“标识符号” (notation〕,如象 UML 需承担的角色了。如果我们能用UML作出所有主要的技术决定,那么就可以 用UML来做建造计划,然后把计划交给程序员去编码,即是建造活动。

但这里存在一个关键问题。你是否能作出这样的设计使得它能够让编码成为一项 建造活动?如果能,那么这样干的成本上是否充分地小而使得这种途径值得 一用?

这提出了几个问题。 第一个问题是到底有多困难能使一个用类似UML作出的设计达到交给程序员 就能直接编码的状态。用象UML那样的语言作出的设计在纸上看起来非常 漂亮,而实际编程时可能会发现严重的缺陷。土木工程师使用的模型是基于 多年的工程实践,并结晶在工程典章中。更进一步来说,一些设计上的关键 部分,如应力作用,都是建立于坚实的数学分析之上。而在软件设计中,我们 对UML图纸所能做的只是请专家同行审阅。这当然是很有帮助的,但是往往一些 设计错误只能在编码和测试时才能发现。甚至于熟练的设计者,我自认为我 属此列,就常常对在把设计变成软件的过程中出现的错误感到意外。

另一个问题是费用比较。建一座桥梁时,设计费用一般占整个工程的10%, 左右,余下的90%左右为施工建造费用。而在软件开发中,编码所占的时间 一般要少得多。 McConnell 指出在大型项目中,编码和单元测试只占15%,这几乎和桥梁工程中的比例倒 过来了。即使把所有测试工作都算作是建造的一部分,设计仍要占到50%。 这就提出了一个重要问题,那就是和其他过程领域的设计相比,软件设计到底 是什么性质。

这些问题导致了Jack Reeves 提出 源码也应是设计文档,而建造应该是编译和链接。的确,任何你认为属于建造的工作 都应当是自动化的。

这些讨论导致了下面一些重要结论:

  • 在软件开发中,具体建造费用非常低,几可忽略不计。
  • 软件开发中所有工作是设计,因此需要富有创造性的才智之士。
  • 创造性的过程是不太容易计划的,因此,可预见性是个不可能达到的目标。
  • 我们应该对用传统工程模式来进行软件开发的做法保持足够的警觉,因为它们 是不同类型的活动,因此需要不同的过程。

需求的不可预见性

在每个我参加的问题项目都有这样一种情况,开发人员跑来抱怨说, “这个项目的问题是需求老是在变”。而让我意外的是每个人都 对此感到意外。其实在建造商用软件系统中,需求变更是常态, 问题是我们如何来处理它。

一种方法是把需求变更看成是因需求工程(requirements engineering〕 没作好而导致的结果。一般来说,需求工程(或曰进行需求分析〕是要在 着手建造软件之前,获取一幅已完全理解了的待建系统的画面,然后取得客户 认可签发,并且还要建立一套规章来限制需求变更。

该方法的一个问题是要准确获取所有需求是困难的,特别是当开发商 不能提供某些需求的费用信息时。例如,你买车时想在你的车上装一个天窗, 而推销员却不能告诉你要在车价上只再加10元钱呢,还是10000元。如果不知道 这点,你如何能决定你是否愿意花钱在车上加个天窗呢。

作软件开发的费用估算是不容易的,这有多种原因。部分原因是因为软件 开发是一种设计活动,因此难于精确计划。部分原因是系统的“基本材料”变化 非常之快。部分原因是开发活动极大地依赖于项目参与人员,而个体是难于 预测和量化的。

软件的“不可触摸”性也是一个原因。在系统建成之前,有时很难判断一项 功能的具体价值。也就是说,只有当你在实实在在地使用系统时,你才能 知道哪些功能是有用的,哪些没什么用。

这样的结果颇具讽刺意味,即人们期待需求应该是可变的。毕竟,软件应该是 “软”的。所以,需求不仅是可变的,简直就是应该变的。要让客户把需求固 定下来要花很大的力气,特别是当他们“参与”了软件开发并且“知道”软 件是多么易于修改。

但是,即使你能把所有的需求都固定下来,并不意味着你的开发就是阳光灿烂 了,你可能仍然会在昏暗之中。在当今的经济形势下,决定并推动软件系统功 能特性的商业因素飞快地变化着。现在一组很好的功能六个月以后可能就不那 么好了。 商业世界并不会因你的系统的需求固定下来了而停止不动,商业世界的许多变化是 完全不可预测的。如果有人不承认这一点,要么他在撒谎,要么他已炒股成了 百万富翁了。

软件开发的一切都取决于系统需求,如果需求不固定,你就不能制订出一个可 预见性的计划。

预见性是不可能的吗?

一般来说,不可能。当然,有一些软件开发项目中,预见性是可能的。象 NASA的航天飞机的软件开发项目,应是这样一个例子。它需要大量的会议、 充足的时间、庞大的团队、以及稳定的需求。毕竟,这些是航天飞机的项目。 但我并不认为一般的商用软件开发属于这类系统,所以你需要不同的开发 过程。

如果你不能遵循一个可预见性方法,而你强装能够,那么这是非常危险的。通常, 一个正规方法的创造者不是很善于(或乐于〕给出其方法的边界条件,换句话 说,当这些边界条件不满足时,则该方法就不适用。许多方法学者希望他们的 方法能够放之四海而皆准,所以他们既不去了解,也不公布他们方法的边界条 件。这导致了人们在错误的情形下来使用一种方法,例如,在不可预见性的环 境中使用一种预见性的方法。

使用预见性方法具有强烈的诱惑力,因为预见性毕竟是一个非常需要的特性。 可是,当你不能达到预见性时而你相信你能够,这将会导致这样一种局面:你 可以很早就制订出计划,但不能适当地处理计划崩溃的情形。你看见现实与 计划慢慢地偏离,而你可以在很长的时间里,装着认为计划仍是有效可行的。 但是当偏离积累到足够的时候,你的计划就崩溃了,这通常是很痛苦的。

所以说,在不可预见性的环境中是不能使用预见性方法的。认识到这点是 一个很大的冲击。它意味着我们用的许多控制项目的模式,许多处理客户 关系的模式,都不会再是正确的了。预见性的确有非常多的好处,我们 很难就放弃预见性而失去这些益处。象很多问题一样,最困难的一点是 认识到这些问题的存在。

可是,放弃预见性并不意味着回到不可控制的一片混乱之中。你所需要的 是另一类过程,它们可以让你对不可预设性进行控制,这就是“适应性” 的作用了。

不可预见过程的控制 - 迭代

那么,我们如何对付一个不可预测的世界呢?最重要,也是最困难的是要随时 知道我们在开发中的情形处境,这需要一个诚实的反馈机制来不断准确地告诉 我们。

这种机制的关键之点是“迭代式”(iterative〕开发方法。这并不是一个 新思路,迭代式开发方法已存在很久了,只是名称不同,如“递增式” (Incremental〕,“渐进式”(Evolutionary),“阶段式”(Staged〕, “螺旋式”(Spiral〕等等。迭代式开发的要点是经常不断地生产出最终 系统的工作版本,这些版本逐部地实现系统所需的功能。它们虽然功能 不全,但已实现的功能必须忠实于最终 系统的要求,它们必须是经过全面整合和测试的产品。

这样做的理由是:没有什么比一个整合了的、测试过的系统更能作为一个项目 扎扎实实的成果。文档可以隐藏所有的缺陷,未经测试的程序可能隐藏许多缺 陷。但当用户实实在在地坐在系统前来使用它时,所有的问题都会暴露出来。 这些问题可能是源码缺陷错误(bug〕,也有可能是对需求理解有误。

虽然迭代式开发也可用于可见性环境,但它基本上还是用作“适应性” (adaptive〕过程,因为适应性过程能及时地对付需求变更。需求变更使得长 期计划是不稳定的,一个稳定的计划只能是短期的,这通常是一个“迭代周 期”(iteration〕。迭代式开发能让每个迭代周期为下面的开发计划提供 一个坚实的基础。

迭代式开发的一个重要问题是一个迭代周期需要多长。不同的人有不同的答案, XP(极限编程〕建议一到三周,SCRUM建议一个月,Crystal(水晶系列〕 更长一些。不过,一般的趋势是让每一个周期尽可能地短。这样你就能得 到频繁的反馈,能不断地知道你所处的状况。

适应性的客户

这类适应性过程需要与客户建立一种新型的关系,特别是当开发是由一家签约公 司来进行的时候。因为当雇佣一家签约公司来进行开发时,多数客户愿意订一 个固定价格的合同。他们告诉开发方他们所需要的功能,招标,签约,然后剩下 的便是开发方去建造系统了。

固定价格合同需要稳定的需求,即一个可预见性过程。适应性过程和不稳定的需 求意味着你不能做这种固定价格的合同。把一个固定价格模式弄到适应性过程 将导致一个痛苦的结局。最糟糕的是客户将与软件开发者受到同样的伤害,毕 竟客户不会想要一个不需要软件。即使他们未付开发方一分钱,他们仍然失去 许多。的确,他们失去的比要付给开发商的要多(他们凭什么付这笔钱,如果 这个软件的商业价值很小?)

因此,在可预见性过程不能用的情况下,签订固定价格合同对双方来说都有危 险。这意味着客户须换一种工作方式。

这并不是说,你不能为你的软件固定一笔预算。这实际意味着你不能固定时间、 价格和范围(scope)。通常一个敏捷方法是固定时间和价格,而让范围能够 可控制地变化。

在适应性过程中,客户实际上能够对软件开发过程进行很深入细微的控制。在 每一个迭代阶段中,他们都能检查开发进度,也能变更软件开发方向。这导致 了与软件开发者更密切的关系,或曰真正的商业伙伴关系。但并不是每一个客户, 也并不是每一个开发商都准备接受这种程度的介入,不过如要让适应性过程能 很好工作,这种合作程度是基本的要求。

这种开发方式可以给客户带来很多的益处。首先,这种开发的“回应性” (responsive)很好的。一个可用的,尽管是很小的系统能够尽早投入使用。 客户可以根据实际使用情况,以及变更了的需求,来及时改变一些系统功能。

这样一种方式能够更真实地反映出项目的实际状态。可预见性过程的问题是: 项目的质量是根据与计划的一致性来衡量的。当实际情况与计划脱节时,人们 很难提出来。一般的结果是在项目的后期出现进度上的大滑坡。 在敏捷型的项目中,每一个周期都对计划进行评审。如果有什么糟糕的事情 的话,它也会早点被发现,因此仍然会有时间来解决。的确,这种风险控制 是迭代式开发的一个关键优点。而敏捷型开发更进了一步,因为它的周期很 短,同时它也把这些变化看作是机会。

这点对于定义什么是成功项目有重要的意义。预见性项目是否成功是由它是否 很好地按计划执行来衡量的。一个项目如果在规定的时间和预算内完成,那 就是成功的。对于敏捷型环境而言,这种衡量是没有意义的。对于敏捷型 项目实践者来说,最重要的是商业价值(business value)- 客户得到的 软件的价值是否大于他们的投入。一个好的预见性项目是依计划而行,而一个 好的敏捷型项目会建造出一个与最初计划不太一样却是更好的软件。

把人放在第一位

实施一个适应性过程并不容易,特别是它要求一组高效的开发人员。高效既 体现在高素质的个体,也体现在有能让团队协调一致的工作方式。这里有一 个有趣的和谐:并非只是适应性过程需要强的团队,多数优秀的开发人 员也愿意采用适应性过程。

可兼容性程序插件

传统正规方法的目标之一是发展出这样一种过程,使得一个项目的参与人员 成为可替代的部件。这样的一种过程将人看成是一种资源,他们具有不同的 角色,如一个分析员,一些程序员,测试员及一个管理人员。个体是不重要的, 只有角色才是重要的。这样一来,在你计划一个项目时,你并不在乎你能得到哪个分 析员,哪些测试员,你只需关心你可得到多少,知道资源数量会如何影响你 的计划。

但这有一个关键问题:参与软件开发的人员是可替代的部件吗?敏捷型方法 的一个重要特征就是拒绝这种观点。

也许最明确地反对这种观点的当数Alistair Cockburn. 在他的论文 “软件开发中人是非线性,一阶的部件”中,他指出可预见性软件开发过程要求 “部件”的行为也是可预见性的。 但是,人并非可预见性的部件。更进一步,他对软件项目的研究导致了如下结论: 人是软件开发中最重要的因素。

在本文的标题里,我将人称为“部件”。(传统〕过程/方法就是这样看待 人的。这种观点的错误在于没有看到“人”是非常可变的和非线性的, 不同的个体具备特有的成功或失败模式。那些因素是一阶的,不可忽略的。 一种过程或方法的设计者如不能充分考虑到这些因素,那麽其后果就是项目 的无计划轨迹。就象我们经常看到的那样。
— [Cockburn non-linear]

Cockburn是最鲜明地主张在软件开发中应以人为中心,其实这种概念在许多软 件行业的有识人士中已是共识。问题在于所使用的方法是与这种理念背道 而驰的。

这造成了一个很强的正反馈机制。如果你期望你的开发人员是可互替 的编程插件,则你不会去试着把他们看成是不同的个体。这会降低士气(和生 产率〕,并使优秀的人才跳到一个能发挥其个性特长的地方,最后你倒是得到 你所需要的:可互替的编程插件。

作出使人优先的决定是件大事,它需要很大的决心来推行。把人作为资源的思想 在工商界是根深蒂固的,其根源可追溯到 泰勒的“科学管理”方法。当管理一个 工厂时,这种泰勒主义途径是有效的。但是对有着高度创造性和专业性的工作, 我相信软件开发当属此类,泰勒主义并不适用(事实上现代制造业也在脱离 泰勒主义模式〕。

程序员是负责任的专业人员

泰勒主义的一个关键的理念是认为干活的人并非是那些 知道怎样才能把这件活干的好的人。在工厂中可能是这样,原因是许多工厂里 的普通工人并非是最具聪明才智和最富创造力的人员。另一个原因也许是由于 管理层和工人的的工资悬殊太大而导致的关系紧张。

历史证明这种情形在软件开发中是不存在的。不断有优秀人才被吸引到软件行 业中,吸引他们的既有耀眼的光芒也有丰厚的回报(正是这两样诱使我离开电子 工程〕。其他一些福利如对公司的股份持有使得程序员的利益与公司紧联在一 起。

〔可能还有一个“产生”(generational)效应。一些所见所闻让我想 到是否在过去十来年中有很多的优秀人才转入软件行业。如果是这样,这可能 是当今年轻人崇尚IT业的原因,就象其他时尚一样,其后总有一些实在 的理由。〕

如果你想聘到并留住优秀人才,你得认识到他们是有能力的专业人员。因此, 他们最有资格决定如何干好他们的技术工作。泰勒主义让计划部门来决定如 何干好一件工作的作法只有当计划者比实际操作者更能知道怎样作时才有效。 如果你拥有优秀的、自觉自励的员工,那么这点并不成立。

面向人的过程的管理

敏捷型过程中“以人为本”的理念可以有不同的表现,这会导致不同的效果, 而并非所有结果都是完全一致的。

实施敏捷型过程的一个关键之处是让大家接受一个过程而非强加一个过程。 通常软件开发的的过程是由 管理人员决定的,因此这样的过程经常受到抵制,特别是如果管理人员已脱离 实际的开发活动很长时间了。而接受一个过程需要一种“自愿致力” (commitment),这样大家就能以积极的态度参与进来。

这样导致了一个有趣的结果,即只有开发人员他们自己才能选择并遵循一个适 应性过程。这一点在XP中特别明显,因为这需要很强的自律性来运行这个过程。 作为一个互补,Crystal(水晶系列〕过程则只要求最少的自律。

另一点是开发人员必须有权作技术方面的所有决定。XP非常强调这一点。 在前期计划中,它就说明只有开发人员才能估算干一件工作所需的时间。

对许多管理人员来说,这样形式的技术领导是一个极大的转变。这种途径要求 分担责任,即开发人员和管理人员在一个软件项目的领导方面有同等的地位。 注意我说的同等。管理人员仍然扮演着他们的角色,但需认识并尊重开发 人员的专业知识。

之所以强调开发人员的作用,一个重要的原因是IT行业的技术变化速度非常之快。 今天的新技术可能几 年后就过时了。这种情况完全不同于其他行业。即使管理层里的以前干技术的人 都要认识到进入管理层意味着他们的技术技能会很快消失。因此必须信任和依靠 当前的开发人员。

测度的困难性

如果有一个过程,规定工作应该如何来做的人不是具体去干的人,那么你需要一些 方法来测度干工作的人是否工作有效。在“科学管理”中,有种强烈的力量驱使着 发展出客观性方法来测度人们的工作输出。

这与软件特别有关,但是要测度软件是非常困难的。尽管人们已经尽了很大的努力, 我们仍然不能对软件的一些很简单方面进行测度,如生产率。如果没有一套有效的 测度方法,任何外部的控制都会是困难的(doomed)。

不存在一套有效的测度方法而要在管理中引入测度将会导致管理本身出问题。关于这点, Robert Austin有段出色的讨论。他指出,当进行测度时,你必须要获取影响这种 测度的所有重要因素。任何缺失都将不可避免地使得具体干工作的人改变 他们的工作方式以获得最好的测度成绩,甚至于那样会明显地降低他们真正的工作 有效性。这种测度的“失效”(dynsfunction)正是基于测度的管理方法的 致命之处(Achilles heel,即阿其里斯的脚踝)。

Austin的结论是你得在这两种方法中作选择:基于测度的管理,或是“委托式” (delegatory)管理(干工作的人决定该怎么干)。基于测度的管理是非常适合 简单的、重复性的工作,知识要求低并且易于测度输出 -- 这恰恰与软件开发 相反。

关键之处是传统方法假设的前提是基于测度的管理是最有效的管理方式。而 敏捷开发者则认为软件开发的特性会使得基于测度的管理导致非常高度的测度 “失效”(dysfunction)。实际上使用委托式的管理方式要有效得 多,这正是敏捷论者所持观点的中心所在。

业务专家的引领作用(The Role of Business Leadership〕

但技术人员并不能包打天下,他们需要应用系统的需求引导。这导致了适应性过程 的另一个重要方面:他们需要与应用领域的业务专家非常紧密的联系。

这种联系的紧密度超过了一般项目中业务人员的介入程度。如果开发人员和 业务人员只有偶尔的沟通,那么敏捷型过程是不可能存在的。他们需要不断地 获取业务方面的专门知识。此外,这种沟通不是由管理层来处理的,而是每个开发 人员需要做的事。因为开发人员在他们的行业里是有能力的专业人员,因此他们 能够与其他行业的专业人员同等地在一起工作。

这是由适应性过程的特点来决定的。因为敏捷开发的前提是在整个开发过程中, 事情变化很快,你需要经常不断的联系沟通以使每个人都能及时知道这些变化。

对开发人员来说,没有什么比看见自己的辛勤工作白白浪费更让人痛苦的了。 因此,开发人员能随时获取准确的高质量的应用系统的业务知识就显得很 重要了。

自适应过程

到目前为止,我谈到的适应性是指在一个开发项目中如何频繁地修改软件以适 应不断的需求变更。但是,还有另一种适应性,即是过程本身随着时间推移变 化。一个项目在开始时用一个适应性过程,不会到一年之后还在用这个过程。 随着时间的推移,开发团队会发现什么方式对他们的工作最好,然后改变过程 以适应之。

自适应的第一步是经常对过程进行总结检讨。一般来说,在每一次迭代结束后, 你可以问自己如下问题 〔 Norm Kerth〕:

  • 有哪些做的好的部分
  • 有哪些教训
  • 有哪些可以改进的部分
  • 有哪些没搞清楚的部分

这些问题会帮助你考虑在下一次迭代中如何对过程进行修正。在样,如果 开始时使用的过程有问题的话,随着项目的进行,该过程会得以逐步的完善, 以使其能更好地适合开发团队。

如果一个项目采用了自适应方法,则可以进一步在一个组织内引入这种方法。 如果要深化自适应过程,我建议开发人员专门用一段时间做一次更为正式的 回顾总结,象Norm Kerth所建议的那样,这些活动包括离开工作地点,到另外 一个地方,在一位有经验的专家主持下开2-3天的总结会。这不仅是给开发组 提供一次学习机会,同时也给整个组织一次学习机会。

自适应性导致的结果是你绝不能期待着只用一个过程。相反,每个项目组不仅 能选择他们自己的过程,并且还能随着项目的进行而调整所用的过程。公开 发表的过程和其他项目的经验都可以拿来作为参考和样本。但是开发人员需 根据手中项目的具体情况而对其加以调整,这也是开发人员的专业职责。

这种自适应性在ASD和Crystal(水晶系列〕中都鲜明地提及。XP的严格规则 似乎不允许这样,但这只是表面现象,因为XP是鼓励调整过程的。这一点上 XP和其他方法的主要区别之处在于,XP的倡导者建议在采用XP时,先根据书本 循规蹈矩不走样地做几个迭代之后,再考虑调整。另外,回顾总结这点在XP中 没有被强调,也不是这个过程的组成部分,尽管XP建议经常性的回顾应作为XP 的实践准则之一。

敏捷型方法

好几个方法都可以归入敏捷型旗下,它们有许多的共同特征,但也有一些重 要的不同之处。在此简短的综述中,我不可能列出这些过程所有的特点, 但至少我可以告诉你可以到什么地方去查找更详细的材料。这些方法的大多数 我都没有深入的实际经验。我有很多工作是基于XP的,也对RUP有些经验。 但是对其他方法来说,我的知识主要是来自书本(当然这是很不够的〕。

XP(Extreme Programming -- 极限编程〕

在所有的敏捷型方法中,XP是最为引人瞩目的。部分原因是因为XP的领军 人物们的卓越能力,特别是Kent Beck,他能够把人们吸引到这种方法来, 并一直处于领先地位。但是XP热也带来了一个问题,就是它把其他一些方法 和它们非常有价值的思想给挤了出去。

XP根源于Smalltalk圈子,特别是Kent Beck和Ward Cunningham在(19)80年代末的 密切合作。90年代初,他们在一系列项目上的实践深化扩展了他们关于软件 开发应是适应性的、应以人为中心思想。

从非正式的、探索性的实践到形成系统化的正规方法的关键一步是在1996年 春。Kent被邀对Chrysler的一个工资管理项目(C3〕的开发进度进行审核。 该项目由一个签约公司用Smalltalk开发,正处于困境之中。由于源码质量 低劣,Kent建议推倒重来。该项目然后在他的领导下从头开始并成了早期 XP的旗舰和培训基地。

C3的第一期系统在1997年初投入运行。项目继续进行了一段时间后,遇到 了麻烦,导致了在1999年开发计划被撤销。(这也证明了XP并不是成功的保证)

XP的四条基本价值原则是:交流,反馈,简洁和勇气。在此基础上建立了 十多条XP项目应遵循的实践准则。其实,许多准则是以前就存在的并经过实 践检验的,而常常被忽略了的。XP重新建立了这些准则,并把它们编织成 了一个和谐的整体,使得每一项准则都能在其他准则里得以强化。

XP有一个最具冲击力的,也是最初吸引我的特点,是它对测试的极端重视。 诚然,所有的过程都提到测试,但一般都不怎么强调。可是XP将测试作为 开发的基础,要求每个程序员写一段源码时都得写相应的测试码。这些测 试片段不断地积累并被整合到系统中。这样的过程会产生一个高度可靠的 建造平台,为进一步开发提供了良好的基础。

在此基础上XP建立了一个渐进型的开发过程,它依赖于每次迭代时对源码 的重整(refactoring〕。所有的设计都是围绕着当前这次迭代,而不管将 来的需求。这种设计过程的结果是“纪律性”与“适应性”的高度统一, 使得XP在适应性方法中成为发展的最好的一种方法。

XP产生了一批领军人物,许多是从C3项目中出来的。关于XP有许多文献可 读。Kent Beck写的 Extreme Programming Explained, 是一篇XP的宣言,它阐述了隐藏在XP后面的理念。此书对有心于XP并致 力于将其发扬光大者提供了充足的说明和解释。过去两年里也出版了一 批“多姿多彩”的XP书籍,但多数都很相似,主要是从一些XP早期的实 践者们的角度上描述了XP的整个过程。

除了书之外,还有不少网上资源。如果你想找到更有结构性的材 料,你最好访问两位C3成员的网站:Ron Jefferies的xProgramming.com 和Don Wells的 extremeProgramming.org。 许多XP早期的倡导和发展可在Ward Cunningham的 wiki web(合作写作〕中找到。wiki是个令人着迷的地方,尽 管它的漫游性质常令人身不由己地陷入其中。 XP讨论组〔xp discussion egroup〕也很有意思。 还有一篇很有意思的文章从(XP圈)“外面”来审视XP,这就是Mark Paulk所写的 从CMM的角度看XP。Mark Paulk是CMM的领军人物之一。

Cockburn的水晶系列方法

Alistair Cockburn 在90年代初受IBM之约进行正规方法的研究,从那时起他就活跃于这个领域。 但他的研究途径和其他方法学者有所不同。一般的方法 学者是将他们个人的经验升华成理论,而Cockburn除了归纳整理他自己的实 践经验以外,他还积极地造访其他项目,和项目组成员进行广泛的讨论, 考察这些项目是怎样运作的。难能可贵的是,他从不固守自己的观点, 他会根据新的发现而随时修正自己的理论。他的这些特点使得他成为我 最喜欢的方法学者。

他的著作 Surviving Object-Oriented Projects 汇集了很多如何顺利运行软件开发项目的建议,此书也是我推荐的运行迭代 式项目的首选书。最近,Alistair写了一本关于 敏捷型软件开发 的综述性著作,探讨了这些方法的基本原则。

Alistair还更进一步地探索了敏捷型方法,并提出了 水晶(Crystal〕 方法系列。 之所以是个系列,是因为他相信不同类型的项目需要不同的方 法。他认为决定一个方法与两个因素有关:项目参与人数和出错后果。如果用 两个坐标轴来分别表示这两个变量的话,那么在这张图上,每一种方法都 有其相应的坐标位置。例如,有两个项目,一个是有40人参加,如果失败造成 的资金损失可以接受;另一个项目只有6人,其成败生存悠关。那么这两个 项目所用的方法在坐标图上就有不同的位置。

水晶系列与XP一样,都有以人为中心的理念,但在实践上有所不同。Alistair 考虑到人们一般很难严格遵循一个纪律约束很强的过程,因此,与XP的高度 纪律性不同,Alistair探索了用最少纪律约束而仍能成功的方法,从而在产出 效率与易于运作上达到一种平衡。也就是说,虽然水晶系列不如XP那样的产 出效率,但会有更多的人能够接受并遵循它。

Alistair也费了不少笔墨强调每次迭代后的总结回顾,因而鼓励过程本身的 自我完善。他的理由是迭代式开发是用来尽早发现问题并解决之。这样就更 加强调了开发人员要随时观察他们所用的过程,并随着项目的进行而调整。

开放式源码

看到这个标题你可能会有些意外。毕竟,开放式源码(Open Source〕 是软件的一类风格,而非一种过程。这里我是指开放源码界所用的一种 运作方式,这种方式适用于开放源码项目,其实它的许多做法也可为封闭式源 码项目所用。开放式源码项目有一个特别之处,就是程序开发人员在地域上分 布很广。注意到这点相当重要,因为一般适应性过程都强调项目组成员在同一 地点工作。

多数开放源码项目有一个或多个源码维护者(maintainer〕。只有维护者 才能将新的或修改过的源码段并入源码库。其他众人可以修改源码,但需将他们 所做的改动送交给维护者,由维护者对这些改动进行审核并决定是否并入源码库。 通常来说,这些改动是以“补丁”(patch〕文件的形式,这样处理起来容易一些。 维护者负责协调这些改动并保持设计的一致性。

维护者的角色在不同的项目中有不同的产生和处理方式。有些项目只有一个 维护者,有些项目把整个系统分成若干个模块,每个模块有一个维护者。有 些是轮流做维护者,有些是同一个源码部分有多个维护者,有些则是这些方 式的组合。许多开放源码项目的参与者只是部分时间(或业余时间〕干,如 果项目要求是全日制的,那么这有一个问题,就是怎样才能把这些开发人员 有效地协调组织起来。

开放源码的一个突出特点就是查错排故(debug〕的高度并行性,因为许多 人都能同时参与查错排故。如果他们发现了错误,他们可将改正源码的 “补丁”文件发给维护者。这种查错排故角色对非维护者来说合适,对那 些设计能力不是很强的人来说,也是一项挺好的工作。

关于开放源码的方法过程还没有很系统的文献。目前最著名的一篇文章是 Eric Raymond写的 The Cathedral and the Bazaar(教堂与集市〕, 文章虽短,但很精彩。另外,Karl Fogel所著的 关于CVS的书中也有几章 描述了开放源码的方法。即使你不想使用CVS,这几章还是值得一看。

Highsmith的适应性软件开发方法(ASD--Adaptive Software Development)

Jim Highsmith 多年来一直从事可预见性方法的研究,建立和教学,而最后得出的 结论是这些方法都有着根本性的缺陷,特别是在用来作现代应用系统 的开发时。

他最近的 一本书 集中论述了新方法的适应特性,重点讨论了把一些起源于 复杂适应性系统(通常称之为混沌理论--chaos theory〕的思想在软件 开发中加以应用。此书没有象XP那样提供详尽的实践准则,但它从根本上 说明了为什么适应性开发方法是重要的,并进一步说明了其对组织结构和 管理层的影响。

ASD的核心是三个非线性的、重迭的开发阶段:猜测、合作与学习。

在一个适应性环境中,因为结果是不可预见的,Highsmith把计划看成是一个 “反论”〔paradox〕。在传统的计划中,偏离计划是错误,应予纠正。 而在一个适应性环境里,偏离计划则是在引导我们向正确的目标迈进。

在不可预见的环境里,你需要大家能以多种多样的方式合作来对付不确定性。 在管理上,其重点不在于告诉大家做什么,而是鼓励大家交流沟通,从而 使他们能自己提出创造性的解决方案。

在可预见性环境里,通常是不大鼓励学习的。设计师已经都设计好了,你跟 着走就行了。

在适应性环境中,学习对所有各方,包括开发人员和客户, 都是一个挑战。他们需要学习以检验他们作的假设,需要学 习以便能用每次开发周期的结果去适应下一个周期。
 [Highsmith]

这样的学习是连续不断的,这已成为这种方法的一个重要特点,因此我们 必须得认识到计划和设计都得随开发的推进而改变。

适应性开发周期的最强力的、不可分割的好处是其对我们自以为是的心理 模式的挑战,它迫使我们更实际地估计自己的能力。
 [Highsmith]

有了这样的出发点,Highsmith把他的工作集中放在适应性开发的难点上, 特别是如何在一个项目中增强合作和学习。基本上说,他的这本书 是侧重于“软”方法,这样对那些从开发实践中提炼出来的方法如XP,FDD 和水晶系列来说,这本书将是一个很有益的互补。

SCRUM

SCRUM在OO界里已很有些时日了,不过我得承认我对其历史发展并不是 太知其详。象前面所论及的方法一样,该方法强调这样一个事实,即明 确定义了的可重复的(defined and repeatable〕方法过程只限于在明 确定义了的可重复的环境中,为明确定义了的可重复的人员所用,去解决 明确定义了的可重复的问题。

SCRUM把一个项目分成若干个为期30天的迭代阶段,称之为一“冲” (sprint〕。开“冲”之前,你得明确这一“冲”要实现的功能,然后 交给开发组去完成。但是,在“冲”期间,需求必须是固定的。

管理人员并非在“冲”的时候就撒手不管了。每天,他需召集一个短会 (15分钟左右〕,称之为一个scrum,会上大家讨论决定第二天干什么。 特别是大家会对管理层提出那些阻碍项目进行的因素,并希望管理层能 予以解决。当然,他们也需要报告目前完成了什么,这样管理层每天都能 了然项目的进展情况。

SCRUM文献多集中论述迭代阶段计划与进度跟踪。它与其他敏捷型方法在 许多方面都很相似,特别是它可以与XP的编程准则很好地结合起来。

相当长的一段时间没有关于SCRUM的专门书籍,直到最近 Ken Schwaber和Mike Beedle写了 第一本SCRUM的专著。Ken Schwaber还 主持了一个网站 ControlChaos.com,可能是对SCRUM的最好的综述。Jeff Suthurland有个总是很活跃的网站讨论OO技术,其中有一部分是专门讨论SCRUM的。另外,在 PLoPD 4书中也有一篇关于SCRUM的很好的综述。 Scrum也有一个 Yahoo讨论组.

功用驱动开发方法(FDD--Feature Driven Development〕

FDD是由Jeff De Luca和OO大师Peter Coad提出来的。象其他方法一样, 它致力于短时的迭代阶段和可见可用的功能。在FDD中,一个迭代周期 一般是两周。

FDD有以下五项任务:

  • 建立总体模型
  • 提出功用清单
  • 针对功用逐项制订计划
  • 针对功用逐项进行设计
  • 针对功用逐项开发实现

头三项在项目开始时完成,后两项在每一次迭代周期时都要做。每一项 任务又可进一步分解并制订出相应的检验准则。

在FDD中,编程开发人员分成两类:首席程序员和“类”程序员(class owner〕。首席程序员是最富有经验的开发人员,他们负责开发实现 系统的各项功能。对每一项功能,首席程序员要定出需要哪些类(class〕 来实现这项功能,并召集“类”程序员们组成一个针对这项功能的开发 组。首席程序员作为协调者,设计者和指导者,而“类”程序员则主要 作源码编写。

关于FDD的文档资料比较少。直到最近终于有了一本全面 论述FDD的著作。FDD 的主要提出者Jeff De Luca现已建立了一个 FDD门户网站, 收录了一些文章、笔记和讨论。FDD的最早的论述见于Peter Coad等所著的 UML in Color 。他的公司 TogetherSoft也从事FDD的咨询和培训工作。

动态系统开发方法〔DSDM--Dynamic System Development Methods〕

DSDM在1994年始于英国。 英国一些想用RAD和迭代方式进行系统 开发的公司组成了一个社团〔Consortium〕。刚开始有17个组建成员, 到现在成员已超过1000个,遍布英国内外。DSDM由于是由一个社团所 发展,它与其他一些敏捷型方法有些不同。它有专门的组织支持, 有手册,培训课程,认证程序等。因为它 上面的价格标签而限制了我对此方法的进一步调查。不过Jenifer Stapleton已写了 一本书来介绍这种方法。

如果你要用这种方法,你得先作可行性和业务分析。可行性分析要考虑 DSDM是否适合手上这个项目。而业务分析则是开一系列的讨论会, 以期能充分了解应用域,同时也要提出大致的系统结构与项目计划。

余下的工作由三个互相交织的周期组成:功能模型周期产生文档和原型 (实验系统),设计建造周期生成可操作使用的系统,实现周期 处理系统安装部署(deployment〕问题。

DSDM有一些基本的原则包括与用户积极的交流,频繁的交付(delivery)。 有充分职权的项目组,完全的系统测试。象其他敏捷型方法一样, DSDM的一个周期在2-6周之间。它强调高质量的系统以及对需求变更的高 度适应性。

我还没有在英国之外的地方看到有项目使用DSDM。DSDM的基本结构有许多 成熟的传统方法的东西,同时又遵循了敏捷型途径。但这里的确有一点 值得注意,即是这种方法是否有鼓励一种面向过程与繁琐的倾向。

敏捷软件开发宣言

可以看出,前面所提到的这些方法有很多的相似之处,那么自然大家 就会有兴趣进行某种形式的合作。2001年2月,这些方法的代表人物们 被邀至犹它州Snowbird举行了一个为期两天的讨论会。我也身在其列, 但开始并未抱太大希望。毕竟,当你把一堆方法学者塞进一间房子时, 他们能以礼相待就是上上大吉了。

结果却出乎我的意料之外。每个与会者都认识到这些方法有许多的共同 点,这种共识远远大于他们之间的分歧。这次讨论会使这些一流的 方法学者们增进了联系,大家还有意发表一份联合声明--呼吁推动发展 轻灵型开发过程(我们也同意用“敏捷”(agile〕这个词来表达我们 共有的理念〕。

成果便是一份 敏捷软件开发宣言〔Manifesto for Agile Software Development〕, 它表述了敏捷型过程所共同具备的价值和原则。与会者也有意在将来进 一步合作,并鼓励方法学者与业务人士使用敏捷型方法进行软件开发。 Software Development Magazine〔软件开发杂志〕有一篇关于 宣言的评注与解释的文章。

当然,宣言只是一份发表的文件,是一个让有着共同理念的人们的聚集点。这个 努力的另一个成果是建立了一个 敏捷联盟。敏捷联盟是个 非盈利性组织,其宗旨是推广敏捷型方法的知识和促进这方面的讨论。许多 我已提到的敏捷方法的领军人物也都是这个联盟的成员和领导者。

相关环境驱动测试(Context Driven Testing)

敏捷开发运动最初是由软件开发人员来推动的。但是,参与软件开发的其他方面 的一些人士也受到这个运动的影响。一个明显的群体是测试人员,他们通常是生活 在由瀑布式开发所限定的世界里。一般来说,测试的作用是保证软件与开始的设计 相符合。而在敏捷世界里,测试人员的角色还很不清楚。

实际上,在测试圈内有好几位人士有相当一段时间一直在质疑这种主流的测试思维。 这导致了一个称之为“相关环境测试”(context driven testing)的群体。 对这个概念的最好的论述是 “Lessons Learned in Software Testing这本书。 这个圈子在Web上也很活跃,你可以去看看这几位的网站, Brian Marick(他也是敏捷宣言的作者之一), Brett PettichordJames Bach,和 Cem Kaner

RUP是一种敏捷型方法吗?

当我们开始讨论OO领域的方法时,不可避免地会碰到 RUP(Rational Unified Process〕。该过程由Philippe Kruchten, Ivar Jacobson以及Rational公司 的其他一些人士开发,主要是作为一个与UML相配合和补充的过程。RUP其实是 个过程的框架,它可以包容许多不同类型的过程,这一点正是我对RUP的主要 批评。因为它可以是任何东西,那么就跟什么都不是一样了。我愿意选择的 过程是它能明确告诉你干什么,而不是给你无穷无尽的选择。

由于RUP是一种框架,你可以以不同的方式来使用它,如象非常传统的“瀑布” 式开发方式,或敏捷式。你可以把它用得轻捷灵便,也可把它弄成繁文缛节。 这取决于你如何在你的环境中对它裁剪运用。

Craig Larman极力主张以敏捷方式来使用RUP。在他的关于OO开发的这本出色的 引论著作 中,他提出了一个过程,就是基于这种“轻型”RUP的思想。他的观点是: 目前如此众多的努力以推进敏捷型方法,只不过是在接受能被视为RUP 的主流OO开发方法而已。在做一个项目时,Craig要干的事情之一便是在为期 一月的迭代周期的头两三天和整个开发组呆在一起,用UML勾勒出这个迭代 阶段的设计。这个设计并非是一个不可更改的,它只是一个使大家能 知道这个阶段如何干的草图。

另一种对待RUP的策略是Robert Martin的 dX过程。dX过程是一个完全符合RUP 的过程,而又碰巧与XP完全等同(把dX转180度可见,一句戏言〕。dX是 特别适合于那些不得不用RUP而又想用XP的伙计们。由于dX既是XP又同时是 RUP,它可作为以敏捷方式运用RUP的一个极好的例子。

对我而言,在运用RUP时的一个关键之处在于业界RUP的领头者们需强调他们 的软件开发途径。曾经不止一次,我听到使用RUP的人是在使用“瀑布”式 开发过程。根据我在业界的联系,我知道Philippe Kruchten和他的小组是 坚定的迭代式开发信奉者。澄清这些原则并鼓励敏捷式使用RUP,如象Craig Robert的工作,将对软件开发有着重要的影响和作用。

其他参考材料

最近,有两本好书出版,分别由 Alistair Cockburn 和 Jim Highsmith所著,他们在书中广泛地讨论了敏捷开发的方方面面。

关于敏捷型方法有不少文章和讨论组,它们可能不会提供完整的方法,但可以 给你一个窗口以观察这个正兴起的领域在如何发展。

程序设计的模式语言(Patterns Language of Programming〕 大会经常会有一些 材料讨论这个题目,这也许是因为许多对模式(Pattern〕感兴趣者也对适应 型和“人道”方法过程感兴趣的缘故吧。这方面有一篇早期的一流论文, Jim Coplein所著,收集在 PLoP1中。Ward Cunningham的Episodes模式语言收集在 PLoP2 中。Jim Coplein现主持一个网站, OrgPatterns, 以wiki方式收集了不少组织结构模式。 Dirk Riehle在XP2000大会上提交了一篇论文,该文 比较了XP和适应性软件开发(Adaptive Software Development, ASD〕的 价值系统。Coad Letter的 七月期比较了XP和FDD。IEEE Software的七月期有几篇文章论述“过程多样性”(process diversity〕,也提及这些方法。

Mary Poppendieck写了一篇很精彩的文章 比较敏捷型方法与精悍(lean〕型制造业

你是否应走向敏捷?

并非人人都能使用敏捷型方法。当你决定走这条路时,你得记住许多准则。 但是,我确切相信,这些新方法可被广泛的应用。只是考虑使用它们远远 不够,应该有更多的人来实践中运用它们。

在目前的软件开发中,多数方法仍是边写边改(code and fix〕,那么,引入 一些纪律约束肯定会比一片混乱要好。敏捷型途径的主要优点在于它比重型 方法的步骤要少得多。如果你已习惯于无过程,那么遵循简单过程应该比遵循 繁琐过程更容易一些。

这些新方法的一个主要局限是如何对付较大的项目组。象其他许多新方法一样, 这些敏捷型方法也是愿意先在小规模上使用,而通常它们被提出来时的重心 也是放在小规模的项目组上。XP明确说明它适合于最多20人的项目组。这里 值得一提的是,许多软件项目组可以减少人数而不会减少总体的生产率。

其他敏捷型方法试图能用在大一些的团队。FDD最初是为50人左右的项目设计 的。ThoughtWorks曾在三个大陆(洲)上使用过类似XP的方法,项目组成员 是100人左右。Scrum也在类似规模的项目中使用过。

这篇文章至少清楚地传递了这样一个信息,就是适应性方法对需求不确定或常 常变更的情形是有效的。如果你没有稳定的需求,那么你就不可能进行稳定的 设计并遵循一个计划好了的过程。这种情况下,适应性过程可能感觉上不太舒 服,但实践上会更有效。通常来说,使用适应性方法最大的障碍来自客户。我认 为,重要的一点是让客户理解在一个需求不断变更的环境中,遵循可预设性过程 对他们是有风险的,同样对开发方也是有风险的。

如果你要采用适应性方法,你需要信任你的开发人员,并让他们参与(技术〕 决策。适配性过程的成功依赖于你对你的开发人员的信任。如果你认为你的开 发人员素质不够,那么你应采用可预设性途径。

总结一下,如下的因素建议你采用适应性过程:

  • 不确定或常变更的需求
  • 负责任的、自觉自励的开发人员
  • 理解并愿意参与其中的客户

而如下这些因素则建议你使用可预见性过程:

  • 100人以上的项目组
  • 固定价格,或更确切的说,固定任务范围的合同

鸣谢

本文得益于许多朋友的意见,恕难一一列出。但是,我要特别感谢Marc Balcer, Kent Beck,Alistair Cockburn,Ward Cunningham,Bill Kimmel 和Frank Westphal。

请记住这是一篇不断改进的网络文章。我将附上主要修改记录,而小改动将不作记录。

修改记录

  • 2003年4月:更新了几个小节,增加了“测度的困难性”和“相关环境驱动测试(Context driven testing)”。
  • 2002年6月:更新参考材料。
  • 2001年11月:更新一些最近的参考材料。
  • 2001年3月: 加上关于“敏捷联盟”的内容。
  • 2000年12月:本文缩写发表于Software Development杂志。
  • 2000年11月:更新ASD部分并加上DSDM和RUP的章节。
  • 2000年7月: 初稿发于martinfowler.com。

译后注:

我在2000年曾参加过一个ECommerce系统的软件开发工作。这个项目 采用了一种类似XP(极限编程〕的开发方式,一个迭代周期约为三周,实现 一项use case〔use case driven〕。开发中特别强调单元测试(unit testing, 使用JUnit)与每天的“冒烟测试”(smoke test〕。 2001年初读到Martin Fowler的网站 (www.martinfowler.com〕上的这篇 “The New Methodology”时,我正参加一个投资银行的证券分析信息系统 的开发工作,该项目也采用了迭代式开发过程。但由于环境不同,这个项目 的迭代周期较长一些,约六到八周。这个项目的另一个特点是开发人员 和系统分析员〔business analysts〕以及测试人员〔testers〕的沟通特别 频繁。读了这篇文章后,我觉得它能够让人从一个比较广阔而系统的角度来 考察一个迭代式项目的运作。

原文初期是以“lightweight”来指称新方法的,主要是针对传统的 “重型”方法。Agile Alliance决定用agile来指称这些新方法后,原文中的 “lightweight”改成了“agile”。agile本意“敏捷”、“灵动”、“快 速”。译文中原译为“轻灵”,而现在“敏捷”似乎已成标准译法,因此也 改成“敏捷”。

诚如作者所言,这是一篇不断改进的网络文章。我将尽力随原文的更新而及时 更新译文。此译文中如有所译不当之处,望诸位同行不吝赐教。

[repost ]Waterfall vs. RAD vs. RUP vs. Agile (Scrum, XP, etc.)

original:http://blog.practicalagility.info/2008/11/waterfall-vs-rad-vs-rup-vs-agile-scrum.html

When I broke into this industry in the mid to late 1980’s, it was pretty well a Waterfall world. By that I mean the minimal definition of waterfall from the top of page 2 of Winston Royce’s seminal 1970 paper Managing the Development of Large Computer Systems that showed the flowing steps of Requirements, Analysis, Design, Coding, Testing, etc., and not the more comprehensive definition that followed in the rest of that paper. I was a good soldier, defining and designing everything up front… well, OK, sometimes I cheated and did some coding work because I was impatient or bored and needed to get moving forward, but generally I followed those steps.

In the early 1990’s, along came this cool concept called Rapid Application Development (RAD). The consumers of the systems we were building were also impatient – they wanted value NOW, and were willing to have corners cut with the design and documentation. So, RAD espoused getting something – anything – into production RIGHT NOW!! That worked fine, except that you didn’t spend much time on any of the activities that promoted sustainable development.

So, we went from too much process to too little.

At the same time, Object Oriented languages were coming into prominence and the development models created by Grady Booch, Ivar Jacobsen and James Rumbaugh (with contributions from Philippe Kruchten) were combined into a single process know as the Rational Unified Process. The RUP dealt with many of the shortcomings of both Waterfall and RAD – it was iterative allowing the constant feedback missing in Waterfall, and was heavily weighted towards architecture and risk management which was missing in RAD. Cool, now the industry could move forward with a standard process.

But there was a problem. It wasn’t so much the process contained in the RUP but how it was packaged. The RUP was put together as a process framework, which was not unlike a large pantry containing all the ingredients you would need to make any number of meals. Unfortunately, people didn’t seem (or didn’t want?) to realize that you didn’t need all of the ingredients for every project. The older Waterfall mentality was used when attempting to tailor the process to local needs, and when faced with paring down a large process people seem to err on the side of not paring enough.

What resulted was many projects using way too much process, which in turn resulted in more documentation, more design and less software. This was not what the RUP’s creators had intended, not unlike what happened to Royce’s definition of Waterfall.

So, in the late 90’s, people tired of the heavyweight processes started rebelling against them. Along came what eventually became known as the Agile processes such as Extreme Programming, Scrum, Crystal, Feature Driven Development, etc. They focused on delivering value, and value to them was running software. Many of the Agile processes also added technical practices intended to provide the sustainability missing from RAD. They also overtly identified the people as being as important as the process itself.

Success stories abounded, not unlike what happened with each of the prior waves of processes. There were also, though, some failures. Those have, in my observation, increased over time as more teams started to use Agile processes. When looking at the causes of these failures, they often show that teams weren’t using all of the practices in a given process, or they didn’t use good technical practices at all and just adopted the management practices.

So now, is the pendulum swinging back towards more process?

There was an interesting post from David Anderson on the KanbanDev Yahoo Group this morning. In that post he states,

At this point, it is impossible to take the ‘David’ or ‘Jeff” or ‘Israel’ factor out of the achievement of the high maturity.

This is in reference to increasing the maturity level of organizations beyond just “Agile”, and to do so he believes that we must remove the human element not from the process itself, but from the stewardship of the process.

I think this is the correct direction – acknowledge, retain and leverage the human factors of executing the process, while at the same time removing the human element from managing it. Any team could be successful using XP if Kent Beck, Ron Jeffries, Jim Shore, etc. were running it. What we want to achieve, though, is a point where any team could be successful with (insert process name here) regardless of who is running it.

To answer the question, then, yes I believe that some more process is required. However, I think the amplitude if the pendulum swings is decreasing and eventually we’re going to find a happy medium that’s sustainable both within an enterprise setting, and over a long term.

[repost ]敏捷(agile)开发与极限编程(XP)

original:http://www.xuebuyuan.com/1230523.html

在按照我的理解方式审查了软件开发的生命周期后,我得出一个结论:实际上满足工程设计标准的惟一软件文档,就是源代码清单。
— Jack Reeves

简介
2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟。敏捷开发过程的方法很多,主要有:SCRUM,Crystal,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。

极限编程

  设计和编程都是人的活动。忘记这一点,将会失去一切。

— Bjarne Stroustrup

  极限编程(XP)是敏捷方法中最著名的一个。它是由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。

下面是极限编程的有效实践:

  1. 完整团队 XP项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中,他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
  2. 计划游戏计划是持续的、循序渐进的。每2周,开发人员就为下2周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。
  3. 客户测试作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
  4. 简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西,并且包含尽可能少的代码
  5. 结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
  6. 测试驱动开发编写单元测试是一个验证行为,更是一个设计行为。同样,它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环,尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作,他们先增加一个失败的测试,然后使之通过。
  7. 改进设计随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净、具有表达力。
  8. 持续集成团队总是使系统完整地被集成。一个人拆入(Check in)后,其它所有人责任代码集成。
  9. 集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责,每个人都可以参与任何其它方面的开发。
  10. 编码标准 系统中所有的代码看起来就好像是被单独一人编写的。
  11. 隐喻 将整个系统联系在一起的全局视图;它是系统的未来影像,是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符,那么你就知道该模块是错误的。
  12. 可持续的速度 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。 极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。

敏捷开发
人与人之间的交互是复杂的,并且其效果从来都是难以预期的,但却是工作中最重要的方面。

— Tom DeMacro和Timothy Lister

敏捷软件开发宣言:

  • 个体和交互     胜过 过程和工具
  • 可以工作的软件 胜过 面面俱到的文档
  • 客户合作       胜过 合同谈判
  • 响应变化       胜过 遵循计划

虽然右项也有价值,但是我们认为左项具有更大的价值。

  • 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
  • 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
  • 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
  • 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
  • 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
  • 在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
  • 工作的软件是首要的进度度量标准。
  • 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
  • 不断地关注优秀的技能和好的设计会增强敏捷能力。
  • 简单是最根本的。
  • 最好的构架、需求和设计出于自组织团队。
  • 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

当软件开发需求的变化而变化时,软件设计会出现坏味道,当软件中出现下面任何一种气味时,表明软件正在腐化。

  • 僵化性: 很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。
  • 脆弱性: 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
  • 牢固性: 很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。
  • 粘滞性: 做正确的事情比做错误的事情要困难。
  • 不必要的复杂性: 设计中包含有不具任何直接好处的基础结构。
  • 不必要的重复性: 设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。
  • 晦涩性: 很难阅读、理解。没有很好地表现出意图。

敏捷团队依靠变化来获取活力。团队几乎不进行预先设计,因此,不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单,并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。为了改变上面软件设计中的腐化味,敏捷开发采取了以下面向对象的设计原则来加以避免,这些原则如下:

  • 单一职责原则(SRP)
    就一个类而言,应该仅有一个引起它变化的原因。
  • 开放-封闭原则(OCP)
    软件实体应该是可以扩展的,但是不可修改。
  • Liskov替换原则(LSP)
    子类型必须能够替换掉它们的基类型。
  • 依赖倒置原则(DIP)
    抽象不应该依赖于细节。细节应该依赖于抽象。
  • 接口隔离原则(ISP)
    不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。
  • 重用发布等价原则(REP)
    重用的粒度就是发布的粒度。
  • 共同封闭原则(CCP)
    包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成任何影响。
  • 共同重用原则(CRP)
    一个包中的所有类应该是共同重用的。如果重用了包中的一个类,那么就要重用包中的所有类。
  • 无环依赖原则(ADP)
    在包的依赖关系图中不允许存在环。
  • 稳定依赖原则(SDP)
    朝着稳定的方向进行依赖。
  • 稳定抽象原则(SAP)
    包的抽象程度应该和其稳定程度一致。

  上述中的包的概念是:包可以用作包容一组类的容器,通过把类组织成包,我们可以在更高层次的抽象上来理解设计,我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分,然后把那些划分后的类分配到包中。

下面举一个简单的设计问题方面的模式与原则应用的示例:

问题:
选择设计运行在简易台灯中的软件,台灯由一个开关和一盏灯组成。你可以询问开关开着还是关着,也可以让灯打开或关闭。

解决方案一:
下面图1是一种最简单的解决方案,Switch对象可以轮询真实开关的状态,并且可以发送相应的turnOn和turnOff消息给Light。


解决方案二:
上面这个设计违反了两个设计原则:依赖倒置原则(DIP)和开放封闭原则(OCP),DIP原则告诉我们要优先依赖于抽象类,而Switch依赖了具体类Light,对OCP的违反是在任何需要Switch的地方都要带上Light,这样就不能容易扩展Switch去管理除Light外的其他对象。为了解决这个方案,可以采用ABSTRACT SERVER模式,在Switch和Light之间引入一个接口,这样就使得Switch能够控制任何实现了这个接口的东西,这也就满足了DIP和OCP原则。如下面图2所示:

解决方案三:
上面图2所示解决方案,违返了单一职责原则(SRP),它把Switch和Light绑定在一起,而它们可能会因为不同的原因而改变。这种问题可以采用ADAPTER模式来解决,适配器从Switchable 派生并委托给Light,问题就被优美的解决了,现在,Switch就可以控制任何能够被打开或者关闭的对象。但是这也需要会出时间和空间上的代价来换取。如下面图3所示:

  敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。 

======================================================
在将什么是极限编程之前,咱们先来讨论一下,当今信息技术中最迫切的两个问题是:
How do we deliver functionality to business clients quickly?
如何能快速地向商业用户交付功能? 

How do we keep up with near-continuous change?
如何才能跟上近乎连续的变化?
变化本身也在不断地变化中。不仅仅是变化的速度在不断地提高 ,已经成为电子商务支柱的Internet, 就已使大范围的行业产生剧变–更多的是打断的平衡而不仅仅是一次剧变。当整个商业模式正在发生变化,当”时间意味着市场”正成为公司的咒语,当适应性与互连性正在成为甚至是最呆板的组织的需要的时候,我们将有必要检查以下的每一个方面:
1.商业是如何管理的,
2.客户为什么而感到高兴,
3.以及产品是如何开发的。

终极编程(Extreme Programming )运动成为面向对象编程这个团体的一部分已经有数年了, 但是直到最近才引起了越来越多的注意,特别是最近Kent Beck的《终极编程 释义:拥抱变化》(Extreme Programming Explained: Embrace Change)一书的出版。

有一种趋势,特别在那些严格的方法论者中,希望剔除那些与”能力 成熟度模型”(Capability Maturity Model CMM)或者是国际标准化组织的标准相比不那么笨重的方法,比如象hacking.注释: hacking推崇行动而不是思考从而导致了较低的质量。 剔除与某人关于这个世界的假设相冲突的实践,这倒不失为一种简单的方法。
从另一个角度来看XP,它倒可能是一个难题的某个潜在的部分,这个一个我在过去18个月中一直都在写的内容。混乱 的时期产生新的问题,而后者又导致了新的实践–新的实践公然违抗 传统的知识,但却得以幸存下来是因为它们能更好地适应这个新的现实世界。至少有四种实践方式我觉得是属于这个范畴的:
XP
轻量级的开发(Lean development)
轻量级的Crystal方法(Crystal Light methods
自适应软件开发(Adaptive software development)

我必须承认一件事情,就是我喜欢XP的原因应该是它没有其他的那些花哨的东西。支持XP的人们总是会向你指出XP适合的地方以及他的某些局限性。而XP的实践者Beck以及Ron Jeffties却相信XP会有更广泛的应用前景。他们通常对于自己的要求都是很谨慎的。例如:小的(小于10人),公司局部(他们有直接的经验)两者对于XP的适应性都是很明显的;他们并没有试图让人们相信XP可以适用于一个200人的团队。

xp基础—工程
最为著名的XP项目是克莱斯勒综合补偿系统(Chrysler Comprehensive Compensation system称为C3工程)。
最初,C3是一个基于OO(面向对象技术)的开发项目,尤其是它采用Smaltalk语言进行开发。作为著名的Smalltalk专家,Beck被邀请来讨论有关SmalTalk性能优化的问题,并且在原项目被认为不可救要的时候将其变为一个采用面向对象OO(XP)方法的试验性项目。Beck并且带来了Jeffries用于帮助那些基本的东西,Jeffries在C3组一直干到1999年的春天。最开始的需求是要做一个对约10,000个雇员每月薪水发放进行管理的系统。这个系统由大约2,000个类以及30,000个方法构成,并且在计划方面提供有合理的容忍度 。当有人问Jeffries他怎样成功的将C3变为XP并应用到其他的克莱斯勒IT项目。他笑着告诉了我。多年来我为许多大型IT组织开发了不少RAD系统(快速原型开发),因此我知道为什么我们无法将成功的经验运用于其它项目中. 对于RAD, XP, 轻量级的开发以及其它一些未得到广泛应用的方法, 它们成功的原因至少有一百条.

xp基础—实践
应记住的一件事情就是我们应倾向于在小型的, 局部的团队中运用XP。除了代码与测试用例外, 尽量减少有些的影响。XP的实践既有正面的表现,也有负面的。在某些方面看来,他们听起来就像一堆规则,要做这个,不要做那个。对此Beck解释道, 与规则相比, XP更像是指导方针,一个灵活的依赖于具体环境的开发方针。但是诸如“每周工作40小时”等看起来可能会感觉絮絮叨叨。Jeffries使得实践也会互相作用的,平衡,互相加强。以至于挑选使用的同丢弃的都是棘手的事情。

计划的制定:XP中关于制定计划的实现方法中可以反映出大多数迭代式RAD项目的特点。短期的,每三周为一个循环,频繁地更新,按优先级划分任务与技术, 分配stories(一个story定义了一个特殊的功能需求并以一种简单的方式记录在卡片上),所有的这些就是构成了XP中的计划。

小版本:“每个版本应该尽可能的小,而且包含最有商业价值的需求”,Beck如是说。这也反映了Tom Gilb在他的<软件工程管理原则>书中提到的关于渐进式发布的两点:“所有的大的项目都可以被分为局部的, 有用的小的步骤”以及“进化的步骤会传递到下一级。”小型版本的发布意味着具有在大型项目中经常缺少的频繁的反馈的实现.。 然而,一个开发小组当然需要考虑到“发布”同“可发布”的不同。无论是否是最终的版本发布还是一个简单的可发行版本的发布, 都需要付出安装,培训,转化等代价。

隐喻:在XP中“隐喻”以及“story”的使用可能会让人有一点不舒服。但是,这些术语的使用可以帮助我们以一种更人性化的方式加以理解,尤其是对客户而言。从某种程度上来说,隐喻同体系结构是同意语――他们都着重于从全局描述一个项目。但是体系结构经常会陷于符号与连接的泥潭。而XP使用“隐喻”定义一个从开发者到商业客户都可联系的全面一致的主题。隐喻用于描述项目全面的面貌,而Story用于描述个别具体的特征。

简单的设计:简单的设计包含两个部分。一,为已定义的功能进行设计,而不是为潜在地未来可能的功能进行设计。二,创建最佳的可以实现功能的设计。换句话说,不用管未来会是怎样,只创建一个目前为止可以实现的最好的设计。“如果你相信未来是不确定的,并且你相信你可以很方便的改变你的主意的话,那么对未来功能的考虑是危险的。”Beck写到。“只有在你真正需要的时候才去做“。 数据的质量是使用功能,不是捕捉与存储。此外,我说数据如果不是很系统的使用便会变坏。数据质量是系统使用的功能,不是可预料的设计。无论预期的对还是错,试着设计一个我们从来都不会用到的数据,最终结果很可能我们一次也不会用到它们。XP的简单设计方法反映了相同的观点。如在本文后来所描述的那样,这并不意味着不需要预测,而是说为预测的内容所做的设计一旦发生变化,其导致的代价是十分巨大的。

重构:如果我不得不找出一个能够将XP和其他方法区别开来的东西那就是重构――不断的软件再设计以改进它对于变化的反应。RAD方法常常很少甚至根本不与设计相关;XP应当被看作持续设计。当变化既快而且频繁的时候,应投入更多的精力于重构之上。参见下面的“重构”和“数据重构”部分。

测试:XP充满发人深思的有趣的难题。例如:什么是“先测试后编码”?在一些软件公司是通过代码的行数来对程序员的绩效加以考核,而测试的绩效则是通过发现的缺陷的数量来考核的。这两种方法都不能鼓励减少测试前产生的缺陷的数量。XP使用两种测试:单元测试和功能测试。单元测试要求在写代码之前就开发出相应功能的测试方法,并且测试应当是自动化的。代码一完成,它就被立即用有关测试集加以测试,从而能立即得到反馈。

配对编程:代码检查(还是直接用Inspection为好?)(也称审查或走查)也是被广为接受(至少在理论上)和有效度量的少数软件工程实践之一。在最好情况下,Inspection这种协同交互的检查能够加速学习,同时发现缺陷。一个较少被知道的关于Inspection的统计数据是尽管它在发现缺陷方面非常有效,但通过团队对于好的开发实践持续的学习和协作,可以更好的在第一时间预防缺陷。 一家软件公司客户引用一个内部研究结果,表明在测试阶段发现一个缺陷需15小时,在Inspection阶段发现一个缺陷则需2-3小时,而在Inspection之前发现缺陷只需15分钟。后面的数据来自于产生于常规审查的持续的团队学习。配对编程将这个带入下一步――与其用Inspection来递增式学习,为什么不用配对编程来学习呢? “配对编程是两个人试图同时编程和理解如何更好编程的一种对话”,Beck写道。让两个人同时坐在一台终端前面(一个人敲代码或测试用例,一个人审查和思考)产生一种持续的、动态的交流。Williams在犹他大学进行的博士论文研究证明了配对编程不仅仅是一种美好的想法而且确有实效。

代码共享:项目组中的每个人都可以在任何时候修改其他项目成员的代码,这就是XP中所定义的代码共享。。对许多程序员以及经理而言,,共有代码的想法会引起一些疑虑,诸如”我不想让那些笨蛋改我的代码”,”出现问题我应该怪谁?”等等。共享代码从另一个层面提供了对配对编程中协作的支持。

经常集成:每日构造(build)在许多公司已经成为规范,许多公司将每日编链作为最小要求,XP实践者将每日集成作为最大要求,选择每两个小时一次的频繁编链。XP的反馈周期迅速:开发测试集、编码、集成(编链)和测试。 对于集成缺陷危险的认识已有多年了,但我们并不是总能拥有相应工具和时间将这些知识好好用起来。XP不仅提醒我们有可能有严重的集成错误,而且从实践与工具的角度提供了一种新的认识。

每周只干40小时:XP有12条实践的基本原则,但是有时候,比如象每周只干40小时的原则,听起来更象规则。我同意XP中的观点。只是不认为有必要硬性规定工作小时数。相比起来,我更喜欢一句类似于“不要把部队烧光”的话。在一些情况下,工作40小时太劳累,而在另外一些组里,甚至需要一周60个工作时。 Jeffries提供了关于加班的更多思索:”我们说的是加班被定义为我们不想在办公室的时候呆在办公室。而且你不应当加班超过一周。如果你超过了,就有什么东西出了问题――你过于劳累,有可能比你按时下班干的还差。我同意你关于60工作时一周的感受。在我们年轻和满身干劲的时候,这也许没问题。值得注意的是拖沓的一周又一周。” 我不认为一周的工作时间会造成大的差别。决定区别的是自愿的贡献。人们愿意来工作吗?他们对每一天都充满干劲吗?人们必须来工作,但是他们通过投入项目来创造巨大成就,而投入仅仅产生于目标感。

现场客户:这就对应到了最初软件开发时所提出的问题――用户参与。XP,同其他的快速开发一样,要求客户在现场持续地参与到项目组中。

编码标准:XP实践相互支持。例如,如果你进行配对编程并让他人修改共有代码,那么编码标准看起来就是必须的。

价值和规则
在2000年一月一日周六时候,华尔街日报(周一到周五出版的)用一个58页的版面发布了一个千僖年纪念版。在篇首的有关工业及金融的介绍里标着Tom Petzinger.写的:“长久的需求与召唤:经济新的增长点――显得同以往不同”。底下的一行 Petzinger 写着:“创造性正代替’万金药’的资本在成为首要的因素”。 Petzinger并没有谈论少数天才的创造性,而是谈了以下群体的创造性――从组到部门。一旦我们撇下天才们的个体创造,创造性就是环境的功能,而人们运用并互相协助而达到我们的结果的能力。如果你的公司认为软件开发只是一个统计上的重复试验,刻板的,技术性的过程,那么XP对于您也许并不合适。虽然XP中也有技术实践里的严格,但是XP本身是追求”创造”与”沟通”。

环境是靠价值同规则共同驱动的系统。XP(或者其他类似的)可能、也可能不适合您的单位,可是,应该澄清的是成功并不是只靠每周40小时的疯狂工作或者配对编程,也不是依靠XP之中应用在您单位中的价值或者是规则。 Beck指出了四个价值,五个基本规则,以及十个辅助规则–不过我要提到是这五个规则。

沟通:是的,沟通,可是,这里似乎没有新的东西在里面?沟通主要是看人们自己的看法,XP构建的基本是人与人,通过最简洁的文档,最直接的面对面沟通获得对任务环境的理解。

简洁:XP问每个开发组成员:“可能实现的最简洁的方法是什么?”。今天所保持的简洁,可以降低明天由于变更所带来的费用

反馈:Beck说:”对于编程而言,乐观主义是一种冒险。”,”而反馈则是相应的解决良药。”无论是用反复的构建或者频繁的用户功能测试,XP都能不断地接收到反馈。虽然每次对软件开发策略进行研讨时,我们都会说及反馈–即使是非常有害的瀑布模型–不同的是XP的实践者认为反馈比起前馈(feedforward)来更为重要。无论是对测试失败的代码进行修改或者是对用户拒收的软件从新返工,开发环境的快速变化要求开发人员对反馈有更好的认识。

勇气:无论您是使用CMM方法或者是XP的方法,方法使用的本身是要求勇气的。许多地方将勇气定义为做某件事情的权利,即使被迫去做其他的事情。开发人员经常借口压力而发出带有许多缺陷的产品,并对此加以坚持。然而,更进一步的应该包括其他的正确的不同的东西进来。通常,人们并不是缺少勇气,而是缺少一种让正确实践获得承认的理由,而且,也不坚信这点,勇气不像看起来那么重要。而如果你对之没有信心,那么是很难尽力工作的。 “勇气并不只是方法”,Jeffries说道,它是一种最终的价值。如果你在一种基于”沟通”,”简洁”,”反馈”的模式下工作,你将获得勇气,越往前信赖就越不重要。

优质的工作:好,如果你们中有赞成劣质工作的话,那么请举手离开这儿吧。不论你是一个Rational Unified Process,CMM,或是XP的赞成者,其本质的观点”你怎样定义质量”与”什么样的活动会赢得高质量”,定义”无缺点”质量是这个问题的一个方向。Jerry Weinberg的定义是”质量是对多数人有益”

===============================
================================

在一起做一段时间不就熟悉了吗,这个反对理由不充分。再说了,都已经是一个公司的了,还在一个团队里,沟通还算是问题吗?

我们在开发过程中采用了xp的方法,并且在开发过程中也有新人加进来,只要是不对xp的方法有抵触心理(不排除有这样的人),每天一起PP,很快就能融入到团队中。并且通过PP,整个团队也会互相熟悉起来,增进了解,这是一个渐进的过程。

要有一个适合xp的工作环境,包括硬件环境和软件环境。硬件环境就是在一台机器前有足够的空间坐下两个人,如果不PP就无所谓了。重要的是软件环境,比如CVS,bugtrack,能够快速频繁运行的单元测试等等,这些最好能有人来把关,建议在项目中用maven,每天能生成很多报告,比如checkstyle的,可以看看谁的代码格式不符合规范,还有什么包依赖的检查啊,代码重复的检查啊,单元测试覆盖度啊等等。

[repost ]Agile Principles and Values, by Jeff Sutherland

original:http://msdn.microsoft.com/en-us/library/dd997578.aspx

Jeff Sutherland invented Scrum in 1993 and worked with Ken Schwaber to formalize Scrum at OOPSLA’95. Together, they extended and enhanced Scrum at many software companies and helped write the Agile Manifesto. Jeff’s blog reviews the origins and best practices of Scrum at http://scrum.jeffsutherland.com.

Agile development is a term that was derived from the Agile Manifesto, which was written in 2001 by a group that included the creators of Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), and Crystal; a representative of feature-driven development; and several other thought leaders in the software industry. The Agile Manifesto established a common set of overarching values and principles for all of the individual agile methodologies at the time. The manifesto details four core values for enabling high-performing teams.

  • Individuals and their interactions
  • Delivering working software
  • Customer collaboration
  • Responding to change

These core values are supported by 12 principles, which you can find at the following Web site: Manifesto for Agile Software Development.

These values are not just something the creators of the Agile Manifesto intended to give lip service to and then forget. They are working values. Each individual agile methodology approaches these values in a slightly different way, but all of these methodologies have specific processes and practices that foster one or more of these values.

Individuals and interactions are essential to high-performing teams. Studies of “communication saturation” during one project showed that, when no communication problems exist, teams can perform 50 times better than the industry average. To facilitate communication, agile methodologies rely on frequent inspect-and-adapt cycles. These cycles can range from every few minutes with pair programming, to every few hours with continuous integration, to every day with a daily standup meeting, to every iteration with a review and retrospective.Just increasing the frequency of feedback and communication, however, is not enough to eliminate communication problems. These inspect-and-adapt cycles work well only when team members exhibit several key behaviors:

  • respect for the worth of every person
  • truth in every communication
  • transparency of all data, actions, and decisions
  • trust that each person will support the team
  • commitment to the team and to the team’s goals

To foster these types of behavior, agile management must provide a supportive environment, team coaches must facilitate their inclusion, and team members must exhibit them. Only then can teams achieve their full potential.

For teams to achieve these types of behavior is more difficult than it might appear. Most teams avoid truth, transparency, and trust because of cultural norms or past negative experiences from conflict that was generated by honest communications. To combat these tendencies, leadership and team members must facilitate positive conflict. When teams engage in positive conflict, they not only foster more productive behavior, but also work to achieve several other benefits:

  • Process improvement depends on the team to generate a list of impediments or problems in the organization, to face them squarely, and then to systematically eliminate them in priority order.
  • Innovation occurs only with the free interchange of conflicting ideas, a phenomenon that was studied and documented by Hirotaka Takeuchi and Ikujiro Nonaka, the godfathers of Scrum.
  • Resolution of conflicting agendas occurs when teams align around common goals and surface their concerns and potential conflicts.
  • Commitment to work together happens only when people agree on common goals and then struggle to improve both personally and as a team.

This last bullet, about commitment, is especially important. It is only when individuals and teams are committed that they feel accountable for delivering high value, which is the bottom line for software development teams. Agile methodologies facilitate commitment and self-organization by encouraging team members to pull items from a prioritized work list, manage their own work, and focus on improving their work practices. These practices form the basis of self-organization, which is the driving force for achieving results in an agile team.

To create high-performing teams, agile methodologies value individuals and interactions over processes and tools. Practically speaking, all of the agile methodologies seek to increase communication and collaboration through frequent inspect-and-adapt cycles. However, these cycles work only when agile leaders encourage the positive conflict that is needed to build a solid foundation of truth, transparency, trust, respect, and commitment on their agile teams.

Working software is one of the big differences that agile development brings. All of the agile methodologies that are represented in the Agile Manifesto stress delivering small pieces of working software to the customer at set intervals.All agile teams must establish what they mean when they say “working software,” which is frequently known as the definition of done. At a high level, a piece of functionality is complete only when its features pass all tests and can be operated by an end user. At a minimum, teams must go beyond the unit test level and test at the system level. The best teams also include integration testing, performance testing, and customer acceptance testing in their definition of what it means to be done with a piece of functionality.

One CMMI Level 5 company, that already has one of the lowest defect rates in the world, has shown through extensive data on many projects the benefits of agile practices. Specifically, they were able to systematically double the speed of production and reduce defects by 40 percent by taking the following actions:. This from a company.

  • Define acceptance tests when defining the feature.
  • Implement features serially and in priority order.
  • Run acceptance tests on each feature as soon as they are implemented.
  • Fix bugs that are identified as highest priority as soon as possible.

The Agile Manifesto recommends that teams deliver working software at set intervals. By agreeing as a team on what success means is one of the practical ways that agile teams bring about the high performance and high quality that is needed to accomplish this goal.

Over the past two decades, project success rates have more than doubled worldwide. These improvements occurred as a result of smaller projects and more frequent deliveries, which allowed customers to provide feedback on working software at regular intervals. The writers of the manifesto were clearly on to something when they stressed that getting the customer involved in the software development process is essential to success.The agile methodologies foster this value by having a customer advocate work hand-in-hand with the development team. The first Scrum team, for example, had thousands of customers. Because it was not feasible to involve them all in product development, they selected a customer proxy, called a product owner. The product owner represented not only all the customers in the field, but also management, sales, support, client services, and other stakeholders. The product owner was responsible for updating the list of requirements every four weeks as the team released working software, taking into account the current reality and actual feedback from customers and stakeholders. Customers actively helped shape the software that was being created.

The first XP team began with an internal IT project. The XP team was able to have a company end user on their team work with them daily. About 10 percent of the time, consultants and internal teams can find an end user who can work with the team on a day-to-day basis. The other 90 percent of the time, they must appoint a proxy. This customer proxy, whom XP teams call the customer, works with end users to provide a clear, prioritized list of features for developers to implement.

It is through daily customer (or customer proxy) collaboration that industry data shows that agile projects have more than twice the success rate of traditional projects on average worldwide. Because agile methodologies recognize the value of customer engagement, they have created a place on their development teams that is specifically for the customer representative.

For teams to create products that will please customers and provide business value, teams must respond to change. Industry data shows that over 60 percent of product or project requirements change during the development of software. Even when traditional projects finish on time, on budget, with all features in the plan, customers are often unhappy because what they find is not exactly what they wanted. “Humphrey’s Law” says that customers never know what they want until they see working software. If customers do not see working software until the end of a project, it is too late to incorporate their feedback. Agile methodologies seek customer feedback throughout the project so that teams can incorporate feedback and new information as the product is being developed.All agile methodologies have built-in processes to change their plans at regular intervals based on feedback from the customer or customer proxy. Their plans are designed to always deliver the highest business value first. Because 80 percent of the value is in 20 percent of the features, well-run agile projects tend to finish early, whereas most traditional projects finish late. As a result, customers are happier, and developers enjoy their work more. Agile methodologies are based on the knowledge that, in order to succeed, they must plan to change. That is why they have established processes, such as reviews and retrospectives, that are specifically designed to shift priorities regularly based on customer feedback and business value.

Agile development is not a methodology in itself. It is an umbrella term that describes several agile methodologies. At the signing of the Agile Manifesto in 2001, these methodologies included Scrum, XP, Crystal, FDD, and DSDM. Since then, Lean practices have also emerged as a valuable agile methodology and so are included under the agile development umbrella in the illustration later in this topic.Each agile methodology has a slightly different approach for implementing the core values from the Agile Manifesto, just as many computer languages manifest the core features of object-oriented programming in different ways. A recent survey shows that about 50 percent of agile practitioners say that their team is doing Scrum. Another 20 percent say that they are doing Scrum with XP components. An additional 12 percent say that they are doing XP alone. Because more than 80 percent of agile implementations worldwide are Scrum or XP, MSF for Agile Software Development v5.0 focuses on the core processes and practices of Scrum and XP.

The Agile UmbrellaScrum is a framework for agile development processes. It does not include specific engineering practices. Conversely, XP focuses on engineering practices but does not include an overarching framework of development processes. That does not mean that Scrum does not recommend certain engineering practices or that XP has no process. For example, the first Scrum implemented all of the engineering practices that are now known as XP. However, the Scrum framework for software development was designed to get a team started in two or three days, whereas engineering practices often take many months to implement. Therefore, it left the question of when (and whether) to implement specific practices up to each team. Scrum co-creators Jeff Sutherland and Ken Schwaber recommend that Scrum teams get started immediately and create a list of impediments and a process improvement plan. As engineering practices are identified as impediments, teams should look to XP practices as a way to improve. The best teams run Scrum supplemented with XP practices. Scrum helps XP to scale, and XP helps Scrum to work well.

The following table shows how key terms in Scrum and XP can be interchanged.

Scrum XP
product owner customer
scrummaster XP coach
team team
sprint iteration
sprint planning meeting planning game

[repost ]The 12 Agile Principles

original:http://www.dummies.com/how-to/content/the-12-agile-principles.html

The 12 Agile Principles are a set of guiding concepts that support project teams in implementing agile projects. Use these concepts to implement agile methodologies in your projects.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity — the art of maximizing the amount of work not done — is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

[repost ]What Is Agile? (10 Key Principles of Agile)

original:http://www.allaboutagile.com/what-is-agile-10-key-principles/

What is agile?  Agile is one of the big buzzwords of the IT development industry. But exactly what is agile development? Put simply, agile development is a different way of managing IT development teams and projects. The use of the word agile in this context derives from the agile manifesto.  A small group of people got together in 2001 to discuss their feelings that the traditional approach to managing software development projects was failing far too often, and there had to be a better way.  They came up with the agile manifesto, which describes 4 important values that are as relevant today as they were then.  It says, “we value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.” Ever since then, the use of methods that support these values has become increasingly popular. From my use of various agile methods, I have written about 10 key principles of agile.  These are characteristics that are common to all agile methods, and the things that I think make agile fundamentally different to a more traditional waterfall approach to software development.  They are: 1. Active user involvement is imperative 2. The team must be empowered to make decisions 3. Requirements evolve but the timescale is fixed 4. Capture requirements at a high level; lightweight & visual 5. Develop small, incremental releases and iterate 6. Focus on frequent delivery of products 7. Complete each feature before moving on to the next 8. Apply the 80/20 rule 9. Testing is integrated throughout the project lifecycle – test early and often 10. A collaborative & cooperative approach between all stakeholders is essential There are various methodologies that are collectively known as agile, as they promote the values of the agile manifesto and they are consistent with the above principles.  The most popular ones are: DSDM is probably the original agile development method. DSDM was around before the term ‘agile’ was even invented, but is absolutely based on all the principles we’ve come to know as agile.  DSDM seems to be much less well-known outside of the UK. Scrum is also an agile development method, which concentrates particularly on how to manage tasks within a team-based development environment.  Scrum is the most popular and widely adopted agile method – I think because it is relatively simple to implement and addresses many of the management issues that have plagued IT development teams for decades. XP (Extreme Programming) is a more radical agile methodology, focusing more on the software engineering process and addressing the analysis, development and test phases with novel approaches that make a substantial difference to the quality of the end product. DSDM is probably the most complete agile methodology, whereas Scrum and XP are easier to implement and complementary because they tackle different aspects of software development projects and are both founded on very similar concepts. Over the last 10 years, there is an ever-increasing volume of success stories, where companies have dramatically improved the success and performance of their IT development teams and projects.  This has caused agile to be widely adopted across a variety of industries, including media and technology, large corporates, and even government. In reality, though, agile is not a magic bullet for all software development issues.  The real trick is to know lots of techniques from various waterfall and agile development methods, and to select a mixture of the best approaches that are most appropriate for any given situation.  To do this reliably with any degree of success really requires a lot of experience and skill. In agile software projects, project management takes a slightly different form, relying far more on the project manager’s skills in communication, facilitation, coordination, and emphasising far less on planning and control. Agile development can be a very exciting and invigorating approach, although some projects suit agile more than others.  The collaboration and visibility can provide a much richer and more rewarding experience for teams to develop great software products. Agile development can be a lot more enjoyable than the waterfall approach, which requires lots more documentation and is less flexible by its nature. And when people enjoy their work, it’s amazing what they can achieve! Kelly. See also: 10 Key Principles – PowerPoint Presentation – See more at: http://www.allaboutagile.com/what-is-agile-10-key-principles/#sthash.t3UCoE62.dpuf