敏捷开发 & 团队之日常

敏捷开发（scrum）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。因此敏捷开发是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。

❶敏捷开发模型
 ✦特点：
不要求需求预先完备定义，支持用户参与，支持需求的渐进式完善和确认，能够适应用户需求的变化。
✦使用范围：
需求复杂、难以确定、动态变化的软件系统。
❷传统瀑布模型
✦特点
简单，分阶段，阶段间存在因果关系，不支持用户参与，要求预先确定需求。
✦使用范围：
需求易于完善定义且不易变更的软件系统。
❸ 敏捷过程展现

三：Scrum三大角色

➀  产品负责人PO  

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

✚职责：

★  清晰地表达产品代办事项列表条目；

★  对产品代办事项列表中的条目进行排序,最好地实现目标和使命，并且最大化实现ROI；

★  确保开发团队所执行工作的价值；

★  确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作；

★  确保开发团队对产品代办事项列表中的条目达到一定程度的理解。

➁  Scrum   Master

主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍。

✚职责：

★ 领导并指导组织采用 Scrum；

★  在组织范围内计划 Scrum 的实施；

★  帮助员工及干系人理解并实施 Scrum 和经验性产品的开发；

★ 发起能提升Scrum 团队生产力的变革；

★ 与其他 Scrum Master 一起工作,帮助组织更有效的应用Scrum.

➂  Scrum   开发团队  

主要负责软件产品在Scrum规定流程下进行开发工作，包括功能实现、测试等团队，不同职能的团队人数控制在5~10人左右，相互协作使得最终能达到Sprint的目标。

✚职责：

★  他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能；

★ 开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能；

★ Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外；

★  开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队；

★  开发团队不包含如测试或业务分析等负责特定领域的子团队。

 ❶应用Scrum的团队中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(唯品花目前使用1周的Sprint).
❷ 在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。
❸在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog.
❹ 在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。

5

➀ 我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由产品负责人 负责的；

➁Scrum开发团队(包括产品负责人)根据Product Backlog列表，做工作量的预估和安排；

➂有了Product Backlog列表，我们需要通过 Sprint计划会议从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

➃ Sprint Backlog是由Scrum开发团队去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量控制在0.5-1天内能完成），并将细化后的任务以贴便签到看板的形式体现出来供后续跟进；

➄ 在Scrum开发团队完成计划会议上选出的Sprint Backlog过程中，需要进行每日站立会议，每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人发言完成后，要同步更新自己负责的看板；

➅ 在Scrum每日站立会议过程中，将参会成员遇到的问题整理到所有人可见的看板中，记录所有需要跟进的事项；

➆ 当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 评审会议，产品负责人和客户都要参加（最好本团队老板也参加），每一个Scrum开发团队的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

➇最后就是 Sprint回顾会议，也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

⑨ 当一轮Sprint的工作完成时，就开始计划下一轮的Sprint的工作计划，直到所有Story都完成为止（计划好的n轮Sprint计划）；

六：敏捷开发流程的优点

❶ 精确：瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点；

❷ 质量：敏捷方法对每一次迭代周期的质量都有严格要求，这些都为敏捷项目的整个开发周期提供了可靠的质量保证；

❸ 速度：敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态；

❹丰厚的投资回报率：在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率；

❺高效的自我管理团队：敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。

七：Scrum常见问题总结及解决方案

➀ 故事分解任务过程中任务规划较粗，会造成在评估时造成工时不准确，存在资源浪费和资源使用不均衡的情况。

团队把工作拆分成更加细致的任务，控制在小时级的工作量，不要超过一天。这样更有利于团队为了同一个故事而共同努力，也便于协调多人同时参与，可以有效保证团队资源的均衡利用，同时也便于成员确认每天的进展。

➁ 每日站会过程中，Scrum Master会不自觉的成为主导、主持人的角色，通过问答形式与站会成员交流。

团队成员面对所有参会人员进行交流，而不是单独为PMO进行工作汇报，并引导团队成员自己掌控每日站会，从而带动整个团队的参会、工作积极性，同时控制好会议有序高效进行。(前一天做的事情、当天准备做的事情、遇到的问题)。

➂ 个别核心人员迟到或缺席，导致站立会的效率和质量下降。

确定项目的固定站会时间和必须参会人员，原则上缺席需要安排BackUp；若确定缺席，需提前告知团队成员，以便评估早会是否照常进行还是适当推迟进行；必要时可引入奖罚机制。

➃ 没有实施Sprint回顾会议，进行问题总结和跟踪。

固定1-2个迭代周期组织团队成员发起Sprint回顾会议，借助回顾的方式与团队成员共同参与讨论，总结出在上一个迭代中遇到的所有问题，并商讨产出完整的后续改进方案和流程，重要的一点是在以后的迭代中能够做到有效地跟踪并解决这些问题。

➄ 没有做好Product BackLog管理。
协调各产品经理(Product Owner)统一整理并维护Product BackLog，制定明确的优先级，使得开发、测试团队成员能够清晰、高效地筛选并完成每个Sprint内容。