Scrum敏捷团队的必备技能

作者 Prasad Prabhakaran 译者 金明 发布于 2010年11月8日

领域

过程 & 实践,

语言 & 开发

主题

团队协作 ,

敏捷实施 ,

分布式团队 ,

协作 ,

持续集成 ,

单元测试 ,

企业级敏捷 ,

团队工作 ,

自动化操作 ,

敏捷技术 ,

生产力 ,

测试 ,

敏捷 ,

重构 ,

测试驱动开发

分享到

本文介绍了Scrum敏捷项目的独特性，并且定义了一个成功团队的必备特征。本文最后对高效Scrum团队所需要的干预提出了建议。

敏捷项目的工程独特性

几个方面使得敏捷项目迥异于使用传统方法的软件项目，其中包括：

1. 设置开发环境
   

   在传统项目中，团队可以投入充分的时间来设置开发环境；而在敏捷团队里面，他们需要从第一刻时间起就能产出。根据我们的经验，我们认识到缺乏设置开发环境的相关文档是设置环境如此耗时的一个关键原因。第二个关键原因是在设置过程中涉及的手工步骤数。在第0次sprint，我们必须记录每一件开发人员必须做了才能开始编写代码，并集成团队其他人工作的小事。

2. 自动构建
   

   让我们尽早失败！我们领悟到，手工构建可能既脆弱，又特定于某一台机器，而且当时间耗费在手工构建的基础工作上面时，开发和测试的时间就被挤占掉了。除去最小的项目，自动构建过程对于每一个项目都是必不可少的。我们认识到，即使需要抽出时间来创建自动构建的环境，你以后是能把这些时间赚回来的。这也使得我们更易于确保项目有一个人人共有的标准化构建。我们曾经使用过的主要工具包括Ant、Maven和Nant。

3. 持续集成
   

   根据我们过去的经验，我们领悟到，等到最后的几个星期才去把不同团队成员的代码集成到一起是一个灾难。如果你已经拥有了自动构建，接下来的事情就是持续集成。当然，版本控制（或者软件配置管理——另一个更为正式的和令人印象深刻的名字）是自动构建和持续集成环境的前提。我们学到的一个重要教训是，你越快识别出集成的错误，你就能越快地解决这些问题。我们曾经使用过的主要工具包括 CruiseControl、CruiseControl.Net和Bamboo。

4. 单元测试
   

   在高度流动的环境中，随着多个开发人员一起工作、需求的变更和优先级的不断变化，确保昨天可以运行的东西今天也能运行，这是至关重要的。此外，我们还要与集成出现的错误为战。一种方法（我们从艰难岁月中学习得来）是使用单元测试，这样代码的更改不会破坏现有的功能。我们也开始在开发编码之前编写单元测试用例。我们曾经使用过的主要工具包括JUnit（以及其他的xUnit工具如NUnit、HttpUnit等）和MockObjects。

5. 重构
   

   在传统的项目中，通常有一个人保护他们的代码库，直到代码集成阶段。但是在敏捷里面，我们持代码集体所有制的观点——所有的代码属于所有的开发人员，只要开发人员认为有必要，每个人都能不受约束地去改善代码。在一段时间里面，我们的代码库开始出现奇怪的行为——解决办法就是重构（感谢Martin Fowler在他的同名著作中把重构一词推广开来）。重构的本质归结为修改代码以改善代码的结构和清晰度，但不改变代码的功能。我们学到的一个重要教训是在重构代码之前使用单元测试作为安全网，我们曾经使用过的一些主要工具包括Eclipse、NetBeans、IntelliJ IDEA的和Visual Studio.NET。

敏捷项目的工程实践中有一些独特的东西，这是显而易见的，所以团队需要针对这些实践做好准备，并以之为导向。

在敏捷团队之中工作所必备的行为特征

由于敏捷团队不同于普通的团队，并且非常倚赖于有效果和有效率的沟通和快速执行，敏捷团队更需要使用软技能。如果我们意识到这一点，并积极鼓励使用这些特征和技能，我们可以使得敏捷团队更有价值和富有成效。

自组织往往倚赖于诸如正反馈、负反馈、深度探索和广度调研之间取得平衡以及多重互动的基本要素。根据我们的经验，团队可能由于许多文化和社会因素无法给予正确的反馈或者回避人与人之间的互动。

根据我个人的经验，这仍然是一个“神话”。我们总是倾向于患有“可预测性综合症”——如果我们做更多的规划，我们将更加功能预测。

团队需要有良好的纪律、有能力承担责任、尽忠尽责以及承担职责和所有权。

