print 和println_printpen打印机

敏捷微知识（六）：关于冲刺（Sprint） 　　一、什么冲刺（Sprint） 　　冲刺（后续统称Sprint），是Scrum的核心。Sprint在英文中是“短距离快速奔跑”的意思，敏捷的第一步就是把 “迭代” 变为 “冲刺” 开始，冲刺是有目标的团队行动，而迭代只是一个时间盒的概念，Scrum团队如果把Sprint称之为迭代，就失去了每个Sprint为目标而奋战的本意，只有实现了目标，我们才算冲刺成功。 　　Sprint是固定时长的事件，周期通常为2-4周。Scrum团队在一个Sprint中产出完成的、可用的、潜在可发布的产品增量。在每个Sprint中，开发团队负责开发和测试用户故事（User Story，简称Story），直到产品负责人（Product Owner，简称PO）接受它并且使其成为一个潜在的可交付价值。当前一个Sprint结束后，新的一个Sprint开始，并设定新的Sprint目标、保持节奏。通常在整个开发过程中Sprint周期一致，不会轻易变更。 　　

　　图1-1 行云Sprint 　　二、Sprint生命周期 　　Sprint 是所有Scrum事件的容器，包括Sprint计划会（Sprint Planning Meeting ），每日站会（Daily Scrum），Sprint评审会（Sprint Review Meeting）以及Sprint回顾会（Retrospective Meeting）。 　　一个Sprint通常以Sprint计划会开始，计划会是一个“双向”承诺的会议，开发团队承诺交付的Sprint待办项，PO承诺在一个Sprint中不改变待办项优先级和内容。 Sprint计划会包含两部分工作：开发团队从产品待办列表（Product Backlog）中选择要开发的Story，PO或者业务分析人员（BA）讲解Story，开发团队和PO一起完成Sprint待办列表（Sprint Backlog）的创建，设定Sprint目标；开发团队针对Sprint待办列表中的Story进行估算（通常使用故事点进行相对估算），创建Story开发、测试等子任务，并完成Story及任务的认领。 　　在Sprint进行中，Scrum团队会在同一时间、同一地点召开每日站会评估Sprint目标完成的进度趋势，聚焦团队面临的问题和阻碍，会后采取必要的措施以确保Sprint目标顺利达成。 　　Scrum团队在每一个Sprint结束前都会举行Sprint评审会，演示Sprint的产品增量，收集相关的反馈，并作为下一个Sprint的改进输入。产品发布通常发生在一Sprint结束或者多个Sprint结束之后。在一个Sprint中，可能会存在一些变动，但是Sprint目标不会发生变化。 　　一个Sprint以回顾会为结束。回顾会是一个行动导向的会议，通过召开回顾会来评估Sprint结果并制定相关改进计划（如在行云中创建相关任务并排入后续Sprint进行跟踪）。 　　一个Sprint的循环过程如下： 　　

　　图2-1 Scrum流程 　　关于更多Sprint中的各会议介绍（如会议目标、流程、举行时间与频率、注意点等），请参看：Scrum会议总结及特点 　　三、Sprint目标 　　Scrum团队在Sprint计划会上会共同制定一个Sprint目标（Sprint Goal），用以沟通当前Sprint对所有利益相关者有价值的原因。Sprint目标应该易于度量，并且能够充分体现Sprint待办列表中Story的商业价值，其是开发团队在一个Sprint中试图实现的如新特性开发、产品性能提升、用户体验优化等。Scrum团队会在计划会结束前最终针对Sprint目标达成一致。 　　一个行云中的Sprint目标如下： 　　

