我们是这样转向敏捷开发的

“瀑布式开发是一种老旧的，正在过时的计算机软件开发方法。最开始的软件行业普遍采用这种方法，但是这种方法套用自传统工业生产，不适应计算机软件开发的具体情况。”来自百度百科的一段话，确实它用在软件开发会出现很多问题。
使用瀑布式开发经历过2、3个产品的研发，问题很有共同性，《30天软件开发：告别瀑布拥抱敏捷》帮我完美总结：

版本发布所需时间越来越长。
无法按时发布。
在版本发布的最后阶段，软件达到稳定状态需要的时间越来越长。
制订计划的时间太长，而且计划得不准确。
在版本发布中期很难做更改。
质量持续恶化。
“死亡行军”损伤士气。

正因为这些问题，所以渴望开发流程的改变。偶然（或许是必然的结果，只是时间点的问题）的机会，让我的团队转向敏捷开发。

敏捷开发是什么？

本节内容基本上都是摘自《30天软件开发：告别瀑布拥抱敏捷》。
敏捷开发以用户的需求进化为核心，拥抱变化，采用快速迭代、循序渐进的方法进行软件开发。衡量整个过程的三个指标：

生产效益：指团队开发的效率。
质量：指产品增量的质量。
价值：指开发出来的产品增量的市场价值。

流程如图：

从「愿景」开始，只有时时刻刻铭记迭代的初心才不会偏离航向。
由产品经理梳理需求，形成「产品待办列表」。
在「Sprint计划会议」上，产品及开发团队一起讨论出最优先的需求形成「Sprint待办列表」进入迭代。
在定期的迭代周期中，每天同一时间同一地点的进行「每日站会」，交流上一天做什么，下一天做什么，遇到什么问题，其目的是让团队知道整体进度。期间禁止超期（包括插入其他事务）或修改验收标准。
最终形成一份可发布的产品增量。
客户、产品经理、开发人员等涉及人员进行「Spring评审会议」，主要是开发人员进行Demo演示，产品经理验收需求是否达标，未达标则产生新的产品待办项。客户观察是否达到自己的要求。
最后，开发团队自己进行「Sprint回顾会议」，对该迭代出现的问题进行分析及总结，避免下一迭代中出现。

文章最后附上敏捷开发的3个角色、3个工作和5个事件。

我们怎么落实？

一般来说，都是团队按照一个标准流程执行。因为团队中都是对敏捷开发一知半解的，这样的话，得统一学习，然后一起制定流程，然后在按照流程执行。这样既耽误时间又耽误版本发布。所以我们就反过来，让流程也来个迭代。
要实施敏捷开发，对人的要求挺高，能不能落实很大取决于Scrum Master，落实得顺不顺利很大取决于开发团队，落实得好不好很大取决于Scrum Master和开发团队。

第一阶段：人

让团队有敏捷开发基础，这样反过来执行流程，很多问题就迎刃而解。

自身

作为团队的Leader，也就理所当然的落在Scrum Master这个角色上。我得从以下方面提升：

首先，得有一个接纳、积极的态度。打心里坚信我可以带着这个团队成功转型。遇到问题，我有这个能力解决。
其次，提高自我认知、我在团队的定位及与下属的关系。我花1个月时间精读《30天软件开发：告别瀑布拥抱敏捷》，以它作为蓝本进行入门。我也认识到我的主要精力应该由考虑方案变成帮助团队实现他们的任务。他们，才是主力！
最后，我得改变方式。我慢慢让自己淡出，把机会留给团队的每一个人。我让他们自己提方案，我参与评估。我审视团队的每个人，我把迭代过程中看到的问题记录，然后找合适的时间跟他们面对面并且很直接的沟通。

团队

由于团队人员能力参差不齐，做事方式也都不一样。比较有共性的就是养成惰性习惯，所以主要从两方面提升：

