【转】来自《轻松scrum之旅》的敏捷开发总结

敏捷开发的核心价值观是，软件开发最重要的是给用户提供有价值的、可以工作的软件。如何保证提供有价值的软件，是通过反馈机制来完成的。这一点，我们体会很深。自从采用敏捷开发以后，我们比以前更有意识地希望得到各种反馈，包括来自外部和内部的。我们产品的大部分功能都直接来自客户的需求，并按优先级排序。我们有Beta 项目，在开发中期就给客户试用并得到反馈。并且我们在公司的内部网上也部署了最新的版本，并不断更新，得到了大量的用户反馈。可以工作的软件，含义就是软件是可交付给客户使用的。我们每4 周一个Sprint，即迭代。在迭代结束的时候，就会产生一个可以交付给客户使用的版本，这个版本里包含所有新增功能的实现，并且通过所有的测试。这样带来的好处就是可以大大缩短软件开发周期，提高软件质量。并且在临近发布的后期，我们也没有出现特别紧张的现象。每个Sprint 即将结束时的Sprint评审会议可以帮助我们关注可以工作的软件，并能及时得到反馈。

每日Scrum 会议，我们觉得是非常有效的。团队所有成员都通过这个会议同步信息，每天的问题都能及时发现，并能用最快的速度解决。另外，能够形成一种相互之间的压力，每个人要对自己当天承诺要完成的事情负责，每天都不敢怠慢。过去我们通常只是一周开一次例会，汇报一下状态，效率就低多了。Daily Scrum 还给整个团队带来了凝聚力，每个人都觉得自己是团队不可缺少的一员。

采用敏捷开发，对于分布式开发的团队来说，沟通也大大加强了。我们就是这种情况。我们有北京和加拿大两个研发团队，还有分散在世界各地的商业合作伙伴协助开发。采用敏捷促使我们不再过分依赖于文档进行交流，我们主要通过电话、视频，甚至现场进行沟通。另外，我们使用了一些Scrum管理工具，如ScrumWorks 和Rational Team Concert 这些可视化的工具，可以清楚地看到每一个远程团队任何时候的状态，比如Sprint Backlog、Task 的分工及完成情况以及燃烧曲线的情况等，这些都大大提高了沟通的效率和效果。即使是本地的团队，沟通也比以前更有效。比如我们特意安排整个团队都坐在一起，大家的交流变得非常方便。我们有意识地简化文档，而更多采用面对面的交流。交流多了，工作也变得更有趣了。

我们采用敏捷开发，测试很早就介入了，这样就再也不会出现半年多测试部门无事可做，一旦介入便疯狂加班的情况。开发人员也不会由于要更改很久以前的Bug，而把很多时间和精力花费在回忆上。而且一旦发现重大的问题，也不会出现疯狂加班的情况。由于测试的提早介入，开发人员可以立即解决问题，还能够有效地调动测试人员的积极性和主动性，让他们也参与到软件的设计中来。在敏捷开发里，测试和开发的交流更多了。测试和开发不再是两个孤立的部门，而是真正意义上的团队，这有效避免了过去测试和开发之间一些消极的争斗和不合作的局面。

在文档管理方面，我们摒弃了过去烦冗的文档管理，节省了大量的时间和精力。需求、计划以及设计文档我们通常只保留一个一页多的版本，并且放在Wiki 这样的敏捷文档系统上，任何人、任何时候都可以更新它。而且，由于文档只记录必要的信息，所以不需要再像过去那样花大量时间保持同步，不断修改。

由于采用敏捷开发，测试人员的积极性大大提高。过去测试人员一直处于被动的角色，而现在，在开发中就需要测试人员的大量参与，参与需求、参与设计。测试人员对产品的影响力大大增强，也更有利于他们的个人成长。