团队需要拥有的关键技能之一是有能力寻求帮助，并寻求他人的评价。在某些情形下，我们已经看到了“自我”因素表现为一个主要的障碍。

有些时候，承担责任，尽忠尽责和协作精神是理所当然的，但是根据以往的经验，为了这些能够出现，我们有时需要外部干预。

有些我们常常倾向于忽视的关键技能是积极主动、在激烈的环境中享受工作和易于适应新的形势和框架。

我们的大多数项目都是分布式的，这意味着在客户和服务供应商之间将会共同使用Scrum。在这种情况下，诸如管理多样化团队、时间管理、外交技巧和领导力等技能是非常关键的。

敏捷团队的成功“咒语”

对于任何一个希望成功和高效的敏捷项目，团队需要对向同侪学习（不管资历和专业知识）表现出更大的热情和正确的态度。必须保证一个无畏表达的安全网，这样才会展现出真正的友情，而这反过来会增强团队成员对团队目标的关注，而不是“哪些由我来做”？

结论

根据我个人的经验和观察，对于提高生产率所需的技能，敏捷项目与传统项目有所不同。本文定义了团队提高生产率所需的行为和技术技能。具有这些“delta” 特征的人应该具备了合适的行为和技术技能，这些技能使得他们在敏捷项目中的工作能够富有成效。对于这些技能的总结请见下表。

技能表

作者简介

Prasad，拥有10年的IT服务行业经验，他第一次接触敏捷项目是在2005年微软的一个项目；从那时起，他为许多公司如GE、思科、可口可乐等，针对敏捷及其变体提供了解决方案开发、培训、咨询以及指导。目前他正在Symphony Services的敏捷实验室担任经理。Symphony40％的项目都是关于敏捷或其不同的形式，并且自2004年起就通过敏捷为客户提供商务的关键价值。你可以通过pprabhak@symphonsysv.com与他联系。

查看英文原文：Skills for Scrum Agile Teams

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

1. 返回顶部

   QA具体职责是什么？

   发表人 Jiang Lanvige

   SCRUM里里的自动构建和布署是归于QA团队的？
   能具体讲下QA在这里的作用吗？

   回复

2. 返回顶部

   Re: QA具体职责是什么？

   发表人 峻申 吴

   你的问题充分暴露了你不清楚QA和QC的区别。或许还暴露了你从来没有做过测试方面的工作。呵呵

   回复

3. 返回顶部

   Re: QA具体职责是什么？

   发表人 majesty name

   在不同的公司，对QA可能有不同的理解，这里的QA团队应该是测试团队，而不是CMMI中的QA团队。

   回复

4. 返回顶部

   Re: QA具体职责是什么？

   发表人 吕 新科

   啊，我也不懂。什么是QA，什么是QC，吴同学顺便帮忙科普一下啊...

   回复

5. 返回顶部

   Re: QA具体职责是什么？

   发表人 黄 雯

   我是这样理解的 QA是参与项目，帮组完善项目的 QC只是监控项目的最终完成质量

   回复

6. 返回顶部

   三个人的小团队，可以用Scrum吗？

   发表人 wang hongsheng

   我们是一家很小的软件公司，软件开发人员(包括我在内)只有三位，平常基本上是每个人负责一个独立的软件在开发，像我们这么小的软件团队，能用得上Scrum吗？

   回复

7. 返回顶部

   Re: QA具体职责是什么？

   发表人 chen Joseph

   QA是强调质量和过程改进的。
   QC是针对产品本身的。
   QA是项目之外的群体，QC是项目内的。
   QA在外资是一个独立的部门，强调过程和质量。
   QC是一般是团队内部的，针对功能和case来测试。
   很多公司只有QA的概念，其实CMMI和PMI中的QA概念完全不同。大多数公司的QA其实在做QC的工作。
   外资企业三权分立，开发、QA、行政。QC的工作其实是开发团队中的。
   如果运用 TDD，QA和QC的概念就更清晰了。

   回复

8. 返回顶部

   Re: QA具体职责是什么？

   发表人 峻申 吴

   darkranger.javaeye.com/blog/367872
   这里有你想知道的答案
   欢迎大家讨论。

   回复

9. 返回顶部

   Re: 三个人的小团队，可以用Scrum吗？

   发表人 谢 尚磊

   个人认为，虽然负责着不同的项目，但是与共同工作的人有一定的沟通在有困惑或者问题的时候相互帮助，也是重要的。
   这些都是开发人员之间的交流与沟通。也是敏捷开发最看重的一点。
   况且你不能确定各自独立开发而不进行合作的事情一直不会出现吧？
   所以在此之前有一定的了解和信任还有帮助，总是好的。

   回复