提高执行力，聚焦于任务。遇到问题给他们引导技术方向，梳理方法以提高执行力。死盯任务，卡死2周的迭代时间，曾经好几次加班到深夜2、3点，目标就是想表明一个态度——时间是神圣的，不可侵犯，来打消惰性及退缩。
提高「自组织」。执行力提高之后，慢慢培养他们的积极性，把主观能动性激发出来，让他们自己思考。

第二阶段：流程

一开始，我们的流程只有：需求评审->迭代->发布，加上拖了很久的总结。刚好我们团队接到公司一个内部工具的新研发，我们在这个工具的开发上尝试。当进度和质量可控时，我们调整流程让它往标准的敏捷开发靠近。
我们把总结放在迭代时间内，不在隔很久。当我们信心满满，我们落实在旧的产品研发上时，虽然团队还是这个团队，但是因为团队接手旧的产品也才2、3个月，所以需求评估有误，导致延期一周。从结果上看我们失败了，但是这个延期我们深入的分析，总结出很多改进的点，其中就包括需求评估不明确。所以我们在流程上，把需求评审拆成产品经理讲需求，然后开发团队理解需求、理需求涉及代码的系统流程、最后需求反讲产品经理确认。在接下来的迭代中，果然按时发布。之后，我们又陆陆续续加入「每日站会」、「Sprint目标」、「Sprint评审会议」，还制定了完成核心编码、开始测试、完成编码的参考时间点。也规范了最终除了产品增量还有「测试用例报告」、「核心功能测试报告」、「Sprint回顾报告」、「项目日志」和「版本迭代检查表」。在加入每一项之前，我都会跟团队分享它是什么，有什么作用。最终制定了我们的流程规范v0.1：

当然，在过程中会遇到很多问题，比如任务做不完，我们预留了几个需求作为弹性需求。再比如开发团队觉得需求不够明确，我们就跟产品经理沟通等等。方法总比问题多，拥抱问题，不断迭代优化。

第三阶段：规范化

这个阶段处于计划阶段，还未执行。打算严格按照流程规范来执行，然后对每一个过程进行精细化管理，形成规范。这样后续可以通过一些源数据进行分析问题。

我们遵循什么原则

原则及是一种态度！之前有一个版本在周五时面临难产，一位开发人员理不清一段逻辑的思路，而下一周还没安排事情。此时他很大程度上觉得下周做也没事。但是我坚持，我帮他写了逻辑（不会出现下次），那天我们测试到凌晨3、4点搞定。之后跟他私底下聊天，他说确实是觉得下周做也没事，但是经过那晚，一直压着的压力一下子释放，然后版本又可以发布，感觉挺好。所以，原则还是要有。
原则一、时间和质量不可侵犯
保证质量的前提下，2周一个版本的迭代时间不会变，可以调整需求。
原则二、坚持原则一
时时刻刻提醒自己和团队、坚持原则一。

总结

敏捷开发有人说好，有人说不好，对于我们来说，没有好与不好，只有适合不适合。能让我们团队成长，持续产出，就是适合的。我们会坚持，也坚信我们可以做到v1.0。

附

敏捷开发的3个角色

产品负责人：负责最大化产品以及开发团队工作的价值。决定每个迭代要开发的功能，并在每个Sprint结束时评审软件增量是否符合要求。

清晰地描述产品待办列表项
对产品待办列表项进行排序，最好地实现目标和使命。
优化开发团队所执行工作的价值。
确保产品待办列表对所有人可见、透明、清晰，并且显示Scum团队的下一步工作。
确保开发团队对产品待办列表项有足够的理解。

开发团队：负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。

他们是自组织的，没有人（即使是Srcum Master都不可以）告诉开发团队如何把产品待办事项列表变成潜在可发布的功能增量。
开发团队是跨职能的。团队作为一个整体，拥有开发产品增量所需要的全部技能。
Scrum不认可开发团队成员的头衔，无论承担哪种工作他们都叫做开发人员。此规则无例外。
Scrum不认可开发团队中的所谓“子团队”，无论是测试还是业务分析的成员都不能划分为“子团队”。此规则无例外。
开发团队中的每个成员可以有特长和专注领域，但是责任属于整个开发团队。

