在敏捷开发的实践中，通过规划冲刺中不同的阶段，开发可以达到如下几个目的：

可视化管理团队的目标；

明确目标的优先级；

明确目标分解后的任务项；

可视化管理任务的进展状况。

规划冲刺

利用发布计划，可顺利地将粗颗粒度的故事分配到发布中的多轮迭代中。不过，在开始一轮迭代时，有必要去针对该迭代再去做进一步的计划。

计划会议

整个团队通过举行计划会议来为下一个迭代做计划。客户以及团队中的所有开发人员，包括程序员，测试人员和其他人都要参与这个会议，计划会议的内容一般如下：

讨论分析用户故事；

从故事中拆分出任务；

分配每个开发人员需要承担的任务；

开发人员单独估计自身所承担的任务，以确保他们不会做出过于乐观的承诺。

在实际的操作中，团队计划会议后会开启一个冲刺，将backlog中确定在该冲刺进行的故事拖到冲刺列表中，随后为每个故事进行分解并关联对应的任务。

讨论故事

迭代计划会后，团队会获得一个已经排好优先级的故事集合。正如程序员可能改变他们对实现一个故事难度的看法，客户或产品负责人一样可以改变他们对故事优先级的想法。计划会议是客户或产品负责人为团队调整故事优先级的最佳阶段。

会议中，PO（产品负责人）会从最高优先级的故事开始给团队讲解每个故事的内容。然后由开发人员提问，直到他们充分理解故事，能从故事中分解出任务。这个过程没有必要理解故事的所有细节，过分地深入每个故事细节会使会议变得低效、冗长，因为会议中不是每个人都需要聆听所有故事的细节。在计划会议后，开发人员可以和PO一起理清故事的关键细节。

拆分任务

理解用户故事的大致内容后，需再将故事分解为任务。在JIRA敏捷管理中，可以通过创建子任务的方式来分解故事，并将故事与这些拆分后的任务进行关联。只有当所有的子任务状态变成已完成时，这个故事才能拖到已完成的列中。

为何要拆分故事而不直接把故事作为独立的工作单位？

尽管故事的确可以小到作为工作单位，但将故事拆分出更小的任务，一般更符合项目开发的需要。

首先，对于很多团队来说，实现故事的开发人员不止一个，需要由多个开发人员共同完成一个故事。这要么是因为开发人员在某些特定技术上的专业性，比如前后端分离开；要么是因为工作划分是完成故事的最快途径。

其次，故事是对用户或客户有价值的功能的描述，不是开发人员的代办事项，把故事拆解成任务有助于发现那些可能会被遗忘的任务。一整个小组一起来拆分任务，依靠的是所有人的集体智慧，避免某个人忘记了故事中的某个部分。

相比瀑布过程，敏捷没有前期设计阶段，其过程特点是做频繁的短期设计，当脑海里至少有一个最小的设计方案时，才可能从故事中拆分出任务。所以，一个故事的任务拆分其实是即时设计中的一次短脉冲，以这些短脉冲的集合取代瀑布过程的前期设计阶段。

在团队成员说明任务时，需要实时将围绕某个故事的任务都记录下来，然后将任务以卡片的形式在物理或电子看板中进行展示。

JIRA敏捷管理中的活跃冲刺模块，团队可以针对每一个迭代开启一个新的冲刺，规划好时间，通过看板工具实时查看工作进度或开发瓶颈。

承担责任

通过看板，我们可以清晰地看到每个任务的责任人（采用结对编程时，每个任务也只关联一个人的名字，此人将承担完成任务和与PO、客户沟通信息的责任，确保在迭代期间完成任务。）

虽然任务事先已经由每个人认领，但在冲刺期间并不是一成不变的。在冲刺中，随着开发取得进展，成员会比之前预想的更了解任务，因此任务的认领及承诺也需要相应做出调整。

在敏捷中，团队协作非常重要，只有所有人达到预期，这个迭代才算完成，如果有开发人员不能完成他承担的所有任务，团队中的其他成员应该尽量勇于承担。

估算和确认

