敏捷项目管理介绍及实施

一. 简介

敏捷开发 Scrum Scrum就像你的丈母娘，不断支出你的问题在哪，错在哪 Scurm只是不断的暴露你的问题

团队问题: 做出来的项目无法满足客户需求-分析到底是谁在用

蜕变: 敏捷开发，倾听用户剩余

• 倾听用户痛点，了解使用场景
• 小版本迭代，边做边使用调整
• 团队高度合作，加班也happy
• 研发人员体验运营人员的工作场景
• 却说运营人员排除一个代表到研发部门

1. 产品代办列表

· 排序：产品一定是排好续的 · 详略得当：越上面，越排前的比较详细，越后面的相对粗略 · 动态的：调整顺序，及调整价值，那个价值高，就可以调整前置 · 估算需求的大小：价值，成本

2. 透明

传统：代码不可见，需求方对进度不可见，程序员对业务场景和用户使用习惯不清晰 敏捷: 任务看板，用户展示会议

3. 迭代

增量式软件开发 在时间限定，限定资源的情况下，重复做一件事情 2~4周的迭代形式进行，结束后进行回顾和反思，并拿出潜在的可交付的软件

4. 反馈

传统: 产品开发完毕交付到用户手中，才能得到用户的反馈 敏捷: 每日站会(15m)，评审会议(反馈)，回顾会议(问题及优化)

5. 传统开发中的问题

· 用户需求和最终成功存在偏差 · 需求，设计，开发，测试一环套一环，需求修改智能拼体力 · 很多公司向节约成本，缩短开发周期，导致质量不能保证 · 文档复杂，用户需求变化后，维护成本高

6. 什么是敏捷开发

敏捷开发(Agile Development) 一种以人为核心，迭代，循序渐进的开发方法

7. 敏捷方法论

Scrum，极限编程(XP), MSF,OpenUP(RUP敏捷版)，水晶方法…

XP-偏重于结果(以结果为导向 ) Scrum-偏重于(开发)过程

二. 核心

1. 敏捷四大宣言

· 个体和互动高于流程和工具 · 可工作的软件高于面面俱到的文档 · 客户合作高于合同谈判 · 相应变化高于遵循计划

2. 敏捷十二条准则

· 目的: 使客户满意 · 态度: 欢迎需求变更 · 关注: 客户需求的软件 · 合作: 推到那堵墙 · 核心: 团队成员 · 沟通: 面对面 · 标准: 可工作的软件 · 倡导: 可持续开发 · 追求: 技术卓越和设计良好 · 根本: 简洁 · 团队: 自组织 · 调整: 定期反思

3. Scrum 框架来源

· 带球过人需要计划 · 带球过人需要灵活应变

Scrum 是一个用于开发和维持复杂产品的框架，增量，迭代

产品backlog -> sprint计划会议 -> sprint backlog ->(每日站会/2~4周sprint) -> 潜在可交付产品增量

4. Scrum 敏捷的核心要素

4.1 三类角色 product Owner/The Team /Scrum Master

4.2 三个工件 Product BackLog Sprint backlog Increment

4.3 四种会议 Sprint Plan meeting Daily Stardup Meeting Review Meeting Retrospective Meeting

5. Scrum 三大角色

5.1 Product Ownner(PO)

· 与客户沟通 ：确定客户真正意图，产品交付日期 · 与团队沟通 ：共同确定需求 · 考虑团队研发实力

5.2 Scrum Master

· 负责整个Srum流程在项目的顺利实施和进行 · 没有行政权力 · 不帮团队做决定，可提出意见

5.3 Develop Team

· 负责整个Scrum流程在项目中的顺利实施和进行自组织的开发团队 · 一般5~9人 · 跨职能团队(业务分析师，程序员，测试人员，架构师，数据库设计师 )

自组织团队

6. 工件

product backlog po负责产品列表，随优先级，价值和风险而变化的文档 sprint backlog 团队负责随时更新，是团队在sprint中完成的任务清单 increment 每个sprint的交付件

6.1 Product Backlog 需求列表

字段: 编号，名称，重要度(IMP)，初始估算(EST,故事点)，如何演示 可选: 类别，所属组件，请求者，bug跟踪ID

6.2 Sprint Planning Meeting 迭代开发计划会议

Scope + Estimate + Impotence

· 召开时间：每个迭代第一天召开 · 目标：选择和估算本次迭代的工作项，指定Sprint Backlog · 参会人: PO，,ScrumMaster,DevelopTeam · 会议准备: - Produck Backlog - 上次Sprint Review Meeting - Retrospective Meeting结果， - Sprint时间表安排 · 会议进程: - 公开Sprint 时间表 - 一起确定Sprint目标 - 如果有问题一楼，Po有权向Backlog中添加 - 细化任务(编码，测试，代码评审，编写文档…) 一个个task，需要添加点数，和est那个类似

6.3 Daily Stardup Meeting

