今天小编就为大家带来一篇有关Scrum敏捷开发冲刺的文章。小编觉得挺实用的，为此分享给大家做个参考。一起跟随小编过来看看吧。
在敏捷开发过程中，一个产品或者一个发布版本通常是由多个冲刺来实现的，每个冲刺都能增量交付可运行的系统功能，实现客户价值。每个冲刺都是从冲刺规划开始，团队成员一起商定冲刺目标和明确交付的系统功能，并进行冲刺执行，实现系统功能，再通过冲刺评审和回顾对实现的产品功能和过程进行检视，期望在下一冲刺过程中对产品功能和过程进行改进和完善。
冲刺包括冲刺规划、冲刺执行、冲刺评审、冲刺回顾四大过程。冲刺是从规划开始，团队成员必须就本次冲刺的目标和计划达成共识，全体成员在整个冲刺过程按照既定的计划奔着这个目标前进，每天对取得的成果和面临的问题进行沟通讨论。冲刺结束阶段，在冲刺评审活动中召集相关利益相关方一起演示产品功能并获得反馈，获得的反馈是产品列表和下一阶段冲刺规划内容的重要来源。在冲刺回顾活动中，全部团队成员对冲刺执行过程进行检视和讨论，抓住其中存在的问题并讨论优化方案，在下一个冲刺进行改善和优化，实现冲刺过程的优化和冲刺执行效率的提升。
一般情况下，是在每个冲刺的开始阶段进行冲刺规划，因为在这个时间点上，能充分利用已掌握的信息最出最优的决策。冲刺规划过程时间的长度根据冲刺的长度而定，占用整个冲刺的5%左右时间是比较合理的，比如两周的冲刺应该控制在4小时以内，一个月的冲刺应该控制在8小时以内。
冲刺规划过程应该由整个团队协作完成，产品负责人从现有的产品列表清单中选取清单项，提出冲刺的初步目标，并负责解释开发团队针对选取的产品清单项提出的任何疑问。开发团队对冲刺内可交付的工作清单进行评估，并在规划结束时做出最终的承诺。Scrum Master作为教练，参与和观察整个过程，提出可能的风险点，引导和帮助开发团队做出有效的承诺。
在冲刺规划过程中，基本的流程是：
冲刺规划过程结束时，最终获取冲刺目标和冲刺清单，开发团队为此目标和任务清单做出承诺，并在接下来的冲刺执行中为此目标而努力。
冲刺执行包括了交付一个增量可发布的产品而必须完成的所有工作，其本身就像一个超小型的项目，冲刺执行过程占用了冲刺大部分时间，比如两周的冲刺中，冲刺执行占用10天中的8天，所以冲刺执行过程对冲刺目标的顺利完成至关重要。冲刺执行包含了规划、管理、执行和沟通等工作：
冲刺执行规划可以对冲刺清单中的重要工作项进行依赖关系的梳理，但不需要做详细的执行计划，比如一个甘特图，因为这可能是在浪费时间。团队不仅仅浪费了制作计划的时间，还浪费了更多时间试图将计划调整为反映真实执行情况。冲刺执行规划的原则是见机行事，逐步明确任务规划，这个活动是一个持续性的，贯穿整个冲刺执行过程。
冲刺执行管理是保证为达成冲刺目标而进行的管理活动。开发团队的特点决定了管理风格。冲刺执行管理具体来说要解决以下几个问题：
应该并行几个工作项？并行太多的工作项，团队成员会在不同工作项中切换，造成浪费；并行的工作项太少也会造成资源闲置浪费，适量的并行数量，力求充分利用团队的生产能力，而又不至于过于繁重，达到合理的平衡，这需要每个团队根据自身的能力和特点来实践和探索。
从哪个工作项开始？最简单的方法应该是按优先级的排序从高到低依次进行，但是在具体执行过程中可能会碰到各种问题导致优先级高的工作项暂时无法开始，这种情况下也可以开始次高优先级的工作。
由谁来做？最明显的答案是由那个能完成得最好最快的人去做。但是每个团队有自己的考虑因素，比如最合适的人可能在忙于其他的工作抽不开身，或者他可能正在休假中，甚至从团队发展的角度考虑，可以给其他成员锻炼机会，以达到团队成员在各项技能上的重叠，互为补充。
每日例会是一个关键的每日检视-调整活动，时间控制在15分钟以内，主要目的是检视、调整和同步每日工作计划，帮助团队把工作做得更好。
进行Scrum敏捷软件开发，团队成员需要熟练一些应用软件开发技术实践，比如持续集成、自动化测试、重构、测试驱动开发等，这些技术实践会给开发团队提出较高的要求，在短期内会对开发团队造成进度或其他方面的压力，但是长期来看，只有积极运用这些良好的技术实践，才能切实体验到敏捷的好处。
敏捷团队一般是足够小的团队，小团队成员的沟通不需要复杂的图表和报告来沟通工作进展，推荐使用以下方法和工具：
任务板：显示冲刺清单随时间的任务状态.
冲刺燃尽图：显示未完成任务的剩余工作量曲线。
冲刺燃烧图：显示达成冲刺目标过程中所完成的工作量曲线。
冲刺评审过冲关注的重点是产品，即关注的是结果，对冲刺执行期间完成的工作成果进行检视，参与的人员包括Scrum团队、内部利益干系人和外部利益干系人等。评审开始前的一项重要准备工作是确认冲刺工作完成，这项工作是由产品负责人来做，他最终确认冲刺清单中的工作项是否完成，确认的时机不是等到评审前最后一刻，可以冲刺执行过程中尽早确认，这样会及早发现问题，赢得补救的时间。
冲刺评审过程中采用的方法包括：
通常由产品负责人对本次冲刺的工作进行概括性说明，并展示冲刺目标和冲刺清单，说明完成的产品增量的基本情况。
由开发团队成员演示已完成的系统功能，对于不那么容易演示的功能（比如后台运行的程序）至少要提供一些测试程序来证明已完成的工作满足产品负责人的要求。需要注意的演示本身不是目的，演示的目的是激发团队成员的思维碰撞，提出更有建设性的建议和反馈。
产品增量演示引导参与者就产品功能或目标等方面进行评论、建立和适当的讨论，如需要更深入的问题方案的讨论，应该另外进行会议独立进行。
通过演示和讨论，会产生一些变更或新增的需求，这些变更和需求会对产品清单和下阶段的冲刺清单带来调整，通过梳理之后，在每次冲刺结束的时候会得到更新后的产品清单，可以在接下来的冲刺中及时响应变化。
冲刺回顾关注的是产品构建过程本身，即关注的是过程。团队一起回顾冲刺过程中发生的事情，分析自己的工作方式，找出可能存在的问题点，提出改进方案和制定改进计划。每次进行冲刺回顾前，可以先定义回顾的重点内容，以免过于分散。在回顾会议中，需要确保营造“对事不对人”的氛围，回顾的目的在于改进过程，而非指责某个人员。回顾结束时，让团队成员跟进并落实改进措施，使得团队在下阶段的冲刺中更加高效。
冲刺包括了整个产品或项目开发和管理中的多数的时间和活动，是产品功能实现的主要环节。本文尝试从冲刺规划、冲刺执行、冲刺评审和冲刺回顾四个过程的角度，全方位探讨了冲刺涉及的所有活动和工作内容，希望可以对敏捷团队在冲刺过程的执行中有所启发和帮助。
看完上述内容，你们对Scrum敏捷开发冲刺大概了解了吗？如果想了解更多相关文章内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
