摘要：敏捷工作流程是敏捷团队用于开发应用的一系列阶段，从构思到完成。
每个软件团队都有一个用来完成工作的流程。对这个流程进行规范化（即，将其建立为工作流），使其结构清晰且可重复，进而具有可扩展性。在 Atlassian，我们采用迭代方法来管理工作流，因为这可帮助我们更快实现目标，体现出我们的团队文化。我们是敏捷开发工作流管理方面的专家（如果我们夸一夸自己的话），而且我们也希望帮助您成为专家。
敏捷工作流程入门
在为团队实施工作流时，始终从简单着手。抵制住花数周时间（过度）设计它的诱惑。过于复杂的工作流很难理解和采用，更不用说适应调整了。对于软件团队来说，我们建议采用以下基本工作流状态：
尚未开始的工作
团队正在积极关注的工作
已完成并等待审核的工作
已彻底完成并符合团队“完成”定义的工作
在事务跟踪器中，这些状态使用构成工作流的过渡从一个状态流向另一个状态。
一些软件团队将其他状态纳入到其工作流中，帮助他们更精确地跟踪工作状态。
已实施但仍在等待测试人员审核的工作（如需更多详细信息，请参阅我们关于敏捷测试的文章）。
代码已通过审核并准备合并到主要或发布分支。
工作流中的每个状态不一定要由不同的人来处理。随着敏捷开发团队变得成熟，开发人员负责的工作越来越多，涵盖从设计到交付整个过程。毕竟，能够应对异构工作的自主团队是敏捷开发的标志之一。
在团队回顾期间讨论各个痛点，并且牢记一点，每个团队的价值观略有不同，取决于他们的项目、技术堆栈和偏爱的工作方法。因此，选择具有灵活工作流配置的事务跟踪器非常重要。令人沮丧的是，许多团队为了适应特定工具集而在工作风格上让步妥协。这可能会导致团队成员彻底避免使用该工具，加剧整个团队的挫败感，并且造成普遍的严重破坏。一旦士气下降，生产力就会受到影响。而这是所有人都想避开的双重打击！
对于刚接触敏捷开发或不具备跨职能技能的团队，工作流中常会出现“小瀑布”。例如，设计人员使用模型来启动工作项。开发人员负责实施。测试人员确认质量。每一状态都都被封锁，直到前一状态完成。听起来耳熟？那就是瀑布。然而，我们可以利用敏捷工作流做得更好，扫清团队的障碍，让开发变得更加轻松。
针对敏捷流程进行优化
当您熟悉基本工作流程并准备好转变为敏捷流程时，可以为团队流程中的每一工作类型创建状态。构思、设计、开发、代码审查和测试是不同的职能，可以是单独的状态。瞄准一组精益状态，清晰传达每项工作所处的阶段。
项目状态也可与组织的其他团队共享。在构建敏捷流程时，思考哪些指标对报告而言是重要的，哪些指标又是非团队成员或许有兴趣了解的。例如，精心设计的工作流程能够回答以下问题：
- 团队完成了什么工作？
- 积压工作是在增加，还是能跟上团队步伐？
- 每种状态下有多少工作项？
- 是否有减慢团队节奏的瓶颈？
- 完成一项任务平均需要多久时间？
- 多少工作项未能在首轮通过我们的质量标准？
优化工作流的下一步是确保工作在工作流中平稳流动。进行中工作 (WIP) 限制规定了特定工作流状态下事务的最小和最大数量，确保每个状态都有足够的工作，让团队既能得到充分利用，又不会因为忙于处理优先事项而失去重心。执行 WIP 限制能够很快显示哪些流程会减慢工作在整个管道中的总体流动速度。随着团队学会围绕其 WIP 限制进行优化，产出也会得到提高。（如需更多详细信息，请参阅有关 WIP 限制的文章。）
扩展敏捷流程所面临的挑战
拥有多个敏捷团队的组织面临着特殊的工作流挑战。团队通常希望优化自己的工作流，以体现出独特的流程和文化。这完全可以理解。但是，如果不同团队在处理同一个项目时采用不同的流程，这可能会令人头疼。
协同工作的敏捷团队可以从共享相同工作流中受益。通过使用相同的工作流，工作可以在敏捷团队之间更轻松地过渡，因为他们使用同样的约定来定义和交付工作。为了创建一个共同的流程，通常需要两个团队做出一些相互迁就。这很好！他们可以互相学习，最终制定出更好的工作流。
借助 Atlassian 的事务跟踪器 Jira，团队不仅能共享工作流，还可以在敏捷面板上以不同的形式呈现流程。这种能力可带来灵活的可视化选项，而且不会影响工作流的共享资产。
无论工作流是什么样的，它的开发过程也应该是敏捷的。不时在回顾期间加以讨论，并随着团队文化和组成的变化而进行调整。
