在敏捷软件开发方法上中下系列的最后一篇文章里，我们将探讨开发小组如何与客户交互，如何让其参与到开发过程里来。

在《敏捷软件开发》上中下系列的上篇里，我们了解了开发人员做法以及技术优势如何带来质量的显著提高。在中篇里，我们探讨了开发小组做法以及如何建立一个效率最高的开发小组，并重点研究了代码编写标准、连续集成和用于描述系统的通用语言。现在，我们要看看最外面的圆环——“统一小组做法（one team practice）”，这其中包括开发人员、测试人员和客户——并帮助更好地协调业务和IT。

协调业务和IT——“统一小组”做法
敏捷软件开发里的统一小组指的是敏捷开发小组和所有的利益相关人为了一个共同的目标结成一个团队工作。尽管小组里的每个成员都必须把各自主要精力放在具体的任务上，但是小组更喜欢开放的、真诚的和频繁的沟通，而不是暗地里的操作。

统一小组强调由开发人员作出技术决定而由客户作出业务决定，一贯如此，毫无例外。高度的交流，例如每日例会以及项目辐射（在《中篇》里讨论过）会帮助增加交流并不断持续下去，以确保及时获得频繁的反馈信息。

这一概念对于将敏捷开发的所有元素集中到一起是必需的。

创建背景并取得需求——第一步
在你开始敏捷开发的这一部分之前，从客户、业务方和用户取得需求信息；他们才是定义需求的人。由于业务方在这些做法中扮演了至关重要的角色，所以他们必须完全理解自己在敏捷开发环境里的角色是什么，以及他们能够做到什么。让其高速运转起来肯定需要进行讨论会和其他培训工作。

在解释敏捷开发的时候，需要向业务人员阐明的重要优势有：

1. 能够，在任何时候，改变其对最小成本的观点。
2. 能够根据来自市场或其他地方的反馈进行调整和应变。
3. 在任何时候都知道项目的状态，并具备可预见能力。
4. 能够从业务的角度参与项目的指导工作。

重要的成功因素

• 理解——客户将需要某种程序的培训才能确切地理解他们在敏捷开发环境里扮演的角色。
• 沟通——以协作的形式与客户进行交谈和沟通是十分重要的。在整个项目过程中都应该这样，但是从一开始就坚持这样显得尤其重要。

客户／业务方介入——第二步
在这一步骤里，我们要通过用户的素材和验收测试让客户参与到开发过程里来。很多客户可能在编写用户素材或者验收测试上经验不多或者完全没有经验；再强调一次，可能需要某种程度的讨论会或者培训来帮助其完成任务。

用户的素材
用户的素材就是“需求”。每个素材都代表系统需要如何解决某个特定的问题。然而，用户的素材不是大量的写满需求的文档，而是写在素材卡上，应该作为实现更进一步谈话的引子。

好的素材需要什么？
客户，或者更加常见的客户小组，需要聚在一起，在一张5x3寸的素材卡上为系统编写用户素材。我们用财物管理软件公司3Q Solutions来作为例子：

“客户希望能够获得一个规则引擎，从而可以用规则来评估顾客的经济状态。”

这一要求或者素材存在的问题是太不明确。编写好素材卡的正确规则应该是INVEST：

独立的（Independent）
可协商的（Negotiable）
垂直的（Vertical）
可估计的（Estimable）
短小的（Small）
可测试的（Testable）

面的素材显然是不可估计的（很难判断它需要花多长时间）、不短小的（这是一个非常巨大的、不明确的要求），也是不可测试的（你如何能够对像这样的要求进行由测试驱动的开发工作？）。所以下面这样一个素材可能会更好：

“客户希望能够分析顾客当前拥有的现金量——太多、太少，还是刚刚好（取决于生活方式的成本和对风险的态度）。”

这一素材就满足了我们INVEST标准的所有要求。当这个素材在小组（客户和开发方）中讨论的时候，它很明显地就传达了客户真正需要的是具备说明规则引擎的能力。上面的例子表明，一条规则就足够说明用户的需要。这就是编写素材的方法。重要的是，素材要引发产生对话，而对话带来对客户需求的明确和真正理解。

沟通
要记住，素材的主导思想是，它们是发生更进一步对话的引子。其原因是语言要以上下文和理解为基础。没有提问，没有对话，我们将无法体会其中微妙的含义。我们就以Matt Cohn’s Buffalo这个短语为例子。Buffalo（布法罗市）是美国纽约州的一座城市，是野牛（bison）的同义词，还有动词“欺骗和困惑”的意思。所以这样一个句子“Buffalobuffalobuffalobuffalo”是成立的。或者更加明确一点就是来自（纽约州）布法罗市的野牛欺骗了其他的野牛（bison from Buffalo (NY) intimidate and confuse other buffalo）。所以如果没有上下文，这个短语就是毫无意义的。

在每张素材卡的背面，我们建议客户快速记下任何有关验收测试的想法。

验收测试
验收测试用来保证：

