我与敏捷

2013年，我和几位小伙伴一起在公司接触了敏捷开发，当时还没有对敏捷体系的认知，只是跟随的技术负责人一起开站会，赶进度。到今天，回首居然已有了7年。

我对于敏捷的认知的加深，前后共有三次。

第一次，参加了优普丰的培训，获得了scrum master的证书，从“野路子”发展成“持证上岗”。

第二次，在前东家接触到thoughworks的一众大佬，认识到开发配合敏捷是要有相关工具支持的。

第三次，是在当前公司敏捷文化下的思考，在当前体制下，到底如何做敏捷？

什么是敏捷？

敏捷有很多流派，大家比较熟悉的有Scrum和XP，另外还有如Crystal，iScrum，太极敏捷等流派。我这边主要谈Scrum框架。

Ken Schwaber和Jeff Sutherland 开发并维护Scrum指南，里面很详细了说明了Scrum游戏规则，这里只做个简要说明。如需查看全文，请点击：https://mp.weixin.qq.com/s/mGAlH-sImN6-6LbGJx17TA

Scrum定义：Scrum是轻量级的、容易理解的、难以精通的；Scrum是一个框架在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。

Scrum包含5个事件：Sprint，Sprint计划会议、每日Scrum站会、Sprint评审会议、Sprint回顾会议；

Scrum包含3个角色：产品负责人、开发团队、Scrum Master；

Scrum包含3个资产：产品待办列表、Sprint待办列表、产品增量；

Scrum包含5个价值观：专注、勇气、开放、尊重、承诺；

对于敏捷的普遍误区

1、只有精英才能够使用敏捷并成功迭代出好的产品。

这个问题其实Ken Schwaber早在千禧年初，就已经回答。

Ken Schwaber（以下为原文翻译）：

2001年正式宣布敏捷时，有很多评论家说，敏捷真的很不错，如果你有杰出的工程师团队，他们使用优秀的工程工具，运用正确的工程实践，全面了解业务范围和技术领域，不受任何干扰，并且拥有所有需要的资源，那么就可以使用Scrum。

没错，像这样的人可以在每个迭代都构建产品，很棒！但是，Scrum只对傻子起作用，你可以找来一些痴呆的人，可能他们没有上过学，不知道计算机科学，不了解软件工程绩效，相互憎恨，不知道业务范围，使用糟糕的工程工具，他们生产出的每个增量一律是废品，这也很棒！

每个迭代的过程中，我们的开发情况，所有人都可以随时了解情况，Scrum的要点部分就是透明，并且我们从一开始就知道。

这就是Scrum的魅力，我们不用像瀑布开发一样，6个月过去了，大家都在祈祷没有问题。Scrum是一个框架，就像所有的方法论一样，任何人都可以来使用。

2、自己（Scrum Master）可以指导团队成员每一项工作和改进，并对自己的意见信心满满。

Scrum Master是Scrum团队中的服务型领导。Scrum Master帮助Scrum团队外的人员了解他们如何与Scrum团队交互是有益的，通过改变他们与Scrum团队的互动方式来最大化Scrum团队所创造的价值。

Scrum的开发团队应该是自我改进的。Why？

整个软件开发中，开发团队才是真正的执行者，他们分析需求、设计软件、编写工程、测试保障、运维上线，是最一线的工作者。我们这边大多数的Scrum Master是不具备这些专业能力的。一个不具备开发团队专业能力的人来指挥甚至命令团队按照他的想法来落地，只会适得其反。这是一个典型的外行逼死内行的例子。

3、运用敏捷之后，所有的迭代都会非常的快。

这个锅，翻译的兄弟应该背背好。相对于快，敏捷更应该被人们（领导）记住的应该是灵活，通过敏捷框架，我们可以应对瞬息变化的市场，而不是我们用了一个框架，原来写2000行代码的程序员就能成为写10000行代码的软件工程师了。另外，通过敏捷，开发效率确实可以提升，但这是建立在各种工具、流程、体系、基本功训练上的。有时间我会单独写一篇关于敏捷落地开发团队需要的支撑。

4、我们敏捷了，可以和设计文档、需求文档、开发文档说再见了。

敏捷软件开发宣言中确实说过“工作的软件高于详尽的文档”，但这不等价于不需要写文档。文档的必要性取决于团队的决策，如果团队觉得当前类型的story需要流程、需要时序图，那么开发团队就应该将他们编写出来。当然，文档存在的形式可以是多种多样的，比如：详细的word文档，process on上的时序图，黑板绘制的草图（团队成员拍照保留）。我们可以简化形式，但不应高举敏捷旗号，大行不作为之实。