通常当一个团队经历了3个以上的迭代之后，基本可以确定团队的速率（即一个迭代可以完成的故事点总数），当然前提是每个迭代的时间周期是一样的。

假如你的团队的速率是平均每个迭代40个故事点，每个开发人员首先以理想时间估算自己承担的工作量，然后整个团队相加进而做出实际的评估，判断在该迭代中能否完成所有任务。

例如，为期2周的冲刺开始了，一个开发人员估算完成任务实际需要55个小时，算上必须要做的其他事情，没有把握在这些任务上投入更多时间，这种情况有以下选择：

继续往前走，一个一个的去完成，寄希望于一切顺利

请求团队中其他成员接收一部分任务

与PO讨论，放弃一个故事，或者拆分故事，放弃其中一部分

最好的方法是后两种，整个团队必须同舟共济。

开启冲刺

迭代会议结束后，团队正式进入到这个迭代的开发中。JIRA敏捷管理中，把一个正式开启的迭代称作为一个活跃冲刺，一个看板针对一个活跃冲刺。团队根据计划制定这个迭代的目标和时间范围。

在迭代过程中，JIRA管理引用了看板方法来管理我们的开发。 看板的结构通常包括如下几个列： - Backlog ：是这个冲刺需要完成的所有用户故事，这些故事加在一起就是这个迭代的目标，这些故事通常按照优先级从上到下排列。 - 待办 ：这一列代表的是待办任务项，用户故事会被拆分为对应的开发任务，这些待办的开发任务将展示在这一列中。 - 进行中 ： 进行中的任务。 - 完成 ：已经完成的任务和用户故事。

任务看板上除了有默认的3列之外，还可以自定义新建泳道，通过泳道来管理故事和任务的对应关系。

在冲刺的交付阶段我们应该将以下几点作为看板方法的步骤去贯彻执行：

专注于质量；

减少进行中的工作（work-in-process）；

频繁交付；

根据交付速率来平衡任务的请求量；

按照任务的优先级排序进行开发；

消除变异性的根源，提高可预测性。

专注于质量

很多开发团队将可用资源花在与缺陷修复相关的工作上，这会对高缺陷率团队的生产力和交付速率产生巨大影响。

鼓励提高初始质量，很可能提升2-4倍的交付速率，如果团队真的很糟糕，那么通过“专注于质量”的做法，甚至都可能获得10倍的交付速率的提升。

专业的测试人员应该做好测试，让测试人员来发现缺陷，防止缺陷遗漏在代码中。要求开发人员编写单元测试代码，使单元测试代码自动化，也就是我们经常提及的自动化测试，以提供自动化的回归测试，这样也可以产生巨大的效果。测试驱动开发似乎确实能带来使测试覆盖更为完整的好处。对于普通团队，在功能编码前编写测试代码，能够提高代码质量。

代码检查能够帮助改善外部和内部的代码质量，最好经常做，并且以小批量进行为好。

协作式的分析和设计，也能够提高代码质量。团队一起分析问题和设计解决方案，产出的质量会更高。

还有使用现代开发工具提高质量，许多现代开发工具都包括静态代码分析和动态代码分析的功能，需要在开发中不断地进行代码优化，这些工具可以防止程序员犯低级错误。

减少在制品

在制品和平均前置时间之间存在相关性。前置时间越长，质量就会显著下降，而在制品数量越多，平均前置时间则越长。因此，提高质量的关键是减少在制品数量。

减少在制品的数量或缩短迭代的长度，将对初始质量产生重大影响。随着在制品数量的增加，缺陷数量会不成比例地增加。为期2周的迭代比4周的迭代好是很有道理的。较短的的迭代会产出更高的质量。

仅需使用看板来限制在制品数量便可提升质量，那为什么不引入明确的规则来限制在制品数量，解放管理人员使其可关注于其他的管理工作。

敏捷管理中强调的对于在制品的限制，JIRA管理也进行了应用。团队可以根据开发能力和进度设置列约束，通过限制处理中的卡片数量来控制开发人员的在制品数量，只有当在制品卡片数量小于限制数，才可以到backlog中拉取新的任务。如下图：

频繁交付