1. 客户确信给定的功能能够满足设计的要求。
2. 给予开发人员一个明确的停止点：当验收测试通过的时候，功能就被实现了。

在敏捷开发项目里，客户要编写所有的验收测试。在项目初期，开发人员可能需要与客户紧密合作，以编写验收测试的内容。

我们还建议你使用AT框架并将测试自动化。开人员人需要能够随着他们不断加入新功能而反复地运行这些测试。

下面就是与上述素材相关的AT框架的例子。

交互测试（示例）

//概述
“分析顾客的现金收支状况，考察他们在给定的生活方式成本和对风险的态度的条件下是否握有过多的现金。”

在3Q公司，客户会编写验收测试，并以电子文本的形式每天提交给开发小组。所有的验收测试都会被尽早地提供给开发小组。这一过程与测试－编码－重整循环配合得相当好，它使得开发人员可以在进行验收测试失败之后，运行通过测试－编码－重整循环，然后重新运新验收测试，直到看到其通过测试。每个素材都可能多次进行验收测试，但是一旦所有的验收测试都通过了，那么该素材／功能的实现就完成了。

重要的成功因素

• 不慌不忙——用户素材不容易写好，所以在进行首批任务和讨论任务的时候给自己充裕的时间。
• 验收测试帮助——开发人员可能需要从一开始就与客户一起编写验收测试。专门为这一任务拨出时间——好的验收测试将带来不同寻常的收获。
• 寻求帮助——如果意识到你和你的小组需要帮助——去寻求帮助吧，不要犹豫！
• 已有的需求文档——如果有现成的需求文档，你要将它用作编写素材的基础。要记住，把这些文档当作“新的”素材。它们是对话的要点，而不是定好的要求。

策划——第三步
敏捷软件开发有三个层次的策划：

1. 高层次的发布策划，在这里策划项目的所有发布。这通常取决于项目的规模，但是某些项目的多次发布要求对长达18个月的期限的高层次策划。
2. 发布策划，第一次发布在这里被策划。每次发布之间的间隔为3个月。
3. 反复策划，通过其来策划下两个星期的工作。

这一三级策划过程的目的是让小组首先理解最终的目标，但是只详细策划他们现在所知的内容——未来两周的工作。

发布策划
在高层次发布策划阶段，客户和开发人员应该在一起共同讨论和理解整个系统。通常已经存在的需求文档能够用于启动这一讨论。在理想状况下，客户应该在开会的时候带上含有即将发布的大多数内容的素材卡。

在会议过程中，开发人员将需要估计素材的难度。这可以在会议过程中或者在会议之后进行。我们建议每个人相互比较各自素材，并把具有相同难度的素材集中到一起。然后，使用一个从最简单到最难的测量表，你就可以开始估计每个素材（的难度了）。小组使用不同的方法来给素材评分，按照难度分别打上1到10分。

现在客户能够策划最初的高层次发布计划了。高层次发布并不一定要十分精确，优先顺序和估计都不需要很可靠，但是它会为小组定下方向和提供决策的足够信息。

小型发布
下一步，客户需要拿走估计好的素材卡，并根据最近一个发布将素材的重要性的优先顺序排列好。客户需要考虑它们需要系统立即实现什么，因而这些素材将构成即将进行的发布。这些估计在这里变得十分重要，因为开发人员已经估计的是他们能够给定的发布时间里完成什么；（这个给定的时间）在大多数情况下是3个月。

短期发布循环可以保证紧密的反馈循环，还能让小组把精力放在与项目紧密相关的重要目标上。

反复策划
现在小组需要为未来两周制定具体的计划。再强调一次，客户必须将素材的优先顺序排列出来，详细说明他们希望在未来两周里看到的功能。

这些素材卡然后就被放到两周的反复（发布里）。最近的一次反复将是小组立即进行的工作。他们将交付这个反复，也就是全力工作、软件测试和取得反馈（即再次为未来两周策划），然后再次开始。如果素材在一个反复之前就完成了，开发人员会要求获得更多的素材。如果所有的素材都看起来是无法完成的，那么开发人员和客户要共同将素材移到下一个反复里或者适当地分割一下素材。

两周的反复让客户可以充分利用任何变化。例如，3Q公司碰到了一个很有预见能力的客户。他意识到一个按计划放在发布后期的素材事实上需要更早完成。在经过一个简短的讨论之后，小组用客户要求的素材替换掉了当前发布里具有同等价值的素材。那么成本呢？只是一个15分钟的对话。

以上只是对策划过程如何工作的简要概述。我们建议寻求对该过程这一部分的一些帮助或者指导，因为它可能会十分复杂，仔细调整常常也是必需的。

这一反复过程和发布策划分别要每两个星期和每三个月进行一次。

重要的成功因素

