scrum敏捷开发方法论_敏捷方法论 scrum

什么是scrum敏捷开发方法论

当前业界有两种主要的软件项目开发方法论，分别是Waterfall（瀑布模式）和Agile（敏捷模式）。而本文介绍的scrum便是敏捷模式中一个很常用的方法论。
瀑布模式是传统的软件开发模式，一般会在软件开发前期确定好软件需求，设计好软件架构，安排好开发计划，然后开始具体的开发工作。当软件开发基本结束后，测试人员开始介入，着手软件测试工作，同时开发人员开始修改bug，在软件最终交付日期前完成开发和测试的所用工作。一般瀑布模式会设立一些里程碑节点，在对应的节点输出对应的文档，同时评审对应节点的目标是否完成，从而保证每个阶段内的项目质量，推动项目向正确方向前进。
瀑布模式有两个痛点，一是难以应对开发过程中出现的高频需求变更，二是难以高效纠正开发过程中错误。

• 对需求变更的处理。需求确认是整个项目的第一阶段，后续所有的软件架构设计，项目排期，编码和测试都是以需求为基准的。如果需求在软件开发阶段发生变更，尤其像互联网行业，可能会有高频的需求变更，此时，软件架构和项目排期很可能也会随之发生快速变更，编码和测试工作更是很难稳步推进。这对项目管理是很大的挑战，其中因此的风险非常高。
• 对开发过程中错误的纠正。里程碑节点的时间间隔并不固定，如果间隔较长，比如2个月，那个这两个月内编码和测试的工作如果出现错误积累，等到里程碑节点时错误可能已经很严重了，这时是很难对错误进行纠正的。

敏捷模式可以说就是针对瀑布模型的这两个痛点提出的解决方案。但这并不意味敏捷模式是完美的，实际在软件开发过程中，敏捷模式也会有其固有的一些痛点。在本文的最后会进一步总结敏捷模式的痛点及解决方案。

scrum中的关键技术解释

scrum value

scrum 模式的价值观，包括承诺，专注，开放，尊重和勇气。
scrum模式是以人为本的工作模式，所以它所强调的价值观都是对团队每个成员的要求。
正确的理解是：

• 承诺：团队承诺达到目标，并相互支持；
• 专注：专注于sprint中的工作，以求达到计划目标；
• 开放：团队和利益相关人员对挑战持有开放太对；
• 尊重：团队成员之间需要互相尊重；
• 勇气：团队成员有做正确事情的勇气，也有接受挑战的勇气；

不正确的理解是：

• 承诺：迫使团队承诺过于沉重的目标，让团队加班赶工；
• 专注：客户的需求就是一切，有需求变更马上处理；
• 开放：团队要保持开发，暴露问题后，该问责的问责，该检讨的检讨；
• 尊重：我们要尊重客户，遇到问题时我们要第一时间反省自己哪里做的不好；
• 勇气：解决不了困难问题，要你们干什么；

scrum theory

透明，审视和调整时scrum 模式的理论核心。

• 透明，是指让各方知道团队在做什么，包括让客户，项目经理，团队内每个成员，甚至是其他团队的人知道团队的工作进展。交付物是scrum透明性的体现。增加透明度后，可以减少浪费和误解。
• 审视，团队需要对交付物和共同目标进行频繁的审视，及时纠正错误，按时交付。在落地时需要注意，对目标的解释权不能只在个别几个人的手里，否则审视者和被审视者就会被对立起来，导致团队不断分化。
• 调整，就是当在审视中发现问题后及时纠正错误。在落地时需要注意，调整往往意味着新增工作量，团队有可能不愿意接受这种调整，或者调整后可能无法按时交付，因此需要对调整的必要性和方案进行更深层的讨论。

sprint

sprint，中文可以叫做一个冲刺，或者叫一个项目排期。它有如下几个特点：

