一个IBM敏捷团队的一周

引言


近些年来,敏捷软件开发方法似乎在神州大地上突然变得火热起来,越来越多的软件团队开始了敏捷软件开发的转型。迭代开发增量开发持续集成ScrumXP等概念和实践越来越深入人心。但纵观现实,真正把敏捷玩得非常转的团队却并不多见。每个团队都有自己的问题,而优秀的团队似乎也很难找寻。

俗话说:“榜样的力量是无穷的。” 本文介绍一个IBM敏捷团队的一天,让我们一起来看看,优秀的团队是如何玩转敏捷的。由于某些原因,这里隐去了团队及产品名称。为便于描述,本文使用第一人称进行讲述。

背景


我们是一个典型的“两个披萨团队” (Two Pizzas Team)[1]。所谓“两个披萨团队”是指,团队的人数规模,刚好能够吃完两个披萨,既不剩余浪费,又不饿肚子。我们认为,这样的规模能够足够好地让他们自己保持敏捷。本团队负责开发和支持 IBM 的一个重要产品,由设计师、产品经理和开发人员组成。在实践上,通过采用测试驱动开发(Test-Driven Development,TDD),并强制要求100%的自动化测试覆盖率,团队已经将每周发现的缺陷数量降低了大约60%,从过去一个周7.2个缺陷降低到了3个左右,并带来了大约20%的团队开发速率提升。

我们的Sprint长度为“一周”5个工作日。对此,我们的产品经理如是说:

作为产品经理,使用“一周”的Sprint长度使我有了很大的灵活性,当某些新情况出现时,我可以及时改变和调整产品待办事项列表(Product Backlog Item,PBI)的优先级。我们可以按时交付一大票东西,我们可以这么做,却无需受困于一个不可能完成的计划,而且能够根据实际情况,快速做出反应,及时转换业务重点。

敏捷的一周


周一

我们召开了Sprint规划会议。在会上,我们把整个团队承诺这个Sprint要完成的所有工作进行分解。这些任务都是基于实际的业务需求,而且数量刚刚够我们在这个Sprint里合理地完成它们。在整个星期,我们每天都举行15分钟的站会,以便于大家了解团队里每一个成员正在做的事情,以及为Sprint 目标所正在做的贡献。我们的发布经理说:

通过举行每日Scrum站会,每个人都知道别人在做什么。我们可以快速地向有问题的地方倾斜资源,问题和阻碍也能快速而高效地得以解决。

周二

要真正变得敏捷,一部分工作就是要为下一步做什么做好规划。因此,周二,产品经理会与我们产品的相关干系人会面,以便理解哪些任务(工作)需要团队在下一周(下一个Sprint)里优先完成。产品经理将会在本周周五将这些信息传递给开发团队。

周三

周三是我们觉得过得最快的一天。如果突然出现什么问题,我们会立即解决掉它们。团队负责人经常让陷入困境、为某个问题而苦苦挣扎的程序员与另一个对该特定领域有深刻了解的程序员进行结对。这非常有助于我们整体上作为一个团队,相互协作地解决问题。

周四

周四,全体团队成员都要参加代码审查(Code Review)会议,会上不能指责、贬低别人的代码。在代码审查会上,我们会考虑这一周我们要交付的代码中,哪些是好的例子继续发扬,哪些是不好的例子努力改进。这么做能让我们的团队从错误中吸取经验教训,并为未来的工作指引正确方向。

周五

周五,我们会举行一次 “Sprint 结束”演示会,向产品的相关干系人和其他希望从我们的工作中学习点儿什么的团队进行演示。演示之后,我们会以一个“回顾会议”结束一周的工作。回顾会议是我们团队专门进行反省的时间,我们会对这周刚刚完成的工作进行反思。

当然,当团队一起工作时,新想法会不断涌现。我们会鼓励团队成员将他们的新想法,与所有其他我们希望在不远的将来进行研究或完成的任务一起,添加到待办事项列表(backlog)中去。

这种工作模式迫使我们每周都要以一个清晰定义的业务目标开始本周的工作。它让我们在进行开发工作时保持正确的前进方向。最后,它也使每一个团队成员都能为产品设计贡献力量,并自主决定我们创造最终解决方案的方法

对于敏捷开发方法,团队的技术负责人如是说:

通过提升所交付的软件代码的质量,敏捷不仅提升了我们有效地进行规划的能力,还让我们有更多的时间付诸于用户故事的实现。

总结


现在,回头看看这个团队所使用的敏捷。

从上面的描述中,我们不难发现使用了如下实践:

  • 两个披萨团队 —— Two Pizzas Team
  • 测试驱动开发 —— TDD
  • 100%自动化测试覆盖 —— 100% Automation Test Coverage
  • “一周”的Sprint长度 —— One Week Sprint
  • 产品待办事项列表 —— Product Backlog
  • Sprint 规划会议 —— Sprint Planning meeting
  • Sprint 迭代目标 —— Sprint Goal
  • 每日15分钟站会 —— Daily Stand-Up meeting
  • 产品待办事项管理 —— “基于实际的业务需求”、 “与我们产品的相关干系人会面”、“及时改变和调整”
  • 管理技术债 —— Technical Debt
  • 结对编程 —— Pair Programming
  • 代码审查 —— Code Review
  • Sprint 结束演示会议 —— Sprint Review meeting
  • Sprint回顾会议 —— Sprint Retrospective meeting
  • 自组织团队 —— Self-directed team
  • 跨职能团队 —— Cross Functional Team
  • 整体团队 —— Whole Team,One Team