Choerodon的敏捷进阶之路

Choerodon认为软件交付过程的本质是用户价值的实现，而用户价值的实现是通过用户价值流动来体现的，Choerodon提供了一套工具来帮助用户通过敏捷的方式来管理用户价值的流动，使整个软件开发流程管化规范化。

关于软件开发，我们可以找到很多前人的经验，包括已经存在的方法论和工具。这两者很难说哪个方法论正确，或是哪个工具是最好用。其实开发是“任性的”，它没有特定的规律，整个开发过程是否高效，除了【团队的实力】这个决定因素以外，还取决于整个开发的流程是否清晰，通常高效总是伴随着清晰而来。

敏捷管理是以用户需求演变为中心，通过迭代方式来进行的软件开发。Choerodon敏捷管理的核心是需求，计划和执行。即通过故事地图、用户故事来管理用户故事和发布计划，通过迭代来管理冲刺，最后通过看板来可视化冲刺的执行。

故事地图

故事地图已经成为敏捷管理在需求规划中的一个重要的方法。Choerodon的故事地图可以将你的用户故事（user stories）像地图一样展现出来，而不是传统的简单列表形式。故事地图之所以重要是因为：

让你更容易看清整个项目的规划，所有的product backlog
为新功能筛选（grooming）和划定优先级提供了更好的工具，帮助你做出决策
便于使用头脑风暴或其他协作方式来产生用户故事
帮助你更好的进行迭代开发，同时确保早期的发布可以验证整体架构和解决方案
对于传统的项目计划，如：传统产品需求文档（PRD）提供了一个更好的替代工具
有助于激发讨论和管理项目范围
允许你从多个维度进行项目规划，并确保不同的想法都可以得到采纳

猪齿鱼中的故事地图

猪齿鱼中的用户故事地图也是基于敏捷管理的理念设计的，但是整合了版本和史诗两个维度对需求进行梳理，对故事进行编排，编排好的用户故事列表指引产品管理者和团队成员开展后续的迭代工作，印证了“地图”这一概念的作用。

用户故事地图中主要包含故事地图主界面和工具栏：

主界面：主要是故事地图的显示区域，图中紫色区域表示史诗，绿色区域表示故事，在主体的底部可以鼠标定位不同的区域来显示具体位置的故事地图。
工具栏：主要包含故事地图界面中涉及的主要操作按钮，比如可以创建新的史诗，查看当前需求池中仍然存在的问题，全屏显示故事地图，选择查看故事地图的泳道模式。

编排用户故事

如何编排用户故事是用户故事地图最核心的内容。在进行用户故事编排之前，需要产品管理者带领团队成员，基于划分好的史诗和规划好的产品版本，按照用户故事的优先级进行排序，然后再在用户故事地图中进行编排。

故事地图中用户故事的来源方式：

从需求池引入
直接在用户故事主界面的泳道或者版本下创建问题

什么是需求池：需求池，顾名思义，是需求的集合，但是不是所有的需求都会进入到需求池，需求池中只包含未被分配到史诗或者版本中的故事，不包含其他类型的需求。

1.您可以通过点击需求池按钮，通过搜索帮助，选择合适的故事，拖拽到故事地图中，需求池中同样支持通过拖拽调整顺序：

2.您可以在当前史诗或者版本中直接点击创建问题，编辑问题的描述、优先级、状态、经办人等信息，其中在版本泳道下创建的故事，系统会自动对应版本：

关于更多用户故事的操作，请移步什么是用户故事

3.从需求池引入或者新建问题之后，您可以通过拖拽的方式对用户故事地图中已经编排的故事进行调整，比如调整故事的史诗，重新规划故事的版本，如下图：

在用户故事地图中拖拽的方式支持如下几种：

相同史诗下不同版本故事之间相互拖拽；
不同史诗下，无版本、相同版本或者不同版本故事之间相互拖拽。
版本和未计划部分之间相互拖拽。

