漫天风把细小的事情做到极致

敏捷团队要能达到自管理的能力，除了理解敏捷的理念和必要的素质外，其实空间（协作空间）环境也很重要。信息辐射器（Information Radiator，The Ideal Agile Workspace）中介绍了好几种常用的方式，稍微整理一下，分享如下：

1. Sprint Backlog，这是整个项目团队自我管理的核心。实时反映项目的状况。通过 Sprint Backlog可以了解到任务分配，项目进展（燃尽图），缺陷，困难等等。Sprint Backlog上的不同类任务用不同颜色区分，一目了然。很容易就可以了解任务分配，Sprint的瓶颈以及困难（用红色表示）在哪里。
2. 故事墙，较为长期的开发计划。
3. Build Monitor， 一般包括一个红绿灯，一个大屏幕显示器。红绿灯监控主分支的持续集成系统的状况，如果构建失败（可能 原因包括编译错误，单元测试问题，冒烟测试以及回归测试问题等），立刻显示红灯，同时也会发出声音（XXXX project is “still” btoken）。大屏幕显示器主要是反映一些大家主要关注的持续集成项目的状态。其实如果采取按组件做分支的方式，每个Scrum Team还可以有一个熔岩灯，用来监控团队分支的状态。
4. 各种白板，团队成员可以用白板对具体需求，具体模块架构以及其实现进行讨论。然后将白板的内容作公示，指导团队成员的日常开发。如果发现问题，随时修改白板的内容。
5. 团队日历，主要是表明一些重要的日期以及成员请假情况。
6. 系统框架图，招贴画。团队成员可以了解整个系统的高层次的系统架构。
7. 各种手绘表格。用于过程改进或者其他作用的手绘表格，常见的例子有在回顾会议里面发现的问题；测试用例数目；测试覆盖率；结对编程轮换表；要重构的函数；Burnup Chart等。
8. 产品愿景，团队成员对具体开发中遇到的问题，需要做决定的时候，能够基于愿景做出取舍。
9. 系统词汇表，统一语言和隐喻。只有开发团队和客户用同样的语言，才会减少沟通中的误解。
10. 团队可根据自身的需求设计更多的信息辐射器。

信息化工作空间的关键是信息，最终目的是使任何人只要进入一个团队的工作区域，就可以立刻了解项目的进度，项目的运行情况，现有的问 题，每个人现在的任务，一些团队需要改进的地方等等。大家每天来上班，只要看一下板，立刻就知道自己该做什么。不光是团队成员，一些 Stakeholder也可以到工作区域去看一看信息辐射器，了解最新的状况。即使Stakeholder不能到现场，只要经常发送一些照片，或者经常参 加一些演示，效果也会不错。实现信息化工作空间的前提是团队成员要坐在一起，如果不能坐在一起，那只能通过一些电子手段进行同步。当然信息辐射器也不能太 多，太多也会导致混乱。

今天例会的时候听到Lion将要介绍yahoo敏捷实践的东东，网上搜索了一把，发现yahoo其实已经实施3年多了，而且据说获得了比较大的成功，3年后，Yahoo!已经有了200多个开发团队在使用敏捷实践。明天记得找boots 要点资料哈。此外，这本书是yahoo人写的，可以考虑购买看看哦：敏捷估计与规划

Scrum 产生的收益在开发团队经验中体现在不同的方面。在Yahoo!公司，在上18 个月中将近50 个开发项目采用Scrum，一共近600 人参与，采用Scrum 的团队数量在快速发展。这些项目从客户界面，网页设计如Yahoo! Photos, 到后端基础构造服务如服务上百万客户的Yahoo!Mail；从全新的产品如Yahoo! Podcasts，其利用Scrum 作为从构思到发布的流程（并获得该年度同类产品的Webby 奖），到一些增量的项目，包括开发新的部件并维修bug 和其他的维护工作；我们也利用Scrum 来分配分布式项目。每一个季度，我们对Yahoo!公司每一位Scrum 的使用者进行调查（包括产品所有者，开发团队成员，ScrumMaster 和这些人员的经理），并让他们将Scrum 于以前的开发方式做一对比。我们正在准备Yahoo!公司的深入调查报告，以下是相关的资料显示：

