当我们在谈敏捷时我们在谈什么？( 三 ) _敏捷

这几项原则的出发点是为了让任务像水流一样可以流动，不至于阻塞团队。我们不必同时满足这几项原则，因为这几项原则可能在某些条件下矛盾，而是根据情况尽可能做到这些原则。
其中，独立和可被测试让任务可以一定程度上“单件流”，这样测试人员可以提前进行测试；可以估算和短小是为了不阻塞其他人，并能在迭代内部完成集成，满足迭代周期要求；可协商性、有价值是为了能快速给客户演示，并获取反馈。
反之，如果一个迭代必须所有任务合并起来测试，这就像瀑布一样整体分析、开发、提测，会带来人员空闲、集成风险增加的问题。
将用户故事放到团队的代办清单中就叫做 Backlog 。Backlog 是一种弹性空间，我们需要假定团队的工作速度往往不是恒定的，如果工作状态良好就从 Backlog 中获取任务，如果团队进展不理想，就先把任务放回 Backlog 。
估算和迭代计划
单纯有了用户故事还不够。如果我们需要计划迭代过程，就需要任务。团队中的任务往往分为四类：

用户故事
技术事项
日常工作事项
Bug

团队 Backlog 主要构成为用户故事、技术事项，可以把用户故事进行估算就成了任务。技术事项往往不满足 INVEST 特点，所以常常不被看做用户故事，特殊处理不过也需要估算工作量。
在常见的敏捷实践中，有两种估算形式。一种是通过人天来进行估算，一种是通过复杂性来估算。
通过人天估算很容易理解，就是团队的平均水平而言，完成一项任务需要多少天时间。而通过复杂度估算比较复杂，需要找到一项可以参考的任务作为 1 个基本点，其它任务根据这个基本点来进行估算。
在以前的项目中，非常流行使用复杂度估算，并通过斐波那锲数列进行递增（这当中的科学道理我并不知道，也可能是一种文化）；现在越来越多的项目回归人天估算，因为更具有操作性。
通过对任务的估算并结合每个迭代投入的人员数量，可以计算出这个迭代的能完成的任务量，并做合理的规划。
毕竟制定一个永远无法完成的计划和没有计划的结果类似。
敏捷会议当我们谈论敏捷时，另外一个方面是敏捷的会议。
敏捷中有很多会议一般以 Scrum 为代表，有很多文章都介绍过这些会议。这篇文章中，我尝试把这些会议和具体解决的问题映射上。
和敏捷实践相比，会议更像套路，所以需要根据实际环境裁剪制定，这也是为什么没有一套标准的工作框架流行开的原因。
站会站会和大家熟悉的晨会是一样的，站立会议的目的是为了更加高效，追求尽快结束。
站会的目标是更新每项任务的状态，同步团队信息，发现和解决阻塞项。一般有两种运行模型，一种是基于任务清单更新，也可以基于参会人轮流更新。
站会陈述的模板一般为三段：

昨天做了什么？
今天做了什么？
遇到了什么困难？

工作量评估会议工作量评估会议和敏捷实践中的估算对应，是为了更好的进行迭代计划。
工作量估算会议的另外一个用途是对需求的进一步澄清，在工作量评估会议之前，需要完成技术方案设计，才能有效评估出工作量。
在某些团队中，工作量评估会议需要全员参与并投票，并陈述差异。不过这种实践参会成本太高，往往会被简化为关键人员参与即可。
工作量评估会议发生在迭代开始之前。
迭代计划会议工作量评估会议完成后，项目经理或者迭代经理需要计划下一个迭代，包括需求、人员规模、时间等内容。
迭代计划会议的目的是将迭代计划和整个团队同步，有时候也会包含业务需求串讲和同步。
迭代计划会议往往发生在迭代前或者迭代的第一天，迭代计划会议前需要准备好所有的任务清单。
开卡、结卡在敏捷会议中，非常具有仪式感的会议就是开卡、结卡（因为很多时候任务被以卡片的形式书写并放到看板上管理的）。
开卡的意思是开发人员领取任务时候需要找业务人员、测试人员对齐该项任务的内容，所以一般由三方人员参会故被称为 “Three Amigos” 。
结卡同理，当完成任务后，开发人员需要找到业务人员、测试人员进行验收，然后该任务会流转到下一环节。