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