Choerodon猪齿鱼团队敏捷项目管理实践应用

随着Choerodon猪齿鱼的不断迭代更新，它已经被愈来愈多的用户开始在项目管理和开发中使用，成为了开发团队的一部分。

这个过程当中，有不少用户向团队提出一些关于敏捷管理上的问题，或者想了解猪齿鱼敏捷团队是怎么来进行项目管理的。

今天就来聊一聊这方面，如下内容请使用敏捷管理的项目经理或产品经理务必仔细阅读。

本文将以敏捷管理这个子产品团队为例，由敏捷管理的产品负责人亲自讲述，但愿能给你们提供一些参考和帮助，从而改善团队协做，提高团队交付价值和开发效率。

团队组成

猪齿鱼旨在帮助团队进行敏捷化的应用交付和自动化的运营管理，由敏捷、测试、CI/CD、开发流水线、知识管理等多个子产品组成，除了各个子产品团队团队还有架构组这样的基础服务团队。每一个团队根据开发工做量由6-10人构成。

敏捷管理团队从组建以来一直保持8-10人的规模，目前有6名开发人员（2前端，4后端）、1名产品负责人（PO）、1名UI设计师，全部人都全职投入在这个项目中，基本上不会有跨团队的状况发生。

开发节奏

整个猪齿鱼产品的全部团队都保持在同一个开发节奏上，2周一个迭代，2个迭代加上1周的持续改进，这样5周一个版本的速率稳定向前更新。

有人会问：为何是2周而不是1周一个迭代呢？通过团队长期的验证，2周的时间能够开发一些较为复杂的需求，而且还能完成测试验收。

固然，没有准确的标准说1周好仍是2周好，这个能够经过团队的磨合，不断进行调整。

执行

团队组建好了，开发节奏也达成了一致。那么每一个迭代都有什么工做要作？什么先作什么后作？谁来作？这些问题，敏捷管理子产品团队是这样来进行的：

新迭代开始前

以前的文章中，提到在SCRUM开发过程当中涉及了不少会议，在一个迭代真正开始开发前，有一个重要的会议——迭代计划会，来讨论说明下个迭代的开发内容。

敏捷管理团队是每一个迭代的第一天上午，召集团队全员，找一个相对安静的地方，你们坐在一块儿花费2-3个小时的时间进行计划会议。

会议上你们会打开下个迭代整理的待办事项，结合以前确认的UI界面，由PO给开发团队描述这些用户故事。过程当中根据PO的功能描述，团队成员提出本身的疑问，在相互的反馈沟通中达成共识。最后给每一个用户故事指派一个主要负责人，并对这个故事进行估算，将先后端的工做量进行统计，得出一个故事点。这个故事就结束了，进入下一个故事的讨论。

图为小组计划会现场

有可能大家会问，计划好的用户故事必定要在这个迭代完成吗？若是作不完怎么办呢？大家会有这样的状况吗？

固然有，敏捷小组是这样处理的：

你们把全部故事讨论完后，评估发现须要100个故事点（半天=1个点），超过了以往的迭代速率（80个故事点）。此时先把全部的问题按优先级排列，由PO把当前优先级最低的1个故事或几个故事（故事点加起来大约在10个左右）从未开启的迭代列表中移出。如今团队计划的故事中还有10个故事点是大于迭代速率的，这时PO可能会和开发团队商量：是否能尝试在这个迭代中完成90个故事点，若是达成一致，这时候迭代速率就从80个变为90个了。

固然，还有一种保守的作法：继续减小排列靠后的故事。不过，你们得遵循一个原则，减小掉的这个故事得是较为独立的，且与该迭代中其余的故事没有依赖关系，或者关系不大。

故事评估完后，将在每一个故事的经办人处指定主要开发责任人。会后，由负责人带领参与这个故事的开发人员一同进行故事的拆分，并将拆分的任务以子任务问题类型建立在对应的故事下。

随后开启这个冲刺，正式进入该迭代的开发阶段。

▷ 系统工具：敏捷管理待办事项模块、sketch（UI原型设计） ▷ 物理工具：大显示屏（讨论时投放）

迭代中

团队在开发阶段中时，每一个人都按以前领取的任务的优先级进行开发工做。期间，对于功能不肯定的地方须要及时与PO沟通，甚至直接与提出需求的用户沟通。

SCRUM流程中还有一个你们都很熟悉的会议——每日站会。在开发阶段，天天早上敏捷管理团队都会举行10-15分钟的站会，会上只抛出遇到的问题，不对复杂的问题给出结论，会后再由开发人员与PO一同讨论做出决定。

▷ 系统工具：猪齿鱼敏捷管理活跃冲刺模块

图为每日站会

那么迭代中，开发人员进行代码的编写，其余的成员干什么呢？

