敏捷实践中的好品质

作者 Gunjan Doshi & Deborah Hartmann Preuss 译者 乔梁 发布于 2007年6月7日

领域

过程 & 实践

主题

团队工作 ,

变更 ,

敏捷

标签

回顾 ,

持续改进 ,

计划

假如你的团队已经使用敏捷或者敏捷过程的某些内容有几个月了，无论是开发人员、产品经理、架构师、QA，还是管理层，组织中的每个人可能都非常喜欢敏捷的这次首航。此时，你可以认为，你的团队已经发现了一个合适的过程，并可以沿着这个过程走下去了。可需要提醒你一下：“别那么快下结论！如果不小心的话，这个快乐的聚会可能会以你始料不及的速度结束。”

本文聚焦于某些行为模式，它会使团队最大程度地认识到敏捷首航的好处，并保持该过程中得到的经验。本文的前提是：你已经在你的组织中执行了敏捷过程。

成功的实践者会注意到：敏捷更倚重于纪律，而不是几个天才。因此，实践的重中之重就是：把“人”放在第一位，聚焦于价值，频繁地交付高质量的工作成果，通过有节奏重构进行持续改进。一般的团队只要有纪律性，即使在敏捷实践的初期，它也会获得相当大的成效。如果我们这样做了，随着时间的推移，我们的言行就会积极地推动创建并重建我们团队和项目所处的环境。

很多人都知道下面的学习三步法¹：

• 第一步，“照葫芦画瓢”，尽管没能完全理解规则，依然按着它做事。
• 第二步，“边做边想”，随着不断地实践这些规则并从所犯的错误中总结教训，开始思考我们到底在做什么，并观察如何在更深的层次上实践这些规则，看它们之间的关系是什么样的，当前面对的困难是什么。
• 第三步，“无招胜有招”，当我们掌握了规则以后，我们就会忘记这些实践，而只要做我们认为是正确的那些事情，使模式不留痕迹地融入到我们的工作中。

当我们坚持实践敏捷的法则（如结对编程、TDD、编写用户故事、进行计划游戏）时，我们就建立了由这些实践互交互补所形成的网，而这个网产生的效果要超出这几个实践单独产生的效果之和（译者注：1+1>2）。这些效果是我们始料不及的。一旦我们知道了这些益处，接下来的问题就是：我们怎样才能保持这些收益并持续改进呢？这个问题的答案就是回顾（retrospective），它不仅使我们知道做错了什么，还有做对了什么：即我们要巩固和继续坚持的东西。

输入“Agile Karma”，可以得到从过去的示例中总结出下面的结论：

敏捷品质：是指一些根本原则，这些原则是依据那些项目参与者在每个迭代中总结前一个迭代的做法（也可能是错误的做法）并对其进行改善所获得的经验提炼出来的。

好的效果对每个团队都不同，对每个团队中的不同的人也不同。因为尽管根本原则都一样，但每个团队都会找到不同的方法来实践它们。这就是为什么说回顾（retrospectives）很重要，不仅要看什么做得不好，还要回答“做对了什么？”或“我们如何才能保持现有好的做法？”这样可以帮助团队保持士气，表扬他们所做的事，不知不觉中，这就成了团队走向成功的关键因素。

我们先分析一些例子，就会总结出：对于客户团队来说，什么是好的敏捷品质，不同的团队角色如何开展工作。那么，你们团队的好的共同品质是什么样的呢？

客户的好品质

客户是产品或项目的“司机”，保持并调整着方向，与团队讨论它，并提供反馈。通常客户团队由产品经理、信息架构师、QA、可用性工程师等组成。

• 牵记最终的目标：敏捷软件开发并不是建议你“只了解某个迭代内的业务，而不对整体业务进行全面了解”。针对其产品，你应该有一个清晰明了且完整的故事列表（story-board）。持续地沟通，使目标更清晰。
• 在迭代前做好作业： 在迭代会议之前，你应该完成以下内容：
  • 想清楚这次迭代的目标。
  • 清晰地定义故事。每个故事应该：
    • 有清晰且具体的目标。
    • 有清晰的可接受性准则。
  • 对于开发人员要进行开发的故事（Story），在迭代计划之前要准备好测试用例。
  • 如果是新产品，应该有交互和流程图，比如纸上画的原型或条框。
