Borland 的敏捷之旅

  • 李剑

2009 年 1 月 22 日

话题:敏捷Scrum架构文化 & 方法

Chuck Maples 前不久在 Agilejournal 网站上写了一篇文章,介绍了Borland 的敏捷之旅

他一开始这样描述 Borland 的做法:

Borland 从 06 年 2 月开始项目试点,想看看敏捷方法能不能帮助他们达成三个核心目标:缩短交付时间、增强整体生产力、鼓励客户参与开发过程,从而确保产品可以满足市场需要。这个项目非常成功,团队提前十天交付了项目,而且比一开始计划的时候增加了很多新特性。

……

跟大多数向敏捷迁移的组织一样,Borland 也面临着巨大的挑战,它走在一个激进的产品路线图上,同时还要做出规模不小的过程改造。我们的业务目标是向 市场提供革新式的软件产品,而市场压力、客户期待、业务需求等等一系列情况都逼得我们没法“暂停”下来调整过程。所以我们就得一边开车一边给车换轮胎。现 在 Borland 的敏捷迁移已经到了最红火的时刻——有 70% 的团队在用敏捷方法,收益巨大。

然后他逐一列出了 Borland 的成功经验:

构建自组织团队并赋予他们足够的权力

  • 雇一个全职的敏捷专家
  • 把 ScrumMaster 和开发经理的角色合并
  • 关注传统的“功能领导”
把敏捷误解为混乱;透明的重要性

  • 1 号混乱清理器:每日站立会议
  • 使用有意义的、简明扼要的文档
  • 在回顾中孕育改进
  • 在企业环境中推行、支持协作,公开开发过程
不仅仅是验收:引入性能测试



转向敏捷开发并不意味着不需要做性能测试、伸缩性测试。在传统开发模型中,这种测试都是到了开发周期结束的时候才做——这个时间真是再糟 不过了……为了保证性能测试可以迭代式的进行,开发团队不得不放慢脚步,学会如何编写代码才能保证可以一直进行性能测试。首先,我们让所有团队都明白一 点:性能是团队要担当的责任。即便一段代码可以工作,但是如果性能有问题的话,那也不能看做“完成”。一开始开发代码的速度是慢了一点,不过整体的开发速 度和质量却得到了提升。

后来我们就把性能测试作为构建验证过程的一部分,我们用每天的最后一个构建产物做性能测试,测试代码中最复杂的部分。我们还建立了一个性能基准点,它可以 随着应用程序复杂性的变化而变化。这样我们就可以用每晚的构建产物来比较事务响应时间,早早的发现问题、解决问题。我们把性能测试写成一个简单的用户故事,放到每一个 sprint 里面——“作为 xx 应用的用户,当系统中有 xx 个用户的时候,我希望执行 xx 操作的性能不受影响”……

可见性

自然,敏捷会提高可见性。每日站立会议和 sprint 回顾都可以很好的展示出项目和团队的工作状态。但是在企业中,这种可见性不能仅仅限于团队房间内。

正确的工具

把敏捷扩展到企业中少不了工具。如果你可以为团队提供一些适合他们使用,可以提高工作效率,有利于协作的工具,他们会用起来的。





执行层的承诺

让敏捷为业务服务,敏捷不是目的

在文章的末尾,作者还列出了实施敏捷之后 Borland 公司获得的收益:

  • 每年的产品交付数量都比上一年增长了 100%
  • 与策略性客户的关系有了显著改进,他们已经参与了 50 多个 sprint 回顾
  • 减少了管理和计划的成本,平均每个 sprint 少了 15 小时。
  • 从前副总裁和董事每月 6 天花在每个产品组身上的听取汇报时间节省了出来。
  • 提高了产品质量,每个交付中的问题数量减少了 50%
  • 提高了团队生产率和斗志,员工离职率降低。

从前 InfoQ 中文站还报道过Yahoo!应用 Scrum 的成功经验,还有Scrum 在中国的实施情况报告,欢迎继续关注 InfoQ 中文站敏捷社区,获取一手敏捷资讯,成功 / 失败经验交流,专家经验分享。

敏捷Scrum架构文化 & 方法