读程序员的README笔记15_敏捷计划.png

1. 行为准则

12-行为准则.png

2. 敏捷开发

2.1. 软件开发应该有计划和与之相应的跟踪

2.1.1. 你的队友想知道你在做什么，这样他们就能与你有效地配合

2.2. 敏捷开发是一种软件开发模型，被广泛采用于快速交付优质软件的场景

2.3. 要理解敏捷开发实践，你必须要首先理解敏捷哲学

2.4. 敏捷开发诞生于2001年，是由以前的开发过程（如极限编程、Scrum、特征驱动开发和实用主义编程）的领导者合作完成的

3. 敏捷宣言

3.1. 个人和互动高于流程和工具

3.2. 工作的软件高于详尽的文档

3.3. 客户合作高于合同谈判

3.4. 响应变化高于遵循计划

3.5. 尽管右项有其价值，我们更重视左项的价值

3.6. 敏捷实践的重点是与团队成员和客户的合作

3.7. 认识、接受并消化变更

3.8. 注重迭代改进而不是大爆炸式的开发发布

3.8.1. 敏捷开发模型通常与瀑布流模型形成对比，瀑布流模型是指在项目开始时就进行详尽的计划，这是一种过时的做法

4. 敏捷计划的框架

4.1. Scrum

4.2. 看板

5. 看板

5.1. 不像Scrum那样使用固定周期冲刺

5.2. 看板定义了工作流程中的各个阶段，所有的工作条目都要经历这些阶段

5.3. 看板相当于为每个工作流程阶段设置了垂直列的仪表盘，由标题框代表的任务，随着状态的变化在各列之间移动

6. Scrum

6.1. 所有的计划通常都是从前期工作开始的

6.2. 冲刺的周期各不相同，最常见的是两个星期

6.3. 在每个冲刺阶段结束后，团队会进行一次回顾总结，回顾已经完成的工作、讨论新的发现、查看关键指标，并对执行过程进行微调

6.4. 用户故事

6.4.1. 一种特殊的任务票，它从用户的角度定义了特性的需求，格式是“作为一名＜用户＞，我＜想＞＜这样＞”

6.4.2. 一种常见的用户故事的误用是把常规的任务描述塞进用户故事中

6.4.3. 用户故事通常在其标题和描述旁边设有属性

6.4.4. 最常见的两个属性是预估工数和验收标准

6.4.4.1. 用户故事的预估工数是对实现该用户故事所需努力的猜测

6.4.4.2. 验收标准则定义了该用户故事何时完成

6.4.5. 小型的用户故事往往就是工作票

6.4.6. 大型的用户故事则关联实施票或子任务

6.4.7. 尖峰是一种有时间限制的调查，它使其他故事得以完成

6.5. 任务分解

6.5.1. 单一的用户故事可能需要被分解成更小的任务，以预估它需要多长时间才能完成，用来给多名开发人员分配工作，并跟踪实施进度

6.6. 故事点

6.6.1. 团队的工作能力是以故事点来衡量的，这是一个约定好的尺度单位（以小时、天或“复杂性”来度量）

6.6.2. 一次冲刺迭代的能力是以开发人员的数量乘每名开发人员的故事点来计算的

6.6.3. 用户故事的估计时间也是以故事点来定义的，一次冲刺迭代中所有故事点的总和不应该大于冲刺迭代能力的最大值

6.6.4. 一个故事点相当于一个工作日

6.6.4.1. 基于工作日的估计通常需要考虑到非任务工作——会议、中断、代码评审等，请将一个工作日定义为4个小时

6.6.5. 预估故事点是主观的，人们往往是糟糕的预估者

6.6.6. 提高预估准确性的方法之一是使用相对大小来得出数值

6.7. 消化积压

6.7.1. 积压分流或梳理（从修剪树木的意义上讲）通常在计划会议之前进行

6.7.2. 积压是指候选的用户故事列表，分流是为了保持它的新鲜度、相关性和优先级

6.7.3. 最流行的是Scrum，它鼓励短期迭代，并经常设有检查点来调整计划

6.8. 冲刺计划

6.8.1. 一旦前期工作完成，就会召开冲刺计划会议

6.8.2. 计划会议是协作性的，工程团队与产品经理一起决定要做什么

6.8.3. 冲刺迭代的能力是通过查看以前的冲刺中完成了多少任务来确定的

6.8.4. 冲刺最重要的特点是周期短，通常为两周

6.9. 站会

6.9.1. 在冲刺计划完成后，工作就开始了，团队举行站会，也被称为Scrum会议或huddle会

6.9.2. 站会通常是在每天早上安排15分钟的会议（快到可以站着完成，不过实际上可以选择是否一定要站着）

6.9.3. 站会是一种定期的系统检查

6.9.3.1. 如果你的团队举行同步站会，应该尽你所能准时参加

6.9.3.2. 当出现日程安排冲突时，跳过站会是可以接受的

6.9.4. Scrumban是Scrum和看板的混合体

6.10. 评审机制

6.10.1. 演示是会议的重点

6.10.2. 有些团队只关注项目状态的评审

6.10.3. 标准的做法是，每个冲刺周的评审时间不应超过一小时

6.10.3.1. 两周的冲刺迭代将有两小时的冲刺评审

6.10.4. 不要为冲刺评审做过度的准备

6.10.5. 评审是为了庆祝团队的胜利、创造团结、提供反馈的机会，并使团队对进展保持诚实

6.10.6. 项目状态评审也可以帮助团队就什么是真正的“完成”以及他们如何朝着目标前进达成一致，发现的问题可以在冲刺回顾会上讨论

6.10.7. 评审会的重点是在某个冲刺阶段完成的工作

6.11. 回顾会

6.11.1. 领导者（或敏捷专家）将通过要求每个人分享上个冲刺阶段的成功案例和失败经验来召开回顾会

6.11.2. 回顾会的重点是流程和工具

6.11.3. 回顾会也是造成敏捷实践有如此众多的风格的原因之一

6.12. 路线图

6.12.1. 以两周为周期的冲刺迭代是完成中小型工作的好方法，但更庞大的项目需要更先进的规划

6.12.2. 路线图应该鼓励每个人对团队正在构建的东西进行长期思考

6.12.2.1. 更远的地方应该更模糊，而更近的地方应该更准确

6.12.2.2. 不要自欺欺人地认为任何一个季度都是百分之百准确的

6.12.3. 与被锁定的冲刺迭代不同，路线图是要不断发展的

6.12.4. 许多公司都要经历年度计划周期，管理者们在每年的最后一个季度试图为下一年的4个季度的工作进行规划

6.12.4.1. 年度规划几乎都是一个充斥着讨价还价的交易场