Worktile 首席架构师详解：如何让敏捷更好地落地？
作者介绍：徐子岩， Worktile首席架构师，前微软高级项目经理、微软MVP，《实战Windows Azure》一书作者，十五年软件开发经历，包括企业级软件的架构设计、开发和测试等。项目管理及敏捷开发经验非常丰富。
什么是敏捷开发？
首先大家要明白的是，敏捷开发不是具体的指导性方法， 它是一种观点和价值观 ，敏捷开发提供了一种思维方法，但真正的敏捷开发并不告诉大家怎么做。
敏捷开发的精髓是 响应变化，不去控制变化 ，而以往的项目管理是要控制变化，以实现整个开发周期是可控的。敏捷开发产生以前，由于软件开发和传统行业天然的有着鸿沟，几乎用尽了以往所有的经验办法，都没法做到详实的很精确的控制。有人便提出了，既然不能控制变化，何不去响应这种变化，敏捷宣言也由此产生。
敏捷宣言推崇合作、变化 ，并不推崇计划、谈判和条条框框的东西。
因为敏捷开发实际上只是个概念，而怎么落实这个概念呢，怎么转变成敏捷团队呢，就需要运用敏捷的各种方法论和实践。
敏捷的方法论有很多，例如，源于丰田公司的精益软件开发，新兴测试方式-探索性测试，测试驱动开发等。我们今天重点要讲的是Scrum，也是敏捷很重要的一个方法论。
什么是Scrum？
Scrum是敏捷软件开发的方法学，它包括了一系列实践和预定义角色的过程骨架 ，Scrum真正定义了要达成敏捷的流程和方法。
简单来说，你想要成为Scrum团队，你都需要什么样的角色、做什么样的事、开什么样的会……只要按照Scrum的方法论去做，你就能变成Scrum团队，也就是敏捷团队。
总的来说，敏捷提供了一种思维，一种很美好的未来，而Scrum则让敏捷更好地落地。
Scrum团队一般有三种角色： Product Owner、Scrum Master、 Development Team 。
标准的Scrum运行流程是，Product Owner基于Vision，创建多个Product Backblog，即为达成Vision所要完成的各种功能需求，然后Product Backblog会被拆分成一个个Sprint，真正的Scrum是在一个个Sprint周期之内，不断地完善产品。
Scrum开始的时候，会有一个 Sprint Planning 会议，Product Owner、Scrum Master和 Dev Team 会一起计划Sprint要做什么，Product Owner会基于Product Backblog的优先级，筛选出最应该做的Backblog，然后让成员给Backblog打分，并在达成共识后决定某个Backblog的规模。
打完分以后，Product Owner拿次一级的Backblog续打分，直到Scrum成员认为该Sprint周期只能做这些功能为止。并在Sprint Planing会议上，确定所有的Sprint内容。
接着就开始 Sprint周期 ，一般是1到4周，由团队成员去设计、编码、测试等。成员每天会执行Daily Scrum会议，说明三件事： 今天干了什么、明天要干什么、有什么困难 。
1到4周的Sprint完成后，会进入到 Sprint Review ，每个成员用Demo演示自己负责的Backblog，让Product Owner评估是否完成。
敏捷开发遵循了一个原则，所有最终完成的东西对客户都要是有意义的。 在Scrum里面，每个Sprint做完了的Backblog，都是能让用户完整使用的功能。对于开发人员来讲，用Demo的方式去展示成果展示，他会非常重视质量。
所有这些结束后，还会有一个 复盘会 ，整个团队沟通上个Sprint执行中的问题和改进点，这就是一个完整的Sprint的流程。
我们是怎么做的？
在Scrum流程中，总会遇到各式各样的问题，有些是团队的问题，有些是成员的问题，接下来我会讲我所在的团队是怎么执行Scrum的。
1、原则
对产品有用的就做 ，或对客户(用户) 有用的就做，其他的都不做。 这也是评估有些事情做与不做唯一的标准。
2、角色
整个Scrum团队的角色划分，Product Owner一般是产品经理或产品总监，有的时候也可能是客户，很少是Dev Manager、公司高管。
Scrum Master 一般是开发团队中一人兼职，也可能是公司成立的Scrum Master团队，具体的工作包括组织各类会议和把控会议高效进行，确保团队按照Scrum的标准在执行。
然后是Dev Team ，不止是开发，也可能包括测试、运维、架构、设计等，所有最终给客户产出的人都是Dev Team的一员。可参考文章：《scrum团队内部的角色与分工》
这只是一个参考， 敏捷的精髓是响应各类变化，发现不合适的时候也可以改掉 。
我们团队在Worktile里面，对于各类角色，会有 权限划分 ，比方说研发工程师的角色不能创建需求、产品经理的角色不能创建任务等等。
当然，有的团队对权限划分非常细，有的团队会比较OPEN。而在Worktile7.0里面，是可以基于自己的团队风格、氛围去配置的。
3、周期
Scrum周期这块，内部发布的周期我们一般是两周，也建议团队刚开始敏捷的时候，可以用两周一个Sprint，再根据节假日调整成3周。在版本发布之前，可能有的团队需要一段时间集中测试（回归测试、压力测试等）。通过Release Sprint应对，做测试、改Bug等。
下图为Worktile内部的Sprint，右侧的Product Backblog可直接拉到左侧的迭代需求里，未安排的BUG也可拉到当前迭代缺陷里，做Sprint规划。
4、规模-Effort
至于Scrum里说到的规模-Effort，即 某个工作的复杂度 。标准的Scrum里，在第一个Sprint中，估算一个功能点的工作量，多轮的Sprint后，团队会慢慢的达成一个共识。但是大部分团队可能无法按此执行。
我们团队Effort的定义，这里不是一个指导意见，只是一个实践，是团队普通能力工程师1天的工作量 。Effort最大值是32，Work Item经过多个Sprint都无法完成，导致这些Sprint都是失败的，这会让Scrum很难继续推进。
5、Scrum会议
Scrum有哪些会议？
关于如何更好地开Scrum会议，可以参考文章：《Worktile带你学敏捷：如何更好地执行Scrum会议？》
会议遵循的一些规则：
下图为Worktile内部每周的Scrum会议：
总结一下， 敏捷其实是一个观点，不是我们去控制变化，而是我们去顺应变化 。敏捷不会告诉我们怎么做，具体怎么做是Scrum要做的事情，包含持续的进行改进。
同时敏捷自己也要敏捷起来，觉得用得对的地方要持续去使用，觉得不对的地方需要调整，并执行一次让团队评估有没有效果。最后一点， 永远只做有用的东西，对客户有用、对产品有用、对团队有用的东西！