• 尊重团队的迭代计划：一旦确定了迭代计划，不要改变迭代范围，在迭代中不许加入新的特性。
• 坚持频繁演示：在新的迭代开始之前，团队向客户展示上个迭代结束后的成果。在整个迭代中，客户能够与开发人员一起工作，并在下一个迭代开始之前验收本次迭代中做好的Story。

开发人员的好品质

开发团队不仅包括写代码的人，还包括那些为创建迭代结束时的可交付产物提供他们的各种技能的人。这个团队决定如何提供客户所要求的功能。

• 把客户看作伙伴：在写一个Story之前，你要真正理解客户想要什么，并给客户提供更好的建议和设计。一旦完成了Story，向客户解释并得到用户的反馈。
• 尽早沟通：不到等到迭代或发布的最后时刻再沟通相关的问题和风险。如果你发现一些东西改变了你的评估，马上通知你的项目经理。
• 更新计划：每天根据你的评估以及Story的状态来更新迭代计划。
• 尊重业务优先级：与你们不断交付的业务价值相比，业务可以有它自己的议程。当你不能确定业务的优先级时，就去问，不要假设。
• 尊重代码基线的质量(不要偷懒)
  • 坚持测试先行的开发及重构
  • 心中默念“不做重复代码”的咒语。
  • 频繁持续集成
  • 在提交代码之前，运行所有的测试
  • 不要对失败的建构置之不理
  • 不要轻视架构
• 保持团队协作
  • 频繁地要求得到信息
  • 即使你很忙，也要为他人提供帮助
  • 承担别人不想承担的任务
  • 公开承认队友的贡献

内部教练或技术Leader的好品质

与对Agile的了解程度相比，技术Leader可能更了解团队及技术。在行政位置上，这可能使他们比顾问更有优势，可能会弥补他们在敏捷实践方面的经验不足。

• 坚决地指导：这是个艰巨的工作，尤其是与外部顾问指导相比。只要有耐心，随着时间的推移，你最终会被大家接受。不要放弃－做正确的事一定会得到大家的尊重。
• 锤炼你的技术能力：为了成为一个发挥效力的教练，坚持作为团队的一员是非常重要的。如果你的技术能力不济的话，每天提高一点儿。
• 不要读得太多：在读下一本书之前，先理解其基本思想，并把它们传达给整个团队。
• 发现良师益友：很多资深教练从其他人的帮助中获益。反过来，他们也愿意回答你的问题并提出自己的见解。吸收这种不同见解可能是明智之举。如果在本地找不到敏捷兴趣小组，那在线论坛就可能是一个寻求帮助的好去处。
• 设法让关键人员和管理层“拧成一股绳”：不要丧失你的威信。你还是要对你的老板和其它重要的人员负责。设法让他们团结在一起，使新的方法得到他们的信任。

咨询顾问的好品质

咨询顾问是一个有经验的“受雇枪手”，他可以带领团队或组织战胜采纳敏捷过程中所要面对的挑战。这样可以缩短学习曲线，并使其平滑过度。但它不能代替团队的自学习性。一旦顾问离开团队，自学习性会保持并指导这个过程。

• 根据需求进行定制：学习定制过程，以便满足业务目标且适应公司的文化，而且要有充分的理由。如果公司文化不允许迭代，那就先尝试两个星期的迭代，但一定要确保管理层认识到了这种折衷方案带来的风险。
• 多听，多学：一个高效的教练一定是一个好听众和学生。不要冲上来就把你的想法和知识强加于团队。
• 认识到批评者的价值：是的，有些人不喜欢敏捷，但你不能忽视他们的想法而只关心支持你的人的想法。批评者会提供一些重要的信息，而且可能成为有价值的团队成员。
• 握住你的枪：当团队坚持要放弃某个基本实践时，问他们是否知道"放弃这个实践的话，如何才能补偿它带来的损失。"帮助团队应对它带来的风险。如果他们坚持这样做，最好说"我以前没这么做过。让我们一起来解决这个问题"，而不是给团队一个自己都不知道会带来什么结果的建议。
• 谦恭地提供帮助：保护并恢复所有参与者的自尊。
• 知道什么时候转到幕后：当团队开始采纳敏捷并且变得更主动时，知道如何转到幕后。如果必要的话，让他们自己做决定，让他们自己从错误中学习。