自我管理的团队是敏捷里的一个比较“酷”的理念，我们也实施得很好。我们的老板也由一开始事无巨细地干预到最后完全变成了教练的角色。老板轻松了，从琐碎的项目管理中解放出来，把精力放到了更重要的带领我们进行技术创新和帮助每个人更快地成长上。我们每个团队成员也更放松，没有人指指点点，自己有更多的决策权，可以调动更大的潜能。每个人在召开Spring 计划会议的时候可以领取自己最感兴趣的任务。事实上，真正运行良好并自我管理的团队，效率远远高于过去习惯被动地接受命令的团队。

Scrum 回顾会议也帮助我们不断地提高。我们采用了一个叫做“Team Pulse Survey”的模版作为我们Retrospective 的框架。在每一个迭代结束后，Retrospective 框架都帮助我们总结哪些地方做得不好，哪些地方做得好。当总结成为一种思维习惯的时候，想不提高都难。

现在都讲可持续发展，软件开发也一样。如果加班可以有效果，那也只限于一个短的时间范围内。但是任何公司、任何软件产品都不希望只是短命的。所以，我们必须有条不紊、有张有弛，决不提倡加班。我们也曾经加过班，但是发现效果并不好，出现代码质量下降、人员士气低落、精力无法集中等问题，这些都是得不偿失的。后来我们没有再加班，而且由于代码质量高，人员士气也跟着高涨，总体效率当然会比以前有很大的提高。

由于每个 Backlog 都有预设的Story Point，因此过去每个迭代一共做多少个Story Point 就非常清楚。我们可以通过以往Sprint 的速率来计划当前的Sprint，这些数据会帮助我们制定当前Sprint 需要完成的工作量，即放入多少个Story。

敏捷开发的工具，我们用了很多。Scrum 项目管理工具，向大家推荐IBM Rational Team Concert 和ScrumWorks。这两种工具都可以帮助我们有效地管理Scrum 流程，尤其适合地理位置不在一起的多个团队使用，能够大大增强敏捷流程的可视化。在分布式开发的情况下，如果没有好的管理工具，很难想象会如何敏捷起来。至于敏捷的工程实践、管理Build 方面，我们采用了IBM Rational BuildForge 这个强大的持续集成工具。另外，我们还用了结对编程工具ECF、自动重构和自动单元测试工具JUnit 等。

下面向大家推荐一个我们实施Scrum 这种敏捷方法的清单列表。首先是拥有一个具有优先级顺序的Product Backlog，每个Backlog 用User Story 来进行描述，制定它的优先级和预估完成工作量。其次是确定团队构成，确定团队是地理分布的还是在同一个位置，最好不要把地理位置不同的一群人算作一个团队。团队成员由开发、测试、文档人员组成，选出一个Scrum Master，每个团队人数最好是3～10 人。接下来，确定每个Sprint 的周期。根据项目情况的不同，两周到两个月都是可以的，但最好不要超过两个月。然后，召开Sprint 计划会议，把每个Sprint 的要做的工作从Product Backlog中按照优先级顺序排序，确定需求，将任务进一步分解，如人员分工等。无论是否采用敏捷或者Scrum，从现在开始就可以尝试每日Scrum 会议，每天选择固定的时间和固定的地点，15 分钟就可以了。如果选在下班前开这个会，那么每个人陈述的3 个问题就是：今天我做了什么？明天我打算做什么？我遇到了哪些困难？应该从Sprint 的第1 天就开始准备测试用例。当Sprint 结束时，不但功能完成，测试也将同时结束。在每个Sprint 结束的时候召开Sprint 评审会议和Sprint 回顾会议。根据团队情况，不断采用敏捷的工程实践，比如Unit Test、Code Review、结对编程、持续集成等。多学习别人的经验。网上有很多资源，还有很多书籍。

Agile 并不是银弹，它不可能解决你所有的问题。Agile 本身并不是一种软件开发流程，而是一种理念，一组行为方法。只有真正理解了Agile 的精髓，才能真正Agile。

You don’t do Agile, you are Agile。