• 在反复中期进行一次检查——尽早检查小组在反复中期的进展情况。
• 估计就是这样——小组一开始的估计常常会偏离甚远——开发人员都是乐观主义者！但是随着小组进展到新的反复并适应这一过程，估计（的准确性）或者速度（小组工作有多快）就会确定下来。
• 昨天的天气——一旦完成了一个反复，你将对小组的速度有一个粗略的概念——两个星期里可以交付多少素材。这就是小组认可的在未来两周里的速度和小组工作量。随着小组的成熟，具备更好地进行估计的能力，你的速度可能会提高，然后固定在一个稳定的速度上。
• 速度不是一根棍子——而是对管理者的提醒——速度不是用来鞭打小组的大棒；它是用来测量自然波动的。
• 决策——客户或者客户小组必须具有决策权，或者能够迅速进行决策，尤其是在需要变化或者适应的时候。
• 协商的意愿——客户必须愿意就范围等内容进行协商。这才是敏捷开发的工作方式：就范围进行协商，排列最具业务价值的功能的优先顺序。

敏捷开发里的策划可能会很困难，所以我们建议你去寻求一些帮助，并花时间来完成它。

保持高效——第四步
逐步推进这一过程的最佳方法之一是有一个在现场的客户。最理想的方法是让客户坐在小组成员当中，这样就可以随时回答问题。这限制了开发人员的随意猜想。此外，在现场的客户能够以最快的速度回答开发人员的疑问。

这并不意味着这个客户不去从事他的“日常”工作，而是说他就在周围准备好回答问题。即使隔着一层楼也会影响沟通。要进行面对面的对话，而不是用电话或者电子邮件。

显然，设置现场客户并不总是可能的，在这种情况下，他应该尽可能地接近小组，并尽可能地参加每日例会。如果这也不可能，那么你就要让他参加日常会议——至少一周一次——以确保你在不断地去的反馈意见和沟通。

对反馈和沟通的增加也需要定期进行回顾。这最好应该在每个反复结尾的时候进行。这样的回顾能够让小组有机会坐下来检查上一个反复，并弄清楚什么做得好、什么做得不好，以及下一次能够把什么做得更好。应该问三个问题：什么有用？什么没有用？我们要改进什么？

重要的成功因素

• 现场与否？——现场客户或许会带来一些问题，但是如果可能的话还是要找一个现场客户。如果无法实现，就要寻找其他的途径来确保定期的沟通。
• 回顾——把在每次反复结束的时候进行回顾作为一条纪律定来下，并把人们的想法付诸行动。

我们刚刚更加仔细地探讨了《上篇》里第一个图表的外层圆环，它需要所有参与者的同意。这可能是敏捷开发里最困难的一部分，但是它能够很好地协调业务和IT，而且其好处不仅对于业务而且对于IT也是很有价值的。

总结
尽管在本系列里我们向你讲解了如何一步步地培养敏捷软件开发的能力，以及如何从内到外树立开发人员的信心，然后是开发小组的信心，最后是整个项目小组的信心。从在Exoftware公司的经验可以看出，很多公司都选择为某个项目建立一个完整的敏捷开发实验小组，并让一个指导老师手把手地帮助小组。如果你选择这一方法，你将具有从所有做法直接获得好处的优势，此外，它将给你适应你具体环境的有价值的信息。简单地说有：

实验性的敏捷软件开发——如何开始
你的目标是什么？
评估你现在所处的位置以及你想要去哪里，这对于使用敏捷开发做法来说是至关重要的。这将帮助你确定希望取得的预期成果。对其的外部评估常常也是很有用的，因为它们将为处理你的问题提供一个客观的视角。

实验性的敏捷开发
虽然我们已经叙述了开发敏捷开发的一种方法，但是在一个项目上引导实现敏捷开发是理解敏捷开发方法是否适用于你的机构的最佳方法，它还会帮助你了解如何适应自己的环境。

测量标准
如果可能的话，你要在项目开始前或者在实现敏捷开发做法之前收集一些测量标准。即使这些标准来自于其他的项目，它们也将有助于为敏捷开发已经实现的内容提供一个良好的基准。你还要确保能够在敏捷开发项目过程中以及之后收集到一些高标准的测量标准。缺陷率、测试内容或者最终期限都是很好的且简单易行的高标准测量标准。

环境
要明白实验性的敏捷开发可能要求对你的物理环境进行一些改变。例如，开放的工作空间是敏捷开发真正起效的必要条件。

寻求帮助
外部的帮助能够指导你的实验性项目迈向成功。它能够帮助你理解你在哪里以及你想去哪里，并且能够向你指明如何让敏捷开发适应你的环境，从而到达这一目标。此外，外部帮助可以确保小组集中精力回答随时出现的问题。为将敏捷开发应用到其他工程小组里而树立一个业务案例也是十分重要的。

Brian Swan是Exoftware公司教授敏捷开发的指导老师。他在敏捷开发的技术和管理方面具有相当丰富的经验，曾经带领很多小组成功地转换到了敏捷开发，并以敏捷开发的思想和做法来培训开发人员和管理人员。他在Exoftware公司和在敏捷开发方面的工作使他到过很多公司，并对其开发小组产生了持续的、积极的影响。Brian先前的经验还包括担任Napier大学的讲师，讲授软件开发和人机互动。Brian可以通过电子邮件联系上。