Agile - 敏捷项目流程

个人的学习笔记,如果有问题可以留言。
/個人の勉強ノートです。質問等あれば、ご連絡ください。
/Just my study minutes. Do reach out to me if there is any question.

1. 敏捷背景 --瀑布型项目的问题

需求要明确，需要厚实的行业基础。可有以下问题：
- 一开始对详细的需求收集进行很高的投入。
- 一开始就要大量文档
- 客户参与度不高
- 新需求需要评估，走变更流程，需要延长进度或者增加预算。
- 需要花大量时间来汇报当前项目的状态。
- 价值只有到项目结束时才能显现，造成了较高的风险。
- 无法灵活的适应市场变化。

2.敏捷项目的特点

强调小布快走，交付优先级最高的。

需求：
 高优先1
 中优先2
 低优先3
设计：
 高优先1
 中优先2
 低优先3
... 

做法：先搞需求-设计-开发-测试-交付 各个环节中优先级最高的，做完后交付，然后搞下一个优先级的敏捷。

>优点
1. 一开始不需要对详细的需求收集进行很高的投入
2. 一开始不需要大量文档
3. 通过频繁演示，需要相关方频繁的参与
4. 拥抱变化，如果后续要加功能，随时调整优先级
5. 每次迭代（冲刺）时间是固定的（一般是2-4周）

3.敏捷与迭代的区别

单纯的迭代是迭代的整个项目。Version1.0 - Version2.0 - Version3.0
敏捷是针对一个一个功能的迭代（迭代是针对全体），
并强调做优先级最高的（迭代不强调优先级），
每一次都交付最有价值（迭代不强调价值优先），
每次都较小的增量。

4.敏捷中的三个角色

1. 产品负责人（Product Owner,简称PO）
理解并传达需求，对需求进行收集，管理和优先级排序，与开发团队写作并回答问题，接受或拒绝完成的成果。负责产品待办事项。

2.Scrum主管（虽然敏捷中不大说项目经理，这个角色通常是项目经理）
服务型的仆人式领导。不会去命令，控制，而是支持这个团队。
因为团队需要他操心。

3. 开发团队
自组织和自我管理。
团队成员由通用的专才组成。要T型人才，而不是I型人才。
I型：是对一个方向非常专业，如前端，或数据库，纵深发展的。
T型：一专多能。一个比较精的方向。

5.敏捷中如何开发项目

产品待办事项列表（Product Backlog）也叫产品充能列表或未完项。里面包含一组条目化的需求。必须从客户价值的角度去描述，并按照优先级排序。

典型的描述方法：用户故事（User Story）
作为一个角色，我想要什么功能，以便实现什么价值。
- 角色： 谁用这个功能。
- 功能：功能的描述。
- 价值：为什么需要这个功能。这个功能能带来什么价值。

瀑布型流程
范围→进度→成本 正三角

敏捷流程
进度（如两周迭代一次）→ 成本 → 范围（产品待办事项中可以做多少）

两周叫冲刺（一个迭代）：Sprint
故事点：Story Point, 是一个度量单位，可以选择最小的一个故事作为基准，来衡量其他的用户故事的工作量是多少个故事点。
为什么不用时间来衡量？因为每个人的效率不一样。避免不必要的争论。
比如，抽一根烟的时间为1个故事点，抽一盒烟需要20个故事点。就可以统一工作量。
速率：Velocity
衡量团队在单个Sprint中可以解决的工作量的指标，也是Scrum的关键指标。也就是一个团队在两周完成多少个故事点。也就是团队的能力。

举例微信软件开发（优先级的从高到低的顺序）：
- 摇一摇：120个故事点
- 漂流瓶：80
- 朋友圈：150
- 聊天：280
- 支付：200
- 拍照：100
比如，一个迭代2周，团队能力300个故事点。
那么第一个迭代：摇一摇120+漂流瓶80+拍照100（因为放不进其他优先级更高的）

如果演示后，不符合要求时？
把这些需要返工的问题作为待办事项继续排序。

团队的速率是多少？
在前几个迭代，来评估和调整团队的处理能力。
过了一段时间后，就稳定了。

如果在一个迭代中客户要增加功能，如何处理？
通常，当前迭代中不做，下一个迭代时讨论。

敏捷项目的成本，如何对应，签合同如何签？
单价合同。
可以以迭代来计算。

6.敏捷进度管理

可以使用看板和迭代燃尽图。
DOD原则：Definition of Done，要事先确定 完成的定义。
迭代燃尽图：实际剩余工作。

关于变更管理
如果客户中途要加功能，是加入当前迭代事项（Sprint Backlog）还是产品迭代事项（Product backlog）?
答：产品爹地啊事项

关于特殊情况
如果由于法律法规或紧急情况，可以直接宣布当前迭代失败。
如果确实有优先级更高的东西要进入当前迭代，那需要从当前迭代拿出相同故事点的东西。

7.敏捷中常见的四大会议

1. 迭代规划会议
每个迭代开始时，要讨论本迭代要完成什么故事，把大家一致认可的用户故事放在迭代待办事项中（Sprint Backlog）

2.每日站会
每天沟通的内部短会。因为只有15分钟且站立进行。
讲三件事：昨天做了什么，今天打算做什么，现在遇到什么问题。
即使有人说遇到什么问题，这个会议上也不需要讨论，只记录，另行安排时间解决问题。

3.迭代评审会议
再迭代结束前演示成果并接受评价的会议。

4.回顾总结会议
总结经验教训，哪些做的好，哪些可以做的更好，下次迭代准备做哪些改进。

补充：
Scrum of Scrums会议（SoS会议）：
敏捷团队有时比较大，里面有好多小的敏捷会议，对于整个一个项目如何互相了解？从各个敏捷团队里选一个人来SoS会议来回报和协调。

持续集成
第一个迭代交付的可以独立运行，第二个出来后要集成，不断集成，要保证结合后也是完整的。

测试驱动开发（TDD）
只写符合测试要求的代码，只做符合测试的功能。
盖房子是测房子是不是歪的，
并不是先造，而是用一根线先吊着，然后根据线来建房子。
以最终测试的要求要做这个东西。

------ The End -----