敏捷开发以及Scrum介绍

Overview

什么是敏捷软件开发？
什么是Scrum？
Scrum应用

什么是敏捷软件开发

Individuals and interactions over process and tools(个体和互动高于流程和工具)
Working software over comprehensive documents(工作的软件高于详尽的文档)
Customer collaboration over contract negotiation(客户合作高于合同谈判)
Responding to change over following a plan(响应变化高于遵循计划)

再看一下敏捷宣言遵循的原则，总结下来如下：

主张简单
拥抱变化
可持续性
轻装前行
软件是主要目标
令投资最大化

定义与流程

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法
不是一门技术，它是一种开发方法，一种软件开发的流程
主要驱动核心是人；采用的是迭代式开发

以人为核心
与瀑布模型以文档驱动相对比。只有必要的文档，注重人与人交流。
迭代
一个复杂且开发周期很长的开发任务->分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程
-w918
名词解释：

Product Backlog(缩写为PBL,产品清单)
Initial Size Estimates As Story Points (预估初始大小作为故事点)
More accurate estimates as man hours(更加准确的预估工时)
Scope froze(范围冻结)

传统项目管理与敏捷项目管理对比

传统项目管理	敏捷项目管理
对整个项目进行规划/计划	对整个项目进行粗略估计
反对变更	鼓励变化
严密的合同减少风险	信任并赋予权力
产品测试分离	每个迭代版本可交付

优点

开发过程更加透明，及时及早发现问题
遵循JIT(Just In Time)原则，快速交付，及时交付可使用软件
最高优先级需求尽早开发(好钢都用在刀刃上)
改善应对能力，改善项目沟通
更好的客户参与

缺点

强调人的主观能动性，受人影响因素较多
缺少必要的设计和文档编制的强度[扩展:注重文档而非文件导致进度拖延,“Martin文档第一定律（Martin’s first law of documentation）”的简单规则可以预防该缺陷的发生：直到迫切需要并且意义重大时，才来编制文档]
研发人员可能看不到产品的全貌，对Product Item可能存疑
如Product Owner不清楚究竟想做什么，则产品则会迅速偏离方向

Scrum

“Scrum是一种流程，而敏捷是一种观念。” - Jeff Sutherland

定义

Scrum是一种敏捷软件开发的方法学，用于迭代式增量软件开发过程。Scrum在英语是橄榄球运动中列阵争球的意思。

虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。Scrum之间的合作称为“Scrum of Scrums”。

Scrum Process

流程

增量开发/迭代

组成与结构关系

Scrum Roles

在Scrum 中，大致分为下面三种角色：

Product Owner(产品负责人)
Scrum Master(流程管理员)
Scrum Team(开发团队)

Product Owner(产品负责人)

PO（Product Owner）是Scrum中十分重要的一个角色，是连接业务用户及Scrum团队的中间纽带。PO字面意思是产品或业务负责人，即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员，一般可由产品经理担任，也可由熟悉业务的开发人员担任。PO与传统的需求分析人员在工作职责及工作内容上都有比较大的差别，本篇文章将为您详细介绍PO和职责、核心价值及能力要求。

PO的职责

PO负责最大化产品及开发团队工作的价值，是管理产品待办事项列表的唯一责任人。为保证PO的工作取得成功,组织中的所有人员都必须尊重他的决定。在SCRUM中PO所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。PO的职责可以总结为以下6点：

负责确定产品的方向和愿景，为产品ROI（Return On Investment : 投资收益率）负责
理解业务诉求，确定产品的功能，讲故事
定义产品发布的内容及交付时间
维护产品Backlog，确保其定义清晰且分解适当，并负责调整 Backlog 条目的优先级
参与Sprint计划会议、评审会和回顾会
接受或拒绝接受开发团队的工作成果

PO的核心价值