Scrum Master：负责保证项目按照Scrum的方式进行。要确保Scrum团队遵循Scrum的理论、实践和规则。

（1）服务于产品负责人

找到有效管理产品待办列表的技巧
帮助 Scrum团队理解“清晰精炼的产品待办列表项”的重要性
在经验主义的环境中理解长期的产品规划
确保产品负责人懂得如何安排产品待办列表项来最大化价值
理解并实践敏捷
按要求或需要引导 Scrum事件

（2）服务于开发团队

在自组织和跨职能方面给予团队指导
协助开发团队开发高价值的产品
移除开发团队工作中的障碍
按要求或需要引导 Scrum事件
在 Scrum还未被完全采纳和理解的组织环境中指导开发团队

（3）服务于组织

带领并指导组织采用 Scrum。
在组织范围内计划 Scrum的实施。
帮助员工及相关干系人理解并实施 Scrum和经验型产品开发。
发起能够提升 Scrum团队生产效率的改变。
与其他 Scrum Master一起工作，增加组织中 Scrum实施的有效性。

敏捷开发的3个工作

产品待办列表

产品待办列表是一个有序的列表，其中包含一切产品可能需要的东西，也是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。
演进。待办列表是动态的，需要持续更新以反映出产品需要什么来保持其合理、有竞争力以及有用。只要产品存在，产品待办列表就存在。
产品待办列表列出了未来发布的产品在特性、功能、需求、改进和修复上所要进行的所有改变。产品待办列表项包含描述、次序、估算和价值。
随着产品的使用，价值的获取以及市场反馈的获得，产品待办列表变成了更大、更详尽的列表。因为需求永远不会停止改变，所以产品待办列表是个不断更新的工件。业务需求、市场形势和技术的变化都会引起产品待办列表的改变。
“产品待办列表细化”指的是为列表项补充细节，估算和排序。这是一个持续不断的过程，产品负责人和开发团队协作讨论产品待办列表项的细节，并对列表项进行评审和修改。何时如何进行细化的工作由 Scrum团队决定。细化的工作通常占用开发团队不超过 10%的时间。然而，产品负责人可以根据自己的判断随时更新产品待办列表。
排序越高的产品待办列表项通常比排序低的更清晰、更具体。根据更清晰的内容和更详尽的信息就能做出更准确的估算；排序越低，细节信息越少。
开发团队在接下来的 Sprint中将要进行开发的产品待办列表项是细化过的，因此，任一列表项都能够在 Sprint的时限内“完成”。我们把这些能够在 Sprint中“完成”的列表项称为“准备就绪的”（ Ready），它们将作为 Sprint计划会议中的待选列表项。
监控实现目标的进度，在任何时间，达成目标的剩余工作量是可以累加的。产品负责人至少要在每次 Sprint评审会议的时候追踪剩余工作总量。产品负责人比较这个数量与之前 Sprint评审时的剩余工作量，来评估在希望的时间点达成目标的进度。这个信息对所有的相关干系人都透明。

Sprint待办列表

一组为当前 Sprint选出的产品待办列表项，外加交付产品增量和实现 Sprint目标的计划。开发团队在 Sprint待办事项列表中预测哪些功能要包含在下一个增量中，以及交付这些功能到“完成”的增量中所需的工作。
当新工作出现时，开发团队需要将其追加到 Sprint待办列表中去。随着任务的进行或者完成，团队需要估算并更新剩余的工作量。如果计划中某个部分失去开发的意义，就可以将其删除。在 Sprint期间只有开发团队可以修改 Sprint待办列表。 Sprint待办列表是高度可见的，实时反映了团队计划在当前 Sprint内完成的工作，该列表由开发团队全权负责。
监控 Sprint进度，在Sprint中的任意时间点都可以计算 Sprint待办列表中所有剩余工作的总和。开发团队至少会在每日会站时跟踪剩余的工作量，预测达成 Sprint目标的可能性。团队通过在 Sprint中不断跟踪剩余的工作量来管理自己的进度。