　　图3-1 行云Sprint目标 　　四、Sprint的优点和缺点 　　任何事情都有两面性，Sprint也一样： 　　优点：Sprint意味着更短的发布周期，相比传统的方法，用户会更快、更频繁地获得新功能。产品团队也不需要等待一个漫长的周期才能获得新功能的市场接受度。更短的反馈周期意味着产品团队可以快速地调整发布计划及内容，同时更快的响应时间也有助于使整个组织更加以客户为中心。Sprint是一个很好的试错平台，Scrum团队可以及时评估Sprint结果并进行相应的调整，大量的实验机会有助于团队更大胆地探索各种可能性。Sprint能够使产品团队更快地应对市场变化、更灵活地应对竞争对手不断推成出新的节奏。 　　缺点：在整个Sprint过程中，PO必须随时提供答疑解惑，在一些组织中PO并不总是有机会在每次Sprint中提供大量反馈和投入，如参加团队的每日站会等，因此一些细节的内容可能会被忽略甚至阻塞开发团队。另外，一些PO提出的小的调整和改变可能要等到下一个Sprint。Sprint的冲刺特质有时可能会导致开发管理松散，代码质量下降，遗留一些技术债。随着时间的推移，技术债务积累可能会导致生产环境出现问题，并且需要专门的资源、时间去处理。不间断的Sprint可能会让所有参与的团队成员都感到过大的压力。因此偶尔安排一次充满清理和漏洞修复的冲刺，可以让人耳目一新，从而缓解这种情况，并短暂休息一下。 　　五、实践中的常见问题 　　问题：Sprint多长时间合适？ 　　通常是2到4周，一般情况下，一周一个Sprint时间太短，三周太长，两周相对比较合适，当Sprint的长度拉得太长时，Sprint目标可能会失效，复杂性可能会上升，同时风险可能会增加。可以使用较短的Sprint来产生更多的学习周期，并将风险限制在更短的一段时间内，每个Sprint都可以视为一个短期的项目。当前大部分的团队实践也都是2周。 　　问题：Sprint 0主要完成什么工作？ 　　通常，在一个项目正式开始开发前，会先开始Sprint 0。Sprint 0的工作一般聚焦在：基础工作，如行云项目的初始化、团队Wiki的创建等；团队的组建；架构设计；STI环境的搭建；开发环境的初始化；产品待办列表的梳理等。 　　问题：Sprint 1什么时间开始？ 　　通常，项目正式开始，产品待办列表中的高优先级Story已就绪，Story编写完成，Sprint计划会议的前置条件都已经满足，就可以开始Sprint 1了。 　　问题：Sprint的周期是否可以在中途改变？ 　　为了保证开发团队的节奏以及践行Sprint目标的承诺，不建议在Sprint进行中改变周期（如，团队认为因为评估不充分，导致过度承诺，需要将2周改为3周）。在研发成熟度模型V3.0中也有相关的考察项，参看如下： 　　迭代开发，团队有合适的固定的节奏，例如2周一个迭代周期，迭代周期是固定的timebox。做到以下几点：迭代进行中不改变迭代周期，即开始结束时间不变。 　　问题：Sprint中未完成的承诺如何处理？ 　　通常两种处理方式：拆分Story、或将未完成的Story移至下一个Sprint，在研发成熟度模型V3.0中也有相关的考察项，参看如下：迭代结束时，及时关闭每个当前迭代内的任务。无法在当前迭代完成的任务，在迭代结束前做切分：当前迭代已完成的部分，进行关闭；未完成的任务归属于下一个迭代。 　　问题：什么是Sprint速度？ 　　速度（Velocity，也称速率）是一个度量指标，用于衡量开发团队在一个给定周期内的交付速度。速度是一个Sprint内完成的故事点总数。敏捷项目团队在做Sprint计划时，会通过Sprint速度进行预估在未来Sprint内可完成的预计故事点总数。 　　

　　图5-1 速度图 　　问题：如何跟踪Sprint进度？ 　　Scrum团队通常使用燃尽图（Burn-down chart）来跟踪Sprint进度。 　　什么是Sprint燃尽图？ 　　Sprint燃尽图，展示Sprint中所有Story的剩余故事点随Sprint日期的变化而逐日递减的燃尽过程。实际燃烧线（蓝线）与基准线（绿线）越贴合，Sprint的进度越健康。 　　燃尽图提供了量化的数据展示，燃尽图的走向代表了Sprint进度的健康度，当出现异常时，需要对团队开发节奏进行及时调整。 　　一个行云中的燃尽图如下： 　　

　　图5-2 燃尽图 　　问题：Sprint之间是否需要休整时间？ 　　有很多人会问到，Sprint之间是否需要休整时间？如何进行休整？在实际的工作中，团队不可能一直像上紧了发条一样始终高速的运作，团队的确需要在Sprint的间歇进行一些休整。如果团队总是在高压力与快节奏下工作，实际的效率反而不会如预期的那样高，并且会留下较多的技术债。 　　除了团队需要休息外，在Sprint评审和回顾会议结束以后，Scrum团队会有很多想法需要去吸收和消化，也有很多收尾的工作要做。如果这时立刻开始下一个Sprint（或者说Sprint计划会议），很多信息就无法及时处理，并且PO可能无法及时的调整产品待办列表中Story的优先级，也可能无法准备好足够详细的Story进行澄清和计划。一些典型的安排如下： 　　太过于紧张的安排如下: 　　周一09-10: Sprint 1 演示会10-11: Sprint 1 回顾会14-16: Sprint 2 计划会 　　相对较好些的安排如下： 　　周一周二09-10: Sprint 1 演示会10-11: Sprint 1 回顾会09-13: Sprint 2 计划会 　　比较好一些的安排如下： 　　首先确保不在同一天举行当前Sprint回顾会和下一个Sprint计划会。在新的Sprint开始之前，应该至少确保Scrum团队可以度过一个不需要过多思考下一个Sprint的周末休整时间，同时也留足够的时间给到PO和BA进行下一个迭代Story的梳理和完善。 　　周五周六周日周一10-11: Sprint 1 演示会16-17: Sprint 1 回顾会09-13: Sprint 2 计划会 　　当然在具体实践中，不同团队都会根据自身的实际情况创建Sprint日历，下面是一些产品线“效能提升”、“明星标杆”团队的Sprint日历： 　　协同产品线： 　　周一周二周三周四周五周一周二周三周四周五需求讲解及需求澄清开发测试用例撰写及评审开发测试用例撰写及评审开发SIT测试开发SIT测试开发SIT测试开发SIT测试UAT验收UAT验收发版回顾会迭代会 　　风控产品线： 　　第一周周一（计划会）周二周三周四（用例评审）周五迭代计划会开发测试用例编写开发测试用例编写开发测试用例编写开发、测试测试用例评审会代码评审开发、测试第二周周一周二周三（完成开发）周四（发版上线）周五（回顾会）开发、测试开发、测试完成开发测试代码评审PO验收发版评审发版需求澄清运维回顾会