高版本的故事可以直接拖拽到低版本上，但是低版本的故事不可以直接拖拽到高版本上，平台会自动先将低版本到故事放置在未计划部分中，只有在重新规划故事版本之后，平台可以自动将故事放置在高版本迭代中。

迭代

用迭代来管理冲刺，每一个迭代对应一次冲刺，也可以简单理解为每一次冲刺就是一个迭代周期。在固定的时间内，要完成需求分析、设计、实现、测试等一系列活动，在迭代周期完成的时候提供一个可工作的产品(Release/Report)。每一次迭代完成的可能是一个或几个完整的用户故事，也可能是一个用户故事（user story）中的若干用户任务（user tasks）。

敏捷方法很重视稳定的迭代节奏，Simon Baker描述说："就像心脏有规律地跳动来保持身体运行，固定的迭代长度提供了一个恒量，有助于建立开发和交付的节奏。根据我的经验，节奏是帮助取得不变的步幅的重要因素"（2004）。对于敏捷开发的团队而言，稳定的迭代节奏可以让产品保持更稳定的交付。找到适合自身的迭代后期，我们可以从以下6各方面考虑：

整个项目周期长度（完成计划的商业需求所需时间），较短的迭代周期将会有以下一些优点和缺点:
- 更频繁的向客户展示/交付可用的软件，更频繁的取得反馈并改进，一般大的项目最好有3次或以上获取反馈、修正的机会，错误能被尽快发现从而不会酿成大错
- 迭代周期缩短，团队没有能力保证作出的每一个决定都正确，很多开销都必须花在试错上；Scrum 团队的抗风险能力弱于瀑布模型团队，因为一个人的离职或病假都可能对单一功能的进度造成影响
不确定性，客户需求的不确定，团队的工作效率，或者技术难度存在不确定性，总而言之，不确定性越多，迭代周期越短
获得反馈的难易程度
迭代周期内优先级是否被改变，也是选择迭代长度时需要考虑的因素
迭代的系统开销，每次迭代的成本（时间），在测试过程中我们要花费的时间
团队成员的压力，选择一个合适的迭代周期长度，让团队成员在整个迭代过程中感受到的压力尽可能平均

根据每个团队的实际情况，一般建议2~4周。在我们的实践中，通常以1-2周一次迭代的频率，保持相对稳定的开发和交付的节奏。

Choerodon冲刺样例

清晰展现当前迭代的任务及经办人等信息；
可以根据优先级和状态进行评估，对当前迭代进程进程进行整体把控。

看板

看板方法是用于高效管理软件开发流程的新技术。看板方法源自丰田的“及时生产”（JIT=just-in-time）系统。尽管生产软件是一项创造性活动，与批量生产汽车有所不同，但是生产线管理背后所蕴含的原理仍然适用。

一个软件开发的流程可以看作是一段自来水管道，特性需求从一端进入，经过改进的软件从另一端涌现出来。

在管道内部，存在着各种各样的工序，有的是非正式的临时工序，有的是非常正式的阶段性流程。在本文中，我们假设一个简单的阶段性流程：(1)分析需求，(2)开发代码，(3)测试软件运行正常。

Choerodon的看板是Choerodon敏捷管理中执行部分，它的核心作用是可视化整个迭代的计划执行，并且暴露开发执行过程中的短板或者瓶颈。我们都知道在软件开发过程中，短板或者瓶颈会直接的影响整个开发进程。

例如，如果测试人员每周只能测试5个特性，而开发人员和分析人员每周能够生产10个特性，整个管道的吞吐量就只有每周5个特性，因为测试人员扮演了瓶颈角色。如果分析人员和开发人员不知道测试人员是瓶颈，那么测试人员的待办工作就会越堆积越多。

影响就是前置时间增加。并且，就如同库存一样，位于管道中的工作会套牢投入的资金、产生与市场的距离、以及随着时间逐渐失去价值。

最终，影响到质量。为了能够跟上进度，测试人员开始抄近路。最终bug被发布到产品中，导致给用户带来问题，从而影响未来的管道产能。

