今天，如果再花半年时间，去研发一个产品，当这个产品面世时，很有可能已经不能完美满足市场需求。
今天，我们需要更加敏捷，以更敏捷的状态，去应对外部变化。如果你对敏捷研发已经了如指掌，那么 Teambition 敏捷研发专业模板，将是帮助你更好的实践敏捷研发的好工具；如果你正在转型敏捷研发，那么承载敏捷研发方法论的 Teambition 敏捷研发专业模板将能够帮助你快速入门敏捷研发，开始实践；
今天我们首个专业模板——敏捷研发专业模板启动了内测，让我来带大家一起看下如何来实践 Scrum 敏捷研发。
【模拟任务场景】假设我们现在要研发一款笔记类移动端 APP，我们已经组建了我们的团队——1个产品负责人，2位设计师，2位 IOS 工程师，2位安卓工程师，1位后端工程师，1位测试工程师，并且由我们的测试工程师担任 Scrum Master。
首先第一件事情肯定是创建一个项目，并选择专业模板中的敏捷研发专业模板。
项目创建完成后，将所有的9名成员加入到项目中。Teambition 敏捷研发模板主要由5个核心应用组成：需求、缺陷、迭代、日程、统计。我们通过具体的案例来看看怎么利用这5个应用实践敏捷研发。
建立产品订单，并制定冲刺规划
首先产品负责人要制定产品规划，建立产品订单，团队才能基于此实现最终的商业价值。
「需求」应用就是用来维护 Scrum 中的产品订单，以及规划接下来几个冲刺（迭代）的订单。需求规划由产品负责人核心维护，当然需要整个团队的配合。规划的长短因团队而异，一般建议2-3冲刺的规划。越近的冲刺订单越完善，当前冲刺的订单要求每个用户故事都经过整个团队的评估，并定义好 Story Point（在冲刺计划会议完成这件事情），因为这个是开启一个冲刺的基本前提。下图中展示了2个冲刺的规划，Sprint No.1 是首个冲刺，Sprint No.2 是第二个冲刺，还有一些没有规划的用户故事维护在需求池。
启动首个迭代
团队已经到位，需求规划也已做好，是时候开始开工了，那怎么启动一个迭代呢？
这个时候需要 Scrum Master 组织这个至关重要的会议——冲刺计划会议。Scrum Master 可以实现通过「日程」应用创建好冲刺计划会议，并提醒大家。要说这个会议是所有敏捷会议中最重要的一点也不为过，因为它是接下来几周工作的基础，一个好的计划会议，基本上整个迭代算是成功了一半。通常这个会议耗时都会比较长，因为整个团队需要将之前初步规划的产品定义进行细化，拆解成可以执行的任务，并评估每个任务的工作量（Story Point）。如果整体工作量超出了团队的产能，需要适当的将一些需求放到下个迭代；如果低于产能，需要将后续的需求前置。所以产品负责人需要确保尽可能多的需求处于准备好的状态。
当所有的执行任务都定义清楚， Scrum Master 就点击「需求」应用中的「开始迭代」按钮，通过提示中设定好冲刺的开始和结束时间，所有规划好的需求和缺陷会自动进入到「迭代」应用中。「迭代」应用会通过看板的形式直观展示当前迭代内的每一个需求和缺陷的进展情况，包括子任务。右上角会提示离冲刺结束有多少天。
确保迭代按规划进行
迭代过程可以说是最耗时、最复杂的环节，所以「迭代」应用会是所有团队成员关注最多的面板。如何确保迭代按规划进行，是 Scrum Master 最关心的问题。
除了最开始的计划会议，尽可能多的把风险从一开始就排除，很多问题需要在执行过程中去发现和解决。每日站会就起到这样的作用。Scrum Master 利用「日程」应用可以创建每天重复的日程来提醒团队成员参与。团队成员每天早上需要描述昨天做的事情，今天要做的事情，以及遇到的问题。当有问题出现，相关的人需要一起协力解决。
当然前面提到的「燃尽图」也是一个关键的工具，用来判断离冲刺目标的距离。「统计」应用中「迭代报告」分类下的「迭代进展走势」描绘的就是当前冲刺的进展。柱状图描述了每天完成的任务数，折线图描述了当天剩余的 Story Point 数，通过和理想剩余 Story Point 对比可以了解研发状态是不是理想。下面描述的场景可能稍具风险，但在可控范围内。走势图下面有实际完成的任务信息，可以帮助 Scrum Master进一步了解每天有哪些任务被完成。
完成首个迭代
当迭代应用中右上角的数字变为0天，意味着冲刺结束，不管任务是不是都完成。
在真正宣告冲刺结束前，需要确保所有的研发成果经过产品负责人的评估，是不是达到了最初描绘的产品目标。当然研发过程中也可以经常向产品负责人或者利益相关者展示研发成功，避免出现偏差。所有研发成果完成评审后，Scrum Master 就可以点击右上角的「完成迭代」按钮，标示整个冲刺结束。
最后整个团队还需要进行一次回顾会议，回顾这次迭代有哪些做的好，哪些做的不好，并列出下次的可执行任务，便于改进整个团队的效能。
启动新的迭代
接下来做什么呢？当然是火力全开，迎接新的冲刺。Scrum 讲究的就是短频快的冲刺，每个冲刺都是环环相接，并验证最核心的概念。
通常一个迭代都会产出一个可上线的应用版本，上线的版本在暴露到真实用户的时候或多或少会出现一些问题，称之为 bug 或者缺陷。所以后续的迭代中，除了需求，我们需要将另一个任务类型考虑进来——缺陷。
测试人员会在「缺陷」应用中将发现的缺陷在这里管理，并排出优先级，作为冲刺计划会议任务来源之一。当然紧急度高的缺陷会第一时间修复，优先级不高的会安排到接下来迭代修复。缺陷应用用了表格视图，因为可以非常直观的展示出缺陷的分类、严重程度、出现的平台等基本信息；同时可以快速设置执行者，确定缺陷修复版本和发布计划。测试工程师会非常关心缺陷相关的统计，包括缺陷的年龄、缺陷变化趋势、缺陷按照各种条件的分布情况，这一次我们也提供了针对缺陷丰富的统计。将缺陷纳入到新的冲刺计划会议中进行分析评估，便可以制定出新的迭代的可执行任务，并启动新的迭代。
进一步了解你的团队
想要很好的实践敏捷其实并没有上面描述的那么轻松，每个团队都会遇到不一样的问题，实践敏捷本身就是一个迭代的过程，每一次回顾都会发现一些问题，并在新的迭代中改进。不管如何，想要实践好敏捷，最核心的是要更好的了解你的团队，知道当前的产能如何，怎么去提升产能。那怎么了解呢？「统计」应用给大家提供了两个很好的报告，一个是「迭代报告」，一个是「团队速率报告」。
迭代报告可以帮你记录每个迭代的一些核心数据，分别从任务维度和 Story Point 维度去统计，包括计划要完成的量、实际完成的量、需求发生变更的量、缺陷修复的量。通过这些数据可以任务的完成度和迭代的是不是稳定。
团队速率报告是一个很有意思的图，柱状图部分描绘了整个团队每个冲刺完成的 Story Point，折线图描述了到当前为止累计平均完成的 Story Points。通过这两个数据可以判断每个阶段团队的产出是不是稳定，或者是不是逐渐提升，以及可以对整个团队的产能有比较清晰的认知。方法论到这里啦！当然，Teambition 会持续输出敏捷研发相关知识，助力你和你的团队，更好地转型敏捷。
作者：姜翔，Teambition Product VP
点击这里，了解更多关于 Teambition 的故事