· 召开时间: 每天早上，10~15分钟，严格控制时间 · 目的: 成员进度的协调和沟通 · 参会人: Scrum Mstart ,Develop Team,Po 或其他相关人员 只有团队 · 注意: 只有成员可以发言，其他人可旁听 · 会议内容: - Scrum Master主持，团队成员轮流发言(昨天，今天，问题 ) - 更新任务看板，燃尽图

看板

JIRA 敏捷项目管理工具

燃尽图

7. Review Meeting

· 展示功能给Produce Owner,也可以邀请项目其他成员 · 形式: 展示完成功能， · 步骤: - 阐释Sprint目标 - 演示关注业务层面，不是技术层面 - 不需要花哨，只需介绍实现了什么 - 可以的话，让用户体验

8. Retrospective Meeting

· 团队定期的自我检视 · 每个sprint都要做 · 明确好的地方和需要改进的地方

三. 团队组建

1. Scrum开发团队

· 5-9人 · 项目期间，专职投入，以跨职能的方式一起工作 · 每个Sprint结束，提交可工作的软件

2. T型人才

· ——为表示有广播的知识面，|表示有知识的深度 · 既要有较深的专业知识，又有广播的知识面 · 一专多能

ScrumTeam 需要由T型人才组成

问题:如果没有足够好的员工， 解决方案: 专职核心团队+顾问团队

问题: 新团队新项目，如何估算团队速率？ 解决方案: - 使用历史数据(同一团队或其他团队的) - 猜猜看， - 到时候再说

估算工具: 斐波那契数组 （纸牌）

四. 产品需求和用户故事

用户故事: 促进沟通，持续交付，开发敏捷

客户最终需要的并不是文档 短小金瀚的故事可以帮助我们推进沟通，挖掘客户的真是需求 而是通过软件帮助其完成业务价值

什么是用户故事？ 作为一个角色，我想要功能，以便以商业价值

用户故事的描述（3C原则） Card：卡片 Conversation：交谈 Confirmation: 验收

1. 用户故事Invest原则

· 独立的， 可以围绕一个任务，而有一定独立性，并可测试 可以通过组合，分解用户故事，减少依赖性 · 可以商议的， 可协商的，不是合同 细节限制的客户的沟通 · 有价值的 必须以交付商业价值为目的 · 可估算的 ，小的 是进行项目合理估算的基本要求 用户故事需要足够小，颗粒度一致 一个大的story是若干小的story集合 · 可测试的 便于确认他是可以完成的

2. 用户验收

Happy Path Sad Path Performance Usability Security

3. 用户故事分解

3.1 用户故事与需求文档对比

需求文档规定的比较细致，最整体的把握会减弱 不能进行分解 不能进行优先级排序 无法进行跟踪 给设计人员和开发人员发挥空间少

任务-故事-Sprint-发布模型 的关系

3.2 绘制用户故事树

分解是自上而下的， 故事树的完善是自下而上的， 跟客户沟通的是整个故事树 开发的永远是最底层的故事

· 节点业务边界，用户角色 · 故事从哪里来？ · 编写用户故事？ 用户故事列表，包括ID,Name,Discription,How To Demo · 用户故事的细节 需要考虑哪些细节，或略哪些细节？ 只需考虑重要细节，根据经验以及客户的观点决定

3.3 用户故事估算故事点

每个Sprint应完成故事点数 每个Sprint实际完成故事点数

不能如期完成怎么办？

1. 选择次要的用户故事推迟发布？
2. 简化用户故事
3. 增加开发人员 项目认输不能太多，周期不能太长

五. 高效的每日例会

· 每人发言 - 昨天做了什么 - 今天要做什么 - 遇到什么障碍，需要哪些帮助 · 更新看板 · 更新燃尽图

1. 意义

· 及时发现项目中遇到的困难，从而避免项目风险 · 团队成员各自汇报当天工作，打破沟通比例 · 成员感受项目状态，根据进度及时调整项目工作计划 · 增加项目凝聚力

1. 暴露隐藏的问题
2. 任务增加不是问题，记得细节任务，更新燃尽图

2. 每日例会常见问题

问题1： 开会迟到

1. 约定开会时间
2. 提醒
3. 共同协商惩罚办法，团队基金，俯卧撑

问题2: 打断别人，深入细节讨论，未能合理把握会议节奏

1. 说话令牌

问题3: 漫天跑题

1. 会前准备好问题和解决方案，限定下问题的范围和边界

3. 成果秘诀

1. 保持会议周期 每天开会不可商量，团队保持一种模式，一种肌肉记忆，而不是像散步游泳的各自完成各自的目标，并能够及时解决遇到的问题
2. 占着，不要坐着 能够使我们转系投入会议，缩短会议时间，使团队成员更加 专注
3. 朝共同目标前进的集体 不是一群鸽子承担专业化任务的散沙
4. 耐心 纠正行为，形成新的模式需要时间和耐心

六. 其他

1. 学习

https://www.bilibili.com/video/BV1pz4y1R7WK