敏捷开发入门

概念解释

Scrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。 不一样于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为屡次迭代（称为Sprint，冲刺），通常为期2～4周。

图解敏捷开发

关键词

三个角色，三个工件，四个流程（五个事件），四大支柱，五大价值观

三个角色

Product Owner

产品负责人负责的事项：

• 清晰地表达产品代办事项列表条目
• 对产品代办事项列表中的条目进行排序,最好地实现目标和使命
• 确保开发团队所执行工做的价值
• 确保产品代办事项列表对全部人可见、透明、清晰,而且显示 Scrum 团队的下一步工做
• 确保开发团队对产品代办事项列表中的条目达到必定程度的理解

Scrum Master

Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。 Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 经过改变这些交互来最大化 Scrum 团队所创造的价值。

Scrum Team

开发团队包含了专业人员,负责在每一个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量。

开发团队由组织构建并受权,来组织和管理他们的工做。所产生的协同工做能最大化 开发团队的总体效率和效力。开发团队有如下几个特色:

• 他们是自组织的,没有人(即便是 Scrum Master 都不能够)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能。
• 开发团队是跨职能的,团队做为一个总体拥有创造产品增量所须要的所有技能。
• Scrum 不承认开发团队成员的头衔,不管承担哪一种工做他们都是开发者。此规则无一例外。
• 开发团队中的每一个成员能够有特长和专一领域,可是责任归属于整个开发团队
• 开发团队不包含如测试或业务分析等负责特定领域的子团队。

三个工件

分别指的是产品待开发项，冲刺待开发项（开发角度），可交付软件（文档）

四个流程

四个支柱&&五个价值观

四个支柱

• 迭代开发
• 自组织团队
• 高优先级的需求驱动
• 增量交付

五个价值观

• 承诺 – 愿意对目标作出承诺
• 专一– 把你的心思和能力都用到你承诺的工做上去
• 开放– Scrum 把项目中的一切开放给每一个人看
• 尊重– 每一个人都有他独特的背景和经验
• 勇气– 有勇气作出承诺，履行承诺，接受别人的尊重

前置条件

敏捷的团队

敏捷团队要求其成员具备如下的一些基本特色。

• 具备多年工做经验，在本身的负责领域有专业的认知和独立完成能力
• 有较好的执行力，对本身允诺的事情能完整的完成
• 有较好的沟通反馈能力，对敏捷自己的正确理解，在遇到问题、风险、不肯定性、协做等时能快速的经过沟通完成沟通的目的
• 对其余技术栈或者专业领域有必定的认知，有较少的认知壁垒，较快达成共识
• 团队在此以前有至少半年到一年的磨合

比较固定的流程，文档，需求

• 需求是控制稳定性的根本，对于需求必定是总体可控的，而且是能够由迭代内进行调整的，而不是定死的
• 流程是指什么时间什么人该作什么事是高效的，明确的
• 文档是指每一个流程阶段具备可交付或者可查阅参考文档，不是口头或者我的评定

可灵活调整，容许试错

• 检查

检查是指在天天的站会中检查每一个人的工做状态，是否能完成本身的任务，存在什么问题，完成效果如何。另外就是保证总体在天天的进度，是否有有总体效果，若是没有完成今天的总体效果，须要检查是否符合总体迭代。

• 调整

调整是指检查发现迭代的进度或者外界环境发生变化时，及时调整当前迭代的开发任务，保证迭代最终产物的准确及时性变更。固然，这种变更是不容许太多的，通常状况下在需求没有作详细分析时，不接受；在当前有风险的状况下，撤销某些需求；其余状况不作描述。

• 试错

正是因为检查以及调整的策略，保证了迭代的灵活性，咱们能够在敏捷团队中尝试一些较革新、新的功能点或者技术点，若是实验成功则能够对外拓展；若是不行，能够快速切换方案。

适用场景

• 不肯定的开发流程，技术方案
• 不成熟的产品
• 产品快速多方面优化
• 产品新特性研发
• 技术重构

问题场景&&错误认识

• 一个团队闭关开发一个项目就是敏捷

正确理解：敏捷不等于闭关，只是可能坐一块儿效率更高，其倡导的是什么时候均可以发生沟通，并准备一白板能够随时讨论方案；敏捷团队质量以及效率高于通常团队；敏捷团队开发的是以迭代为单位，不是项目；

• 有了任务细分，开发白板，站会就是敏捷

正确理解：任务细分、白板、站会都是其形式，关键仍是其将迭代的内容进行细化，可执行化，用高频的沟通反馈提升开发、沟通、理解的效率。

• 把最好的成员都攒一块儿了就是敏捷

正确理解：这些成员除了各自的专业水平还须要各自的磨合，沟通水平，对其余职能的必定的了解。

• 开发很快，快速交付的是敏捷

正确理解：开发快、快速交付产物只是敏捷的一个特色，也要深入理解其交付的只是一个迭代的，并非一个完整的产品。

• 只有软件开发团队才有敏捷

正确理解：符合能够将任务明细，具备一个可执行团队，一个监督者，均可以尝试敏捷的管理。

• 敏捷团队没有特殊前置条件

正确理解：前面有讲到敏捷对团队，需求，文档，流程，调整等都有比较完整的规定。

• 敏捷团队作的事情没有差异性

正确理解：敏捷完成的任务具备明细化，分阶段性，可调整性。因此在开发相关任务时，也具备相似的特色。

• 敏捷团队会完整完美的交付产物

正确理解：敏捷在迭代结束只交付该阶段的可交付产物，极可能不完整不完美，对于可交付也有不一样的理解。

更多

有兴趣能够持续关注的后续讲解，会针对用户故事、需求管理、跟踪反馈等多角度分析执行敏捷的要点。

参考文档

• 《火星人敏捷开发手册》
• scrum中文官网