产品增量

增量是一个 Sprint完成的所有产品待办列表项，以及之前所有 Sprint所产生的增量价值的总和。
在 Sprint的结尾，新的增量必须是“完成”的。这意味着它必须可用并且达到了 Scrum团队“完成”的定义的标准。
无论产品负责人是否决定真正发布它，增量必须可用。

敏捷开发的5个事件

Spring计划会议

目的是要为这个Sprint的工作做计划，这份计划由整个Scum团队共同确定。为期两周的Sprint的计划会议应该不能超过4个小时。Scrum Master确保会议顺利举行，并且每个参与者都明白会议的目的，同时还要教导大家遵守时间盒的规则。
（1）接下来的 Sprint交付的增量中要包含什么内容？

开发团队预测这个 Sprint中要开发的功能。
产品负责人讲解 Sprint的目标以及达成该目标所需要完成的产品待办列表项。
整个 Scrum团队为了更好地了解 Sprint的工作进行讨论。
Sprint会议的输入是：产品待办列表、最新的产品增量、开发团队在这个 Sprint中预计可接受的工作量和以往的表现。开发团队自己决定选择的待办列表项的数量。只有开发团队本身可以评估接下来的 Sprint可以完成什么工作。
在开发团队预测完这个 Sprint中可交付的产品待办列表项后， Scrum团队会制订一个 Sprint目标。
通过实现 Sprint产品待办列表可以达成 Sprint目标。

（2）要如何完成交付增量所需的工作？

设定了 Sprint目标并挑选出这个 Sprint要完成的产品待办列表项之后，开发团队将决定如何在 Sprint中把这些功能构建成“完成”的产品增量。
这个 Sprint中所选出的产品待办列表项以及它们的交付计划统称为 Sprint待办列表。
开发团队通常先由系统设计开始，设计把产品待办列表转换成可工作的产品增量所需要的工作。工作的大小或预估的工作量可能会不同。
在 Sprint计划会议中，开发团队已经挑选了足够的工作量，并且预计他们在即将到来的 Sprint中能够完成。
在会议结束前，开发团队所计划的 Sprint最初几天的工作被分解为工作量等于或少于一天的任务。开发团队自组织地领取 Sprint待办列表中的工作，领取工作在 Sprint计划会议和 Sprint期间按实际情况进行。
产品负责人对选定的产品待办列表项作出澄清，并协助团队权衡取舍。如果团队认为工作量过大或太小，就可以和产品负责人重新协商选择产品待办列表项。
开发团队也可以邀请其他人员参加会议，以获得技术或者领域知识方面的建议。
Sprint计划会议结束时，开发团队应该能够向产品负责人和 Scrum Master解释他们将如何以自组织团队的形式完成 Sprint目标并开发期望的产品增量。

还需要在会上制定Sprint目标，Sprint目标可以是为唯一功能服务的产品待办列表项的集合，也可以是能够促使开发团队向着同一目标而不是孤立的其他工作。

每日站会

一个以15分钟为限的事件，期间开发团队进行活动信息交流和计划接下来24小时的工作。每天在同一时间，同一地点举行。Scrum Master确保开发团队每日站会如期举行，开发团队自己则负责召开会议。 Scrum Master指导团队把会议控制在 15分钟内。Scrum Master强制执行每日站会的规则，即只有开发团队的成员才能参加每日站会。
会议上，每个开发团队成员都需要说明：

昨天我为开发团队达成 Sprint目标做了什么？
今天我准备如何帮助团队达成 Sprint目标？
有什么事情阻碍了我帮助团队达成 Sprint目标？

Sprint

