领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
Borland的敏捷之旅
作者 李剑 发布于 2009年1月22日
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中文站敏捷社区，获取一手敏捷资讯，成功/失败经验交流，专家经验分享。
李剑 李剑──ThoughtWorks高级咨询师，在持续集成、重构等领域具有丰富的经验；多次为国内大型企业敏捷组织转型提供咨询和培训服务。
没有回复
关注此讨论 回复