连接器。从敏捷运作机制来看，PO作为产品的负责人，对外是产品价值交付和产品反馈的桥梁，对内则是帮助研发团队理解外部需求，转换为软件产品的驱动者。PO应首先打通产品价值创造和软件产品开发的连接，实现高效映射。因此一个好的PO首先应该是一个好的连接器。
拦截器。PO应该能够合理的屏蔽一些外界因素对于开发过程的干扰，给研发团队提供相对稳定的交付计划，使得团队可以有节奏的进行产品开发，让开发人员完全溶入到软件产品开发中，做好代码质量控制，提升软件产品的细节处理，让研发、测试能够以高效的节奏完成软件产品的研发。
过滤器。一个好的PO也应该是一个有效的过滤器。PO应对需求的价值和重要性进行优先级排序，让高价值需求能够优先传递到研发团队，让研发团队在有限的研发资源的情况下实现更有价值需求，优先解决产品中的重点、关键点、热点、痛点。
推动器。一个好的PO是一个推动器，让团队成员感觉到产品价值交付带来的成就感，推动团队工作进入到正反馈通道，激发出团队成员内心对于产品价值的认可，提升团队士气，建立良好的团队文化，成为一个有凝聚力的团伙。 #### PO能力要求
领导力：PO应对产品表现出热情和信念，对于这个产品/版本带来的价值表现出强烈的信心。优秀的PO能从“为什么”开始，来传递和解释产品的定位及其核心功能的思路。PO还能感召团队，调动团队成员为其开发这个产品/版本的兴趣，同时对开发出来的成果制定高的期望，包括质量的标准和用户体验等等。
平衡的艺术和能力：优秀的PO擅长于平衡，包括效果和效率的平衡，探索和交付的平衡，学习价值和业务价值的平衡，长期和短期的平衡，甚至于艺术和科学的平衡，以及感性判断和理性分析的平衡。这些都是艰难的平衡之道和每个迭代，甚至于每天都在做的决策。
Product Backlog的管理：上面提到的平衡之道，最直接体现功力的就是一份Product Backlog。PO不断地梳理Product Backlog，并做出正确的决策。极优秀的PO勇于去说“不”，去做减法，因为PO要面对大量来自不同干系人的声音和信息。好的Product Backlog管理不是左右逢源，PO应该不允许PB无休止的膨胀，而应该能让团队工作聚焦，全力以赴地关注最重要的东西。附和及迎合所有人的意见的产品管理不是最优秀PO所追求的。另外，优秀的PO具备探索的心态，知道最好的主意和想法不一定在一开始就能确定，所以他勇于和团队一起去迭代演进其对市场、用户、需求的把握。
与他人合作的能力：一方面，PO对产品功能和体验需要决策力，并是最终的权威。另一方面，PO应该具备开放的心态，尊重其他人的想法和意见，在很多细节之处愿意与他人合作，也擅于综合利用他人的智慧，整合出最棒的功能集。PO愿意投入精力和时间，与利益干系人和团队频密地互动，以听取和讨论各种想法及创意，了解开发团队碰到的问题，并频繁检验团队产出的成果，确保能不断把控和调整方向，为了获得最优的研发效果和最大化投资回报。

除了满足以上的能力要求，还有以下三点建议：

PO 是一个人并只能由一个人来担任
最佳的PO人选应该是业务方代表
PO可以由团队成员担任，但永远不能由Scrum Master担任

Scrum Master(流程管理员)

江湖上软件开发有两个大门派，第一个门派历史跟软件一样久，心法是以流程为主轴，正式名称瀑布式开发（Waterfall）另一个门派在1990年代异军突起，心法是以人为主轴，正式名称为敏捷式开发（Agile），最知名的武功是 Scrum，
瀑布式开发是法家，法为主，人为辅，强调「不别亲疏，不殊贵贱，一断于法」。只要规则定下去，照著做就会有好产品，铁打的营盘流水的官，人的因素要尽可能排除以利产出的一致性。

而敏捷式开发是道家，人为主，法为辅，主张「道法自然」。道是没有一定的形式，要观察目前的情境，考量人的天性，因势利导，以求功成事遂，百姓皆谓我自然
Scrum功夫的传道者，唯一的大绝是影响力，武器是异于常人的信心与耐心。

对于Scrum Master，有人觉的他是 Team Lead 或是 PM 的角色。但其实他没人事权不能管人，没财务权不能编预算，更可怜的是不能决定产品的走向，是个令人摧心的角色。

有些杂事都是我们Scrum Master做。

“有些杂事”包含但不限于：叫大家开会，整理Sprint Items，更新Burn Down Chart，跟PO沟通，帮忙请假，跑跑公文，买便当送饮料，按摩捶背。某些也许是团队要做，有些更适合程序员鼓励师做，但绝对不是Scrum Master的责任。

通常的原因是SM要做的东西太抽象看起来在发呆，而工业时代的思维就是，看起来不忙等于没有产值。而SM也不好意思整天就观察大家，所以拖一些杂事来做。风险就是，养了一个看起来很忙不务正业的SM，但对团队的帮助比程序员鼓励师还小（至少程序员鼓励师看了大家赏心悦目）

scrum Master的存在是为了让开发团队更好的去完成事情，所以不是SM要求团队完成事情，是团队要求SM帮助他们进步。

SM要移除阻挡开发团队进步的障碍，而非所有障碍。开发团队无法完成Sprint Goal，然后去帮忙完成，跟团队成长的关联性不大，反而让开发团队更依赖SM。SM应该针对无法完成的原因深入探讨，如技术能力不足，需求不清晰，或太多插件等等。然后帮忙从根本解决问题。