另一方面，如果我们知道哪里有瓶颈，我们就能够重新部署资源来解除它。例如，分析人员可以帮忙测试，开发人员开始进行自动化测试。但是，我们怎样才能知道在已知流程中哪里是瓶颈呢？而当瓶颈移动后会发生什么呢？

看板方法可以动态显示瓶颈

看板方法难以想象的简单，但却难以想象的强大。最简单的形式的看板系统包括了一个挂在墙上的大白板，上面有许多卡片或即时贴，这些即时贴按列来放置，每列上方有一个数字。

你之所以能找到这些瓶颈，是因为限制了在制品（work-in-progress, WIP）的数量会显示出瓶颈。
卡片代表了工作项，列代表了开发工序，卡片会从第一步工序流动到最后一步。每一列顶部的数字用来限制每一列最多允许放置卡片的数量。

看板白板的限制大相径庭于其他任何可视化故事板。在流程中的每一步限制在制品（WIP）数量，可以预防生产过剩并动态显现出瓶颈，以便于你可以在达到不可收拾的程度之前找到它们。

Choerodon的看板

注意，我们已经将一些列分割成了两列，这是为了用来说明正在进行中的项与哪些已经完成并准备好被下游工序拉走的项。你也可以用一些不同的方式来布局白板。这里用的是比较简单的方式。列顶部的限制包含了“doing”（进行中）和“done”（完成）两列。

敏捷会议

敏捷管理过程中，看板的使用和敏捷会议流程往往是相辅相成的，常见的主要有以下四种会议

1. 计划会（一）

参与人员：Product Owner、Scrum Master、团队成员，也可以邀请业务人员一起参加
会议时长：1-4小时

根据确定好的故事地图和用户故事，我们通过计划会议，确定迭代的目标、团队成员、形成本次迭代的Sprint Backlog，同时明确评审会、回顾会时间。

确定Sprint Backlog确定工作量（工作时间）。

2. 计划会（二）

参与人员：Product Owner、Scrum Master、团队成员，其他人员选择性参加
会议时长：1-4小时
- 团队成员共同拆解细化sprint backlog，拆解为若干tasks
- 共同进行工作量评估，可以按照天或小时来评估
- 团队成员自主选择任务，共同确定DoD完成标准，团队内部达成一致

如果单个迭代内安排的Product Backlog安排的比较多的话，一般迭代计划会议需要开一个整天，虽然时间有点长，但这个会议会确认整个迭代的详细计划和安排，使开发流程变清晰。

3. 每日站会

团队每天进行沟通的内部短会，一般只有10-15分钟，团队成员通常会在会议上讲述昨天的工作，今天计划做了什么以及遇到的问题，这些问题由专人记录，但不在站会上讨论。站会之后找相关的人讨论和解决。

4. 敏捷迭代评审会议

参与人员：产品经理、Product Owner、Scrum Master、团队所有成员
会议时长：1-4小时，视演示内容而定

在冲刺结束前给产品负责人演示并接受反馈和建议，提出新的产品Backlog，主要是检验成果，看是否完成本次迭代的目标，可以邀请用户参与测试流程，并征询客户的意见和想法。

由Scrum Master来推进会议进程，Product Owner进行会议记录，这些意见和反馈维护产品 backlog，一般在迭代结束前做一次。

5. 敏捷迭代回顾会议

参与人员：Scrum Master，Product Owner，团队成员
会议时长：1-2小时

每个迭代结束后，关于团队自身如何做出改进如何优化产品的会议，团队成员自由讲述关于这次冲刺需要保持的做法，改进的点以及持续跟踪计划。找出本次冲刺中做的好的方面继续坚持，对于做得不好或者可以更好的方面持续改进。并选择出下一个迭代我们要完成的sprint backlog。

Scrum Master或者Product Owner，对于讨论内容整理成会议记录，并发送给整个团队和有关同事。

这四个会议会伴随着每一次冲刺，每一个团队在每个冲刺的执行过程当中不断学习发现和总结经验，找到最适合自身的方法，使团队真正的敏捷起来。