减少在制品数量能够缩短前置时间，缩短前置时间意味着可以更为频繁地提交可用的代码。频繁的提交代码，能够与外部团队或业务建立信任。

JIRA敏捷开发中，开发人员会在每天定点提交合并代码（即使只完成部分功能）。如下图的代码提交日志会记录每个人提交合并的时间，会对提交代码部分进行备注，这样可以提高多个开发人员的合作效率：

在软件开发中，规模虽小但是频繁、高质量地发布交付，较之规模大但频率低的发布，更能够在团队合作上建立起信任。小规模的发布说明，团队具有交付能力，并能够一直致力于产出价值。便于软件开发团队与市场、与用户之间建立起信任。

为什么以小批量的方式进行编码能够提高产品质量？这点其实也很好理解。随着进行中工作项数量的增加，问题的复杂性也会呈指数级增加。在软件开发中，有很多知识迁移和信息发现活动，他们是隐性的，而且都是面对面的协作过程中发生的。虽然这些信息具备口头表述性和可视性的特征，但是他们大多以画像在草图之类的非正式形态存在。我们的大脑无法存储这些隐性知识，即时记住，也会遗忘。更无法记得确切的细节，并会因此犯错。

如果减少进行中的工作，能减少对隐性知识的遗忘，从而获得高质量的产品，并促进更为频繁地发布。

根据交付速率来平衡任务的请求量

意味着根据交付可工作代码的速率，来设置新的任务进入开发流中，这样便可有效地将进行中的任务数量固定在某个值。在有交付后，便会从SpringBacklog里拉入新的任务。因此，任何对新工作的优先级排序，只可能在现有任务被交付的情况下才发生。

这一变化具有深远的影响，流程的交付速率会受限于某个瓶颈，可往往很难准确的找到这个瓶颈在何处。事实上，价值流中的每个人都会说自己已经超载。但通过交付速率，处于价值流其他环节的人员就会发现他们有了富余能力，而那些处于瓶颈处的人员的工作会很忙，但不会过载。这时整个团队成员会有一种手头终于有时间的感觉了。

在活跃冲刺中，团队可以实时查看每个成员的任务量，从而掌握团队进度以及瓶颈。

人们只有释放了大部分压力，才能集中精力准确高质量地完成工作。那些手上有富余时间的工作者，会开始将精力投向于环境改造。他们可能会开始不断提升自身技能，改进使用的工作，改善沟通协作方式等。随着时间的推移，团队在持续进行改善，进而整个团队都会得到改变。通过限制在制品以及当只有可用产能时才拉入新工作的做法，产生的富余时间能带来无法想象的改善行动。

想要进行持续改善，就要具备富余时间，为了产生富余时间，要做到根据交付速率来平衡需求请求量，限制在制品的数量。

优先级排序

当团队做到前几点要求后，心理重心应该转向优先级排序，而不仅仅只是交付的代码数量。

当交付方面缺乏可预测性时，很少有人会去关注优先级排序的问题。在解决这个问题之前，需要保证次序的可靠性，将管理精力重点用于改善交付能力和交付的可预测性上，一旦能够真正做到按需求请求的大致次序交付需求，就应该把思考转向如何对输入的需求进行优先级排序。

JIRA敏捷管理中，根据计划会议讨论后的结果，PO可以重新对故事的优先级进行排序，团队也将根据这个优先级安排开发任务的顺序。

如果不具备定期交付高质量代码的能力，就不可能建立起信任关系，因此，在优先级排序上具备影响力的可能性也会很小，也就无法进一步优化团队交付的价值。

总结

在敏捷管理方法中，前期的需求计划和讨论必不可少。而在正式的开发过程中，首先要学习构建高质量的代码，其次，减少进行中的工作项数量，缩短前置时间，并频繁发布。第三，根据交付速率来平衡需求请求量，对在制品设置限制，进而产生富余时间并释放个体的创造力，促进改善行为的发生。第四，随着软件开发的顺畅运转和能力优化，通过改善优先级排序来优化交付的价值。

期望一步实现优化业务价值，只是一种不切实际的美好愿望。遵循以上几点并采取行动，会让你的敏捷团队逐步达到期望的成熟度水平。