敏捷开发的实质是通过迭代式增量软件开发的方式，防止出现长期闭门造车严重偏离客户需求，达到快速响应市场变化的目的。
应用敏捷就会一帆风顺吗？显然答案是否定的。越来越多的组织、团队开始学习、实践、导入敏捷，然而效果确实相差甚远、判若云泥。为什么会这样？或者说敏捷转型有这么多痛点？
其实，敏捷开发只是一种指导思想和原则，敏捷开发并没有给出具体的实践步骤，重要的是通过实践哪些方法可以帮助达到目标，或者解决哪些问题从而达到目标。
接下来会结合过往的实际经验，介绍敏捷团队走完一个迭代所涉及的内容，希望给即将或已经进行敏捷实践的个人、团队和组织带来一些思考和参照。
以下的内容会以 Scrum 框架为主，但不仅限于 Scrum 框架。
这里我们为了提效利用 Gitee 帮助我们更好的理解如何实践敏捷开发。
在版本规划时，建议综合考虑客户的价值、整体质量与范围、进度、预算等限制条件。常见版本四种发布规则 ，团队采用最适合的即可。
1.在每个冲刺后发布，而是把多个冲刺的结果合并为一个版本进行发布；
2.发布和冲刺保持一致，即冲刺结束后立刻进行版本发布；
3.按特性发布，即每次做完一个特性就进行一次发布，我们管这种发布也叫持续交付；
4.按需发布，它是综合以上发布，按业务方的需求来选择何时发布。
不管你采用哪种方式进行发布，大多数组织实践中发现最好能够稍微做一些长期的规划，有利于整体统筹规划。有些组织可能用别的名称来代替，比如：长期规划（放眼于多个冲刺）、里程碑（各版本与重大里程碑一致）。
我们需要理解，在这里程碑可以是一个迭代，也可以是多个迭代，这和我们的规划相关。为了方便，我们在这里视一个里程碑为一个迭代，即“库存管理上线”为一个迭代。
Scrum 框架下有三种常见角色：产品负责人（Product Owner）、Scrum 主管（Scrum Master）、团队成员（Scrum Team）。
根据我们开发中的实际情况将角色分为以下四种：
1.项目经理：相当于 Scrum 主管，负责协调团队内部合作，召集站立会议，把控项目整体进度；
2.产品经理：相当于产品负责人，负责决定应该做什么工作，明确工作项、评定优先级，拟定待办事项 Backlog 清单的内容，确定各个事项的优先顺序；
3.开发人员：开发人员是项目开发任务具体的实施者。他们负责完成开发任务，及时反馈开发进度；
4.测试人员：测试人员是项目测试任务具体的实施者。他们负责制定测试计划，编写测试用例，创建以及回归缺陷。
项目开始前，由产品负责人收集来自各方需要、期望和诉求，明确工作项、评定优先级，整理出 Backlog 待办事项列表，常见的条目信息表达形式为用户故事。在冲刺计划会议上，Scrum 团队从产品待办列表中挑选其中事项组成 Sprint Backlog。
产品负责人对需求任务设置优先级，结合自身情况自定义需求状态，利用「子任务」进行细化和拆解，设置任务归属于不同的资源池，形成完整的故事结构。
在迭代开始前，我们需要有一个迭代计划会议。在会议中安排迭代中要做的工作以及确定迭代目标。在迭代计划会上，产品负责人需要告诉团队迭代待办列表中条目实现的优先级顺序。团队承诺在迭代中他们能够完成多少个条目。在迭代的过程中，任何人不能单方面擅自变更冲刺内容。最终的计划是由整个 Scrum 团队协作完成的。
在每个迭代/版本开始前，交付团队和需求方就应当在计划会议上针对下一个迭代/版本要交付的范围进行讨论，交付团队就讨论结果，做出 在迭代结束时一定会交付约定范围的需求的承诺。
迭代目标明确后，即将进入迭代冲刺。一般迭代周期为1至4周左右。在整个迭代过程中，需要由 Scrum Master 确保团队在无外界干扰的情况下全力以赴的冲刺。在冲刺的过程中，建议采用可视化管理方式将迭代过程和工作必须对执行工作的人员和接受工作的人员都是可见的。
迭代开始后，团队在每日站立会议（Daily Scrum Meeting）中对每天工作进行迭代跟踪。各成员快速汇报昨天任务进度、是否需要修改计划、遇到的困难等，保证 Scrum Master 和团队成员可以快速处理障碍，集中精力进行目标冲刺。同时建议站会结束后，将比较有价值的信息同步到 Wiki 中。
除了应用可视化看板、每日站会可以监控项目进度和风险以外，还有一个特别好用的实践，即燃尽图。
燃尽图以图形化方式展现了剩余工作量与时间的关系。要求团队每日更新工作进度，养成良好的更新习惯。从图中可以了解团队计划，把握团队进展以及知晓工作步调是否一致。同时可以及时发现问题并做出改进。
通过甘特图能随时查看迭代的具体进度以及每个项目成员的任务分工情况，做到分配合理。
迭代冲刺的结果是潜在的可交付的产品增量，那么如何来评估冲刺目标完成的结果呢？接下来要进行另外一个事件，即迭代评审会议。
迭代评审的目的是检视迭代冲刺的成果并确定未来的适应性。团队向关键利益相关者展示他们的工作结果，并讨论产品目标的进展情况。在迭代评审期间，团队和利益相关者将评审在这次迭代冲刺中完成了什么，以及环境发生了什么变化。基于这些信息，与会者可以就下一步的工作进行协作。PBI也可能会进行调整以适应新的机会。这里需要注意，迭代评审是一个工作会议，团队应避免将其仅限于展示。
最后一个环节为回顾改善会。迭代回顾会议的目的是规划提高质量和效能的方法。应当对整个迭代的过程进行回顾，检视最近一个迭代冲刺中有关个体、交互、过程、工具和他们的 DoD 的完成情况如何及遇到哪些问题，这些问题是如何解决或未解决的。团队识别出最有用的改变以提高其效能。最有影响力的改进将尽快得到执行。甚至可以将它们添加到下一个迭代冲刺的迭代待办列表中。如果需要，可将重要的信息更新到 Wiki 中，让团队成员时时可见。
最后总结一下，敏捷开发只是一种管理方式，不会告诉我们具体每个项目应该怎么做，选择一款趁手的工具能帮助更好的管理实践，达到事半功倍的效果。
工欲善其事必先利其器， Gitee 企业版不仅能为需求管理、迭代规划、进度跟踪等经典 Scrum 环节提供工具支撑，还能很好的帮助企业有序管理研发全流程，云端/本地均可灵活部署，已为 18 万家企业提供服务。
如想要了解更多敏捷管理方法，点击后面的链接或阅读原文，即可免费申请专属您的行业解决方案：https://gitee.cn/contact-us.html
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。