• 生产效率：68%回复显示采用Scrum 后生产效率提高（4 分或5 分在以5 分为衡量标准上）；5%显示采用Scrum 后生产效率降低（1 分或2 分在以5 分为衡量标准上）；27%显示采用Scrum 后无变化（3 分在以5 分为衡量标准上）。
• 团队精神：52%回复显示采用Scrum 后团队精神加强；9%显示采用Scrum 后团队精神减弱；39%显示采用Scrum 后无变化。
• 适应性：63%回复显示采用Scrum 后适应性加强；4%显示采用Scrum 后适应性减弱；33%显示采用Scrum 后无变化。
• 责任性：62%回复显示采用Scrum 后责任性加强；6%显示采用Scrum 后责任性减弱；32%显示采用Scrum 后无变化。
• 协作能力：81%回复显示采用Scrum 后协作能力加强；1%显示采用Scrum 后协作能力减弱；18%显示采用Scrum 后无变化。
• 在产品所有者估算下，开发团队的生产效率平均提高了36%
• 85%的开发团队成员表示如果其拥有决策权的前提下，将会继续使用Scrum。

ADTmag.com的编辑Kurt Mackie与Gabrielle Benefield（这些团队的核心组织者之一）就Scrum在Yahoo中的应用情况进行了对话。

Kurt问到，是什么原因促使Yahoo!转向了敏捷和Scrum开发，Benefield说：

有些公司一起步官僚习气就很严重。可是，Yahoo刚开始时规模很小、发展很快，他们最开始的做法非常敏捷，几个创始人坐在一间屋子里面开发软件。然而当规模扩大到某种需要更加频繁交流的阶段后，他们提出了使用传统的瀑布流程……但是在我们这种创业型文化中，它很难实现。我们的员工都很聪明，富有创新能力，他们习惯于时时刻刻提出自己的想法。瀑布流程对他们来说太古板太做作了，它降低了他们的效率。于是，团队中的一名工程师开始给大家布道，他说：“嘿，我们应该更敏捷一些”……所以在2005年2月，我们就启动了一个敏捷开发的试点项目。

随后Benefield又谈到其在实施敏捷开发的过程中的一些心得体会：

…… 那些我曾参与其中的敏捷团队，尤其是那些对其进行过大量辅导的团队，他们的生产力很容易就提升了200～300%。有些团队做的尤为出色，因为他们真正地 实施了敏捷。某些团队可能由于没经过太多的辅导和训练，或存在系统性的阻碍，所以改进情况就不那么明显。但从整体来看——包括那些最差的情况——生产力的 提升幅度大约在35～36%之间。综合所有情况考虑，这个估算还是相当保守的。

Kurt又问道：“在敏捷/Scrum的世界里，变化是好事吗？”Benefield坦然道：

我 们 的想法发生变化是很自然的事情。当你开始构建一个产品并看到一些结果后，你就会想做出一些改变。我们不会说“你不能改它”，我们是在拥抱变化。在互联网上 面，你不得不拥有快速变化的能力。举个例子来说，当我们搭建Yahoo邮件的大规模存储后端时，中途有一个竞争对手提供了容量更庞大的邮箱存储空间。我们 当时必须迅速做出响应，假如当时我们用的是传统的瀑布模型的话，我们势必无计可施，但最终我们成功地对抗了对手的威胁。在开发产品的过程中，我们曾一次又 一次面临这样的局面。

当其被问到开发中想法常常变化所带来的影响时，Benefield说道：

敏 捷有着严格的纪律。对于类似所有的代码都有全方位的测试这种事情，我们是纪律严明的，所以你有勇气去尝试变化，理解变化所造成 的影响。这里不会出现那种所有人都在尝试自己念头的无序状态。我们允许团队进行自组织，各种想法从团队中源源涌出。但管理层和产品所有者对选用哪种想法来 实施有着最终决定权，会从业务层面上来制定优先级，因为他们对其了如指掌。他们从根本上控制着何时发布产品、发布哪些功能，而团队自己决定如何完成工作。

在最后，Benefield以下面这段话结束了本次访谈：

在Yahoo，我们永远不会命令别人使用这个过程。我认为过程的优点要靠它自身体现出来，人们也应该有选择的自由。敏捷正在Yahoo中慢慢取得主导地位……我相信，随着时间的推移，为了能够在竞争中真正胜出，敏捷会是公司最佳的选择。