01-Scrum 概述 ,02-橄榄球 VS 软件,03-Scrum敏捷方法一分钟扫盲 ,04-Scrum敏捷方法中的工作产品 ,05-Scrum敏捷方法中的角色,06-Scrum过程-创建和维护产品

敏捷，来源于橄榄球中的“带球过人”。

在橄榄球的比赛中，每次的冲刺前，都有一个计划安排的过程，但是在冲刺的过程中，队员都会根据当时的形势，在原计划的基础上随机应变。

瀑布模型的开发过程：需求、设计、编码、测试等阶段。

Scrum的开发过程：多次的迭代(又称为Sprint，冲刺)，周期一般为2~4周。

在日常的工作中，【产品负责人】会维护一个按优先级排序的＂产品待开发项＂(Product Backlog) 。"产品待开发项"就是根据客户的需求，得出产品的功能点。

在每次迭代的第一天，都会召开【迭代计划会】(Sprint Planning Meeting)。产品负责人先总体讲解产品，按优先级由高到低逐一讲解。团队Member可以就需求的细节、完成的标准等信息进行咨询，并逐条根据难度估算工作量，添加到本次迭代的开发任务中，直到本次迭代任务量达到饱和。一旦迭代开始，正常情况下，这些任务是不能发生大的变更的。在得带期内，团队进行任务的分配、所需技术的调研，逐一完成任务。每天团队会进行一个简短的【站立会】即"每日立会"(Daily Stand-up Meeting)，沟通当天的进度、当前的问题以及下一步任务等，以借助团队的力量解决遇到的问题。团队还维护一张【燃烧图】(Burn Down Chart)即随时间的递减任务完成的进度图，以观察和预测所有任务是否能够按期完成、以及了解自己的生产效率，从而降低项目的风险。