• 每个sprint的长度需要保持一致，一般是2周~4周为一个sprint，一般不会超过4周，否则会增大项目的不确定性；
• 一个sprint内的开发/测试工作一般不可变更，这样能保证短期内目标一致性，减小短期内需求频繁变更带来的影响；
• sprint的意义在于小步快跑，逐步完成项目开发和项目迭代；
• 每个sprint的开始会有sprint planning，指定当前sprint的工作内容和计划；
• 每个sprint的结束会有sprint review，评审这个sprint交付的内容是否符合预期；
• 项目最后一个sprint的结束会有sprint retrospective，回顾整个项目开发过程中交付的内容和团队的工作情况；
• sprint内每天会有daily scrum meeting，一般以早会或者夕会的方式举行，每个团队成员会更新自己的工作进度，如出现异常，会对工作内容进行及时调整，从而达到sprint的交付目标；
• 每个sprint的结束都会马上开始下一个sprint（除了项目的最后一个sprint以外），因此，所有的计划会议，评审会议，早会/夕会都是周期进行，不能出现断档；
• sprint可以让团队快速获取反馈（feedback），减少因错误积累而引起的项目风险；
• 小的错误可以在当前sprint内及时纠正，而较大的错误可以在下一个sprint进行纠正；
• 在sprint planning时不需要计划工作细节，只需要定下大体框架，让团队在框架下工作不出问题即可；
• 在sprint review时需要对当前sprint的工作内容进行评审，找出问题点，在下一个sprint 里进行纠正，进而让项目持续演进；

sprint event

sprint 活动包括daily scrum（早会、夕会），sprint planning（计划会），sprint review（评审会），sprint retrospective（回顾会）。这些活动需要按照sprint 的节奏周期进行。

role

在scrum中有多种不同的角色：

• product owner：负责和产品/市场方面的进行对接，对正在研发的产品负责，需要提供产品的详尽需求；
• developers：开发团队，包括研发，测试人员，负责产品的具体开发、维护和测试等工作；
• scrum master：敏捷教练，负责引导开发团队和产品经理遵循scrum 纪律，按照scrum 工作流执行日常工作，让团队在各个层面上保持有效沟通；

backlog

back里放的是有团队划分出来的工作事务，团队中的任何人都可以划分出来的工作事务加入到backlog里。
在sprint 计划会中，团队要一起看下backlog中剩余事务的数量，进而评估后续开发节奏。

敏捷模式的痛点

敏捷模式解决了瀑布模式的两大痛点，能很好的处理需求的高频变更和及时纠正开发中的错误，但敏捷模式也有其固有的两个痛点，一是轻视文档导致开发容易脱轨，二是对团队沟通能力要求高。

• 轻视文档导致开发容易脱轨。为了提升开发速度，我们一般只会定下大体的开发框架，团队在这个大的框架下按sprint进行周期迭代开发。开发的前期，团队成员间还能记得开始对齐的方案，但犹豫对齐的方案都在各自成员的脑子里，并未固化成文档，随着项目的进行，对齐的方案可能会变的不对齐。此时早会和sprint 评审会就可以发挥一定的功效，但也因此带来了因方案经常要对齐而带来的内耗和扯皮，严重的会影响项目的最终验收。
• 对团队沟通能力要求高。由于团队要经常性的对方案进行对齐，每个成员表达和理解能力一定要强，从而让每个人达到方案的实质性对齐。一般程序员的逻辑思维能力会较强，但口头表达能力会较弱，这导致团队在敏捷模式下很难对方案达到实质性的对齐，每个人的脑子里都有一个不太一样的方案。这就会导致开发出错的概率大大提高。

其实，scrum本身只是一个轻量级的敏捷开发框架，这意味它并非是一个开箱即用的简单工具，而是需要在遵循scrum基本原则的基础上，根据项目和团队的实际情况开发出一套可落地工作流。比如上面介绍额这两个痛点，实际根因都是前期缺少固化的文档，为了解决这个问题，完全可以像瀑布模式那样，在项目前期将需求确认清楚，将方案架构设计好，都固化成文档，之后再开始sprint。在sprint周期运行中，如果出现需求变更和方案变更，需要更新对应的文档。这样就能很大程度上减轻上面两个痛点。