项目经理的好品质

实践证明，这个角色很难定义（在不同的上下文中会有不同的意思，而且差别还比较大）它常常是几个角色的混合体。我们决定对这个角色另眼相看，现在把它排除在这篇文章之外。（同时,我们也希望得到读者的建议。)

上层管理者的好品质

每个项目中，上层管理者都是一个关键的项目干系人，但也是最少控制交付物的人。通过对实施工作提供强有力的支持，管理者可以保持沟通渠道通畅，并对所出现的重大障碍做出快速反应。

• 公开支持这个行动：在你的公司会议或季度会议上，公开表态，坚决支持这个过程。这样将会促进敏捷的引入。
• 别期望出现奇迹：“我花了很多钱，却什么也没得到！”。团队需要时间去定制和培养他们的过程，最终才能看到结果。组织级的挑战越大，花费的时间就越长。要时刻牢记：再好的过程也不能解决团队本身的问题。
• 避免日期驱动的诱惑：“就这么定啦（Just get it done）”的口头禅(bravado)需要改为“让我们研究一下，是否通过改变工作范围来满足这个日期要求”。
• 不要草率地在公司范围内全面推行：初步尝试取得成功以后，你可能会热衷于在全组织范围内推广这个过程。在推行之前，一定要确保你真正地理解了这种方法的内涵和约束。
• 在谈论敏捷之前一定花时间去真正地理解它：既然团队是敏捷的了，你就会想与您的朋友或其它公司讨论敏捷。而此时可能是您多读一些相关知识的最佳时间。在这一点上，您与那些比您多知道一些敏捷知识的人沟通时，敏捷兴趣小组成员会对您很有帮助。

希望这会使您考虑一些问题，例如：既然当您感到压力却不想放弃时，你的团队在做什么呢？为什么不在下一个回顾（retrospective）上花些时间，使您的团队从您这里得到更多的信息呢？当事情发生变化时，别忘记时刻去更新它的状态。您知道事情一定是会有变化的!

作者简介

Gunjan Doshi是Community Connect Inc.负责产品开发及过程改进的副总裁。该公司是一个social networking公司，公司地址在纽约市。他负责管理和领导30人的团队，包括开发人员、项目经理和质量保证人员。他先后为不同的组织中的几个团队推行并定制了敏捷方法论。他喜欢不断地学习和成长。他的Blog是http://www.gunjandoshi.com。

Deborah Hartmann 是一个敏捷从业者和教练，生活在多伦多，在加拿大和美国工作。Deborah 喜欢使工作充满价值和乐趣。从2006年3月开始，她一直是InfoQ.com的敏捷社区编辑。

---

¹Alistair Cockburn 是将Aikido 模型介绍给敏捷社区的先驱成员之一，这个模型被称为“shu-ha-ri”。

注意： 为了简单起见，我们用了下面的术语：
迭代（Iteration）：在Scrum中叫做"sprint"
客户（Customer）：在Scrum中叫做"product owner"
教练（Coach）：相当于Scrum Master or team lead，尽管有时候项目经理也充当这个角色；
每日立会（Standup meetings）：每天的项目状态交流会议，在Scrum中叫做“daily scrums”。

原文链接：Good Agile Karma

---

译者简介：乔梁，BJUG成员，在IT领域工作多年，先后从事过软件开发、架构设计、技术管理等工作，目前从事项目管理工作。关心软件技术领域发展，对软件生命周期管理及过程改进方面的内容很感兴趣，对敏捷方法论亦有所了解。他的个人Blog为：http://blog.csdn.net/tony1130。参与InfoQ中文站建设，请邮件至china-editorial@infoq.com。

• 更早的 >