周期大于或等于1周，小于或者等于一个月，其产出是“完成的”、可用的、潜在可发布的产品增量。Sprint的长度在整个开发过程中保持一致。Sprint由Sprint计划会议、每日Scrum站会、开发工作、Sprint评审会议和Sprint回顾会议构成。

不能做出有害于实现 Sprint目标实现的改变。
不能降低产品质量。
随着对信息掌握的增加，产品负责人和开发团队可以澄清或者重新商讨开发范围。

Sprint评审会议

用意在于检视增量，如果有需要的话还会调整产品待办列表。非正式会议，为期两周的Sprint的计划会议应该不能超过2个小时。Scrum Master确保会议顺利举行，并且每个参与者都明白会议的目的，同时还要教导大家遵守时间盒的规则。
Sprint评审会议的目的：

在 Sprint评审会议中， Scrum团队和相关干系人讨论 Sprint中完成的工作。
根据完成情况和 Sprint期间产品待办列表的变化，与参会人员讨论接下来可能要做的事情来优化价值。
演示增量的目的是为了获取反馈并促进合作。

Sprint评审会议包含以下内容：

产品负责人邀请 Scrum团队以及主要相关干系人参加会议。
产品负责人说明哪些工作“完成”了，哪些工作没有“完成”。
开发团队讨论在 Sprint中哪些工作进展顺利，遇到了什么问题，问题是如何解决的。
开发团队演示完成的工作并解答关于所交付增量的问题。
产品负责人描述当前产品待办列表的完成情况，并根据进度推测可能的完成日期（如果有需要的话）。
参会的所有人就下一步的工作进行探讨，这样， Sprint评审会议就能为接下来的 Sprint计划会议提供有价值的信息。
评审市场或者潜在的产品使用方式如何造成接下来要做的最有价值的东西的改变。
为下个产品版本的发布评审时间表、预算、潜在功能和市场。

Sprint评审会议的结果：一份修订的产品待办列表

可能进入下个 Sprint的产品待办列表项。
有可能为了迎接新机遇而对产品待办列表进行全局调整。

Sprint回顾会议

Srcum团队检视自身并为在下个Sprint中制订自我改进的执行计划。Sprint回顾会议发生在 Sprint评审会议结束之后，下个 Sprint的计划会议之前。对于长度为一个月的 Sprint，会议限时为 3小时。Scrum Master要确保会议顺利举行，并且每个参与者都明白会议的目的，同时还要教导大家遵守时间盒的规则。 Scrum Master作为 Scrum流程的监督者，也需要作为团队的一员参加该会议。
Sprint回顾会议的目的是

对前一个 Sprint周期中的人、关系、过程和工具进行检视。
找出做得好的和潜在需要改进的主要方面，并进行排序。
制订改进 Scrum团队工作方式的计划。
Scrum Master鼓励团队在 Scrum的流程框架内改进开发流程和实践，使得他们能在下个 Sprint中更高效，更愉快。
在每个 Sprint回顾会议中， Scrum团队通过适当调整“完成”的定义的方式来计划提高产品质量。
在 Sprint回顾会议结束时， Scrum团队应该明确接下来的 Sprint中需要实施的改进。
在下一个 Sprint中实施这些改进是基于 Scrum团队对自己的检视而做出的调整。
虽然改进可以在任何时间执行， Sprint回顾会议提供了一个专注于检视和调整的正式机会。

取消Sprint

在 Sprint时间盒结束之前取消。取消Sprint不是必要的事件，但如果尽管评估，可以对一个Sprint进行中止。只有产品负责人才有取消Sprint的权力，但他做这样的决定也可能是受到相关干系人、开发团队或是Scrum Master的影响。

如果某个 Sprint的目标过时了（失去了价值和意义），那么也许就需要取消该 Sprint。
当取消某个 Sprint时，任何做完和“完成”的产品待办列表项都需要评审。假如其中有些是潜在可交付的，产品负责人就会采用它。所有未完成的列表项目要重新评估，并放回到产品待办列表中。