▌工做1：整理下个迭代的内容

PO将下个迭代须要进行的需求进行拆分，以用户故事的方式进行描述，建立在backlog中。这时，PO与UI会就这些故事开始讨论，PO描述故事所要达成的功能，UI根据功能描述尽快出具高保真原型图。（在产品初期的迭代，PO也出具简单的原型图，用户确认后，再由UI出具高保真原型图。随着迭代的持续演进，逐渐弱化了PO出图这一环节，更多的关注在沟通、确认和产品体验上。）

在这个过程当中，有一些不肯定的问题及时与该功能模块较为熟悉的开发人员进行简单沟通，如可执行性、是否存在前置条件等等，这些问题不会花费开发人员太多的时间，他们的重点仍是在当前迭代的任务中。肯定了基本的功能设计，UI就能够进行出图工做。

UI出图

UI设计完成后，首先与PO进行沟通调整，再邀请猪齿鱼产品经理或者用户参与最后方案的确认。会后PO与UI一同将反馈的修改意见进行优化调整，而后将这些原型图与相关的故事关联，以便后续开发人员有针对性的查看，另外一方面也是一种存档。

故事的详细描述和原型图

▌工做2：编写测试用例

一旦功能确认后，测试人员或者PO须要开始编写这个迭代各个功能点的测试用例。好比这个迭代的功能均属于1.0版本发布的，PO能够在猪齿鱼测试管理找到0.9版本的用例，将其克隆一份到1.0版本，再针对新增的功能在1.0下建立新的用例，对于变动的功能找到以前的用例，在此基础上进行修改。最后，继续测试计划，指派测试人员。

▷ 系统工具：猪齿鱼测试管理

每一个版本的测试用例管理

▌工做3：按故事进行测试

在团队本身的活跃冲刺看板中，有一列“验证测试”。团队成员达成共识：当卡片流动到这一列时，默认开发已经完成而且测试经过，这时PO和UI能够针对故事进行多方面测试，有功能的、样式的。一旦发现问题，若与开发人员肯定是bug，则将相关的子任务打回给开发人员，而后建立缺陷，随即关联该故事或子任务。

因此开发人员在迭代中除了功能开发，还要进行bug修复。只有当bug验证经过后，这个故事才能算开发完成，并拖动到看板的已完成列。

活跃冲刺待测试问题

团队全部成员在迭代后期协做完成的工做内容——针对测试用例进行全量测试

以前提到过，猪齿鱼产品的节奏是2周一个迭代，2个迭代一个版本。一般在第一个迭代，团队的开发任务会计划到第2周的周四，这个时候只是PO作增量测试，预留1天修改bug。而第二个迭代每每只会计划到第2周的周三，由于在剩下的2天时间，是全员一块儿对整个敏捷管理作全量测试和bug修复。

也许大家会问，开发人员也参与测试吗？答案是：是的，而且是交叉测试。

猪齿鱼测试管理，支持在每一个用例的步骤建立bug，并能够直接关联到当前冲刺，显示在看板上，这时相关的开发人员会停下手头的测试工做优先修复bug。修复完后，各自负责对本身提出的bug进行回归测试，随后作上线前的准备。

在实际的开发工做中，老是不会那么理想。好比，距离上线发布还有2天，仍然有开发任务没有完成，且不是几个小时就能够完成的。这时，PO须要作的决定是果断放弃尚未作完的任务，投入测试中。而不是推迟发布时间，更不是缩短测试的时间，甚至不作测试去开发功能。由于你们一直遵循着敏捷的思想，交付的产品功能必定是有价值的，是可用的。

在敏捷管理团队的平常项目管理中，还有不少其余的环节，好比评审会、回顾会、技术研讨会、技术分享、论坛需求评估以及回复、与其余团队沟通讨论等等，后续再跟你们分享。

猪齿鱼敏捷小组可能不是敏捷项目管理的最佳实践，每一个环节也不可能适用于一个团队的整个项目管理生命周期，更不可能适合每一个团队。但你们须要勇敢去尝试，通过一段时间的磨合，经过不断的调整，相信总能找到适合于本身团队的敏捷管理方法。

但愿那些想尝试敏捷转型、还在敏捷中摸索的团队能得到一些参考。更但愿猪齿鱼敏捷管理能帮助你们改善团队，提高效率，交付更多的价值。

关于Choerodon猪齿鱼

Choerodon猪齿鱼是一个开源企业服务平台，基于Kubernetes的容器编排和管理能力，整合DevOps工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的开源平台，同时提供IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。

你们也能够经过如下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：choerodon.io
• 论坛：forum.choerodon.io
• Github：github.com/choerodon
• 微信公众号：Choerodon猪齿鱼
• 微博：Choerodon猪齿鱼