敏捷软件开发[中篇]

作者:Brian Swan 10/5/2005
出自: http://www.zdnet.com.cn/developer/code/story/0,3800066897,39375772,00.htm 

我们已经了解了敏捷开发如何影响每一个开发人员个体，那么现在我们可以来看看整个开发小组如何采用敏捷开发的做法。

在《敏捷软件开发》上中下系列的<上篇>里，我们探讨了开发人员做法，也回顾了技术优势如何大幅提高软件质量。第一部分把重点主要放在了测试－编码－重整循环上。现在我们转到中间一个圆环，看看敏捷开发做法如何在小组这一层次发挥作用。

让小组高效工作——小组做法
一旦每个开发人员都在紧密围绕中心圆环的反馈循环工作时，我们就可以看看整个开发小组能够如何以更加敏捷的方式工作。小组这一层次的做法是敏捷开发的核心，因为它们能够显示出小组成员可以如何更加高效地一起工作并推动共同进行技术决策。我们将分别从四个方面来讨论小组的这种改变——设定基调、基于小组的代码编写标准、提高和保持效率、采用“统一小组”方式（包括与开发小组直接相关的东西）的首要步骤。我们给你举的例子来自于3Q Solutions公司，这是一家生产财物管理系统并完全使用敏捷开发方法的软件公司。

设定基调——第一步
敏捷软件开发的一个中心思想是小组朝着一个共同的目标工作。尽管很多流程都提倡小组工作，但是敏捷开发（真正）融合了支持小组工作的做法，并将小组工作放到了日常做法里。在开始讨论小组做法之前，我们需要先为小组设定一个基调，让他们开始感觉更像是一个真正的小组。

开放的工作空间
为更加开放的、基于小组的敏捷开发方式设定基调的一种最佳方法是为小组创造一种开放的工作空间（open workplace）。这意味着要建立一个或多个开放的区域，并尽最大可能进行沟通和合作。你想要专门了解什么样的环境能够让配对编程更容易。小格间和办公室是与敏捷开发开放工作空间格格不入的，所以应该避免其出现。在一家与Exoftware有合作关系的公司里，开放空间区域只被用于工作，里面只有用于配对编程、集成和构建软件的机器。其它的所有区域都留给带有Internet连接和电话的个人计算机。如果你有这样的空间，这就是应该考虑的东西，因为它有助于清楚地表明“当我们在工作区的时候，我们在工作”。

不要低估开放的工作空间对于小组的重要性——这就是为什么我们将其作为第一步的原因。下面的一幅照片就是是3Q Solutions开发小组的工作空间。

 

就如上面图画所显示的，构建服务器能够向小组提供额外的信息。

 

重要的成功因素

• • 自动化——这需要成为一个自动化的过程。否则你将不得不专门找一个开发人员来维持构建过程——这可不是一个有意思的工作。首先就要营造环境，取得设备和实现自动化。
  • TCR和配对编程——对于这一层次的集成工作，小组必须按照测试－编码－重整循环来进行，这样他们才有信心保证所有的问题只会发生在集成过程里。如果没有TCR循环，这一部分的过程将会非常困难。
  • 按部就班——就像这个小标题说的，不慌不忙地从简单的地方开始，然后随着时间的推移来逐步改进——尤其是在代码编写标准这一块。

 

保持高效率——第三步
就如我们在《上篇》里说的，敏捷开发过程是一项工作强度很大的编程方式。除此之外，软件开发本身就压力重重，而小组累垮的可能性非常高。

可持续的步伐意味着开发小组现在和未来的工作都将非常艰苦。加班不是我们希望鼓励的事情，尽管有的时候需要如此。如果小组不得不加班工作，那么我们想要尝试将可持续步伐里的加班时间控制在一到两周而不是一到两个月。再强调一遍，敏捷开发是一项强度很大的工作；配对编程要求很多交互和重视，测试－编码－重整循环也是如此。尽管敏捷开发会引发我们小组的最大潜能，但是我们需要清楚很多时候的大量加班会累垮整个小组的风险。

重要的成功因素
这是管理者必须十分清楚的一个领域。确保小组在整个项目里保持合理的步伐是其主要职责。

开始转移到统一小组——第四步
有的人可能认为Metaphor的概念应该来得更早一些，但是我们建议在这一阶段快结束的时候才引入它，因为这是我们首次提到客户／业务方（customer／business）。Metaphor是客户与开发人员之间系统的通用语言。它看起来可能不重要，但是以Exoftware的政府顾客为例，开发小组一般都把业务方（也就是定义系统需求的人）当作客户。但是对于业务方而言，“客户”指的是最终用户。这就导致开发人员和“业务方”之间的困惑和挫折。

Metaphor的作用不只是一门通用语言——它还与上下文和对系统是什么的高层次理解有关。在这里我们能够采取步骤做到真正地与我们的业务合作伙伴沟通并共享共同的目标。3Q公司使用一种叫做Adaptor Tree Hierarchy体系，它通过一门客户／业务方共同认可的语言给予开发人员一个广阔的系统视野。例如：

ThreeQData

• todaysDate
• marriage
  • spouse
  • economicindicators
  • client
    • lossofincomestory
      • annualincome
      • coveramortisationeroision
      • ...
    • managedfundstory
    • pensionstory

这个树形结构的每一部分都可以扩展出更多细节，能够轻易地改变，并提供一个很好的系统视角，同为整个小组提供一门通用的语言。

 

重要的成功因素

• 坚持到底——只有当你坚持使用的时候Metaphor才会有效。它将会成为日常语言的一部分，但是适应它需要花时间。
• 从基本的开始——从Metaphor的基本框架开始，了解它，使用它，然后以此为基础来创建它。
• 取得帮助——让尽可能多的相关业务方／客户参与Metaphor的创建——让其他人尽早参与进来是至关重要的。

敏捷开发的小组做法的目的是帮助小组把重点放在集体工作上，并理解其共有的做法和目标。尽管有的做法，比如代码编写标准，能够在隔离的情况下完成，但是如果与具体的开发人员做法，例如测试－编码－重整和配对编程结合起来，那么这些小组做法将发挥最大效用。

本系列的最后一部分将探讨开发人员小组如何开始同客户方／业务构成“统一小组”。

 

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