随着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 猪齿鱼作为开源多云应用敏捷全链路技术平台，是基于开源技术Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。
更加详细的内容，请参阅Release Notes和官网。
大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：
欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。
本篇文章出自Choerodon猪齿鱼社区朱琳珏。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。