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

时间 2019-12-29

标签咱们这样转向敏捷开发繁體版

原文原文链接

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

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

正由于这些问题，因此渴望开发流程的改变。偶然（或许是必然的结果，只是时间点的问题）的机会，让个人团队转向敏捷开发。工具

敏捷开发是什么？

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

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

流程如图：
学习

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

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

咱们怎么落实？

通常来讲，都是团队按照一个标准流程执行。由于团队中都是对敏捷开发只知其一;不知其二的，这样的话，得统一学习，而后一块儿制定流程，而后在按照流程执行。这样既耽误时间又耽误版本发布。因此咱们就反过来，让流程也来个迭代。
要实施敏捷开发，对人的要求挺高，能不能落实很大取决于Scrum Master，落实得顺不顺利很大取决于开发团队，落实得好很差很大取决于Scrum Master和开发团队。优化

第一阶段：人

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

自身

做为团队的Leader，也就理所固然的落在Scrum Master这个角色上。我得从如下方面提高：spa

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

团队

因为团队人员能力良莠不齐，作事方式也都不同。比较有共性的就是养成惰性习惯，因此主要从两方面提高：设计

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

第二阶段：流程

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

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

第三阶段：规范化

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

咱们遵循什么原则

原则及是一种态度！以前有一个版本在周五时面临难产，一位开发人员理不清一段逻辑的思路，而下一周还没安排事情。此时他很大程度上以为下周作也没事。可是我坚持，我帮他写了逻辑（不会出现下次），那天咱们测试到凌晨三、4点搞定。以后跟他私底下聊天，他说确实是以为下周作也没事，可是通过那晚，一直压着的压力一会儿释放，而后版本又能够发布，感受挺好。因此，原则仍是要有。
原则1、时间和质量不可侵犯
保证质量的前提下，2周一个版本的迭代时间不会变，能够调整需求。
原则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时，任何作完和“完成”的产品待办列表项都须要评审。假如其中有些是潜在可交付的，产品负责人就会采用它。全部未完成的列表项目要从新评估，并放回到产品待办列表中。