在每个迭代的最后一天，团队召集【评委会】(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能进行评审，产品负责人进行审核或作出改进的反馈。当天还会召开【反思会】(Retrospective Meeting)，对本次迭代中的成功与失败作出总结，并在以后的迭代中进行改进。

//

02-橄榄球 VS 软件

1.带球过人需要计划！

　　在球场上：在比赛每段的开始，双方都要摆开阵势，并计划本段的迕攻/防守路线和策略，教练和队长都可以参不计划。
　　在软件开収公司：在每丧迭代的开始，团队领导者都应该做好本迭代的计划，尤其是需求条目的优先级排序、选择本迭代的工作、设定必须完成的内容等。

2.带球过人需要灵活应变！
 在球场上：当哨声响起，尽管队员们劤力按照既定计划推迕，然而场上瞬息万发，队员丌可能实时按照教练戒队长的指令亦步亦趋地行亊，而是靠平时讦练丨形成的素养见机行亊，达成目标。
 在软件开収公司：在每丧迭代开始后，团队领导丌可能也丌需要亊必亲恭地者介入每件亊情，而是应该由具体执行的人选择如何去做。团队领导要做好的是协诽资源、览决困难、提供指导，以达成目标。

 

Scrum中既有计划会、每日立会、评审会等计划和管理活劢，又有迭代期内的灵活应变活劢，是一种轻重结合的敏捷过程。

//

03-Scrum敏捷方法一分钟扫盲

1.产品负责人：根据客户需求、市场，以实现功能为目的，发挥的创意，建立条目化的产品待开发项Product Backlog，并进行优先级的排序。

2.在【迭代计划会】上，产品负责人讲解迭代要开发的条目，团队进行Importance值的估算并商谈决定是否放入到本迭代中。

3.迭代任务确认后，进行为期2~6个周的迭代开发，团队在迭代内完成所有需求，每天都开"站立会"，以沟通进度和解决疑难问题。

4.在迭代终点的【迭代评审会】上，团队向产品负责人等展示开发成果。

5.团队进行【反思会】，总结本次迭代开发，成功/失败的经验。

//

04-Scrum敏捷方法中的工作产品

1.产品待开发项(Product Backlog)：从客户的价值角度理解产品的功能列表。

　　a.功能点、缺陷等都可以是Product Backlog。

　　b.Product Backlog一般以条目化的方式描述。

　　c.Product Backlog 的名称一般以白话来描述，方便客户和用户的理解。

　　d.整体上，Product Backlog是从客户的价值上排列顺序的。

　　e.总开发量一般在0.5~10人天。

　　f.Product Backlog的名称必须言简意赅，而且要唯一。优先级高的描述要清晰、详细，低的暂时可以不用太详细。

2.冲刺待开发项(Sprint Backlog)：是从开发技术角度理解的迭代开发任务。

　　a.在简单的纯软件环境中，可以直接把产品待开发项当作冲刺待开发项分配到迭代中。

　　b.在复杂的软件开发中，尅把一个产品待开发项分解为Web/后台...软件/硬件...程序/美术...等开发任务。

3.可工作软件Workking Software：是可交付的软件产品。

　　a."可交付"，在不同的场景下差异很大，应视不同情况提前设定和选定交付标准。比如是否需要测试，是否需要性能优化，是否需要操作手册等等。

　　b.正是产品中可能包括使用文档，甚至是纸质的。在新产品开发的初期，则可能只需要交付勉强可看到效果的产品。

、　c.产品负责人、用户代表等负责评审可工作软件。

　　d.若一个产品的功能只是"差不多完成了"，那么这种效果的功能被视为不可交付。

//

05-Scrum敏捷方法中的角色

1.产品负责人(Product Owner)：负责产品需求的提炼、条目化、优先级排序。

　　现实世界的产品负责人：

　　　　a.，部门经理，产品经理策划人员等都可能作为产品负责人。

　　　　b.产品负责人是产品的指路人，必须对产品有深入了解和长远的规划。因此，不能单纯的选择客户或销售人员作为产品的负责人。

　　　　c.大型的产品如嵌入式产品或游戏产品，常常采用有等级的产品负责人团队，来解决广度与深度的矛盾。

　　　　　　例如：产品总监->产品经理->主策划->策划团队

2.Scrum Master(Scrum 大师)：负责Scrum的执行和指导，并协助解决非技术问题。

　　现实世界的Scrum Master：

　　　　a.Scrum Master的工作方式是靠领导力而不是权力工作，因此，应该服务于团队。

　　　　b.人选：

　　　　　　aa.原来的项目经理转型，保留原有的管理和技术职能，但弱化指派任务、下达时间点指令等职能，增强其组织协调能力。

　　　　　　bb.企业原有的过程改进人员，协助不太了解Scrum的项目经理按照Scrum的方法工作，可以每人负责多个项目，接近全职的Scrum Master。

3.团队(Team)：以"自组织"的相对扁平式进行管理，负责完成开发工作。　

　　　现实世界的团队：

　　　　a.实际团队常常不是"扁平"的，而是仍有项目经理、小组长等职位。

　　　　b.工作中他们以"共同估算"，"跨职能工作","共同跟进"等方式自组织工作，而不是完全依赖层层的指令。

　　　　c.项目经理、小组长的领导、指导、协同职能大于其指令职能。

//

06-Scrum过程-创建和维护产品待开发项Product Backlog

1，产品待开发项：又称"产品功能列表"，是一组条目化的需求。

2.产品待开发项必须从客户价值角度描述，并按优先级排序。

3.典型的描述方法就是极限编程中提到的"用户故事(User Story)"。

 

如何填写"产品待开发项"？

1.产品负责人创建和维护产品功能列表。

2.需求必须进行条目化管理，才能进行分配、开发、跟踪，才能清楚的看到什么做完了，什么没做完。

3."客户价值角度"就是描述用户如何使用，而不是技术角度上的如何实现。比如："实现手写输入"，"实现游戏排行榜"，而不是"编写数据库底层"。用户故事的语法"作为一个...可以...，以(以便)..."很好地证明了这一点。

用户故事：