十四五规划纲要中指出，要加快数字化发展、建设数字中国，以数字化转型整体驱动生产方式、生活方式和治理方式变革。新形势下，数字化建设被提到了前所未有的高度，是实现创新驱动发展的重要抓手。然而，数字化建设过程中，企业常面临业务变化快、协作流程繁、能力沉淀难等诸多问题，只有提前整体布局规划，以科学方法论和专业管理工具对数字化战略进行落地，才能更好地帮助企业实现数字化转型。

  猪齿鱼效能管理平台，由上海汉得信息技术股份有限公司（以下简称上海汉得）自主研发推出，通过提供体系化方法论和协作、测试、DevOps及容器工具，帮助企业拉通需求、设计、开发、部署、测试和运营流程，一站式提高管理效率和质量，助力团队效能更快更强更稳定，帮助企业推动数智化转型升级。

  本周四，由上海汉得和上海熙上网络科技有限公司共同推出的“企业数字化建设路径与效能提升实践分享”线上直播，将邀请猪齿鱼资深业务架构师程沛女士分享企业数字化建设整体框架设计、方法论、效能提升利器与应用实践，为企业数字化建设提供思考方向。欢迎扫码报名。

直播介绍​

直播时间： 2021年12月16日（周四） 19:30-21:00

直播地址： 腾讯会议 ID：583-107-754 或直接点击：https://meeting.tencent.com/dw/QhDhkbnicp0E

主讲人： 程沛 猪齿鱼资深业务架构师

建议参会人员： 各公司技术总监、研发主管、项目总监、实施顾问、信息中心负责人等

您将收获：

• 企业数字化建设的方法论和五大武器
• 数字化效能提升的要诀

数字化大潮正席卷全球，我们诚邀您和您的团队参加本次线上直播，共同探讨企业数字化建设与效能提升话题！

Atlassian 宣布将在2024年2月2日完全停止销售支持服务器产品线，全面发展云端业务，终止销售的产品有：Jira Software Server、Jira Core Server、Jira Service Desk Service等，这意味着 Jira 服务器产品将不再为使用者提供支持和错误的修复。对于中国的 Jira 服务器使用者来说，如果选择上云，服务器在国外，将面临访问速度变慢及数据安全的风险。 ​

最终的选择只有两种：

• 提早续订Server版本，继续使用至2024年，但会面临无支持的状态；
• 提前选择替换工具。

Choerodon猪齿鱼 与 JIRA​

Choerodon猪齿鱼 与 Jira 在很多方面很相似，都可以作为项目与事务跟踪的工具，广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域，同样适用于中小型团队和大型企业。 Jira 主要采用Scrum或看板模型进行项目管理，Choerodon猪齿鱼不仅包含Scrum、Kanban的敏捷框架，还覆盖故事地图、SAFe等敏捷框架进行敏捷协作管理，并支持持续交付、容器环境、微服务、DevOps、知识库、多组织等能力来帮助研发组织完成软件端到端的生命周期管理。

除了完整的研发管理闭环，Choerodon猪齿鱼还提供敏捷协作、DevOps全链路、自动化测试三款适用于项目管理、开发管理、测试管理的解决方案，提供可插拔的方式，满足不同研发团队的项目管理需求。

• 敏捷协作：深度贯彻敏捷研发理念，提供对需求管理、敏捷迭代、知识库各个维度的协同管理，促进团队成员沟通交流，降低项目管理成本，提高沟通协作效率。 ​
• DevOps全链路：结合Gitlab、SonarQube进行代码管理，提供自动化可编排的持续交付流水线，规范开发流程，并借助可视化、自动化的部署流水线实现多环境的容器化部署，打通持续集成与持续部署，并通过集成Kubernetes实现对环境资源的统一管理与监控，提高团队持续交付效率。 ​
• 自动化测试：贯穿项目管理、敏捷开发等DevOps全流程，提供敏捷化的持续测试工具，包括功能测试、API测试、性能测试、流量重放、UI测试，提高团队测试效率，保证质量。

对比分析​

团队管理​

项目管理​

规模化敏捷​

自动化测试​

DevOps管理​

部署方式及客户服务​

总结​

Jira 作为最早进入中国市场的项目管理工具，确实为加速项目效率提供了卓越贡献，目前国内的效能软件层出不穷，选择更适合企业的软件是管理者们最关注的事情。从对比分析我们可以看出 Choerodon猪齿鱼完整的端到端全链路管理，不仅覆盖了Jira 的事务与项目跟踪功能，还从组织框架、自动化测试等方面扩展多团队和多场景的项目管理。 虽然Jira 也可以通过第三方插件来扩展功能，但除了较高的额外费用外，还需要对工具进行学习和维护。

关于Choerodon猪齿鱼​

Choerodon猪齿鱼是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。 ​

更多内容​

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献： ​

• 官网：http://choerodon.io
• 论坛：https://openforum.hand-china.com/
• 操作指引：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124615&doc_code=119767
• 用户手册：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124273&doc_code=118818

Choerodon猪齿鱼官方社区用户交流群，此群可交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得，群同步更新版本更新等信息，大家可以加群讨论交流。 ​

请添加Choerodon猪齿鱼小助手微信：hand-c7n

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。 ​

​

​

​

​

​

​

​

​

​

看板的核心是将状态可视化，一张看板承载着所有卡片，一张卡片代表一个任务，同时看板会被分成几列，每一列代表一个任务可以处于的状态。

在研发项目中，各团队常常用看板管理任务的生命周期，并且不同团队的看板任务流转都是不同的。通过实践，我们收集到不同团队对看板管理的需求

• 项目经理期望知晓团队的整体工作情况，期望可以定制一套符合团队的任务流程；
• 开发团队注重每个人的任务进度及开发量，同步管理代码质量；
• 测试团队针对测试的功能提交缺陷后，缺陷的修复情况如何；
• 产品团队梳理完需求，需求各阶段的状态得到反馈；

针对各团队的需求，Choerodon猪齿鱼的看板管理引入「状态机」功能，用来制定不同的任务流转的工作流程，跟看板中的列对应，针对看板中的每种状态也定义了对应的工作流及处理问题时执行的特定操作。帮助大家专注研发流程，提升研发效率。 ​

🙌Choerodon猪齿鱼「状态机」使用场景​

下图为研发项目的通用研发流程，其中包括项目中需求各阶段的流转历程，以及对代码开发的整个周期管理。

需求管理是研发项目活动中的一个重要过程，可以说需求是产品开发的开端，贯穿着整个产品的生命周期，从一开始的需求收集、到需求设计、开发、测试、最终上线，无论哪个环节都是依赖着需求进行的。 当需求评审通过后，项目进入到开发侧。这时，开发团队需要制定明确的迭代计划，包括product backlog（产品待办，也就是评审通过的需求）的优先级、迭代目的等，随后进入到开发阶段。 开发人员确定任务后，创建对应的开发分支，开发完成后，开发人员本地自测，再合入开发环境测试主分支，安排测试人员进行开发环境测试。最后通过验收测试后，系统发布上线。

定制任务流程​

以这套流程为例，在Choerodon猪齿鱼中如何使用状态机进行任务流程配置呢？ ​

配置看板中的状态与流转​

Choerodon猪齿鱼看板管理契合项目从需求管理到开发、测试、上线的全流程配置。根据示例中的研发项目的整个流程体系，我们首先需要确认看板中有以下信息： 明确迭代的三个阶段： 设计、开发、测试 三个阶段分别对应以下状态节点： 设计： 功能设计、技术设计、设计评审、设计完成； 开发： 待开发、开发中、本地自测、开发完成； 测试： 待测试、staging测试、验收测试、已完成；

不同阶段专注的内容可以汇集到不同的看板。如下，我们可以建立设计看板、开发看板、测试看板。 设计看板与开发看板的连接依靠：设计阶段的设计完成=开发阶段的待开发； 开发看板到测试看板的连接依靠：开发阶段的完成态就是测试阶段的初始态。

当然，如果需要全局维度的查看看板，我们也可以建立全局看板。

根据制定好的看板、列和状态以及场景，配置状态的流转方向可以控制看板中卡片的流转。 以<故事>这个issue类型为例，流转流程如下：

状态的流转状态配置好后，在看板中拖动任务时，任务会根据流程流转。

​

配置​问题类型​

此外，项目上往往存在多个不同类型的需求，对不同的需求有不同的处理流程。例如：

不同的需求同样需要不同的issue类型来梳理，Choerodon猪齿鱼通过不同类型issue的流程管理能力，以帮助项目实现多样化，多情景的流程管理能力。详细配置信息，请参考用户手册「问题类型配置」。

「issue与分支联动」​

开发团队进入到开发阶段后，产生了一条代码分支的生命历程。即：确定任务后，创建对应的开发分支，开发完成后，开发人员本地自测，再合入开发环境测试主分支，安排测试人员进行开发环境测试。从这个流程提炼出了以下和issue相关的联动：

1. 开发人员本地开发分支feature合并入测试环境测试主分支master后，开发完成；
2. 开发完成通知测试人员测试；

例如：根据上诉需求配置如下

Choerodon猪齿鱼支持issue和开发分支联动起来，为团队的DevOps实践提供更好的支持。

「用户故事与开发子任务自动流转联动」​

项目迭代过程中，开发人员专注于所负责的子任务的开发，忽略的用户故事维度的管理和流转，会造成子任务已经完成，但是用户故事依旧在某个状态积压，不能及时进入测试流程。这将会导致这些用户故事没有得到充分的测试，最终会影响到产品的交付质量。Choerodon猪齿鱼的状态机功能支持父子任务进行状态联动，无需人工维护。 例如：开发子任务全部开发完成后，用户故事自动流转到开发完成状态。

「钉钉、企业微信等第三方应用Webhook推送」​

为了方便项目成员能够及时收到任务处理的通知，除邮件、站内信外，Choerodon猪齿鱼支持钉钉、企业微信等其他平台的Webhook消息推送。项目负责人可以在需要及时收到通知的状态节点启用Webhook通知，实时接收任务状态流转的消息推送。 例如：设置向【报告人、经办人】发【邮件、站内信】通知，启动Webhook通知。

了解如何添加Webhook，请参考用户手册「Webhook配置」

「不只是研发项目」​

当然，除了研发类的项目之外，在销售项目、人力资源、市场营销、运营等项目也会有与当前情景匹配的任务管理流程。这里我们拿一个销售管理项目举个栗子🌰： 不同的销售业务对应不同的销售流程，销售总监根据团队需要来规定销售流程。常见的这销售流程如下：

• 潜在商机--> 联系--> 商业接洽-->打单--> 签署合同；

状态机配置如下图：

看板管理如下图：

贯穿着产品的整个生命周期，包括项目内部及外部用户的需求收集、需求审核、分析、拆解及开发进度的跟进。

🤗Choerodon猪齿鱼「状态机」如何使用​

更详细的操作教程，请参考用户手册：

☞如何配置问题类型

☞如何配置状态机

☞如何配置看板

☞如何配置Webhook

欢迎免费试用SaaS企业版

试用链接：https://choerodon.com.cn/register-organization/#/

关于Choerodon猪齿鱼

Choerodon猪齿鱼是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更多内容​

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：https://openforum.hand-china.com/
• 操作指引：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124615&doc_code=119767
• 用户手册：https://open.hand-china.com/document-center/doc/product/10177/10419?doc_id=124273&doc_code=118818

Choerodon猪齿鱼官方社区用户交流群，此群可交流猪齿鱼使用心得、Docker、微服务、K8S、敏捷管理等相关理论实践心得，群同步更新版本更新等信息，大家可以加群讨论交流。

请添加Choerodon猪齿鱼小助手微信：hand-c7n

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

在首个 Sprint 开始之前，需要召开一个递增的 Sprint 计划。用来计划和确定一列敏捷发布火车的时间维度，通过定量的时间递增（Sprint）来保证编码实现和我们计划任务（Mission）的持续一致。PI 将在固定的时间箱内计划出一个可量化、可实现和最终可测量验收的计划路线图。Choerodon猪齿鱼通过以下步骤进行PI过程：

• ART同步会议
• 通过项目群看板促进可视化
• 通过迭代日历提高敏捷团队可见性

ART同步会议

在 PI 计划会议之后，各种项目群事件创建了一个闭环系统，从而 “保持火车在轨道上行进”。如图所示： 

为了保持工作持续进展和透明度，就需要频繁的协作。为了评估和管理进度和依赖关系，ART通常通过各种同步会议进行协调。这其中包括:

• Scrum of Scrum（SoS）：发布火车工程师（RTE）每周（或更频繁）引导 Scrum of Scrum会议，来协调依赖，并将进展和障碍以可视化的方式呈现出来。Scrum Master或者其他人向大家同步敏捷团队实现里程碑和PI目标的进度,并管理团队间的依赖关系；
• 产品负责人(PO)同步：产品经理（PM）和产品负责人（PO）通过 “PO 同 步”会议，对 ART 的进展在多大程度上与项目群 PI 目标相一致获得可视化呈现。讨论特性开发中遇到的问题或者创造的新机会，并评估任何可能出现的范围调整。这个会议也是每周进行一次，也可以根据实际情况更加频繁的举行。

一些 ART 将 Scrum of Scrums 会议和 PO 同步会议组合成一个“ART 同步”会议。ART同步会议有助于跟踪计划的进展并解决重要问题（障碍）。

ART同步会议需要展示：

• 目标和特征的全部进展；
• 需要上报给其他团队或计划级别的风险和问题；
• 与其他团队的依存关系状；

通过ART同步会议，高级管理层和团队可以轻松了解进度，预测，依存关系和问题。这将有助于整个ART确实我们的目标是否对齐，是否存在障碍延缓按期交付。Choerodon通过项目群看板、迭代日历提供了较为全面的可视化依据。

通过项目群看板促进可视化

PI开启后，看板立即开启。项目群看板提供了流转可视化，通过特性在持续开发、持续集成、持续部署、持续交付中不断流动，最终实现价值流的交付。同时，看板有助于预测瓶颈，通过每个状态的队列长度，快速确定ART要面临的风险，并且及时消除风险。如下图所示：

通过迭代日历提高敏捷团队可见性

迭代日历完整、透明的展示了ART中各个敏捷团队的开发情况，项目群管理人员可以通过PI、团队、冲刺多个视角，再结合故事点、问题计数两种维度，多方位的展示各个团队、各个冲刺、各个工作项的进展情况。

总结

PI执行过程中，敏捷团队在源源不断的为ART提供动力，每个独立的敏捷团队在不断的进行迭代重复工作，这包括：迭代计划、每日站立会议、团队演示以及团队回顾。而ART管理人员只需要通过看板和迭代日历了解各个团队的进展，及时移除障碍。

如何在Choerodon中进行SAFe大规模敏捷实践，请参考大规模敏捷实践指南（一）：如何开启大规模敏捷之旅。 了解SAFe的术语以及对应到Choerodon上的功能，请参考大规模敏捷实践指南（二）：SAFe术语与Choerodon功能对照表。 了解什么是大规模敏捷框架SAFe以及Choerodon猪齿鱼如何聚焦SAFe框架理念进行大规模敏捷实践，请参考Choerodon大规模敏捷|大规模敏捷框架SAFe。

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更加详细的内容，请参阅Release Notes和官网。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

原文作者：Sjoerd Nijland

原文地址：https://medium.com/serious-scrum/the-sprint-planning-c24df3e09779

翻译：柴晓燕&付新圆

对于敏捷中的活动有很多，本文先从Sprint计划开始，分享一些方法、建议和注意事项，这些对理解和实践Scrum都很有帮助。

Who？

Sprint计划的参与者：整个Scrum团队。

请注意，Sprint计划是一个积极的、合作的活动。如果需要的话，大家可以随意走动查找资料或解决问题。开发团队可以召集其他人来帮忙，在会议期间能收集到更多信息。

“开发团队还可以邀请其他人参加，以提供技术或领域建议。” — Scrum指南

参与性​

并不是每位成员都会在参与活动时表现出积极主动和创造性，有些成员只有在感到自信或舒服时才会加入。

出勤率和参与度低都会降低透明度，并带来风险。Scrum Master认为每个人都参加和参与是他们的责任。

“ Scrum Master可以确保活动进行，并确保参与者了解其目的。” — Scrum指南

我认为，解释出勤和参与的价值，同时创造一个舒适、愉快、平静和尊重的环境，是Scrum Master 激励团队成员参与的最佳方法。

“给他们提供所需的环境和支持，并信任他们来完成工作。” —敏捷宣言。

有时，参与者可能会占据主导地位，并试图利用一事件来指导和影响团队的方向。这些输入可能非常有价值，但可能会妨碍其他人添加宝贵的输入，参与者应该意识到这一点。当团队成员之间发生不尊重甚至敌对时，Scrum Master应该及时介入。团队要把Scrum Master视为教练，以保护团队环境的安全。

When?

Sprint计划发生在什么时候： Sprint的开始。

这其实是一个很难回答的问题，《Scrum指南》并没有明确指出Sprint计划必须在一开始就进行。 事实上，如果准确地解释的话，在Sprint计划期间计划的工作指的是即将到来的Sprint，而不是当前的或这个Sprint。 Sprint计划不会在两者之间进行，因为Sprint在上一个Sprint结束后立即开始。请记住，Sprint充当的是事件的容器。

《Scrum指南》暗示了这一点。

“每个人都在另一个Sprint中重新组合，计划开始另一个Sprint” —《 Scrum指南》。

幸运的是，Scrum.org的Scrum词汇表更加具体：

“Sprint计划：定时活动，以开始Sprint。” — Scrum词汇表

团队在优化期间准备Sprint计划并不少见。总的来说，Sprint计划在一致的时间和地方开始。

How long ?

如果进行长度为一个月的冲刺，最多需要8个小时来进行冲刺计划 。对于周期短的冲刺， 则花费的时间更少。

团队通常会根据sprint的周期来制定迭代计划 ，一个星期的Sprint可能 需要2个小时的计划时间。请记住，这只是最大时间，没有最小时间。经验丰富的团队很可能在时限到期之前完成计划 。

好的协作与改进能促使sprint计划会议更加迅速，更加有效。就是说，时间并不能决定解决问题的效率 。

准备​

Sprint计划时我们要准备以下内容 ：

• 来自Sprint回顾会的反馈和有价值的输入内容 （可能已经加入到产品待办事项列表中）
• 完善的产品待办列表
• 在上次迭代回顾会议上确定的至少一项 优先级较高的流程改进
• 讨论Sprint的潜在目标
• “完成”的标准，即验收标准。
• 最近一次的产品增量
• 最近一次迭代开发团队的表现
• 冲刺期间开发团队的预计容量

在我的项目中，团队经历了很多次迭代 ，成员们都在呼吁推迟Sprint计划，他们要么不认为上一个Sprint已经完成，要么觉得自己准备不充分 。

那么， 上一个Sprint中 未被认 为“完成”的工作可以重新 规划 到下一个Sprint中。 请记住一个冲刺规定的时间范围结束标志着这个冲刺的结束，当然取消冲刺除外。

无论哪种情况，Sprint计划都不会推迟。如果在Sprint计划之前，上述所有内容都不是透明的，那么Sprint计划的时间范围可能允许在计划期间创造这种透明性。

Ready的解释​

一些团队使用“ Ready ”的定义。Scrum仅规定了一个定义（尽管这并不排除团队引入诸如 INVEST标准之类的其他定义）：

“可以由开发团队在一个Sprint内“完成”的产品Backlog项被认为是“准备好”的，可以在Sprint计划中进行选择。”—Scrum指南。

目的

“在Sprint计划结束时，开发团队应该能够向产品负责人和Scrum Master解释其打算如何作为自组织团队来实现Sprint目标并创建预期的增量。” — Scrum指南

并且 ：

“ 开发团队在Sprint 的第一天 计划的工作将在本次会议结束前被分解。” — Scrum指南（强调）

如果实现了此目的，就达到了Sprint计划的目的 。

为了实现此目的，Sprint计划分为两个部分：

1.此Sprint可以做什么？​

Scrum团队共同的 Sprint目标 应该达成一致。 产品负责人不指定Sprint目标，而是讨论Sprint应该实现的目标。最开始的时候团队需要透明性， 每个人对Sprint的目的的理解都需要保持一致。Sprint目标为开发团队选择实施的目标提供了一定程度的灵活性。冲刺目标可能雄心勃勃（毕竟这是一个目标），并有促进集体协作的作用。

产品负责人也将讨论产品待办事项，如果这些事项在Sprint中完成，将达到Sprint目标。

然后，开发团队将创建一个 Forecast （预测） ，这是对产品待办事项的初步选择，基于对产品的认识可以在Sprint中完成任务以达到Sprint目标。

“只有开发团队才能评估在即将到来的Sprint中可以完成的工作。” — Scrum指南

开发团队可以要求产品负责人说明并重新协商这些待办事项 。

在第一个Sprint的末尾，开发团队应该了解为什么要构建增量。

2.所选工作将如何完成？​

当协调一致时，开发团队将制定一个交付的初始计划。 这些内容就是Sprint Backlog，它将在整个Sprint中继续出现。请记住，这还包括来自 最近一次 Sprint回顾 会 的改进计划。

温馨提示：预测并非承诺。开发团队创建的预测，应有效的去实施或对有价值的更改进行实践。 虽然开发团队作为专业人员承诺尽其所能， 但质量目标不应降低， 团队也不应为了实现预测而在“完成”的定义上偷工减料。

在此活动中，开发团队可能已经自组织并承担了工作：

“开发团队在Sprint计划期间以及整个Sprint中根据需要自行组织以进行Sprint Backlog中的工作。” — Scrum指南

透明性

除了为Sprint计划准备输入之外， 团队还有很多方法来完成Sprint计划。在Sprint计划期间，团队的力量在工作中的汇报是显而易见的。

团队来决定如何最好地推动Sprint计划，是非常关键的。

“流程中最重要的是必须对负责结果的人员 可见 。” — Scrum指南

并且 ：

“产品负责人的决定在产品待办事项列表的内容和 序列中 可见 。” — Scrum指南

更重要的是：

“ Sprint待办事项是开发团队计划在Sprint期间完成的工作的 高度可见的 实时 影像 ” —《 Scrum指南》

也就是说，我要提醒大家不要仅仅依赖电子看板来实现这种透明性：

有些糟糕的设置，例如：“ 团队会不耐烦地、漫不经心地围坐在一张桌子旁，桌子上的大屏幕正显示着电子看板，团队们 紧盯 着一个人按照指示更新看板…”

S.W.O.T​

团队可以考虑的非Scrum技术是一个SWOT画布，在这个画布上，团队可以使重要因素变得透明。依赖关系会带来风险，因此可以在sprint期间跟踪它们。

当然，在Sprint过程中，也会发现或引入新的威胁，如障碍物。Sprint计划可以帮助团队为当时已知的事情做准备，也需要考虑到它未来可能遇到的未知挑战。

分歧

一致性，是我认为的任何Scrum活动的目的（即使Scrum指南中没有使用这个术语），仔细的检查能使团队在实际情况上保持一致，从而形成共同的理解。

通常，在Sprint计划期间会讨论许多主题，如果不是所有成员都在场，或者输入内容不透明，那么团队可能就会做出错误的假设，沟通不畅，从而导致团队不协调。产生了分歧将无法做出最佳决策，从而引入风险且价值无法最大化。

有时候，Scrum团队成员很难真正地在Sprint目标、预测或如何进行工作的计划上保持一致。与任何事件一样，每个人都必须遵守Scrum价值观，每个人都应该能够以尊重的方式表达自己的想法，不同的观点是学习的机会。当团队不能就如何同意或不同意达成一致时，这将在整个开发过程中造成严重的中断。

自组织团队需要学会平和的处理分歧。“不同意但承诺”是团队可以同意的潜在原则，但这可能并不适合每个团队。因此，有多种方法可以达成共识。为了快速检测是否达成共识，团队可以采用诸如 使用手势这样的方式。

请记住，仅在Sprint的第一天就计划好工作就足够了。

Scrum Master对 Sprint计划的作用

作为Scrum Master，可以试着验证团队中每个人是否理解Sprint的目的和方法，并且支持Sprint。

整个团队是否了解如何协作？信心水平是多少？他们实际上是在承诺还是在默默地服从？

从Sprint计划结束时的氛围来看，Scrum Master通常已经可以在某种程度上预测整个Sprint的期望。

请记住，这仅仅是开始。随着Sprint的进步和更多的知识，计划必须进行调整，并且团队的自我组织，实现Sprint目标或创造预期增量的能力可能会受到挑战。

另外，作为Scrum Master，提醒Scrum团队他们的改进目标很重要，在制定计划时也要考虑到这一点。

Sprint计划在其时间范围到期时结束，或者如果事件的目的实现了，则可以提前结束。

原文地址：https://www.knowledgehut.com/blog/agile/scrum-vs-safe

Scrum是基于敏捷的价值观和原则的框架，而SAFe是在企业级别实施Scrum的框架，它们都是基于敏捷价值和原则下的产物。Scrum和SAFe之间的区别是有限的，但也存在着明显的差别。简单来说，Scrum主要基于敏捷的原则和价值观，侧重于少量团队，SAFe是在企业级别的实施敏捷的。

Scrum和SAFe之间的主要差异​

让我们看一下Scrum和SAFe之间的主要区别：

Scrum是管理软件开发的敏捷方法，而SAFe是企业级敏捷的建立方法。

两者之间的主要区别取决于他们选择处理工作的方式。简而言之，Scrum基本上用于组织小型团队，而SAFe用于组织整个大型团队甚至企业。此外， SAFe填补了Scrum在各个重要方面的空缺。

Scrum在概念上听起来很简单，但是很难从核心执行。

Scrum​

Scrum是产品开发的一种迭代方法，它将项目分解为小段，然后由小型跨职能团队在定义的时间段内完成。它着重于规律的交付节奏，并且依赖于跨职能团队，一些特定的支撑角色以及一系列流程来完成项目的交付。

为了计划，组织，管理和优化流程，Scrum在很大程度上取决于三个角色：

• 产品负责人：他负责规划工作，组织团队和与公司进行沟通。
• Scrum Master：Scrum Master的职责是在冲刺期间关注特定的工作。
• Scrum团队：Scrum团队 的主要目标是为每个冲刺指定的计划工作。

SAFe​

SAFe是“大规模敏捷框架”，是一种建立在整个组织/企业上的方法，不仅仅局限于Scrum中的团队，SAFe对Scrum进行了扩展。SAFe在组织中描述了三个级别，即投资组合层，项目群层和团队层。这种结构在大型组织中被广泛接受，它采用分层的方法来交付工作。与Scrum不同的是，它专注于回顾和发布计划，以便可以进行改进。

SAFe的三个重要部分是：

• 精益产品开发
• 敏捷软件开发
• 系统思考

SAFe的开发方式填补了Scrum留下的空白，并专注于Scrum缺少的发布计划和改进回顾。

总结​

总而言之，敏捷是一种思维定势，一种工作方式。Scrum是一个基于敏捷价值观和原则的框架，而SAFe是一个在企业级别实施Scrum的扩展框架。

在敏捷软件开发中，史诗＆故事都是常用的术语。对于管理敏捷软件开发来说，Choerodon猪齿鱼是一个很好的工具，为敏捷术语和功能提供了非常广泛的实践方法，例如：史诗，故事、任务、子任务和缺陷，这些都是Choerodon中的问题类型。

• 史诗：是一个功能集或是一个大的用户故事，但因为颗粒度太大而无法适应冲刺，它可以分解为许多较小的故事；
• 故事：是简短的用户需求，足够小以适合冲刺；
• 任务：是完成用户需求的过程性的工作，表示用户故事开发任务的完成；
• 子任务：子任务通常是故事或任务的具体拆分，由单人承接，而且通常能在短时间内完成；
• 缺陷：主要针对测试中的缺陷或者已发布版本的缺陷；

本文将详细为大家介绍敏捷中史诗和故事以及它们在敏捷中的具体使用规范。

什么是史诗？

史诗是一个大的故事，当一个功能具有多个场景时，该功能则需要在史诗层面进行多种实现。史诗代表的通常是与特定结果密切相关的原始想法，与该史诗相关联的用户故事则代表需要交付的解决方案的各个方面。总的来说，通过史诗可以跟踪待办事项中比较大的用户需求，史诗中包含多个小的产品功能的用户故事，这让用户需求更加具有层次结构。

如何编写史诗？​

对于史诗的编写，目前还没有标准格式，一些团队会使用熟悉的用户故事格式，也有一些团队则用简短的短语表示史诗。

在命名史诗时，请牢记以下两点：

1.它是开发或需求的核心内容；

2.编写时使用组织中的每个人都可以理解的语音文字，以免产生歧义；

因为史诗是编写用户故事时要参考的内容，并且在编写用户故事时还要参考所有团队成员的意见，所以正确的编写史诗并将详细信息在史诗中体现非常重要，这有助于避免团队中的许多冲突和对产品功能的误解。

用史诗介绍开发的新功能时，需要包括开发此功能的原因、需要解决的用户需求以及新功能的度验收量标准。此外，该功能的任何文档或早期的思路，可以向团队简单介绍，或者提供清晰的图片和信息。注意：团队对功能达成共识和目标是成功交付的关键。

Choerodon中的史诗示例：

• 史诗01：向用户提供排序和优先级选项，以轻松管理需求
  • 用户故事01：作为发布经理，我希望将发布映射到不同的sprint，并看到每个故事的优先级。
  • 用户故事02：作为系统管理员，我拥有优先处理产品需求的权限。
  • 用户故事03：作为用户，我可以标注需求的优先级，并实现简单的拖放操作重新排序需求。

编写史诗时需要注意的是：

1. 谨慎思考 在编写史诗时，可以先撰写项目构想的草稿，并需要思考最有必要的内容以及在以后的开发中包含的内容。这些都需要仔细考虑。

2. 逻辑清晰 在编写后续的史诗时，应该根据先前的主题来创建史诗，前后的史诗需要合乎逻辑且一致。

3. 结合测试 史诗不只是从大的故事进行思考，它分解的每个功能还需要在测试中可用。

4. 参考专家人士的意见 在编写过程中不应仅依靠个人或团队成员的眼光和思路，还需要参考专家人士的意见，阅读专业人士的的博客或他们推荐的书籍。他们的工作经验和意见能使史诗更加客观，也能让团队成员获得专业的经验和技能。

史诗是项目计划过程中重要的组成部分，有了史诗，团队成员和利益相关者可以看到产品真正的目的和用户需求。正确的史诗是进一步项目开发甚至产品研发的好帮手。

什么是用户故事？

用户故事是基于史诗进行分解的，反映的是用户需求和用户可以得到的价值。它们从用户的角度描述功能的各个部分。在敏捷开发过程中，当我们开始站在用户的角度上思考时，即使这个功能不是当前解决方案的范畴，我们仍需要建立用户可以操作的行为场景。例如，我们正在针对共享照片和视频的特定问题制定解决方案，根据经验我们按照预期的方式执行所有操作，但是用户第一次使用并且不了解产品，可能查找不到特定角色对应的照片。为了避免这种情况，在用户故事中从用户角度清楚地说明所需的功能非常关键。

如何编写用户故事​

在敏捷方法论中，团队构建的所有内容都应围绕用户，这里的团队指的是产品经理、客户、利益相关者还有产品的最终用户。为了深度了解用户的需求和痛点，在开始编写用户故事之前，需要确定好产品的角色。以下是编写用户故事时广泛使用的模板：

“ 作为一名 <角色或角色>，我可以 <目标/需要> 这样说 <为什么>”

或者，在另一种情况下：

“作为 <特定的用户类别>，我希望 <能够执行/执行某项操作>， 以便 <获得某种形式的价值或收益>”

上面的描述为产品用户制定了业务价值。除此之外，用户故事的魅力在于，它不仅制定了业务价值，而且还制定了开发和测试的要求。通过简单的描述，添加产品功能的验收标准等描述，以总结需要完成的所有任务。

以下Choerodon中某个项目的用户故事的简短形式：

作为夜晚驾驶的驾驶员，我想迅速找到最近的优质加油站，以补充高品质的汽油。

• 验收标准：

  • 作为开灯的司机，我可以看到所有即将到来的加油站。
  • 点击“Ctrl+T”，我可以选择适合我的加油站品牌的加油站。
  • 到达加油站，我可以看到即将到来的选定品牌的加油清单。
  • 点击“M”键，我可以看到最近在地图上选择的加油站。

用户故事的重点是从用户的角度清楚地说明所需的功能，需要正确的理解用户需求并详细的表达出来。编写用户故事时需要注意：

1. 用户故事≠任务 用户故事不是任务。在实际开发中，一个故事可能需要数百个任务才能成功交付，任务与执行有关，而用户故事是根据用户需求定义的。在编写故事时，应着重于提供有关产品功能的信息。

2. 故事简明扼要 故事必须简单而准确。只需使用简单准确的语言即可，有助于团队成员和利益相关者深入了解用户需求，避免花时间澄清用户故事中不清楚的地方，比如术语和首字母缩写词等。

3. 了解用户 在开始编写用户故事之前，都需要收集一组关键用户（理想情况下是产品的角色用户），了解他们的个人资料、观点、对产品的期望以及相关的“痛点”，以帮助更好地了解用户及其需求。

4. 大胆思考 当将产品描述为用户故事放到待办事项中时，“没有预算，时间周期不允许，可行性低或成本高等”会限制产品的思维。正确的做法是大胆思考 ，将用户故事维护到待办事项列表，从产品的清晰度、用户愿景方面获得的价值。

用户故事提供了一种快速而准确地描述软件产品或系统功能的好方法，在产品规划会、产品迭代会中具有主导和输出作用。在这些会议过程中，用户故事需要以紧凑、结构化的方式阐明思想的提要。

故事地图

根据敏捷的定义，在Choerodon中我们使用故事地图的形式来体现史诗和用户故事的价值。

故事地图的优势：

1. 将史诗用作业务价值的容器；
2. 根据产品版本得到横向流程；
3. 快速制定出产品的蓝图，得到mvp版本的制作周期；（关于MVP的介绍可以参考《MVP：平衡“可行性”和“最小化”》）；
4. 以故事为中心，使开发人员的精力全部集中到重点功能上；
5. 使用增量来定期检查并调整项目进度；

总结

敏捷开发关注于快速且持续地交付给用户高价值、高质量、可用的产品功能。通过史诗和用户故事梳理用户需求、识别用户角色、梳理用户故事逐步完善更多细节，使执行的故事足够短小、简单，能在单个迭代期内完成，达到快速交付的目的。

Choerodon的测试管理主要为用户提供敏捷化的持续测试工具，包括测试用例管理、测试计划、测试分析等，可以有效地提高软件测试的效率和质量，提高测试的灵活性和可视化水平，最终减少测试时间，让用户将主要精力放到软件功能构建上。本文将为您分享敏捷测试概念及Choerodon在敏捷开发过程中的测试实践。

什么是敏捷测试

在敏捷开发流程中，测试不再是瀑布式开发流程的其中一个环节，而是全程参与整个开发流程。开发中可以通过多种方式来保证产品的质量，无论是原则中的“频繁交付”，还是对“可工作的软件”的度量，或是敏捷开发实践中的“测试驱动开发”、“行为驱动开发”，都离不开测试的支持。 当然，敏捷测试对测试人员也提出了更高的要求，对测试人员来说是新的挑战。

敏捷测试人员的定义

专业的测试人员，必须有适应变化的能力，理解利用测试记录需求和驱动开发的思想，才能与技术人员和业务人员展开良好的协作。敏捷测试人员往往具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试，他们了解客户在做什么，以此更好地理解客户的软件需求。

测试人员在敏捷过程的价值体现​

1. 需求讨论：测试人员可以站在客户角度上来阐述自己的观点，和产品人员、开发人员等进行充分的交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。
2. 开发过程：测试人员不仅扮演“用户代表”角色，而且可以及时提供更全面的质量反馈，包括代码质量、接口一致性等。测试人员不写代码，可以参与代码复审(code review)，将质量问题及时提交给项目组，保证在产品构造的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。
3. 单元测试：单元测试由开发人员做，测试人员可以推进开发人员进行单元测试，检查单元测试状态。例如确保单元测试达到75%以上覆盖率，以及帮助开发人员开发出具有良好可测试性的代码。
4. 集成测试、端到端(end-to-end)测试、性能测试：因为在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统(模块/组件)，集成测试和端到端(end-to-end)测试显得更重要。其有效保证整个功能流程的完整、畅通，以及所开发的产品与其任何子系统协调良好。
5. 回归测试：持续回归测试，保证产品的稳定性。可以采用自动化回归测试。
6. 对缺陷进行分析：总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。例如标记出反复出现的bug，以便于开发总结原因。
7. 缺陷优先级：与开发沟通上有直接交流、灵活应对变化，质量控制，什么bug是重要的，什么是可以后期去做，分清bug优先级。

Choerodon在敏捷迭代中的测试流程

1. 需求分析：依据需求文档提取测试点​

通过分析需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容，并分析各个功能模块之间的业务顺序，和各个功能之间的传递信息和数据，对存在功能交互的功能项，给出对应的验证内容（功能交互测试）。同时需要考虑到需求的完整性，要充分覆盖软件需求的各种特征，包含隐形需求的验证，比如界面的验证，账号唯一性验证（界面、易用性、兼容性、安全性、性能压力）。

2. 编写测试计划和测试用例​

为项目需求而编制的一组测试步骤，测试数据以及预期结果，以便测试某个程序是否满足客户需求，测试用例需关联到对应的issue或者story，测试计划的内容包含迭代内的全部开发任务。

3. 用例评审：确认用例是否覆盖到各个场景，以及用例是否符合需求​

用例评审主要是产品、开发和测试人员，针对测试用例能否用于项目的测试而做的工作。主要是为了减少测试人员执行阶段做无效工作（提交无效问题等），以避免三方需求理解不一致。评审按用例的优先级，功能的复杂程度进行；先对优先级高，功能复杂，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。评审过程中尽量做到思路清晰，用最简洁的语言阐述每一个功能点。对于评审过程中，超过5分钟无法确定结果的问题，可以记录下来，作为会后讨论跟进的重点。

4. 测试执行；​

测试执行是执行所有或部分选定的测试用例，并对结果进行分析的过程。测试执行活动是整个测试过程的核心环节，所有测试分析、测试设计、测试计划的结果将在测试执行中得到最终的检验。

5. 转化测试后的bug​

将执行完的有bug的测试用例关联敏捷协作中的缺陷。在敏捷协作中一个缺陷可以快速定位到测试用例，帮助开发者快速获取测试结果，实现测试闭环。

6. 回归bug测试​

通过敏捷中的迭代规划，制定团队的回归方案，积极跟开发人员沟通问题原因、修复的方案和影响。整体的回归bug测试进度计划中需要包含所有回归测试和自动化回归测试时间，同时预估好每天的工作量，与实际完成的工作量进行对比，尽早知道测试进度是正常还是延期，提早控制好风险，从而达到团队能更好地交付价值的目的。

总结

以上我们回顾了Choerodon猪齿鱼敏捷测试在整个项目开发中的基本流程，详细介绍了各阶段存在的主要测试活动。总的来说，敏捷测试的最终目的是持续交付，快速交付可靠的产品。敏捷过程的测试，除了对测试能力的要求之外，还要求测试人员在团队的协作能力更高。此外，随着迭代的不断增加，对自动化测试的能力也有较高要求。

希望本文有助于正在使用敏捷模式或者打算使用敏捷模式的团队更好得理解敏捷测试。

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更加详细的内容，请参阅Release Notes和官网。 大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

本篇文章出自Choerodon猪齿鱼社区柴晓燕。

在SAFe中，每个PI都需要交付一定的价值。PI的执行过程中，各个敏捷团队致力于实现PI计划会中承诺的PI目标。PI过程中的每个敏捷迭代都很重要，每个迭代都承担了和团队相符的工作量，敏捷团队大多数时间都在“低头干活”，并且将精力聚焦在最近要交付的价值上。每个迭代、每个PI都有一种时间紧迫性。由于这种紧迫性，可能会存在一种风险，ART（敏捷发布火车）没有预留的时间用来调整、创新学习、计划，那些时间紧迫的任务的优先级将超过任何活动。为了解决这个问题，SAFe提供了专门的Innovation and Planning（IP） 迭代。下文将为您详细介绍IP迭代。

什么是IP迭代

IP迭代是固定在PI末，持续一周的特殊迭代，它为团队提供了一个有规律、有节奏的时间段，让团队可以有机会开展一些在持续不断的增量价值发布的环境中很难进行的工作。这些工作可以包括如下内容：

• 创新和探索；
• 编写发布文档、产品手册；
• 黑客马拉松；（下文有解释）
• 检视和调整工作坊，包括最终PI系统演示；
• 项目群和团队待办事项列表梳理；
• 处理技术基础设施、工具和其他系统障碍；
• 促进持续学习；
• PI计划。

同时，IP迭代还有其他重要的作用，比如提供为满足Pl目标实现所需要的缓冲时间，以及增强发布的可预测性。从敏捷发布火车的执行可以看出，通过有规律地对团队进行“重新充电和工具锐化”，整个团队的有效性、速度、稳定可持续的步伐和工作的满意度都得到了提高。

IP迭代可以进行的活动：

创新​

创新是精益敏捷思维的支柱之一。但是想要在发布的截止时间之前专门留出时间进行这样一件事通常是很困难的。为此，ART使用IP迭代进行一些研究和设计的活动，以及黑客马拉松。黑客马拉松的规则很简单:

• 团队成员可以做他们自己想做的任何事情，也可以做任何其他人想让他们做的事情，只要这些事情和ART的使命保持一致即可。
• 团队会在活动结束时，向其他人演示他们所做的事情。

通过这些活动得到的成果或者发现，通常会进入项目群待办事项中，以帮助推动创新。还有一些创新和修复则会直接进入产品。黑客马拉松产生的自动化和过程改进也将会立即得到应用。

投入时间参加PI活动​

Pl系统演示、检视和调整工作坊、Pl计划会议都是非常重要的PI活动，需要花时间去执行。把这些活动放在专门的IP迭代周期中，意味着其他的迭代周期可以有正常的长度和速度，而不会被这些关键的活动干扰。更为重要的是，这些重要的活动在项目群日程表中，被系统化固定下来以保证它们能够按时举行。

同时，这样做使得在迭代的最后时刻可以进行项目群层和价值流层待办事项列表的梳理，以及特性和能力的优化，可以帮助下一个计划阶段显著提高效率。

促进持续学习​

各个级别的员工都是终身学习者。科技的变化日新月异，方法和实践也在不断变化，这些都给持续学习带来很多机会，然而他们通常却并未有效利用这些学习机会。此外，最初向精益敏捷的转变需要许多新技术和技能，包括：

• 专题报道和故事写作
• 建筑质量
• 自动化测试
• 集体所有权
• 精益--敏捷架构
• 持续集成
• 结对工作
• 产品负责人和Scrum Master技能的掌握
• 团队建设

从业人员也面临着使他们的技术水平保持最新的挑战。新技术的引入比以往任何时候都更加频繁，只是埋头忙于交付，忽略了新技术的学习，会不断累积技术债。IP迭代正是偿还技术债的时机。ART需要为持续学习提供时间，以便团队成员和领导以有时间学习和掌握这些新技能。这些学习时间也可以用来增强和支持实践社区的专项主题研究。最终结果将是个人和企业都从中受益，员工的技能得以提升，工作满意度增加了，速度也提高了，而且产品和服务上市时间也变短了。

为实现PI目标提供缓冲区​

精益原理告诉我们，100%的利用率会带来不可预测的结果。简而言之，如果每个人都满负荷工作，当出现不可避免的问题时，就没有人有空余的时间来进行处理。这将会导致价值交付的不可预测性和延迟。

作为对策，IP迭代也可以被视为一个“保护带”（或缓冲区），以防止当前PI中未完成的工作转移到下一个PI中。 在PI计划期间，ART不会为IP迭代安排功能或故事，而是为团队提供了一个缓冲（额外的时间）以应对突发事件、因依赖关系导致的延迟，以及其他问题，从而提高了团队实现PI目标的能力。此缓冲区大大提高了项目群结果的可预测性，这对业务负责人来说是极为重要。但是，通常将这段时间用于完成工作是一种失败模式。这样做会破坏IP迭代的主要目的，创新可能会受到影响。团队必须注意，这个IP迭代不能被简单地看作计划不充分的补充，或者是作为预留时间用于执行那些本该在各个迭代完成的质量活动。

如果没有IP迭代，会发生什么​

• 没有容量缓冲，ART是不可预测的；
• 由于交付的紧迫感，没有时间进行创新学习；
• 技术债持续增长；
• 人员过度疲劳；
• 节奏和同步成为挑战，因为没有时间分配给团队共同计划、共同演示、共同改进；
• 没有时间持续学习；
• 实际的工作速度变慢。

总结

IP迭代为团队提供一个定期的、专用的、有节奏的机会，使团队能够处理一些通常不容易被放入标准开发迭代的活动（例如PI计划会、检视与调整、黑客马拉松等）。它作为PI的完整结束，也是下一个PI的开端。当然，ART可以根据实际的情况决定是否使用IP迭代。

• 如何在Choerodon中进行大规模敏捷规划，请参考大规模敏捷实践指南（三）：如何进行大规模敏捷规划。
• 如何在Choerodon中进行SAFe大规模敏捷实践，请参考大规模敏捷实践指南（一）：如何开启大规模敏捷之旅。
• 了解SAFe的术语以及对应到Choerodon上的功能，请参考大规模敏捷实践指南（二）：SAFe术语与Choerodon功能对照表。
• 了解什么是大规模敏捷框架SAFe以及Choerodon猪齿鱼如何聚焦SAFe框架理念进行大规模敏捷实践，请参考Choerodon大规模敏捷|大规模敏捷框架SAFe。

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更加详细的内容，请参阅Release Notes和官网。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

原文作者：Maarten Dalmijn

原文地址：https://medium.com/serious-scrum/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7

译者：付新圆&柴晓燕

几乎每个Scrum团队都在使用故事点，但故事点不是官方Scrum指南的一部分，就存在很多不同的解释和使用方法。本文旨在消除围绕故事点的神秘感，也将分享我在敏捷实践中遇到的对故事点的误解。

故事点代表什么？

故事点是用于估计敏捷开发中用户故事的相对大小和复杂性的度量单位，表示投入PBI (Product Backlog Item产品待办事项) 所需的工作。每个故事点代表一个时间的正态分布。例如：1个故事点可以表示4-12小时的范围，2个故事点可以表示10-20小时的范围，依此类推。这个时间分布在预估过程中是未知的。通过参考PBI (Product Backlog Item产品待办事项) 得到相对估计值，虽然不知道完成任务的具体时间，但可以粗略地知道需要多长时间完成任务。

使用故事点有什么好处？

故事点使团队能够：

• 快速预估问题。预估可以参考已经完成的产品待办事项。这比没有任何参考的预估要快。
• 估算时无需给出具体的时间承诺。以小时为单位进行估算时，您需要做出精确的时间承诺。但估算故事点时，不需要做出确切的承诺，不需要对特定问题指定多少小时完成。
• 拥抱预估带来的不确定性。故事点指定了未知的时间范围，从故事点的特定Fibonacci-like序列中进行选择可以捕获不确定性。
• 足够准确，可以提前计划冲刺。可以更好地管理利益相关者对未来工作的时间期望。

使用故事点时常见的12个误区

1.讲故事只是指复杂性，不确定性或价值。​

PBI (Product Backlog Item产品待办事项)的实现需要复杂的算法。有些PBI (Product Backlog Item产品待办事项)很复杂，但并不需要很多时间，团队之前已经做过了此类的操作，所以他们能快速完成。相反的情况也会存在，比如一个简单的PBI需要很多时间，团队需要重构一小段代码，但影响了很多功能，结果许多功能需要进行回归测试，这将花费大量时间。

预估的不确定性在故事点fibonacci-like序列本身中捕获：1、2、3、5、8、13、20、40、100。从该序列中选择特定数字反映了不确定性。当不确定性太大而无法估计时，则可以使用“?” 卡。

故事点提供了一个粗略的估计，并不能说明PBI的价值。该项目可能非常有价值，或者根本没有增加任何价值。故事点可以帮助项目确定PBI的ROI（投资回报率），您可以考虑将功能与价值一起交付。

故事点与工作相关。 复杂性，不确定性和风险是影响工作量的因素，但它们单独使用时不足以决定工作量。

2.将故事点转换为小时。​

通过将故事点数转换为小时数，您就无法从相对估计的速度中受益。您开始以小时为单位工作，冒着做出承诺的风险。当您将故事点的时间范围从10-20个小时减少到15个小时时，它提供了一种错误的准确性。当您开始在确切的时间范围内工作时，团队在预估上达成一致就会非常困难。

3.平均故事点数。​

在计划扑克游戏的过程中，团队的一半人预估PBI为3个故事点，另一半人预估为5个故事点。只需将4个故事点作为估算值​​，就可以解决讨论。这样并不是100%准确的，关键是要足够准确，提前做好计划。团队不应这样做，因为它提供了错误的准确性。另外，您可能会因为平均而失去一次有价值的讨论。也许5个故事点是一个更好的估计。

4.在冲刺期间调整故事点对问题的估计。​

当团队开始处理问题时，即使事实证明他们的预估是不准确的，团队也不应调整“故事点”。如果预估不正确，则它是最终冲刺速度的一部分。有时预估不正确是正常的。您不会丢失这些信息，这将成为团队历史速度的一部分。

5.从不讲故事的bug。​

一个与当前冲刺无关的bug应该只在故事中提到，该bug是团队需要完成的工作。如果团队在冲刺期间保留了固定的时间来处理bug，那么这就不适用。与冲刺中的问题相关的bug不应该用故事描述，因为这是原始评估的一部分。

6.将故事点增加到小型任务中。​

调查一些关键的事情应该有时间限制，这件些关键的事情通过经验可能只需要4个小时来完成，就无需在其中添加任何故事点了。

7.调整参考PBI的冲刺。​

当一个团队调整参考PBI的冲刺时，那么不同冲刺的速度不再具有可比性。团队会丢失信息，您将无法再使用历史速度来提前计划。最好使用一系列最新的PBI作为参考。

8.故事再次指出未完成的问题。​

将未完成的PBI移至下一个冲刺时，无需重新估计。这个估算可能不准确，但这不成问题。作为冲刺计划的结果，团队将了解完成问题所需的所有任务。这些任务的估算以小时为单位。因此，下一次冲刺，团队将知道完成PBI仍需要多少时间。PBI未完成的将成为速度的一部分。

9.因为有特定的开发人员来处理，而调整故事点估算值。​

故事对应的PBI与参考的用户故事相关，由团队完成。团队成员讲述了PBI的故事，并在规划会议中就估算值达成了共识。对于高级开发人员，PBI可能是3个故事点，对于初级开发人员，一个PBI可能是8个故事点。团队工作量应达成协议，并将其用于计划。您不应调整故事点，因为每个PBI都将由特定的人来完成。也许当他们开始处理该问题时，高级开发人员正在处理生产问题。然后，初级开发人员就需要将其剩余的工作捡起来。

10.切勿调整参考PBI。​

当团队组成发生变化时，这可能会影响速度和故事点评估。他们俩都依赖于执行工作的团队。想象一下，当两个高级开发人员在场时，您就可以从故事中找到问题所在。当您要开始解决这些问题时，他们俩都离开了公司。现在，团队中有两个新的初级开发人员。建立一个新的用户故事参考是很好的实践，它需要整个团队来进行。这样可以确保每个人在讲故事时都在一个步调上，并给团队一些时间来建立新的速度。随着团队的越来越成熟，估算能力也越来越强，建立新的参考PBI可能是一个好主意。

11.与专家保持一致。​

在制定冲刺计划时，团队可能会与专家保持一致。解决此问题的一种方法是让专家详细说明这项工作，然后让团队的其他成员在没有专家的情况下进行评估。积累特定的专业知识是不可避免的，但不要让这削弱了团队的估算能力。

12.在回顾会中不讨论错误故事指向的问题。​

每隔一段时间，团队都会指出故事评估的错误问题，讨论这些问题并尝试了解这些问题非常重要的，这样未来的评估就会更准确。在我的一个团队中，我们忘记了在评估时考虑测试数据的创建，因此，我们特别讨论了创建测试数据是否适用的每个问题。如果适用，我们会询问他们是否考虑了测试数据的创建。这大大改善了我们的评估质量。

结论

故事点的概念很简单，但很难应用，几乎每个Scrum团队都使用它们，但它不是官方的Scrum指南的一部分。正因为如此，人们对如何使用故事点有不同的看法。术语“故事点”本身已经令人困惑，因为您也可以将它用于用户故事以外的工作类型，在这个“点”字上，说明一个故事点代表了价值。正如一位同事指出的那样，或许用“计划因素”一词来说故事点会更容易让人理解。本文旨在帮助大家了解在使用故事点时可能会犯的错误，并以正确的方式应用它们。

Scrum敏捷过程中在迭代开始前需要进行迭代规划会，那对于SAFe大规模敏捷在PI开始之前要经历什么呢？上文提到PI提供了一个更大、更具有战略意义的PDCA时间盒，所以PI也是有规划会的。下文将为您介绍PI规划会的历程。

什么是PI规划会？

项目群增量(PI)提供了一个比SPRINT更大的PDCA环，为整个ART的计划、集成、演示、检视和调整提供了节奏。PI规划会就是一个非常重要的，有节奏的同步点，它有着标准化的流程。可以说，没有什么比PI计划更强有力的活动了，PI计划是PI的基石，确定了ART的节奏。

当100多人为了一个共同的目标一起工作，仅仅两天内就可以达成共识，而不是花费几个月或者几周的时间来等待决策和通过一系列邮件来达成一致，这会产生怎样令人惊叹的协作能力？

• 通过PI规划会，ART成员会定期进行同步，更好地定义和设计愿景及承诺，从而满足近期的PI目标；
• ART成员通过PI规划会来创造、不断培养维持一种共同的使命、责任或承诺，养成高度的合作协作意识；
• PI规划会将ART的责任从中央管理转移到真正负责工作的团队；
• 通过PI规划会建了ART所依赖的社交网络。

准备PI规划会

• 组织结构准备：产品管理者、敏捷团队、业务负责人，以及其他利益相关者。 有可能的话，所有的ART成员都应该参与进PI规划会。毕竟，他们才是计划的最终执行者，他们是唯一可以对计划作出承诺的人。
• PI规划会输入内容：

（1）当前业务愿景和背景；

（2）项目群待办事项列表中排名较前的特性，包括其接收标准，以确保特性满足其完成定义。

如何确定去排名靠前的特性？

我们可以通过WSJF（加权最短作业优先）法则来确定出价值较大，时间较紧迫但规模较小的特性。通过WSJF权值排序，筛选出优先级较高的特性。

标准的会议议程

PI规划会通常会遵循一个标准的会议议程，如下图所示：

如何进行PI计划会？​

• 快速确定要满足PI目标所必要的特性或者优先特性；
• 团队快速识别出所有必要的故事，以满足PI目标和优先特性；
• 识别与其他敏捷团队之间的依赖关系；
• 估算故事点，按照优先级放入每个迭代；
• 识别出无法在当前PI完成的工作，可以考虑放在下一个PI周期；
• 团队确定迭代计划；
• 整合项目群风险、障碍，以及依赖关系；
• 将特性依赖和跨团队依赖整合到项目群公告板。

PI规划会的第一天的内容包括：建立业务背景和计划过程背景、创建计划草案，并以管理者评审和问题解决会议作为结束。

PI规划会的第二条的内容包括：计划调整的讨论、得出计划终稿和设定业务价值、批准计划终稿并对PI目标作出承诺。

最终，PI规划会产出：

（1）已承诺的PI目标、PI计划；

（2）维护完依赖关系的项目群公告板。

缺少有效的PI计划，会发生什么？​

• 利益相关者和团队对愿景、目标没有清晰的理解。
• 团队不知道业务环境和最重要的目标。
• 业务和技术之间缺乏一致性。
• 依赖关系被发现得太晚。
• 计划是集中但无效。
• 团队缺乏对业务目标的承诺。

总结

PI规划会是定期举行的，可以在一个地方面对面进行，也可以在多个地方同时“面对面”进行的计划会议，其与ART存在依存关系。对SAFe来说，PI规划是不可或缺的（如果你不做PI计划会议，就相当于没做SAFe）。但是PI规划会的议程可以根据组织的实际情况进行调整。

如何在Choerodon中进行SAFe大规模敏捷实践，请参考大规模敏捷实践指南（一）：如何开启大规模敏捷之旅。

了解SAFe的术语以及对应到Choerodon上的功能，请参考大规模敏捷实践指南（二）：SAFe术语与Choerodon功能对照表。

了解什么是大规模敏捷框架SAFe以及Choerodon猪齿鱼如何聚焦SAFe框架理念进行大规模敏捷实践，请参考Choerodon大规模敏捷|大规模敏捷框架SAFe。

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更加详细的内容，请参阅Release Notes和官网。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

SAFe框架为企业解决多团队开发提供了多层级的指导，包括团队（team）层、项目群（program）层、价值流（value stream）层以及投资组合（portfolio）层。Choerodon猪齿鱼就是应用了SAFe框架概念进行的大规模敏捷实践。本文将为你介绍SAFe框架项目群层的基本术语及其在Choerodon猪齿鱼上的对应功能。

总结​

SAFe可以帮助企业在可持续的最短前置时间内处理开发和交付企业级软件和系统中的各种重大挑战。SAFe中的核心是项目群层，它围绕着ART开展工作，ART包括了从概念设计到部署过程中所需要的所有角色。每个ART都通过协调敏捷团队来实现共同的使命和愿景，使用同一个项目群待办事项列表，它产生有价值的、可测试的系统解决方案。ART在架构师和敏捷教练的指导下，使用固定的PI计划和执行时间周期。

如何在Choerodon中进行SAFe大规模敏捷实践，请参考大规模敏捷实践指南（一）：如何开启大规模敏捷之旅。

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更加详细的内容，请参阅Release Notes和官网。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

原文作者：Jeremy Bird

原文地址：https://uxplanet.org/lean-product-strategy-balancing-value-and-minimums-aae06e754f68

译者：付新圆&柴晓燕

“ MVP”或“最小化可行产品”是技术中使用最多，却最难理解的概念之一。该术语由弗兰克·罗宾逊（Frank Robinson）于2001年提出，如今这个词有很多种解释，但大部分失去了最初的含义。大家现在似乎都只专注于“最小化”，但忘记了产品的“可行”或“有价值”的部分。

现在大多数技术公司都把MVP定义为一个“可用的最小功能集合”。但是什么是可用的最小功能集合呢？这样做的目的是什么呢？

弗兰克·罗宾逊（Frank Robinson）清楚地定义了他所说的“ MVP”。

MVP是为您的公司和客户量身定做的产品。它有足够大的规模，能让公司和客户满意的接受，并可以正常销售；但又不至于太大，以至于膨胀到充满风险的程度。

—弗兰克·罗宾逊（Frank Robinson）, 2001

换句话说，MVP是一种解决问题的方法，它可以从三个方面提高用户体验：有效性、效率和满意度。

为了最小化风险并且得到最大的投资回报，MVP是精益的。换句话说，MVP是每次迭代都要交付一个可用的最小功能集合，这个集合的功能可以满足用户的基本需求，虽不完善但至少可用。Jeff Gothelf和Josh Seidon在他们的书《精益UX》中这样写道：

每个设计都是一个被提议的业务解决方案——一个假设。通过客户反馈，逐步修正产品设计和解决方案，MVP就可以来验证产品是否满足客户的需求。

—Jeff Gothelf和Josh Seidon，“精益UX”

大多数公司的问题在于，他们对MVP的理解还只停留在“最小的代价”部分。只是急于做出一个版本，用来告诉公司上层项目取得了良好的进展。还有一些公司他们的问题是，完全忽略了客户的体验和反馈。假设你正在开发一个产品，客户有Frank Robinson、Jeff Gothelf、Josh Seidon，但是他们从来都没有使用和反馈过产品，那就不会有MVP了。

MVP首先着眼于基本的客户需求，快速构建一个可满足客户需要的初步产品原型。做出最小可用产品，通过销售数字、应用商店评级等形式获得客户反馈后，逐步调整产品战略，尽快达成短期目标。即使它没有任何效益，但满足用户的基本需求，虽不完善但至少可用。为了避免消耗过多精力和费用得到一个有效的、精益的MVP，基于客户需求进行开发很重要。

滑板&汽车车架

关于MVP这个概念，我最喜欢的总结之一是Henrik Kniberg撰写的《赛车vs滑板》(以下是我的团队成员对原版的改编):

图片来源：Bethany Larsen和Jason Baddley

在这个假设的示例中，我们正在改善步行通勤用户的交通状况。请注意，我们不是从产品功能角度出发达到客户需求，而是把重点放在改善步行交通状况的结果上。从A到达B滑板的速度比步行快；踏板车吸引了更多人，并且更易于使用；自行车速度很快；摩托车比自行车还要快；汽车更安全，并且可以容纳更多人。通过以上分析，我们可以迅速地将产品价值传递到用户手中，通过客户的反馈和时间的推移还能不断增加这种价值。

实现一辆汽车传统的产品设计思路是一步一步，从车轮、车轱辘、外壳、动力装置、内部装饰一个流程一个流程做起，同样需要很多时间来完成。但是在上面的方法中，我们在完成的同时还能为客户提供了更高的价值(因此也提高了效率、效果和满意度)。

这里还要强调的是，从自行车到摩托车是需要一个过程的，无论是制造自行车还是摩托车，都不是一蹴而就的。通过用户的反馈，你可以用MVP的思想不断的改进、迭代，从而推动获得更好的产品，这就是敏捷和产品进步的意义所在。即使大家都懂得这个道理，但还是有很多开发人员和领导会因为用户的反馈而感到困惑。值得再次重复的是：没有什么工作是一蹴而就的，如果想要产品进步，那么它的改善一定离不开你的客户，只有不断的改进、迭代、收集反馈，才能得到更优质的产品。

如果不是因为从自行车中得到用户的反馈，也许我们永远不会制造出摩托车。如果我们制造了摩托车后，得到的客户反馈是摩托车已经满足了所有需求，那么我们就不用去造汽车了，防止浪费时间和资源。

MVP和怎么去做MVP

但另一方面，如果我们要做的项目是城市交通呢？在这种情况下，滑板是否还是MVP吗？当然不是。但是我看到的许多公司都会犯一个错误，他们只做到了“最小的代价”部分，却忘记了产品的有效性，效率和客户的满意度。

为什么会这样？我观察到，当公司只专注于根据产出衡量成功时，他们就无法预测结果，就会发生这种情况。在Scrum世界中，大多数开发团队都是在完成所有事务、提高迭代速度和准确估计时间点的基础上进行产出评估的。当你沿着这个链走下去的时候，就会进入发布时间表会比实际改善用户体验更重要的误区。

快速行动虽然很重要（这就是精益用户体验的意义所在），但是我们应该牢记快速行动的方向：提高效率，有效性和客户满意度。

引导公司专注于成果

那么，在持续产出的敏捷世界中，我们如何将重点转移到结果上呢？寻找一种让自己的敏捷团队以及利益相关者能够定期与用户沟通的方法。这种沟通方法可以是远程的，也可以是不定期式的。一开始需要一些技巧的，甚至需要对潜在客户（而不是实际用户）进行不定期式研究，如果你这样做并找到一种简单的方法汇总结果，与团队其他成员分享学习经验，就会发现你的团队会有很大的转变。

我过去不得不使用了这种方法。我带领的是一支完全不愿意分配时间并拒绝与用户联系的团队，但通过这种方法，我们的用户研究作为竞争优势为公司赢得了数百万美元的交易。

最后一点，不要认为这种变化会在一夜之间发生的，这是一个过程。就像在用户界面中一样，在这个过程中收集用户需求，采访用户（团队成员，利益相关者，业务主管）体验。了解为什么他们觉得没有时间了，然后想办法让他们知道得到想要的东西的方式。（例如，更快的更新版本）。

当人们认为您试图说服他们改变优先顺序时，他们很难被说服。如果你发现什么对他们来说是重要的，并向他们展示用户研究将如何帮助他们实现他们想要的，事情就会变得容易得多。

另一个有帮助的想法是制定在各个阶段都有成功标准的路线图。你的“MVP”步骤是什么？如何快速地做到这一点，如何进行学习和调整呢？下一步可以看到什么？以这种方式设计组织中的流程更改，能够最大限度地减少挫败感，并随着您的前进而看到递增的结果

总结

随着社会越来越发达，用户的需求越来越高会给开发者很大的压力。但是，当我们将“最小的努力”和短时间的精力集中在用户反馈和学习上，以提高用户对产品的有效性，效率和满意度时，我们会对开发的产品更有信心，用户会有更好的体验感和购买欲。如果用户还是不满意，我们就迅速进行调整，以减少失败的损失。

为了解决与多个团队合作时的效率低下的问题，通常有人建议引入大规模敏捷框架。此类框架最著名的示例就是规模化敏捷框架（SAFe）。在计划增量级别，SAFe提出了Scrum作为创建产品增量的方法之一。因此，改编版的Scrum通常是SAFe的一部分。在《Choerodon大规模敏捷|大规模敏捷框架SAFe》中您可以了解什么是大规模敏捷框架SAFe。

本文将为你介绍如何用SAFe开启大规模敏捷之旅，主要内容包括：

• 设置ART节奏；
• 组建ART中的敏捷团队；
• 组织敏捷团队
• 准备项目群待办事项列表

对于Choerodon来说，规模化敏捷是实现多团队研发协作不可或缺的一部分，Choerodon实现规模化敏捷就是以SAFe框架为理论基础，目前Choerodon仅实现了项目群层-团队层部分。

• 项目群层：由产品经理（Product Manager）负责把等待安排的计划（Backlog）进行排序，并且把史诗（Epic）拆分成具体的新功能（Feature），同时和业务负责人一起设计出项目的愿景和路线。
• 团队层：由产品负责人（Product Owner）和团队成员根据上面的定义细化出用户故事（User Story）和验收标准，开发团队可以从候选的用户故事里面优先选择可以提前开始的内容，其余的留到需求池里面等待后续的选择。

设置ART节奏；​

启动ART必须确定迭代节奏，它是由迭代长度（默认2周）和PI长度（默认包含两个迭代，以及IP迭代）组成。

PI开启后，子项目会自动按照这里的默认节奏创建冲刺。

product是由多个团队集成的，因此各个团队在相同的节奏下使用相同的迭代持续时间是十分重要的。否则，团队可能按照迭代执行，但是很难集成，而且会以步调最慢的团队为准结束工作，延迟对集成时问题的发现。最终团队可以按迭代执行，但是系统无法按迭代交付。

为了解决这一问题，SAFe提供两个同步的PDCA环，团队的PDCA循环是同步的，所有的团队在同一时间开始迭代，也在同一时间结束迭代。团队的循环包含在PI的循环里面。

那么疑问来了，如果没有节奏和同步，会怎样呢？

• product变得混乱，缺乏可预测性；
• 集成延迟，导致延期交付；
• 单个团队可能是敏捷过程，但是系统没有按照迭代交付；
• 无法让合适的人都参与会议。

Choerodon-设置ART节奏：​

组建ART中的敏捷团队；​

敏捷团队是跨职能的，拥有创建产品增量所需的所有团队技能，没有敏捷团队，就不可能有火车，他们为ART乃至整个企业提供动力。ART负责提供更大的解决方案价值。火车上的所有团队都与其他团队合作，为PI目标和路线图做出贡献 ，并参加ART活动。此外，他们还负责构建持续交付管道和DevOps功能。

组织敏捷团队​

• 把为ART提供动力的敏捷团队都整合到ART中，并且确定每个团队的主要负责人，可以是产品负责人，也可以是Scrum Master。
• 组织ART的管理团队，包括发布火车工程师，系统架构师，产品负责人等。

准备项目群待办事项列表​

准备好我们的人员和团队，我们就需要定义我们要做什么，做成什么样，做到什么程度。也就是我们的敏捷团队最终要构建什么。

“构建什么”是由项目群待办事项列表控制的，它包含一系列待开发的特性、非功能性需求。他是由ART的利益相关者，包括发布火车工程师、架构师、业务负责人、产品负责人、客户，共同定制出一个待办事项列表。

总结​

经过上面的准备，大规模敏捷的前期准备工作已经就绪，就可以正式步入大规模敏捷了，以提高团队的生产力，增加价值交付。

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更加详细的内容，请参阅Release Notes和官网。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

“它由Product backlog开始，经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事（story）形成迭代的sprint backlog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。”

了解敏捷的朋友都知道backlog和spring是待办事项和冲刺的意思，但在使用Choerodon实践敏捷开发的时候这些敏捷术语对应的系统功能是哪些呢？为了解决大家在使用Choerodon时的困扰，整理了以下Choerodon功能与敏捷术语的对应表，以便大家进一步了解Choerodon的具体功能。

关于Choerodon猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

在进行团队敏捷开发的过程中，会听到大家各种各样的疑惑：“我们项目的燃尽图怎么显示不出来？”，“燃尽图反映不了当前迭代真实的情况，没什么作用呀？”，“燃尽图有线条，但是具体是什么意思呢？”等等这一类的问题。造成了更多的时候，团队把燃尽图当成一个摆设，有它没它都一样。为了解决大家的这些疑问并且把燃尽图正确的使用起来，本文专门针对燃尽图的概念以及在Choerodon中燃尽图的运用进行介绍，帮助大家在敏捷路上不迷路。

什么是燃尽图

燃尽图用于表示一个敏捷迭代剩余工作量的工作图表，由横轴（X）和纵轴（Y）组成，横轴表示时间，纵轴表示工作量。可以实时、客观、直观展示当前冲刺任务的完成情况，达到预测项目当前迭代工作进展，并且提前预测出当前迭代有超前完成或者延期完成的情况。它是由项目中的所有团队成员共同维护的数据信息，提供的是实时客观的任务完成情况数据。维护好燃尽图的数据，可以实时提供准确的进度信息，提高了整个团队、项目的透明度。懂得运用燃尽图，可以更早的预测团队当前迭代开发的进度风险，让团队可以尽快消除风险。

如何维护Choerodon燃尽图的数据？

Choerodon燃尽图提供了三个维度的进度反馈：问题计数、故事点、剩余时间。

(1)问题计数​

根据当天的剩余问题个数来渲染图表，这里的问题包括故事、任务、子任务以及缺陷。

(2)故事点​

根据当天剩余的故事点来渲染图表。故事点需要在进行Sprint计划会议时由团队共同来估算，并且同步记录到Choerodon平台。

(3)剩余时间​

根据当天的剩余的预估时间来渲染图表。这个时间需要团队的迭代过程中实时更新工作记录。在Sprint计划会议上，每个问题的经办人需根据自身的工作速率，估算出完成问题需要的大致时间，并且同步记录到Choerodon平台。剩余时间的数据需要各个经办人在问题详情页面维护工作日志才能得到，更新工作日志后，剩余预估时间会自动调整。工作日志如下图所示：

通过维护工作日志，得到以下剩余时间维度的燃尽图：

此外，团队成员需在每日站会前或者问题状态变更后，及时在敏捷看板拖动卡片改变问题状态，燃尽图会实时显示当前迭代看板的剩余任务情况，也就是未燃尽的部分，直到迭代的问题彻底解决，也就是当前迭代的任务全部燃尽了。

Choerodon燃尽图上线条表示的意义？

Choerodon燃尽图提供一条特殊的参考线：期望值。这条线为团队的开发速率提供了一个较为标准、开发速率正常的参考线。团队成员可以通过实际剩余值线条和预期值线条来对比，了解当前开发的进度是否正常。 例如：

（1）如果剩余值低于期望值​

那说明该时间节点开发速率快，有提前完工的可能性。如果整个迭代内长期处于这种情况，那么就需要考虑当前迭代在规划时工作量是否饱和的问题了，接下来的迭代可以参考此次的速率进行规划，以及考虑是否提前结束当前迭代。

（2）如果剩余值高于期望值​

那说明该时间节点开发速率比预期较慢，有延迟迭代的可能性。如果长期存在这种情况，需要考虑当前迭代规划时是否有工作过饱和的情况，在接下来的迭代中吸取经验，并且考虑适当延期当前冲刺。如下图的冲刺就有延期的风险，需要PO或者敏捷教练及时了解情况消除风险。

Choerodon燃尽图在敏捷迭代各个历程如何使用？

(1)Sprint计划会议：当次迭代的工作量规划可依据历史冲刺的燃尽情况、燃尽速率进行更加合理的规划。

(2)每日站会：站会除了可以通过看板来了解各个问题的进展，也可以通过燃尽图来了解总体的进度。团队成员可根据燃尽图线条及时的了解工作进度，预测并提醒迭代可能面临的风险，及时的沟通消除这些隐患。

(3)回顾会：在迭代末，燃尽图就是当前迭代进行情况的很好的图表数据反馈。参照燃尽图的不同节点，团队可以更好的总结经验教训，在以后的迭代周期扬长避短。

Choerodon燃尽图为什么要使用多种维度来展示进度？

(1)问题计数的维度​

是以当前迭代的问题卡片数量为衡量单位。相对剩余时间粒度较粗，相对故事点较为独立。这种维度不需要成员维护过多的数据，直接以个数来评估。

(2)以剩余时间的维度​

通过团队录入实际的剩余工时，可以得到比较准确的进度信息。团队成员每个工作时刻都在完成任务，努力把问题到达done的状态，使实际的剩余值更加靠近期望值，使得燃尽图的线条在更小的粒度范围跌宕起伏。以剩余时间的维度查看燃尽图虽然能够反映出团队成员工作的状况，但却不能更加明晰的表示出功能完成的进度。

(3)以故事点的维度​

故事点的完成标志着一个story到了done的状态，也就是这个用户故事通过设计、开发、测试、完成的所有阶段，故事下的各个子任务也完成，用户故事已经验收通过了。站在客户的立场就是这个需求点可以交付了。也就是说完成一个用户故事，就是实现了一些故事点的价值交付。所以在敏捷开发过程中，掌握使用故事点燃尽图来维护进度的能力后，团队应对变化、快速交付价值的能力也会得到极大的提高。

这三个维度在不同情况下适当的结合运用，可以得到更加准确、客观、直观的迭代进度展示。

总结

燃尽图作为敏捷开发过程中一个重要的图表，能提供迭代或者项目进度和最新任务状态的报告，并对故事点、任务变化、工时变化这些迭代过程的重要数据指标进行直观的展示，确保团队中每个成员都能统一进度。此外，将燃尽图展示在团队成员面前，能够很好的激励团队成员积极参与项目，高效的完成迭代任务，提前处理开发可能遇到的风险。

关于团队的敏捷实践的其他相关信息，可以参考以下文章：

• 使用Choerodon平台进行敏捷需求管理可参考Choerodon猪齿鱼敏捷管理实践（一）:需求管理

• 结合Choerodon平台敏捷管理模块进行冲刺管理可参考Choerodon猪齿鱼敏捷管理实践（二）：冲刺管理。

• 组织Sprint计划会议、每日站立会议、评审会、回顾会等敏捷会议可参考Choerodon猪齿鱼敏捷管理实践（三）：敏捷会议

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

近几年，很多公司都在使用敏捷，最开始时候，是从3-9人的小团队开始尝试的，scrum就是在小团队中实施的敏捷，实践起来比较简单。如果是多个业务团队和开发团队一起协作，人数达到上百人，该如何管理产品开发进度呢？又如何让产品及时顺应市场需求呢？SAFe就可以解决这些问题。本文通过介绍什么是大规模敏捷框架SAFe以及Choerodon猪齿鱼如何聚焦SAFe框架理念进行大规模敏捷实践，带大家了解面向企业的大规模敏捷。

什么是大规模敏捷框架SAFe​

• SAFe 是一个企业级的大规模敏捷框架，它基于精益和敏捷的最佳实践。大规模敏捷主要针对系统较大，团队较多，业务复杂的项目。
• SAFe 的理论基础包括精益-敏捷原则、敏捷核心价值、精益-敏捷领导、精益-敏捷思维、敏捷实践社区、敏捷的实施经验。
• SAFe 可以处理大规模复杂的应用开发，使用 SAFe 可以获得以下好处：
  • 生产效率提升 20-50%
  • 质量提升大于 50%
  • 产品发布缩短 30-75%
  • 员工满意度和忠诚度提升

SAFe框架​

SAFe 的一个核心概念可以概括为分层，可以分解为团队层、项目群层、价值流层、投资组合层。

团队层​

敏捷团队是由5-11人组成的跨职能小组，包括所有必要的角色。它是确保在每一次迭代中定义、构建、测试并且交付增值。为了降低沟通成本及文档成本，通常敏捷团队的规模较小。

在团队级的SAFe中，这个框架使用Scrum和看板，冲刺采用至少2周一个迭代周期，并且交付有价值的、测试完备的、可工作的系统。团队工作的用户故事（开发特性所需的小块功能）列表来自项目群的产品列表。

没有敏捷团队，就不可能有火车。他们为敏捷发布火车（ART）乃至整个企业提供动力。ART负责提供更大的解决方案价值。火车上的所有团队都与其他团队合作，为“愿景”和“路线图”做出贡献， 并参加ART活动。此外，他们主要负责构建持续交付管道和DevOps功能。

项目群层​

由敏捷团队、主要利益相关者及其他资源组成的一个项目群结构，被称为“敏捷发布火车（ART）”。 敏捷发布火车（ART）是典型的虚拟组织，它包含定义和交付价值所需要的所有人员； 具有定义、实现、测试、部署、发布和操作解决⽅案所需的所有能力(包括：软件、硬件、固件等其他能力)。ART的目的是通过⼀个明确的愿景、路线图和项目群待办事项列表，使管理层、团队和利益相关者向⼀个共同的使命保持协调⼀致。敏捷发布火车交付的是⼀个持续的价值流，如下图长期存在的敏捷发布火车：

在项目群层，敏捷发布火车（ART）采用10-12周为一个发布周期。敏捷发布火车由多个冲刺组成，这一系列冲刺发布一个或多个程序增量（PI）。ART可在每个PI迭代末设置一个特殊的IP冲刺，各团队可以提出PI过程中产生的问题、分析问题产生的原因，提出解决问题的方案，确定是否可放在接下来的PI计划中，以及为接下来的PI进行预计划。

程序增量（PI）提供了⼀个更⼤的、更具有战略意义的PDCA时间盒，用来收集和评估系统级的绩效表现。它还为整列火车的跨领域计划、集成、演示、检视和调整(I&A)提供了节奏。PI的时间盒是固定的。敏捷发布火车上的所有团队都同步相同的PI长度(通常是8 - 12周)，并且有共同的迭代开始/结束⽇期和持续时间。PI最常见的模式是四个开发迭代，加⼀个创新和计划（IP）迭代。

PI是针对ART的，而迭代是针对敏捷团队的。这是⼀个固定的时间段，用于构建和验证整个系统增量，所有敏捷团队保持同一开发进度，每个迭代都必须产出对迭代任务有价值的内容，在较短的周期内防止实现和迭代任务的偏离。一旦发现偏离，可以及时纠正。每个PI将节奏和同步应用于：

1. 方便规划 ；
2. 限制在制品（WIP）；
3. 总结具有价值的反馈；
4. 确保前后⼀致的ART回顾。

价值流层​

价值流层可以应对更大更复杂的产品，一个敏捷火车已经不能满足开发工作，需要多个敏捷火车协同工作，由多个角色、组件和事件来帮组协调和集成各ART。

价值流层的增加是因为产品复杂度的增加造成。它需要完成定义解决方案，生成解决方案。这里的方案是一个高层面的解决方案，比如需要软件A，软件B,第三方软件，硬件系统A，硬件系统B,系统之间如何集成等。

投资组合层​

投资组合层，从价值流的角度来分析史诗级的需求。史诗可以以价值流的角度分解成能力层、产品特性、用户故事等，然后由敏捷团队来实现用户故事。 Choerodon猪齿鱼的大规模敏捷实践。

在Choerodon猪齿鱼大规模敏捷管理中，主要应用了SAFe的团队层和项目群层概念进行大规模敏捷实践。我们将多个敏捷团队组建成一个项目群，由项目群的所有者统一管理并规划。制定开发节奏（迭代周期）、开发内容等，项目群中的任何项目都在同一个节奏上进行，从而提升产品开发交付周期。

如上图，在Choerodon猪齿鱼大规模敏捷管理的PI过程中，首先需要制定PI目标，即各个团队制定他们基本的业务目标，然后就接下来的开发目标达成⼀致。接着需要制定出特性，特性是满足利益相关⽅需要的服务。每个功能均包括收益假设和接受标准，并按需要进行大小调整或拆分，以由单个敏捷发布火车（ART）在程序增量（PI）中交付。当特性使能规划完毕后，就要把制定好的特性-PI，特性-史诗，规划PI关联起来了，并使用项目群公告板查看当前PI的各个子项目/冲刺/特性之间的关联，查看当前PI的各个子项目的冲刺周期，以及各个冲刺所要完成的特性。

以上的这些都可以体现在Choerodon猪齿鱼大规模敏捷管理的看板中，通过移动看板泳道中的特性卡片，来体现团队任务状态的变化，同时体现整个ART所有特性的状态流转。

总 结​

通过上述对 SAFe相关理论的介绍，以及Choerodon猪齿鱼实践经验的分享，大家对SAFe 的概念和实施方式有一个基本的了解。SAFe适用于大型团队的合作开发，帮助团队提高协作性，降低团队管理的复杂性，为Choerodon猪齿鱼大规模敏捷的开发奠定了坚实的理论基础。

参考资料：

• https://www.scaledagileframework.com/

关于猪齿鱼​

Choerodon 猪齿鱼作为全场景效能平台，是基于Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

翻译 | 高钰淋

本文翻译自《From Scrum to Kanban–A Team’s Journey》，以第一人称视角讲述了移动广告公司Marchex的团队Kanban过渡经历，从改变动机，到过渡过程，再到实践经验，希望能给大家带来一些关于团队敏捷实践的启发。

Marchex是一家移动广告技术公司，2014年团队从支持一个已经运行了7年以上的产品转变去开发一个全新产品，当时Scrum实践的效率并不高，想要成功执行sprint计划越来越难，于是公司决定从Scrum转换到Kanban，看看它是否有助于缓解团队在sprint计划中出现的一些问题。

有关Scrum和Kanban的区别，可阅读《Kanban VS Scrum：哪个是最好的敏捷项目管理框架》

Marchex和敏捷

为了使团队的变更最小化，我们在从一个产品过渡到下一个产品时，尽量保持基本的Scrum结构，但事实证明，这个计划并不像我们所希望的那么顺利。

Marchex对敏捷并不陌生，整个产品组织都以某种形式采用了敏捷，不过有些方法上的不同。2014年，在我们过渡到Kanban之前，我的团队看起来像是XP + Scrumban的组合。我们采用了一些标准的XP实践，例如TDD、DailyStandups、结对编程、演示和定期回顾。我们还使用白板通过看板跟踪我们的sprint进度。到了2014年夏天，我们开始采用新的敏捷范例。

向Kanban过渡的动机

不熟悉的领域和技术​

第一个面临的问题是我们的故事定义和故事点的准确性。例如，我们有一组关于创建新服务的故事，其中一个故事被定义为为这个新服务创建一个API。这个故事的接受标准是模糊的，即创建一个客户端应用程序可以用来获取和推送数据的API。一些流程会被归纳在一个状态中，难以准确识别进度，比如团队与内部客户交谈，设计解决方案等，在整个故事中全部属于“处理中”这一状态。再者，我们没有以前的数据比较来帮助我们使用准确地判断故事的大小，所以我们的sprint计划中经常有未完成的故事。因为一个又一个sprint的故事都没有按计划交付，让团队十分受挫，日复一日，周复一周看着同样的故事处于同样的状态，让人感觉陷入了困境。

波动积压​

另一个问题是我们不稳定的任务积压。对于从瀑布式转换到敏捷的团队，一周冲刺似乎是短暂而紧迫的。然而，我们发现在不断发展的新产品开发业务需求中，每周的冲刺时间过长。我们的业务开发团队实时与潜在客户讨论产品，并进行反馈，相应的，我们也必须不断调整产品需求列表的优先级，所以有时感觉我们每天都在改变优先级。

在这种环境下，sprint计划显得过于笨拙，不再适合我们的业务需求。所以在sprint边界的刚性、不断变化的backlog和不断发布特性增强和健壮性的需求之间，需要一个新的范例。

变更需求​

在几次回顾之后，我们发现自己无法完成sprint计划，于是开始寻找如何缓解这些问题的方法。我们将电子Scrum板移到站立空间的一个大白板上，使任务更加显眼。另外，我的团队从一个单独的开发团队(主要是独立工作)变成了三个团队中的一个，3个团队都被要求开发和交付这个新产品。

我采访了一位协作团队的开发人员，问她对Scrum到看板的转变有什么看法。她说她更喜欢看板风格有两个原因：团队只关注待办事项列表中最重要的1或2个故事，当它们完成时，就会转移到下一个故事。第二是她喜欢从积压的故事中挑选最重要的故事，然后完成工作。她还提到，他们团队的过程更容易管理，因为故事范围很小。在与她交谈之后，我确定了团队的正确方向。

不需要改变的事情​

当我们考虑脱离Scrum时，我们坚信有一些实践对团队来说仍然是有效的。众所周知，Scrum是一种组织项目的方法，而XP实践主要是如何开发代码。XP的拥护者经常采用Scrum+XP。同样，我们决定继续使用XP实践，而使用Kanban作为结构：

• 结对编程——2014年团队采用了结对编程方法，我们发现，在采用新的Scala语言和学习搜索范式时，这两种方法是成对的。编程是保持团队生产力的必要条件，我们每天都在会上安排大家组队，尽量一组人一起合作直到完成一个故事。
• 测试驱动开发——几乎所有的新开发都是通过测试驱动开发创建的，我们认为这种实践仍然是开发软件的最佳方式。
• 回顾——这是一个永远不会消失的敏捷标准实践，它是我们持续改进质量的方法。
• 故事点——我们改变了我们的故事点定义，但仍坚持使用点来估计故事的大小。我们会讨论一个故事，就接受标准达成一致，然后通过小组投票分配点数。

过渡过程

我与团队讨论了迁移到Kanban的概念，并组织了一个Lean Coffee (leancoffee.org)风格的会议，以征求反馈并解决团队的关注点。

精益咖啡风格的会议通过要求参与者提交讨论主题，明确地征求每个人的反馈，然后通过分组投票确定优先级。会议中大家认为最大的问题是故事的规模，如果所有的故事都更小、更一致，Kanban将工作得更好。在那次会议之后，我们决定采用以下流程来支持我们的新看板模型：

• 每周一次1小时的会议计划。
• 每周五进行1小时的回顾。
• 如果我们在周中(也就是下周一计划会议之前)故事量开始减少，我们会在每日站立会(daily standup)上做一个小计划。
• 新的故事点“度量参考”：1个故事点=1/2的理想工作日为一对程序员。以前，我们的量表是1个故事点= 一对程序员的理想工作日。这种缩减的规模帮助我们保持我们的故事更小，因为5点故事意味着它应该在大约2.5天内完成，而不是5天。
• 如果在计划过程中，我们给一个故事分配了超过8个点，我们会把它分成2个或更多的故事。
• 每日站会将专注于讨论故事状态，并将它们移动到Kanban上，而不是绕着圈子给出状态。这意味着我们的周期更短，更专注于眼前的任务。这一变化似乎是我们转向Kanban的自然延伸，因为它强调了Kanban对工作和循环的重视，时间更为明显。
• 我们在迭代期间进行结对。我们不一定每天都会改变，尤其是在故事进行到一半时，但我们每天都要讨论到每一对。考虑到我们的团队规模，只花了一两分钟。
• 我们保留了第16分钟的概念——也就是说，如果有人想更深入地讨论某个问题，我们会把它写在白板上，然后把它放在第16分钟的讨论中。在讨论完板上的故事状态和分配对之后，我们在第16分钟讨论项目。
• 团队中每对开发人员的WIP为1，即6名开发人员“开发中”的WIP为3。我们还为“QA”列指定了一个WIP为3。

我们在sprint边界完成了从Scrum到Kanban的过渡，也就是说，我们完成了当前的sprint，在下一次计划会议上，我们创建了一个新的故事点“度量参考”，并开始像Kanban团队一样进行计划。这意味着我们只需要为下周的故事设定范围和计划，因为计划是在周一上午进行的。

对小故事的更改解决了我们现有的一个问题——尚未指定的故事。通过讨论范围较小的故事，我们自然也倾向于收紧接受标准，由于我们的故事是8点(4天)或更少，所以我们以更小的粒度讨论了故事的目标。

例如，与简单地为新服务创建API的故事不同，新故事被分解为更小的故事，如初始化、发布、验证、日志记录和最后定稿。

在为每个较小的故事处理我们的验收标准时，由于范围更小，我们的验收标准在范围和粒度上也变得更加适中。例如，为日志记录的故事创建接受标准变得非常具体，相反，为创建API的故事创建的接受标准的类型要模糊得多。的确，创造更小的故事也意味着创造更多的故事，所以创建一个好的故事层次结构对于确保更大的特性得到充分的实现也非常重要。故事层次结构通常用于在范围更广的故事下组织子故事。更广泛的故事通常被称为“史诗”。使用这种机制，我们可以围绕大量较小范围的故事创建一些顺序。最后我们能够在不到一个小时的时间里轻松地计划一周的工作量，这比我们之前的3h要少很多。

每周的sprint计划会议，有人曾经深情地称之为“伤眼的日子”。不过，公平地说，我们以前的sprint计划会议也包括回顾。现在，我们每个星期五都有一个单独的回顾，把计划和回顾分成两个会议比一个更容易接受。每周会议，我们使用白板开始新的Kanban生活，没有调整列名。

列名分别为：

几周后，我们开始使用电子板来进行我们的测试和计划，方便团队更容易看到backlog。此时，我们在现有的5列的左边增加了4列：

• NEW=新故事
• Bucket =无序积压
• Backlog=优先级列表
• Start =团队认为已经准备好实现的故事，即良好的验收标准和分配好故事点。

过渡非常顺利，在9个月之后，团队仍然对看板范例感到满意。计划更加及时，故事更短，也更容易处理，任何大于8点的故事都必须分解的规则迫使我们将故事保持在小范围内。我们成功从Scrum转向了Kanban。

此外，我们还发现，为范围更小的故事编写接受标准可以更容易地编写更具体的、不那么模糊的接受标准。换句话说，我们的故事定义更加严格。在转换之前和之后，我们从来没有做过关于生产力的A/B比较，但是团队感觉更有生产力，士气也得到了提高，因为我们能够看到每天的进展。此外，我们与项目经理的沟通也得到了改善，因为他对状态变更和完成一个功能需要多长时间有了更好的了解。

持续学习

有几个因素使我们的过渡相当顺利。

经验丰富的团队领导​

在我们从Scrum过渡到Kanban之后，角色变化最大的人是项目经理(扮演Scrum Master的角色)。在整理积压的工作时，他必须至少领先团队一步，考虑团队不断变化的业务需求，有足够好的验收标准来为“Bucket”添加更多的故事，以防处理中的故事在我们下一次站会之前完成。

作为项目经理的另一个挑战是管理转换本身，他指导团队采用新的实践，并帮助督促大家坚持下去。

成熟的敏捷组织​

另一个使我们的转换更加顺畅的因素是组织已经拥有敏捷经验,团队的大多数成员都是经验丰富的敏捷实践者。团队会时常进行回顾，在回顾中我们讨论了当前流程的执行情况，并根据需要进行流程更改。所以一个基本的范例转换对我们来说并不像对一个还没有实践敏捷的组织那样可怕。

看板培训​

在我们向看板过渡的前一年，整个开发组织都通过了由Modus Cooperandi提供的看板培训。了解了精益和看板的概念，如在制品(WIP)、周期时间等。所以当我们的团队开始讨论看板的采用时，我们对一些词汇的含义已经很熟悉。

保持每周的节奏

每周一次的节奏有助于我们构建新的Kanban。我们每周都有回顾，所以如果出现问题，我们可以对我们的流程做一些小的调整。周一计划一周的工作，周五回顾一周的工作，这有助于保持良好的节奏。即使我们取消了冲刺，保持每周的时间表仍然很有意义。

结果

在我们进行了9个月的转换之后，我们在Kanban方面的实践越来越熟练，我们的业务需求仍在频繁地变化，但是团队效率很高，并且持续稳定地发布新功能，同时，JIT（及时）计划也使我们所有的会议都更加高效和富有成效。敏捷有许多不同的实践方法，每个团队有自己的路径，希望我们的经历能对你有用。

关于Choerodon猪齿鱼敏捷管理实践的相关文章，点击蓝字阅读 ▼

• 猪齿鱼敏捷管理实践（一）需求管理
• 猪齿鱼敏捷管理实践（二）冲刺管理
• 猪齿鱼敏捷管理实践（三）敏捷会议

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

作者 | Christopher Lee & Sean D. Mack

如果您曾经对敏捷或DevOps的历史、结构、原则或共性有过疑问，那么您将在这篇文里找到答案，本文被拆分两篇，上篇《使用DevOps强化敏捷（上）》主要介绍敏捷和DevOps的历史、差异和好处，本篇主要介绍敏捷和DevOps的几个共性。

敏捷和DevOps的目标是一致的，因此在实践过程中会发现它们有所重叠。在许多方面，DevOps和敏捷的交叉关系到协作文化以及从这种文化中产生的现代技术实践和过程。

协作文化

敏捷和DevOps之间的核心共性之一是他们都强调打造协作文化。这两种方法都着眼于打破壁垒，增加成员共同责任感。通过打破隔离，DevOps和Agile减少了交接，提高了向客户交付的速度。DevOps将这种协作概念扩展到了运维团队中，而敏捷关注QA是否包含在内。

在敏捷中，我们看到协作文化直接融入到了敏捷宣言的核心原则中。第一个定义“个人和交互重于流程和工具”明显地表达了合作的需要。此外，第三个原则，“客户协作重于合同谈判”，强调需要将这种协作扩展到开发团队之外，也扩展到客户当中。

敏捷教练Susan McIntosh在她的文章《敏捷心态到底是什么》中提到，“敏捷心态是一种支持敏捷工作环境的态度。其中包括尊重、协作、改进和学习反馈、对归属的自豪感、专注于提供价值以及适应变化的能力。这种心态对于培养高绩效团队是必要的，而这些团队反过来又为客户带来了惊人的价值。”

在敏捷中有许多协作的例子，诸如结对编程、Mob编程和Swarming等实践都允许更大的团队合作开发软件，虽然这与开发的原概念相悖（开发原本是指由一个单独的程序员单独完成的任务）。此外，敏捷工作还将QA无缝链接到流程中，作为团队任务的一部分。RonLichty表示：“我将通过Scrum中的产品所有者角色将产品管理集成到团队中。PdMs向开发人员“越过墙”抛出需求的历史由来已久，这与开发人员向测试人员“越过墙”抛出代码的历史没有太大不同！”RonJeffries写了他在极限编程中处理故事的方法。Atlassian建议通过使用单页仪表板缩小PRD（产品需求文档）来保持需求的精简。

DevOps的许多基本概念也是围绕协作的概念构建的。事实上，这个可以追溯到早先反对将开发、运维和QA分割之时。DevOps运动的基础之一，正是人们认识到开发、运维和QA彼此独立会导致利益冲突、增加交接成本。

Thoughtworks的首席科学家Martin Fowler指出协作在DevOps中扮演重要角色，他认为，“DevOps文化的主要特征是增加了开发和运维角色之间的协作……开发和运维之间不应该存在壁垒。”和从一开始就一起工作解决问题相比，切换周期和文档是一个糟糕的替代品。调整资源结构，使运维人员能够尽早参与到团队中来是很有帮助的。

另外，建立协作文化的一个关键方法是在所有参与交付的团队之间制定共同的目标。使开发、运维和QA之间在明确的目标上保持一致，并将重点放在客户需求和最终交付上。

DevOps鼓励协作的另一种方式是将运维活动集成到Sprint中。这可以通过在Sprint中加入运维团队成员来实现，甚至更好的方法是，将运维职责分给所有Sprint团队成员。

除了交付特性和“功能”之外，在高性能的DevOps组织中，通常还向交付产品的团队提供维护这些产品的职责。一旦系统的稳定性得到证明，它就会移交给另一个团队进行维护。其他公司包括开发团队，作为操作问题的寻呼机轮换的一部分。这就产生了共同的责任，并加强了共同的目标和责任。

当然，DevOps不是一份工作，它不是一个角色，也不是任何一个人或团队的责任。DevOps的核心是协作，这与敏捷宣言中的原则保持一致。

小批量、短周期

小批量和短周期是敏捷化的关键。通过减少对系统的更改，敏捷可以更快地为客户带来价值。这种快速部署能带来快速反馈，客户或用户可以快速查看已开发的内容，团队能在必要时快速调整路线。这与瀑布式方法形成了鲜明的对比，在瀑布式方法中，客户可能要等上几个月甚至几年才能看到交付成果，只有到那时才能确定产品是他们所想的还是所要的。DevOps采用小批量的概念，并通过持续集成和持续部署（CI/CD）对其进行扩展。CI/CD提供的工具链加速团队对客户的价值，将周期从几周缩短到几天甚至几小时。

小批量是精益的关键。起源于20世纪30年代的精益为敏捷和开发人员提供了一些核心基础，它专注于消除浪费和减少批量，减少正在处理的工作量，从而减少等待下一个阶段处理的库存量。

这一概念与敏捷的核心原则相呼应，敏捷的核心原则规定“经常交付产品，从几周到几个月，优先选择较短的时间段。”小批量和较短的周期时间有很多好处。根据DonReinersen的说法，为了让产品开发增加价值，结果必然会有不确定性。我们不应该试图最小化失败，而应该接受可变性。我们可以通过有效地学习和高效地生成信息来减少不确定性。VirtualCTO官诺亚•坎特（Noah Cantor）强调了短反馈循环的影响，“有很多学术研究和行业研究表明，反馈周期越长，人们从中学习的知识就越少。反之亦然——反馈周期越短，人们可以从中学习的越多。”

有很多方法可以确保你在敏捷中拥有小批量和较短的周期时间。最基本的方法之一是将用户故事分割成适合迭代的片段。减少故事的规模很多，比如将功能拆分为单个用户故事或任务等。

当划分和拆分用户故事时，重要的是确保您不创建合成型团队，而是坚持使用功能团队。垂直而不是水平地拆分用户故事。也就是说，观察端到端的特性，而不是应用程序的特定层。

小批量和短周期也是DevOps的关键。DevOps的重点是从左到右增加产品流。通过使用精益的工具（如价值流图），可以识别瓶颈并消除它们，从而增加对客户的价值流。

此外，较短的循环时间是DevOps第二和第三种方法的关键。与敏捷一样，更短的周期意味着价值能更快地传递给客户，因此团队可以更快地获得反馈，以便能快速向客户发布特性或更改，并根据反馈快速调整。

DevOps中缩短循环时间和I迭代周期的关键之一是持续集成（CI）和持续部署（CD）。通过持续的集成，一些更改会不断地被合并和验证，从而使整个产品始终具有潜在的可交付性。而持续部署会确保产品始终处于可部署状态，允许随时向客户交付价值。这两个实践采用了敏捷方法中最初引入的快速开发和交付，并将其周期进一步减少到每天甚至每小时。

工作可视化

可视化是DevOps和敏捷中的另一个关键元素。对于像Scrum和看板这样的敏捷实践，通常采用板的形式来共享信息。DevOps利用并进一步扩展了这些方法，来共享系统在某一特定时间内的执行情况，这可以通过大型可视仪表盘和共享仪表盘的形式等展现。

虽然敏捷宣言并没有规定工作可视化的必要性，但是概念是实践的基础。宣言强调“个人和交互重于流程和工具”和“客户协作重于合同谈判”以及“响应变化重于遵循计划”，这三个方面都能通过工作可视化而得到加强。

敏捷促成了“信息辐射源”概念的发展，这是一种位于敏捷开发团队附近的大型图表，能显示整个开发周期的工作进展。Alistair Cockburn在2000年创造了“信息辐射源”这个术语，并在他2001年出版的《敏捷软件开发》一书中做了介绍。

工作可视化能直接暴露出时间的缺漏，以优化工作和流程。通过为团队提供可视化工作的方法，使团队能够一起工作更加方便，这些板还帮助快速识别瓶颈。

DevOps的第二种方法集中于增强反馈和共享操作信息，这是一种很好的方法。这可以包括Scrum板，也可以包括关于系统性能、用户体验以及代码和基础结构性能的实时数据。这些信息图表就像在整个建筑的战略位置张贴的大型监视器。

在DevOps手册中，作者还用了整整一章的篇幅来讨论遥测的问题。他们在他们的“创建遥测技术以发现和解决问题”一章中写道，“我们的目标是将这些信息辐射到组织的其他部门，确保任何想要我们正在运行的任何服务的信息的人都能获得这些信息……使价值流中的每个人都可以实时共享信息和提出观点。”

Etsy是一家以DevOps思想领导能力闻名的工艺电子商务公司，在工作可视化的领域也做了很多工作。“如果Etsy的工程有宗教信仰，那就是图形教会。”Patrick McDonnell在DevOps手册中谈到了监控部署数据的好处，他说：“通过这样做，我们可以更快地看到任何意外的部署副作用。我们甚至开始在办公室周围安装电视屏幕，以便每个人都能看到我们的服务表现。”

持续学习

敏捷和开发人员的核心原则中都有持续学习。在敏捷中，这个概念是敏捷宣言的一部分，在DevOps中，它是DevOps的第三种方法的一部分。

敏捷宣言强调“响应变化而不是遵循计划”，因此，它构建了一个强调适应需求的原则。在这种适应性中，假设团队不断的反思和改进，在持续的敏捷短周期中，团队便能够审查事情的进展情况，并对他们交付的产品和交付过程进行快速调整。此外，“客户协作重于合同谈判”的宣言宗旨意味着严格的反馈循环、倾听和从客户反馈中学习。在敏捷中，产品团队可以快速地向客户交付功能，并快速地从实际反馈中学习和快速调整。

DevOps也强调持续学习，其第三种方法便聚焦于此。在IT革命网站上，Kim写道：“DevOps第三种方法是创造一种能促进两件事的文化：一是持续实践、冒险和从失败中学习；二是理解重复和实践是精通某件事的先决条件。”

同时，敏捷和DevOps都把不断学习和不断实验的精神付诸实践。在Scrum中，有被置于流程中的回顾会，用以确保团队花时间对每一次迭代进行反思、从错误中学习并总结成功的经验。回顾会是团队对前一次迭代进行反思并寻找改进的会议，小组成员会讨论哪些进展顺利，哪些进展不顺利，并列举需要改进的方面。

Sprint演示是敏捷流程中持续学习的另一个很好的例子。许多敏捷团队会在每次迭代结束时对Sprint可交付成果进行演示，这样可以让团队成员互相学习，更好地理解产品的所有部分。Sprint演示中还能加入项目涉众的快速反馈，为团队提供了一个互提意见和互相学习的机会，帮助大家继续成长。

在DevOps中，不断学习和不断实验的精神通过事故事后分析等行为得到了强调。JohnAllspaw帮助推出了事后无指责概念，之后这成为了现在DevOps实践的一个共识。他在博客中写道：“事后总结最重要的事情不是一系列可以采取的行动，而是组织学习。”

在Etsy，员工不仅毫无责备地看待事件，甚至还庆祝失败。庆祝失败的原因之一是犯错误的人实际上是最好的工程师，这些人是那些为企业做出最大改变和推动创新的人。因此，重要的不仅仅是限制责备，实际上还灌输了一种文化习惯，这种习惯将庆祝失败视为学习的机会。Etsy的CTO每年会颁发一个很有声望的奖项，以庆祝今年最大的失败。DevOps通过灌输诸如无指责事后分析和失败庆祝等习惯来鼓励一种开放讨论失败并不断学习和成长的文化。

『由于篇幅原因，本文被拆分两篇，上篇主要介绍敏捷和DevOps的历史、差异和好处，点击蓝字即可阅读《使用DevOps强化敏捷（上）》。』

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

作者 | Christopher Lee & Sean D. Mack

译者 | 温馨

如果您曾经对敏捷或DevOps的历史、结构、原则或好处有过疑问，那么您将在这篇文里找到答案，本文被拆分两篇，上篇主要介绍敏捷和DevOps的历史、差异和好处。

敏捷和DevOps从表面上看可能是不同的，但如果关注他们的目标，会发现它们其实非常相似。两者的目标都是更快地为客户创造价值并更快地改变市场需求。DevOps采用敏捷中介绍的原则，并将其扩展使用到代码以外的部署和运维操作中。

敏捷和DevOps的目标是一致的，因此在实践过程中会发现它们有所重叠。在许多方面，DevOps和敏捷的交叉关系到协作文化以及从这种文化中产生的现代技术实践和过程。连续测试和小批量生产等过程中更容易看到了这一点，在使工作尽量可见化的过程中，公开工作流和系统遥测，有助于确保向客户快速交付工作产品，能加速向客户传递价值。

敏捷和DevOps专注于提供客户价值，这不是为了提供更多功能，而是为了尽可能快速有效地向最终客户提供正确的增值功能。DevOps使用敏捷的概念并对其进行了扩展延伸，因此您可以通过实现DevOps实践来增强敏捷性。

什么是DevOps？什么是敏捷？

在开始研究DevOps和敏捷之间的关系之前，首先要对这些术语的含义有一个共同的理解。虽然有许多定义，但它们可以从根本上理解为一套原则，从中可以衍生出工程师文化和实践。

敏捷的存在时间比DevOps长，定义也更为成熟。首次定义于2001年2月的《敏捷宣言》，该宣言包含了以下几条定义：

• 个人和交互重于流程和工具
• 工作软件重于公共文档
• 与客户协作重于合同谈判
• 响应变化胜过遵循计划

尽管已经有了对DevOps宣言的尝试，但还没有哪一个宣言能够获得敏捷宣言所具有的那种广泛接受度。作为一个一般概念，DevOps重视协作，特别关注开发和运营团队之间的交叉功能以及这两个方面的责任。敏捷教练Anthony Gardiner说，“我测试，我编码，我部署，我在周末起床并修复错误——我让我的代码更好，所以我不必在周末起床。”DevOps可以被认为是一种为客户提供价值的方法，专注于协作和小批量，聚焦持续集成，自动化，持续测试和持续交付。

虽然没有单一的定义，Gene Kim、Kevin Behr和George Spafford在他们的开创性书籍《凤凰计划》中介绍了DevOps的“三种方法”。这三种方法是许多DevOps实践的核心。

Kim后来在《DevOps Handbook》中对这些方法进行了扩展，他与Jez Humble和Patrick Debois合著了这本手册。

这三种方法包括：

历史

追溯到20世纪90年代，敏捷已存在的时间比DevOps长得多，后者在将近20年后才出现。然而，这两套原则都源于精益制造，其历史可以追溯到20世纪40年代。虽然DevOps的流行度持续增长，但敏捷仍然比DevOps更广为人知。谷歌趋势表示“敏捷”一词的搜索量大约是“DevOps”一词的三倍。

敏捷的根源可以追溯到20世纪40年代的精益流程，其中包括看板，一种可视化丰田生产系统一部分工作流程的方法。限制理论也是后来发展起来的。然而，敏捷的软件开发方法在20世纪90年代真正起步，当时一群软件开发人员常受到瀑布式开发方法中涉及的高度严格的流程的困扰。这些常导致软件项目花费了数月甚至数年才导致失败。在20世纪80年代和90年代，诞生了几种软件迭代开发方法作为瀑布方法的替代，包括极限编程（XP）和看板。1995年，引入了敏捷开发的Scrum实践。然后，在2001年Snowbird山度假村的著名会议上，一群思想领袖齐聚一堂，共同编写敏捷宣言。敏捷发展至今，其中许多变化和实践都是从最初的宣言演变而来的，包括现代敏捷。虽然敏捷制定了总体原则，但实践敏捷原则的方法有很多，Scrum和看板是最受欢迎的两种（关于它们的区别，可阅读《Kanban VS Scrum：哪个是最好的敏捷项目管理框架》）。

DevOps是一套更为新的原则，它源于精益制造中的一些相同概念。“DevOps”一词于2009年首次推出，当时Patrick Debois在比利时举办了“Devopsdays”活动。2013年，Gene Kim（作者），Kevin Behr（作者）和George Spafford（作者）撰写了他们的书《凤凰计划》，其中提出的许多内容构成了DevOps的基础概念。2014年，随着DevOps企业峰会的启动，DevOps不断扩展到企业环境中。今天，DevOps继续与敏捷一起成长和发展。

关键差异

虽然敏捷和DevOps具有很多一致性，但需要注意的是它们的侧重点不同。敏捷主要关注应用程序的构建，而DevOps则将这一重点扩展到构建和运营应用程序。DevOps采用了敏捷的许多概念，并将这些概念扩展到构建过程之外并带入生产。正是这个扩展导致了真正的差异。

如果说存在不同，那么主要在于聚焦点的不同。敏捷教练Martin Corbett表示，“敏捷专注于分解工作，以尽快为客户提供更多价值，而DevOps专注于将代码从构建扩展到部署的项目，例如持续部署。”此外，敏捷专注于构建工作软件以及开发和QA之间的协作，而DevOps则专注于开发、QA和运营之间的协作。

虽然许多人都在寻找敏捷与DevOps之间的差异，但实际情况是，这两种方法具有非常相似的目标和基础原则，并且最终具有比差异更多的相似性。

DevOps是敏捷的延伸

在许多方面，DevOps可以被视为敏捷的延伸，甚至是敏捷的自然演变。在瀑布开发流程中，有一个明确的交接（它是强制执行的过程）。敏捷作为一个持续的过程，需要一种新的方法，DevOps有助于实现这种方法。

为了实现精益和敏捷最佳实践的核心小批量发布，在DevOps中普及的全栈工程师的概念是这种需求的最佳答案。为了减少交接，工程师必须悉知系统的所有部分，以便团队中的任何成员都能理解操作要求，而无需交付给其他团队。同样，跨职能团队必须成为常态，以便小型，独立的团队可以提供功能齐全的产品，而无需向运营团队进行额外的交接。

此外，敏捷的持续流程需要一定程度的构建和部署自动化。其中大部分都是在DevOps的CI / CD实践和工具中提供的。CI / CD需要快速部署经过全面测试并且功能齐全的代码给客户。因此，很容易看出CI /CD是敏捷实践所必需的自然演化。这些做法持续发展，使发布周期时间进一步缩短，从数周到数天甚至数小时。

从另一个角度考虑，如果您有一个只有在开发完成后才能开始的为期两周的QA周期，那么在一两周内就很难将代码推出。同样，诸如变更审批、释放资源、硬件购买和安装等需要耗费时间的事情，都会影响你按时推出代码。更不用说，您可能还有很多的交接工作，或者有一个周期长又繁重的发布过程。如何进行为期两周的迭代并进行为期两个月的发布过程？对此的明显答案是DevOps。

这并不是说没有DevOps就无法实现敏捷。敏捷在DevOps之前很久就存在，并且肯定有敏捷团队不遵循许多DevOps实践。正如Noah Cantor所说，“你可以做敏捷实践和DevOps实践，但你不能采用敏捷原则或DevOps原则，因为它们太相似而不能分开。”并不是说它们不可分割，只是敏捷作为DevOps的前身，同时激发了DevOps的影响力。

好处

精益一直是DevOps的核心，就像敏捷是从精益中生长出来的一样。DevOps也是如此，所以这两者有很大的共同点并不奇怪。DevOps采用Agile中的概念，并将其扩展到代码部署之外。DevOps采用这些概念并将其应用于应用程序和服务的管理。它利用并优化了敏捷的原则，并且沿用了敏捷组织早已意识到的长处。

并不是说为DevOps而做DevOps，或者说为敏捷而做DevOps。2017年DevOps状态报告显示，高性能DevOps团队的部署速度提高了46倍，交付时间缩短了44倍，更改失败率降低了5倍，平均恢复时间缩短了96倍（MTTR）。在具有成熟DevOps实践的组织中，这些数字显然被低估了。

当我们查看敏捷和DevOps重叠的每个区域时，DevOps放大了敏捷实践，我们希望您能够采取一些具体措施来推动组织的发展。构建协作的最关键步骤之一是制定共同目标。有了共同的目标，您可以确保开发，运营，QA都一致朝着同一目标努力。

小批量交付为推动DevOps实践加速组织提供了另一个绝佳机会。在Scrum或看板等流程中，要将操作任务和操作思想集成到工作中。如果您正在使用Scrum，您也可以考虑使用看板，它更容易适应操作流程。

无论使用哪种方法进行小批量交付，您都可能希望确保使用相同的系统来跟踪整个团队的工作。通过统一跟踪系统，您可以确保不积压工作，并真实反应所有计划内和计划外工作，让您更容易地使工作可见。作为敏捷的一个关键原则，我们还可以扩展使工作可见的概念，以显示运营工作、系统操作和架构支持等工作。组织还可以通过信息辐射体（比如看板）跨团队分享这些信息。

当您着眼于构建更具协作性的文化时，要把每一次失败都当作组织学习的机会。在这个文化中建立一些仪式，比如无可指责的事后反思、黑客马拉松和失败奖励等。

对于本文中讨论的重叠，存在组织上的含义。在敏捷和DevOps中包含QA意味着我们必须开始构建跨职能团队，并培养具有广泛知识技能的人员。这种重叠是随着“全堆栈工程师”的概念而发展起来的。虽然每个人都知道一切可能不现实，但我们当然可以努力确保团队中的每个人都有共同的责任和目标，包括质量和运营，如果他们乐于负责和学习的话。

有许多方式可以采用敏捷原则并使用DevOps强化它们，但最重要的是组织文化的一致性。如果团队在目标上没有保持一致，那么敏捷中规定的团队方法将不能扩展到部署以外的操作中使用。如果所有技术交付团队都遵循相同的目标，即可立即开始打破这些组织之间的孤岛。如果我们可以通过敏捷开始打破组织孤岛并通过DevOps强化这项工作，我们将拥有真正的高性能组织。

『由于篇幅原因，本文被拆分两篇，下一篇主要将介绍DevOps和敏捷之间的几个共性，欢迎大家持续关注。』

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

在上一篇关于自动化测试的文章 解密敏捷自动化测试 中，为大家介绍了敏捷自动化测试，以及 Choerodon 猪齿鱼自动化测试的落地。在这篇文章中，给大家介绍一下 Choerodon 自动化测试的技术方案的设计思路以及实现。

为什么自动化测试需新建测试应用​

自动化测试的本质是使用一些测试框架开发测试代码，运行测试代码即对已有的业务应用进行相应的测试。对于一个项目来说，测试应用与普通的业务应用应该是同等重要的。

从代码开发上来说，一个自动化测试应用的代码量可能比一般的业务应用要大，多人协作开发也是目前自动化测试的大趋势，所以代码托管可以更好地进行测试代码开发与维护。

之前有用户来咨询，在测试应用与业务应用的对应关系上是如何落地实践的。是否需要每个业务应用都需要对应一个测试应用。猪齿鱼平台本身是基于微服务架构进行开发的，它有很多的后端服务，但这些中有一些的耦合度是比较高的。所以在开发人员的测试实践过程中，并没有针对每个应用一一对应建立测试应用，而是基于大的功能模块进行拆分。比如敏捷管理模块有一个 mocha 框架的测试应用，测试管理模块也有一个。像这样基于大功能模块的拆分免去了很多 feign 内部调用重复测试的冗余测试代码，且易于进行测试代码开发的任务分配。

为什么自动化测试应用要执行 GitLab CI​

在 Choerodon 的 DevOps 模块控制下，当一个应用提交代码后触发一次 GitLab CI，就会为这个应用生成一个版本号，并打出可以部署运行的镜像、Chart 包，对于测试类型的应用也是如此。Choerodon 的自动化测试运行也是基于 helm 进行的部署操作，对应的，也需要对于代码进行构建打包。

并且，测试管理模块对于自动化测试用例的回扫功能是基于测试报告文件以及代码注释进行的（这部分在本文最后章节会进行展开介绍）。对测试代码进行版本控制也就意味着对测试用例进行了版本控制。在一个测试应用可能被定时、反复运行的场景下，如果能保证已有测试用例的时效性并且加以复用就可以最大程度上减少冗余数据的产生。Git 的版本控制刚好就可以保证相同版本下的代码一致性。

Choerodon 提供的模板有什么特别之处​

Choerodon 平台现在提供了三个测试应用的模板，分别是 mocha+chai，TestNG+Assured，TestNG+Selenium。

这些测试模板都对于 helm chart，Dockerfile，gitlabci 等进行了加工，并在其中封装了简单的 demo 代码，例如登录接口测试的简单实现。通过 demo 代码可以快速上手进行测试代码的开发。

并且为了方便对“测试数据”，“预期结果”这两个测试步骤的字段进行维护，我们对官方提供的可以在测试报告中加注释的方法进行了封装并进行数据提取，可以满足步骤信息的维护需求。

这其中 TestNG+Selenium 的模板通过对于官方镜像的修改，支持了在部署过程中独立启动 chrome-standalone 浏览器核心。猪齿鱼基于官方 chrome-standalone 镜像的基础上加入了 servlet 的生命周期管理，可以通过接口调用的形式对浏览器核心的进程进行管理。在 TestNG+Selenium 的应用部署时，一个 pod 对象中存在两个 containers 对象，其中一个是 WebDriver 浏览器核心，一个是我们的 TestNG 应用。后者基于 pod 中的内网进行浏览器核心调用，并在 Dockerfile 的最后通过 curl 结束 WebDriver 的生命周期。这样就省去了 Selenium 框架对于外部浏览器核心的依赖需求。

如下图所示：

拉取模型 OR 推送模型​

在 Choerodon 如何运行自动化测试这个问题的选型初期，使用推送模式还是拉取模式一直是一个比较纠结的问题。团队研究过 GitLab CI、qTest 等平台的部署运行方案并进行了参考，而他们的定位、出发点和猪齿鱼平台又不尽相同。

例如在 GitLab 中他们的方案是单独部署 runner，即需要部署一个 agent 主动进行任务拉取然后调度执行返回结果。而这样的方案无疑会增加部署的成本，就像我们自己搭建一个 GitLab 一样，搭建好了并没有 runner 节点可以直接使用，而是需要额外进行 runner 的搭建与注册到 GitLab 平台的操作。这样提高搭建成本的操作对于本身搭建要求已经较高的猪齿鱼平台来讲并不是非常友好。

所以猪齿鱼选型的最终结果是使用推送模式进行自动化任务的处理。用户在激活自动化测试运行的时候由测试管理模块后端发送请求至 DevOps 模块后端，然后通过 WebSocket 连接 agent 进行任务调度。并将自动化测试功能集成在现有的集群 agent 上，可供用户选择运行自动化测试的环境即为环境流水线中注册的环境。从而减少平台的组件数，并且降低搭建的成本。

测试结果是如何进行回扫的​

Choerodon 测试管理模块对于自动化测试结果的处理是在测试应用的 Dockerfile 中通过 curl 访问测试管理模块的接口，将测试报告打包并回传测。在接收到文件后并将其保存加以解析从而导入到测试用例、测试执行中的。

例如 TestNG 框架，将 Suite 级别对应成一个用例文件夹，那在一个 Suite 中的 Java 类即为一个测试用例，这个类中的方法就是这个用例的测试步骤。并且解析 ReporterUtil 类中打印在 xml 报告中的日志对结果、预期字段进行填充，就完成了测试用例的扫回。

在有了测试用例之后就为其新建测试阶段，然后按照测试报告的结果进行测试执行状态的更新。如有报错日志等信息都会维护在对应步骤的注释字段中。

测试结果扫回逻辑如下图：

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

作者 | Rebecca Pruess

编译 | 毛智伟

随着 DevOps 理念的普及与扩散，大家经常会看到持续集成（Continuous Integration）与持续交付（Continuous Delivery）这样的字眼，而怎样使用与选择这些方法成了大多数 IT 团队必须面对的问题。在讨论更加深入地讨论问题之前，首先需要清楚这两者之间的主要区别是什么，以及用什么方法可以更好改善工作流程，从而在更短的时间内为目标用户提供更高质量的软件。

持续集成（CI）和持续交付（CD）都体现了如今快节奏市场中的文化和发展原则，旨在缩短开发周期、提高软件交付效率以及实现全流程的自动化。同时，两者都有着共同的目标：让软件开发更少地依赖于手动执行的任务，在此基础上使得软件的发布更加频繁、更加安全可靠。由于有着相同的目标，因此持续集成和持续交付并非相互排斥的。只是它们的应用范围有所不同。

那下面就来看下 CI 与 CD 之间的联系与区别。

什么是持续集成​

如上所述，CI 和 CD 是相互关联的。持续集成是指软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。由此可见，CI 专注于定期地让开发人员构建小批量的代码。而对于更新或新增的代码，它们会被上传至统一的代码库，执行自动构建与自动化测试的步骤。 频繁地向主干提交代码，意味着可以针对整个软件执行所有的自动化测试，并且在应用或接口的某个部分出现问题时，及时收到告警信息。

由于合并问题能被及时发现，因此也能被及时解决。此外，由于测试过程采用的是自动化测试，因此最终的主干分支一直处于可发布的状态。而这对传统的瀑布式的开发流程来说就很棘手。遵循 CI 中定义的原则，有助于进一步提高代码的可测试性和可部署性。通过将代码保持在可部署状态，就能避免在项目后期才进行单独的测试和 Bug 的修复，由此使得开发人员避开了“集成地狱”。而这也是 Choerodon 猪齿鱼开发流水线模块的主要目的。

什么是持续交付​

持续集成包含了构建与自动化测试的阶段，而持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的“类生产环境”之中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。此外，持续交付同样遵循一个小型的构建周期，可以将一小批代码推送到多个环境：开发，测试或生产。

在此过程中，它结合了持续集成和持续部署的实践（即：让主干始终处于可部署状态）。而在 Choerodon 猪齿鱼平台中，当提交的代码完成以上步骤后，可以在“部署流水线-流水线管理”中创建对应的 CD 流水线将持续集成后产生的应用版本自动部署到对应的环境中去。此外，对于部署到正式环境的代码，可以在流水线中间添加一个人工卡点任务，只有通过人工审核后，才能执行后续的自动部署任务。

理论上来说，CD 使得 IT 团队可以每天发布与更新应用程序，但大多数 IT 团队选择每月或每两个月发布更完整的更新。

持续集成与持续交付的区别​

CI 和 CD 之间的区别在于使用的范围和主要的受益者。

（1）持续集成​

持续集成对于加快编码和构建阶段的软件交付过程至关重要。因此，它的目标对象主要是开发人员，特别是那些处在复杂组织架构中的开发人员。通过自动构建和测试的流程，将对软件做的所有更改都集成到统一的代码库中，而无需进行手动任务。此外，由于 CI 是一个持续的过程，因此开发人员可以即时得到问题的反馈。他们可以实时获取到相关错误的信息，以便快速地定位与解决问题。显然这个过程可以大大地提高开发人员以及整个 IT 团队的工作效率。

（2）持续交付​

持续交付涵盖了软件交付生命周期的绝大部分，能为目标用户和客户带来重大利益。CD 中包含了自动构建，打包，部署与测试的流程，以此来减少手动任务并加快软件交付速度。小批量的代码成功完成整个流程的每个阶段后，目标用户或客户便能在类生产环境中进行验收。因此目标用户可以在几天或几周内就收到修复后的功能与新增的功能，而无需等待数月后才更新。

CD 的部署频率也加快了整个流程中的反馈循环。最新版本真的解决了预期的问题吗？是否满足了用户的需求？在此用户就可以快速地验收并作出判断，而 IT 团队也可以在问题影响到开发周期之前就解决反馈的问题。持续的反馈循环使得用户与 IT 团队更紧密地合作，以确保能准确的理解与满足他们的需求。整个交付过程进度可视化，方便团队人员与客户了解项目的进度。

在当前快节奏的市场中，这无疑是一个重大的优势。当您将软件更快地推向市场时，您将获得更大的竞争优势。

CI 或 CD 适合您的业务场景吗​

持续集成可确保代码库中始终保持最新的代码，同时可以快速集成来自多个开发人员的代码，并确保这些代码可在多个环境中协同工作。它通常有助于减少错误并通过自动化流程来减少手动任务。CI 可以实现代码的自动构建与测试，减少开发中的 Bug。因此，CI 适用于那些过度依赖手动任务和复杂构建过程的企业。

持续交付适用于需要缩短开发周期，更快地为目标用户提供软件的企业。CD 降低了部署新软件或升级已有软件的难度，且实现了全流程的自动化，因此您的团队无需手动执行复杂繁琐的任务，从而加快反馈速度，来确保您增加的功能真正地满足用户的需求。

总而言之，CI 和 CD 是相互补充的。CI 的统一代码库和自动化测试的方法可用于支持 CD 中更大规模的自动化和更频繁的部署。因此将 CI 和 CD 结合到您开发与交付的流程中，会使您的 IT 团队更加敏捷，更加快速地开发。

目前，大多数 CI / CD 的工具采用的方法都大同小异。 而一般的 DevOps 工具通常都会支持 CI 和 CD 方法，相应地还会提供相关的自动化测试框架。Choerodon 猪齿鱼平台中的 DevOps 模块便是结合了 CI 与 CD 的方法，并在此基础上实现了测试与部署的自动化。用户需要根据自己的实质需求来创建 CD 流水线，以此来实现不同环境不同版本类型的自动化部署；当然，您还可以在其中设置人工卡点任务，使得 CD 流水线随时处于人工的监控之下。

此外，也有不少人认为 CI 是 CD 的前提与基础，没有 CI 就不能实现 CD。这种说法也是比较流行的，其思路如下图。因此，不管是哪种说法，CI 与 CD 都是 DevOps 工具中不可或缺的理念与方法。

原文地址： https://dzone.com/articles/continuous-integration-vs-continuous-delivery

更多 Choerodon 猪齿鱼持续交付相关文章 ▼

• Choerodon 猪齿鱼实践之持续交付中的分支管理与版本控制

• GitOps | 一种云原生的持续交付模型

• Choerodon 猪齿鱼 Agent——基于 GitOps 的云原生持续交付模型

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

什么是猪齿鱼

Choerodon 猪齿鱼 是一个全场景效能平台，是基于 Kubernetes，Istio，knative，Gitlab，Spring Cloud 来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps 等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

公开课有什么？

本次使用培训公开课直播将讲解 Choerodon 猪齿鱼的几大核心功能的使用，详情如下:

5 月 27 日​

Choerodon 猪齿鱼敏捷管理​

1. 敏捷理论的概要介绍
2. 需求的收集及记录
3. 迭代的规划
4. 迭代的执行
5. 数据查看及分析

Choerodon 猪齿鱼大规模敏捷​

1. 项目群管理的使用场景
2. 什么是敏捷发布火车
3. PI 的规划以及目标
4. 项目群与各团队之间的项目协作

5 月 28 日​

Choerodon 猪齿鱼持续交付​

1. Choerodon 猪齿鱼 DevOps 方法讲解
2. Choerodon 猪齿鱼 DevOps 架构讲解
3. Choerodon 猪齿鱼 DevOps 功能演示

5 月 29 日​

Choerodon 猪齿鱼测试管理​

1. 测试用例维护
2. 测试计划
3. 执行测试
4. 测试报表分析
5. 自动化测试

直播平台​

IT 大咖说（搜索 Choerodon 猪齿鱼收藏直播间）

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/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 猪齿鱼是一个全场景效能平台，基于 Kubernetes 的容器编排和管理能力，整合 DevOps 工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台，同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

“我们使用敏捷开发。”在与软件开发团队交流时，你会听到很多这样的说法。根据统计，2018年全球约有90％的开发人员在使用敏捷开发。Choerodon猪齿鱼团队也是其中之一。

但是，敏捷并不统一。作为组织工作流程的一般方法，敏捷软件开发设定了共同的价值观和原则，旨在精简开发流程，敏捷有效地响应变化。这些价值观和原则可以在敏捷宣言中找到，当中就提供了一些建立开发流程的建议。

在实际应用中，几种软件开发框架已经体现了这些敏捷原则。其中Kanban 和 Scrum是最受欢迎和经常使用的。这两种方法都有一个共同的目标，即创建一个有效的工作流程。今天这篇文将围绕他们之间的差异进行讨论。

Scrum和Kanban的基础知识

在深入研究Scrum和Kanban之间的差异之前，先看一下两个框架的主要概念，以便之后可以更轻松地进行Kanban与Scrum的比较。虽然它们都旨在建立一个自组织团队的流动，但是有些方法不同。

▌Scrum是什么？

Scrum的名字来自橄榄球术语，表示“争球”的动作。在软件开发中，Scrum是指采取组织团队合作的方法，以便更高效地开发复杂的软件产品。

Scrum基于开发团队在开始时不知道项目的结果这个假设，他们会随着工作的进展不断学习和适应。Scrum旨在通过每次迭代开始时重置优先级来简化这种适应，这在Scrum术语中称为“Sprint”。

在这里，大家来看一个Scrum的核心概念——冲刺（Sprint），冲刺是用2到4周的时间来完成一定量的工作。Sprint有助于将项目范围分解为更容易管理的任务，并更频繁地交付组件正常运行的软件。

在冲刺阶段，开发团队只需专注于每个sprint中应完成的任务，这为项目规划阶段提供了极大的灵活性。新冲刺开始时，开发团队会重新规划本次冲刺的任务，规划时需要考虑到上个冲刺任务的完成情况以及项目的新需求。

▌Kanban是什么？

Kanban最先由Toyota 提出，旨在优化其工厂库存。在日语中，“Kanban”是指板或卡。在最初的应用中，一个库存越来越少的工厂部门会向仓库发送“Kanban”来请求补货。然后，仓库将“Kanban”发送给供应商以订购更多库存。

从这个例子中，大家可以看到Kanban专注于当前容量，这也是用在软件开发的主要概念。与Scrum不同，Kanban没有时间限制，相反，它限制了可以同时执行的工作量。

看板的主要指标之一是“正在进行的工作” 。Kanban表示，为了实现最高效率，正在进行的工作应进行限制以与团队的能力相匹配，从而降低任何出现瓶颈的风险。

看板也能很好地响应变化，因为可以在项目的任何阶段进行更改并添加到要执行的任务列表中。

Choerodon猪齿鱼团队就是使用敏捷Kanban方法来提升交付效率，具体如何使用可参考Choerodon猪齿鱼博客文章：猪齿鱼团队如何使用敏捷Kanban方法提升交付效率

Scrum与Kanban的主要区别

如果想比较Scrum和Kanban，大家需要看两个框架组织工作流的方式以及它们使用的主要实例和定义。

角色​

角色的分配是Scrum和Kanban之间的第一个重大区别。在Scrum中，团队主要分三个角色：

• 产品负责人：负责产品的人。产品负责人分析客户对产品的需求，并将其转化为团队的任务。产品负责人还确定任务的优先级，并决定何时可以发布特定的功能组件。

• Scrum Master：负责Scrum过程的人。首先，Scrum Masters将Scrum原则引入其团队成员并协助他们实施。此外，Scrum Masters管理冲刺所需的人力资源分配。

• 开发团队：负责实际开发工作的人。由具备自我管理能力的人组成的跨职能团队。

反过来，Kanban对团队角色没有严格的要求，可能有一个产品负责人监督项目中积压的任务，但除此之外，团队是自组织的。

工作流程​

正如上文提到的，Scrum开发在迭代中进行，定义了每次迭代中要完成的工作，而Kanban旨在限制当前正在进行的工作，没有特定的时间限制。下面列出这两种方法在实际应用中的含义。

▌Scrum流程

项目规划从定义项目待办事项开始，即为了交付产品而需要完成的用户故事列表。在这种情况下，Scrum使用以下主要概念来帮助使用者理解工作的计划和分配方式：

Product backlog：代表团队的主要“待办事项”列表。Product Backlog包括项目中需要完成的所有功能和bug修复。待办事项列表根据新需求或检测到的错误而不断更新。产品负责人负责Product backlog的工作，以便客户的反馈和建议与团队的工作进度保持同步。Product backlog的一些任务可以根据优先级排序，一些可以在需求改变时添加，一些可以删除。

Sprint backlog：要在冲刺中完成的任务清单。Sprint backlog的任务需要在sprint结束时交付已完成的功能或组件。虽然sprint backlog也允许一定的灵活性和修改，但sprint的目标应该保持不变，并且应该将更改保持在最低限度。

increment：sprint结束后可交付的可用产品。通常，sprint以已完成的功能或组件的演示为结束。在这方面，一个重要的概念是“完成”，它指的是每个用户故事都要考虑其完整性。“完成”的定义可能根据用户故事而有所不同：它可能包括多个任务，例如开发，测试，设计，文档和演示，也可能涉及不同的团队成员。

每个sprint都从规划阶段开始，在该阶段中计划下一个sprint的任务。对于规划，通常会有整个团队，包括产品负责人和Scrum Master在场。团队决定在sprint结束时他们可以提供什么，并从Product backlog中选择相应的用户故事。这样就形成了Sprint backlog 。

在冲刺期间，团队每天会开“daily scrum”（即每日站立会议），讨论他们的进展以及他们可能遇到的问题。站立会议的目的是尽早发现问题并快速找到解决方案，以免破坏冲刺流程。

在冲刺之后，利益相关者将审查完成的功能。在sprint review期间 ，团队有机会收到有关其工作的反馈或变更建议。

与此同时，团队进行sprint retrospective meeting（回顾会议），分析他们所完成的冲刺并找到需要改进的问题。回顾之后，重置过程，新的sprint从规划阶段开始。

▌Kanban流程

在Kanban中，没有规定时间段来完成一定量的工作，相反，Kanban专注于平衡团队的能力与当前正在进行的工作。

Kanban流程从待办事项清单开始，包括应该完成的所有任务。每个团队成员从待办事项中领取一个任务，并专注于完成它。任务完成后，成员选择下一个，依此类推，直到待办事项完成为止。待办事项按照优先级排序，最紧急的任务放在最顶层，由团队优先选择。

在Kanban中， 项目期间正在进行的工作量不超过团队的能力这点至关重要 。即kanban中的限制在制品原则。出于这个目的，可以根据成员工作能力为任何类型的工作设置限制。

产品负责人可以根据需要尽可能多地设置和更改待办事项中的优先级，因为backlog management对团队的绩效没有影响。团队只需要关心正在进行的工作，只有在当前任务完成后才返回待办事项。

每项任务都沿着“待办事项” - “正在进行的工作” - “完成”路线行进。当然，Kanban也支持“完成”概念（即每个任务被接受的标准）的自定义。

最终，完成的任务形成完成的组件，可以计算交付它们所需的时间。在Kanban中，它被称为 “cycle time”，周期的计算能提供许多优化点。当然，所有团队都在努力缩短周期，并寻找解决瓶颈的方法（如果有的话）。

在Choerodon猪齿鱼中，可对任务进行故事点与时间的评估，并在燃尽图中能很好的看到迭代工作时间的预期值与剩余值。

在这种情况下，让团队成员具有重叠技能至关重要。如果只有一个人拥有某种技能，例如如果你只有一个测试人员，那就是瓶颈，所有测试任务将排队等待产品交付过程中的延迟。

总而言之，Scrum目标是在指定时间内完成预定工作，而Kanban监控以确保正在进行的工作永远不会超过设定限制。

选择哪一个？

如果您一直在等待这个问题的确定答案，答案可能会让您失望。到目前为止，本文列出这两种方法都有其优点，并且两者都有助于建立敏捷开发流程。下面将提供了一些指南，可以帮助您选择最适合您团队的方法。

使用Scrum：

• 你可以相对轻松地将工作范围划分为可在两周内完成的逻辑块。
• 你需要对整个项目具有高度的可预测性。Scrum专注于将sprint中的更改保持在最低限度。
• 团队中有很多新成员。使用Scrum，他们将更容易理解团队纪律并进行改进。

使用Kanban：

• 你希望项目中有很多频繁的更改。
• 很难离析出可在两周内交付的产品组件。
• 你的团队训练有素，可以信任地在没有严格截止日期的情况下安排他们的活动。

然而，好消息是你可以随时结合！甚至还有一种名为 Scrumban 的方法，其中包含了Scrum和Kanban的方法。在Scrumban，你可以在短期迭代中完成工作，并将进行中的任务数量保持在一定限度内，一旦进行中的任务低于限度时会触发新的迭代。

如你所见，选择项目管理方法可以像你希望的那样灵活和自由。没有固定规则，您可以根据自己的项目进行调整，混合和匹配。实际上，选择过程中的主要标准应始终是您的项目成功和团队对工作流程的满意度。

Choerodon猪齿鱼团队就结合了Scrum和Kanban方法，关于团队的敏捷实践相关信息，组织Sprint计划会议、每日站立会议、评审会、回顾会等敏捷会议可参考Choerodon猪齿鱼敏捷管理实践（三）：敏捷会议，结合Choerodon平台敏捷管理模块进行冲刺管理可参考Choerodon猪齿鱼敏捷管理实践（二）——冲刺管理。

本文译者 | 林岩芳 原文地址：https://da-14.com/blog/kanban-vs-scrum-choosing-best-agile-project-management-framework

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

团队敏捷化转型过后，该如何进行项目的测试以及验收？敏捷测试与传统测试有什么不同？自动化测试在其中又担任着怎样的角色？本文将给大家介绍敏捷自动化测试，以及Choerodon猪齿鱼自动化测试的落地。

敏捷测试的定义和意义

在传统开发模式中，开发人员和测试人员往往各司其职：开发人员了解到产品需求后开始编写代码，测试人员拿到产品需求说明书后开始编写测试用例，等到开发完成，再开始对照测试用例进行人工测试工作。

但是在软件生命周期的需求、设计、开发、测试这四个阶段中，后面的阶段一般是依赖于前面的阶段的，所以越往后期响应变化的难度越大。比如，在开发过程中不仅需要响应需求变更，而且需要响应设计上的变化。从这个角度来看，处于最后阶段的测试必须及时响应前面三个阶段的所有变化。可是在传统的开发模式中，当需求变更产生的时候测试人员所编写的测试用例往往已经完成，需要对其进行推倒重构，整个测试流程就是在重复一些没有用的工作。

传统测试流程图：

而敏捷测试是遵从敏捷软件开发原则的一种测试实践。敏捷开发模式把测试集成到了整个开发流程中而不再把它当成一个独立的阶段，因此测试变成了整个软件开发流程中必不可少，需要考虑人力、时间成本的一环。敏捷测试包含了具备专业测试技能人员在内的跨职能团队，这使得这种组合式的团队能更好地交付价值，满足项目的业务、质量和进度目标。

在敏捷开发模式中，所有的开发人员同时也是测试人员，对自己的业务负责，对团队的代码负责，是一种边开发边测试的模式。敏捷模式中一到四周的短开发周期，克服了传统模式中项目周期长、生命周期的工作内容不好分配、后期变更影响大等困难。

由于敏捷方法中迭代周期短，测试人员应尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。敏捷测试中通常包含以下几个阶段来保证敏捷测试的可靠性、时效性：

1. 验收测试：对于这个迭代中新增、修改的功能按照迭代初期提出的需求内容进行测试验收。可采用冒烟测试的方法对新版本的业务流程进行测试。

2. 回归测试：对于模块进行全量测试，保证其全部功能的可用性，验证当前迭代新增、修改过的功能对于其他内容没有不良影响。

3. 系统测试：运用场景法测试和相互交叉测试保证整个系统在迭代结束后处于一个可发布状态。

简单地说，敏捷测试就是持续地对软件质量问题进行及时的反馈与响应。

敏捷测试流程图：

自动化测试能带来什么

自动化测试在敏捷测试中占有绝对的主导地位。虽然在传统项目开发周期的测试阶段也推荐自动化测试，但由于整体的项目周期比较长，人员上的资源也较为充足，不使用自动化测试也可以控制测试人员人天成本并且达到测试目标。一般来说，回归测试能够获得几周甚至上月的时间，而在敏捷的开发模式中则迫切要求测试的高度自动化，一个迭代通常是两三周的时间，那也就意味着你只有两三天的时间来进行整个项目的全套测试流程。没有自动化，也就谈不上敏捷。在敏捷测试流程中，主要分为以下几个主要测试阶段：

▌单元测试（Unit Test，UT）

是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

▌集成测试（Integration Test，IT）

整合测试又称组装测试，即对程序模块采用一次性或增值方式组装起来，对系统的接口进行正确性检验的测试工作。整合测试一般在单元测试之后、系统测试之前进行。实践表明，有时模块虽然可以单独工作，但是并不能保证组装起来也可以同时工作。

▌用户验收测试（User Acceptance Test，UAT）

用户验收测试，也叫用户可接受测试，一般在项目流程的最后阶段，这时相关的产品经理、业务人员、用户或测试人员根据测试计划和结果对系统进行测试和验收，来决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。

▌回归测试（Regression Test）

回归测试是软件测试的一种，旨在检验软件原有功能在修改后是否保持完整。回归测试主要是以检查退化为目的的测试。退化主要指由于系统的版本更新，在之前的版本中正常运行的功能变得无法正常运行，或者紧急修正了某个问题，但引发了其他的问题的现象。

以上这四种测试模式，目前都可以找到适用的主流自动化测试框架来满足需求。单元测试和集成测试可以使用如今比较流行的JUnit、TestNG、Spock等框架进行测试。而用户验收测试与回归测试可以使用一些api接口测试框架 REST Assured + TestNG 、mocha + chai 等。还可以使用一些针对UI界面的测试框架例如selenium和appium来编写测试脚本。

Choerodon自动化测试落地

在敏捷测试的支持过程中，Choerodon平台支持了基于手动测试的操作结构（项目版本->用例文件夹，测试循环->测试阶段）的主流自动化测试框架。目前包括 mocha + chai 的api测试框架，以及 TestNG + REST Assured 的api测试框架。未来迭代中会新增支持 TestNG + selenium 的前端测试UI框架。从而完整地支持了敏捷测试中包含四个测试方面的主流框架（单元测试与集成测试在持续交付模块中落地实现）。

在自动化测试的运行模式上，我们沿用了持续交付模块所使用的基于不同的k8s平台定义环境，然后通过页面修改运行配置，达到可在不同环境中嵌入运行测试的目的。运行结束后将测试报告回传并加以解析，生成测试用例、测试阶段和测试执行。并尽可能保留并重新设计了不同框架的原生html报告，给了PO多种查看测试结果的途径，且支持定时任务等运行方式。

类原生的 Mocha + chai 测试报告：

虽然在技术上支持了敏捷化的自动化测试，但是在自动化测试落地的过程中，也遇到了一些问题的。

1. 重新定义工作量

在敏捷的开发模式中，迭代规划会议尤为重要。因为敏捷团队中没有专门的测试人员，所以当一个团队决定去实践自动化测试的时候，意味着相同难度的任务工作量基本变成了原来的两倍。作为PO在规划故事的过程中，应该充分考虑到测试脚本的编写工作量，并计算到成员的工作内容当中，从而给团队成员”减负“，鼓励他们更高质量地完成测试任务（毕竟在测试脚本上偷懒可比在业务代码上偷懒容易多了）。

2. 鼓励互相帮助

从敏捷测试的理论上来说，每个开发人员负责维护自己功能的测试代码。但是在实际的迭代过程中，难免会造成任务分配有轻微失衡的情况出现。这种情况下应鼓励队员主动帮助其他成员分担测试代码维护等琐碎任务，促进团队成员间的互帮互助，作为团队的一份子应当把整个项目当成自己分内的工作内容。而不是说这个功能是”李四“写的，事不关己高高挂起。

3. 留出足够的测试时间

在实践自动化测试以后，可能在迭代结束前的测试阶段会更容易测出Bug，这个时候应比以前多预留出一段时间给团队成员以确保在迭代结束前可以求证全部缺陷，鼓励团队成员把这个迭代发现的问题就在这个迭代中解决，从而使用自动化测试提高交付质量。

写在最后

手动测试和自动化测试对于敏捷项目来说同等重要，人工手动测试才是保证交付结果的最后一关。不能因为使用了自动化测试而忽视传统测试，这两者只是在开发的不同阶段中扮演了不同的角色。

关于敏捷的自动化测试的实践，太多人有不同的见解，正所谓一千个观众眼中有一千个哈姆雷特。每个团队的敏捷落地都有各自的特色与道路，所以实践出最适合自己团队的自动化测试方案，提高团队的凝聚力与生产力才是敏捷的最终目的，祝大家都找到一个适合自己团队的敏捷方法。

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

在敏捷开发中，大家经常会提到看板（kanban）这个名词，故名思义就是可视化的板。看板作为一个敏捷方法，与其他方法相比具有更强的可实施性，也更易让团队理解和执行。

下面将结合猪齿鱼团队的敏捷故事，给大家讲述下如何来使用看板，以及Choerodon猪齿鱼敏捷管理又是怎么辅助项目成员落地看板方法的。

第一原则：可视化

Choerodon猪齿鱼还没有发布第一个版本时，猪齿鱼的总设计师已经非常确定团队一定要使用敏捷的方式，去做一个敏捷开发工具来帮助企业提升系统交付的价值。

在猪齿鱼开发前期，团队需要去整理需求、收集需求、排列哪个故事先做哪个故事后做。那时候整个猪齿鱼开发团队被分成不同的敏捷小组，在办公室摆了4、5块白板。大家对照着看板方法中的图片模样，依葫芦画瓢地在看板上用线条进行分割，绘制出列和泳道，并买来各种颜色的便利贴和磁贴，猪齿鱼各个敏捷开发小组就这样用起来了看板。

首先需要让任务在板上呈现出来。

团队定好一个开发周期时，产品负责人（PO）会将这个周期内的所有需求都整理出并分别写在一张张大号便利贴上，按照优先级高低将卡片从上到下依次放在story这一列，剩下的故事卡片继续留在backlog这列里，直到有故事（卡片）做完再去backlog中将优先级最高的移动到story这列进行开发。团队根据故事的描述、对象和目的等信息将其拆分成一个个的开发任务，写在小号卡片上贴在doing状态列中。每个团队成员通过磁力贴颜色或其他方式标记出自己，粘在自己所负责的任务卡片上。

在使用看板后的第一个迭代中，团队里几乎听不到“A功能是谁做的？”“B任务做到什么程度了？”“为什么C功能还没开始？”“张三李四王五你们在干嘛？”等等这样的声音了，每个成员只要抬头看看白板，就能大概知晓以上这些信息，而且是即时的。这样一来，看板可视化在猪齿鱼团队算是做到了。

图为猪齿鱼团队物理看板

既然已经将产品功能和开发任务都贴在了看板上，接下来就需要让任务流动起来。管理流动的目的很明确，就是要将所有的卡片从backlog中运送到部署，并能让这个过程在板子上体现出来。

管理流动

每一天的工作从各个敏捷团队成员站在白板前开始，在猪齿鱼产品开发团队现场，每天早上都会看到一副盛景——开站会。

在绘制成多列（分别是待办、分析、开发、测试和待发布或者部署）的看板面前，开发人员依次陈述自己昨天做了什么，并将对应工作的卡片进行状态的更新，也就是将做完的任务卡片从doing状态移动到完成的状态。然后再接着说今天要做什么，并将板上backlog中的任务移动到doing的状态，贴上自己的名帖。接下来测试人员根据板上已完成开发的卡片来安排今日任务或对之前还没进入测试列的卡片进行测试工作，将开发完成的卡片从开发完成这列中移动到测试doing。

在迭代的前1到2天，可能看不出明显的变化，从第三天开始，你会发现卡片动起来了，白板上任何列中都有卡片，从开发doing到开发done，从测试doing到测试done，再到部署。所有到doing的卡片，都不是直接贴上来的，一定是从backlog中经过了分析、开发、测试的各个阶段才挪到了这个位置。

这只是整个流程持续优化之旅的开始，在这个过程中，总是存在某个瓶颈会拖延你的工作，庆幸的是，这些问题在白板上很容易显现出来，比如某个卡片在板上停留了2天了还没有动静，比如谁的名帖在板上最多，谁一个名帖都没有。往往越严重的问题越早暴露，一旦解决掉，工作的流动就会明显改进。

当基于这一原则开展工作时，你能够从精益思想中找到灵感来消除过程中的浪费以便工作能够顺畅流动起来。

限制在制品（WIP）

限制在制品指的是对进行中的任务数进行最多数量的限制。首先限制在制品并不是一个目的，它只是用来驱动改进的手段。

猪齿鱼敏捷团队在前期开发中，也无法理解如何去做到限制在制品。平台设计师张礼军说，“我们就先按一个人最多同时进行3个任务去执行吧”。

于是大家按人员数量去限制在制品，用磁贴来表示工作的分配。我们为团队成员每个人制作3个代表他们自己的磁贴，上面写上代号或者名字。然后将其贴在自己负责的任务卡片上，这样也很容易看出每个人在做什么，并且手头有多少正在进行的工作项。

这样的好处是每个人只有当看板上自己的头像少于3个的时候，才可以去领取新的任务，避免多任务并行而忽略了交付质量。这样实践下来，很容易发现团队中某些人是不是工作项过多，任务一直停滞不前，导致整个团队的在制品过多，影响了整体进度。

但这个原则的目的侧重于确保每个人都有足够多的工作可做，对工作流动的完成状态没有什么大的帮助，因为客户不关注团队是否每个人都有事情做，他们只希望能交付成果。

随着敏捷思想的不断实践，团队尝试不断改善方式，比如在每列上方写上数字标记在制品的数量，开始实施基于列的在制品限制原则。通过在瓶颈之前的步骤设置在制品限制，可以防止瓶颈处工作泛滥，并且促使团队解决瓶颈，进而改善整个流程。

举个例子，比如开发列中的卡片数已经到了在制品上限，可是测试列里的任务也存在堆积，测试人员没精力进行更多的测试。这个时候，开发的卡片无法流动进测试列，开发人员便不能进行新的开发任务，瓶颈就很明显在测试列了，那么团队的开发人员可以去帮助测试人员进行测试，从而解除瓶颈，让板子上的卡片重新流动起来。

猪齿鱼团队运用了人员限制、列限制几个方案，而在敏捷方法里也提供了许多的方法以便你了解如何设置在制品。

限制在制品就是通过条件限制把流程改进的机会呈现在表面，使团队能直接观察到流动迟滞（卡片在白板上的移动非常缓慢）、任务积压（在某列中堆积了很多卡片）、项目停滞（工作项一直等待）的等些问题，以便及时作出调整。

这些看板实践经验后来也在Choerodon猪齿鱼平台的敏捷管理上有所体现，前两个原则自不必说，在限制在制品方面，猪齿鱼敏捷管理采用列限制的方案。支持用户自行对列进行配置，设置该列任务最大数量和最小数量。

数量会在看板上直接显示，当任务数量已经达到最大时，新的任务无法拖入该列。

说到底，敏捷管理是一个方法也是一种心态，选择哪条路改进你的系统完全取决于你，最重要的一点是当你的工作向你发出改进信息时，你要响应并改善它。

猪齿鱼敏捷团队故事看板实践就介绍到此，敬请期待下篇《电子与物理看板的差异化分析》。

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

Choerodon的需求和冲刺管理回顾​

Choerodon敏捷管理中，我们使用用户故事地图和待办事项进行需求和冲刺管理。在敏捷开发实践中，整理需求和规划冲刺是开发中的重要阶段，通过规划管理可以使开发达到以下目标：

1. 可视化管理团队
2. 明确开发需求优先级
3. 明确各个任务项
4. 可视化任务进展情况

明确需求和冲刺管理的目标后，我们会有四个敏捷会议贯穿整个开发过程，需要开发团队的每个成员参与其中，此时也可以使用Choerodon敏捷管理进行会议的管理支持来达到团队的开发目标。

Choerodon对敏捷各类会议的管理支持​

标准的敏捷流程包含了四个会议，即计划会、每日站会、评审会和回顾会。我们在实际开发中会结合Choerodon猪齿鱼平台来管理支持团队中的敏捷会议。

计划会​

在每个Sprint进入开发之前，团队将会召开Sprint计划会议。

在会议之前，产品负责人会在Choerodon敏捷管理中使进行需求和冲刺的规划，并且排列好Backlog的优先级，为计划会议做准备。

在Sprint计划会议的前半段，根据Choerodon敏捷管理计划冲刺中的Backlog，产品负责人会从优先级最高的功能依次为开发团队进行讲解。然后，团队成员针对Backlog中的待开发功能提出问题，团队就该问题进行展开讨论，直到这个功能相关的问题全部解决，再进入下一个功能的讨论。

如果Backlog中的待开发功能在此迭代中已经饱和，或者有阻碍需要在进行重新计划的，产品负责人会把它从迭代计划拖动至待办事项列表进行重新规划。

在Sprint计划会议的下半段，开发团队会讨论这些确定开发的功能问题，这时可以使用Choerodon敏捷管理的报表：迭代速度图。

迭代速度图可以看出每个开发团队在每个迭代中完成任务的情况，大致可以得到一个团队迭代中任务的饱和点，然后开发团队根据这个数据决定下一轮迭代能够完成的工作量。

之后，团队成员对计划中的Sprint列表中的故事进行拆分，将每个故事拆分成一个一个的任务，并估算每个故事的故事点。一旦迭代开始，这些迭代任务将不会发生大的变化。

通过敏捷的计划会议，开发团队和产品负责人可以确认共同的迭代目标和价值。

每日站会​

Choerodon敏捷管理中的活跃冲刺看板可以用来进行开发迭代任务可视化管理，每个任务下的子任务、经办人、任务状态、任务类型都在看板中显示，每一个开发人员都可以看到团队开发的流程进度。

每日站会是敏捷开发中用于开发团队沟通了解进度的会议，可以把看板泳道切换为经办人泳道，这样可以清楚每个人身上的任务进度。

每日站会中，开发团队成员根据看板中自己的任务进度和大家进行交流：我昨天做了什么，今天要做什么，我有遇到什么困难。可以一边交流一边拖动看板上的卡片（或者在站会开始前就已经根据自己情况进行卡片拖动完成），团队成员可以对大家的各种任务状态和受阻问题进行了解。

在每日站会拖动完团队成员的卡片后，会切换到Choerodon猪齿鱼敏捷管理看板中的工作台页面，团队会共同维护一张“燃尽图”（Burn Down Chart），即所有任务的累积剩余时间随开发进程与日递减的图形，用以观察和预测所有任务是否会按期完成。

每日站会中展示燃尽图，也是向团队成员展示一个迭代开发的任务或者时间的总体完成情况，可以指导团队随时调整迭代计划与速度。

评审会​

每个Sprint结束时，都会有一个Sprint评审会议。评审会议最重要的工作是演示功能和成果，验证用户故事的实现场景，并接受评价。

所以在评审会开始之前，开发团队会检查Choerodon敏捷管理活跃冲刺看板中的故事完成情况，根据完成任务后的测试情况拖动卡片到看板已完成的列，把未完成的任务进行整理。

团队成员整理好看板中的已完成和未完成的任务时，我们就可以完成Sprint。这个迭代中未完成的遗留问题我们可以移动到待办事项中进行重新计划，对于已完成的任务，则会在评审会中进行演示验收。

评审会中，团队成员会对本次迭代中已完成的功能进行演示，产品负责人进行验收。团队成员需要接受产品负责人的评价，再针对已有的功能进行优化或者直接验收成功。

评审会后产品负责人会根据验收成果在Choerodon敏捷管理的待办事项中进行下个Spring的优先级调整，重新规划将要进行的新的Sprint。

回顾会​

在评审会之后，开发团队会进行回顾会。回顾会的重点是团队检视与调整，进行工作问题和改进点的反馈。回顾会可以提供一个很好的机会给开发团队，来讨论什么方法能起作用而什么不起作用，并一致通过改进的方法。

在进行敏捷回顾会议时，开发团队会使用Choerodon猪齿鱼Wiki管理中进行会议记录，创建时使用“敏捷回顾会议记录”的文档模板，可进入已经设置好的回顾会议文档编辑页面。

回顾会议中，开发团队会提前根据本迭代的达成目标、产品功能、敏捷流程、需求管理等方面进行准备，针对开发团队在实施敏捷开发中的各种进步和问题进行讨论。可以指派一位团队成员进行会议记录，在已有的Wiki文档模板中记录大家提出的各种问题。

然后，团队成员会共同讨论找寻这些问题出现的根本原因，提出大家认同的解决方案，统一在下一个Sprint中改进，并在下一个回顾会议上评审改进问题的结果。

在Choerodon猪齿鱼知识管理中的回顾会文档，可以记录开发团队关于每个迭代的各种问题的思考，帮助团队不断调整敏捷实施方案，突出敏捷开发的效果。

总 结

回顾整篇文章，我们继上篇进行了简单的敏捷主要规则介绍，同时详细描述了Choerodon猪齿鱼是怎样管理支持敏捷的各个会议，通过使用Choerodon猪齿鱼不断规范、记录开发过程，实现敏捷的开发，希望可以对大家有所帮助。

参考资料：

• https://www.sohu.com/a/147476928_505916
• https://blog.csdn.net/lilin9105/article/details/51183099
• http://www.woshipm.com/pmd/947515.html
• https://blog.csdn.net/baby9900/article/details/79539662
• http://www.woshipm.com/zhichang/1501729.html

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

敏捷之旅是一个国际非盈利性组织，于2008年成立，总部位于法国。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。

汉得信息作为国内领先的企业级数字化服务提供商，本课题将分享其技术研发团队为了支持公司帮助客户完成数字化变革的业务，根据技术研发团队自身的需求，逐步引入和学习敏捷工程实践及敏捷管理方法，并根据使用的反馈持续的进行优化调整，最后将敏捷及相关的最佳实践落地到Choerodon猪齿鱼平台中，帮助客户开启数字化转型之旅。

张礼军

上海汉得信息技术有限公司研发总经理&Choerodon猪齿鱼平台总设计师

16年的IT从业经验，拥有多个产品的成功研发经验，包括传统的Web应用和SaaS应用系统，并广泛被各种类型的客户所使用；同时拥有多年的大型系统架构设计、实施和推广经验。目前正带领团队经营Choerodon猪齿鱼社区、敏捷组织转型、DevOps实践，推动数字化服务转型与变革。获得DevOps Master、Lean IT Professional、Agile Scrum Master、ITIL V3 Expert等证书。

• 敏捷转型的背景
  • 业务转型驱动的技术转型
  • 数字技术转型的需求
  • 数字技术转型的目标
  • 转型面临的双峰挑战（Bimodal Challenge）
• 敏捷实践及工具的应用
  • 敏捷团队管理
  • 敏捷流程建立
  • 技术堆栈选择
  • 团队学习和探索    
• 敏捷转型成果：Choerodon猪齿鱼平台
  • 平台定位与用途
  • 服务模块
• 敏捷转型的经验总结
  • 敏捷的理解
  • 变革的挑战
  • 变革的应对
  • 变革的步骤
  • 研发体系的目标

时间：12月8日 （周六）08:00-17:00

地址：上海市静安区铜仁路258号英孚教育B1

关于信息

欢迎通过我们的GitHub和猪齿鱼社区进行反馈与贡献，帮助Choerodon猪齿鱼不断成长，我们将持续迭代优化，敬请期待。

敏捷之旅是一个国际非盈利性组织，于2008年成立，总部位于法国。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。

敏捷之旅北京站始于2010年。活动致力于在北京地区推广敏捷的实践经验，传播敏捷实践方法，建立敏捷的学习圈子，让敏捷爱好者彼此建立联接。

汉得信息作为国内领先的企业级数字化服务提供商，本课题将分享其技术研发团队为了支持公司帮助客户完成数字化变革的业务，根据技术研发团队自身的需求，逐步引入和学习敏捷工程实践及敏捷管理方法，并根据使用的反馈持续的进行优化调整，最后将敏捷及相关的最佳实践落地到Choerodon猪齿鱼平台中，帮助客户开启数字化转型之旅。

张礼军

上海汉得信息技术有限公司研发总经理&Choerodon猪齿鱼平台总设计师

16年的IT从业经验，拥有多个产品的成功研发经验，包括传统的Web应用和SaaS应用系统，并广泛被各种类型的客户所使用；同时拥有多年的大型系统架构设计、实施和推广经验。目前正带领团队经营Choerodon猪齿鱼社区、敏捷组织转型、DevOps实践，推动数字化服务转型与变革。获得DevOps Master、Lean IT Professional、Agile Scrum Master、ITIL V3 Expert等证书。

• 敏捷转型的背景
  • 业务转型驱动的技术转型
  • 数字技术转型的需求
  • 数字技术转型的目标
  • 转型面临的双峰挑战（Bimodal Challenge）
• 敏捷实践及工具的应用
  • 敏捷团队管理
  • 敏捷流程建立
  • 技术堆栈选择
  • 团队学习和探索    
• 敏捷转型成果：Choerodon猪齿鱼平台
  • 平台定位与用途
  • 服务模块
• 敏捷转型的经验总结
  • 敏捷的理解
  • 变革的挑战
  • 变革的应对
  • 变革的步骤
  • 研发体系的目标

时间：2018.11.25(周日) 9:30-17:30

地址：北京市海淀区中关村软件园13号二期广联达大厦

关于信息

欢迎通过我们的GitHub和猪齿鱼社区进行反馈与贡献，帮助Choerodon猪齿鱼不断成长，我们将持续迭代优化，敬请期待。

在敏捷开发的实践中，通过规划冲刺中不同的阶段，开发可以达到如下几个目的：

1. 可视化管理团队的目标；
2. 明确目标的优先级；
3. 明确目标分解后的任务项；
4. 可视化管理任务的进展状况。

规划冲刺

利用发布计划，可顺利地将粗颗粒度的故事分配到发布中的多轮迭代中。不过，在开始一轮迭代时，有必要去针对该迭代再去做进一步的计划。

计划会议​

整个团队通过举行计划会议来为下一个迭代做计划。客户以及团队中的所有开发人员，包括程序员，测试人员和其他人都要参与这个会议，计划会议的内容一般如下：

1. 讨论分析用户故事；
2. 从故事中拆分出任务；
3. 分配每个开发人员需要承担的任务；
4. 开发人员单独估计自身所承担的任务，以确保他们不会做出过于乐观的承诺。

在实际的操作中，团队计划会议后会开启一个冲刺，将backlog中确定在该冲刺进行的故事拖到冲刺列表中，随后为每个故事进行分解并关联对应的任务。

讨论故事​

迭代计划会后，团队会获得一个已经排好优先级的故事集合。正如程序员可能改变他们对实现一个故事难度的看法，客户或产品负责人一样可以改变他们对故事优先级的想法。计划会议是客户或产品负责人为团队调整故事优先级的最佳阶段。

会议中，PO（产品负责人）会从最高优先级的故事开始给团队讲解每个故事的内容。然后由开发人员提问，直到他们充分理解故事，能从故事中分解出任务。这个过程没有必要理解故事的所有细节，过分地深入每个故事细节会使会议变得低效、冗长，因为会议中不是每个人都需要聆听所有故事的细节。在计划会议后，开发人员可以和PO一起理清故事的关键细节。

拆分任务​

理解用户故事的大致内容后，需再将故事分解为任务。在Choerodon敏捷管理中，可以通过创建子任务的方式来分解故事，并将故事与这些拆分后的任务进行关联。只有当所有的子任务状态变成已完成时，这个故事才能拖到已完成的列中。

为何要拆分故事而不直接把故事作为独立的工作单位？

尽管故事的确可以小到作为工作单位，但将故事拆分出更小的任务，一般更符合项目开发的需要。

首先，对于很多团队来说，实现故事的开发人员不止一个，需要由多个开发人员共同完成一个故事。这要么是因为开发人员在某些特定技术上的专业性，比如前后端分离开；要么是因为工作划分是完成故事的最快途径。

其次，故事是对用户或客户有价值的功能的描述，不是开发人员的代办事项，把故事拆解成任务有助于发现那些可能会被遗忘的任务。一整个小组一起来拆分任务，依靠的是所有人的集体智慧，避免某个人忘记了故事中的某个部分。

相比瀑布过程，敏捷没有前期设计阶段，其过程特点是做频繁的短期设计，当脑海里至少有一个最小的设计方案时，才可能从故事中拆分出任务。所以，一个故事的任务拆分其实是即时设计中的一次短脉冲，以这些短脉冲的集合取代瀑布过程的前期设计阶段。

在团队成员说明任务时，需要实时将围绕某个故事的任务都记录下来，然后将任务以卡片的形式在物理或电子看板中进行展示。

Choerodon猪齿鱼敏捷管理中的活跃冲刺模块，团队可以针对每一个迭代开启一个新的冲刺，规划好时间，通过看板工具实时查看工作进度或开发瓶颈。

承担责任​

通过看板，我们可以清晰地看到每个任务的责任人（采用结对编程时，每个任务也只关联一个人的名字，此人将承担完成任务和与PO、客户沟通信息的责任，确保在迭代期间完成任务。）

虽然任务事先已经由每个人认领，但在冲刺期间并不是一成不变的。在冲刺中，随着开发取得进展，成员会比之前预想的更了解任务，因此任务的认领及承诺也需要相应做出调整。

在敏捷中，团队协作非常重要，只有所有人达到预期，这个迭代才算完成，如果有开发人员不能完成他承担的所有任务，团队中的其他成员应该尽量勇于承担。

估算和确认​

通常当一个团队经历了3个以上的迭代之后，基本可以确定团队的速率（即一个迭代可以完成的故事点总数），当然前提是每个迭代的时间周期是一样的。

假如你的团队的速率是平均每个迭代40个故事点，每个开发人员首先以理想时间估算自己承担的工作量，然后整个团队相加进而做出实际的评估，判断在该迭代中能否完成所有任务。

例如，为期2周的冲刺开始了，一个开发人员估算完成任务实际需要55个小时，算上必须要做的其他事情，没有把握在这些任务上投入更多时间，这种情况有以下选择：

• 继续往前走，一个一个的去完成，寄希望于一切顺利
• 请求团队中其他成员接收一部分任务
• 与PO讨论，放弃一个故事，或者拆分故事，放弃其中一部分
• 最好的方法是后两种，整个团队必须同舟共济。

开启冲刺​

迭代会议结束后，团队正式进入到这个迭代的开发中。Choerodon猪齿鱼敏捷管理中，把一个正式开启的迭代称作为一个活跃冲刺，一个看板针对一个活跃冲刺。团队根据计划制定这个迭代的目标和时间范围。

在迭代过程中，Choerodon敏捷管理引用了看板方法来管理我们的开发。 看板的结构通常包括如下几个列：

• Backlog ：是这个冲刺需要完成的所有用户故事，这些故事加在一起就是这个迭代的目标，这些故事通常按照优先级从上到下排列。
• Todo ：这一列代表的是待办任务项，用户故事会被拆分为对应的开发任务，这些待办的开发任务将展示在Todo这一列中。
• Doing ： 进行中的任务。
• Done ：已经完成的任务和用户故事。

任务看板上除了有默认的4列之外，还可以自定义新建泳道，通过泳道来管理故事和任务的对应关系。

在冲刺的交付阶段我们应该将以下几点作为看板方法的步骤去贯彻执行：

• 专注于质量；
• 减少进行中的工作（work-in-process）；
• 频繁交付；
• 根据交付速率来平衡任务的请求量；
• 按照任务的优先级排序进行开发；
• 消除变异性的根源，提高可预测性。

专注于质量​

很多开发团队将可用资源花在与缺陷修复相关的工作上，这会对高缺陷率团队的生产力和交付速率产生巨大影响。

鼓励提高初始质量，很可能提升2-4倍的交付速率，如果团队真的很糟糕，那么通过“专注于质量”的做法，甚至都可能获得10倍的交付速率的提升。

专业的测试人员应该做好测试，让测试人员来发现缺陷，防止缺陷遗漏在代码中。要求开发人员编写单元测试代码，使单元测试代码自动化，也就是我们经常提及的自动化测试，以提供自动化的回归测试，这样也可以产生巨大的效果。测试驱动开发似乎确实能带来使测试覆盖更为完整的好处。对于普通团队，在功能编码前编写测试代码，能够提高代码质量。

代码检查能够帮助改善外部和内部的代码质量，最好经常做，并且以小批量进行为好。

协作式的分析和设计，也能够提高代码质量。团队一起分析问题和设计解决方案，产出的质量会更高。

还有使用现代开发工具提高质量，许多现代开发工具都包括静态代码分析和动态代码分析的功能，需要在开发中不断地进行代码优化，这些工具可以防止程序员犯低级错误。

减少在制品​

在制品和平均前置时间之间存在相关性。前置时间越长，质量就会显著下降，而在制品数量越多，平均前置时间则越长。因此，提高质量的关键是减少在制品数量。

减少在制品的数量或缩短迭代的长度，将对初始质量产生重大影响。随着在制品数量的增加，缺陷数量会不成比例地增加。为期2周的迭代比4周的迭代好是很有道理的。较短的的迭代会产出更高的质量。

仅需使用看板来限制在制品数量便可提升质量，那为什么不引入明确的规则来限制在制品数量，解放管理人员使其可关注于其他的管理工作。

敏捷管理中强调的对于在制品的限制，Choerodon敏捷管理也进行了应用。团队可以根据开发能力和进度设置列约束，通过限制处理中的卡片数量来控制开发人员的在制品数量，只有当在制品卡片数量小于限制数，才可以到backlog中拉取新的任务。如下图：

频繁交付​

减少在制品数量能够缩短前置时间，缩短前置时间意味着可以更为频繁地提交可用的代码。频繁的提交代码，能够与外部团队或业务建立信任。

Choerodon敏捷开发中，开发人员会在每天定点提交合并代码（即使只完成部分功能）。如下图的代码提交日志会记录每个人提交合并的时间，会对提交代码部分进行备注，这样可以提高多个开发人员的合作效率：

在软件开发中，规模虽小但是频繁、高质量地发布交付，较之规模大但频率低的发布，更能够在团队合作上建立起信任。小规模的发布说明，团队具有交付能力，并能够一直致力于产出价值。便于软件开发团队与市场、与用户之间建立起信任。

为什么以小批量的方式进行编码能够提高产品质量？这点其实也很好理解。随着进行中工作项数量的增加，问题的复杂性也会呈指数级增加。在软件开发中，有很多知识迁移和信息发现活动，他们是隐性的，而且都是面对面的协作过程中发生的。虽然这些信息具备口头表述性和可视性的特征，但是他们大多以画像在草图之类的非正式形态存在。我们的大脑无法存储这些隐性知识，即时记住，也会遗忘。更无法记得确切的细节，并会因此犯错。

如果减少进行中的工作，能减少对隐性知识的遗忘，从而获得高质量的产品，并促进更为频繁地发布。

根据交付速率来平衡任务的请求量​

意味着根据交付可工作代码的速率，来设置新的任务进入开发流中，这样便可有效地将进行中的任务数量固定在某个值。在有交付后，便会从SpringBacklog里拉入新的任务。因此，任何对新工作的优先级排序，只可能在现有任务被交付的情况下才发生。

这一变化具有深远的影响，流程的交付速率会受限于某个瓶颈，可往往很难准确的找到这个瓶颈在何处。事实上，价值流中的每个人都会说自己已经超载。但通过交付速率，处于价值流其他环节的人员就会发现他们有了富余能力，而那些处于瓶颈处的人员的工作会很忙，但不会过载。这时整个团队成员会有一种手头终于有时间的感觉了。

在活跃冲刺中，团队可以实时查看每个成员的任务量，从而掌握团队进度以及瓶颈。

人们只有释放了大部分压力，才能集中精力准确高质量地完成工作。那些手上有富余时间的工作者，会开始将精力投向于环境改造。他们可能会开始不断提升自身技能，改进使用的工作，改善沟通协作方式等。随着时间的推移，团队在持续进行改善，进而整个团队都会得到改变。通过限制在制品以及当只有可用产能时才拉入新工作的做法，产生的富余时间能带来无法想象的改善行动。

想要进行持续改善，就要具备富余时间，为了产生富余时间，要做到根据交付速率来平衡需求请求量，限制在制品的数量。

优先级排序​

当团队做到前几点要求后，心理重心应该转向优先级排序，而不仅仅只是交付的代码数量。

当交付方面缺乏可预测性时，很少有人会去关注优先级排序的问题。在解决这个问题之前，需要保证次序的可靠性，将管理精力重点用于改善交付能力和交付的可预测性上，一旦能够真正做到按需求请求的大致次序交付需求，就应该把思考转向如何对输入的需求进行优先级排序。

Choerodon猪齿鱼敏捷管理中，根据计划会议讨论后的结果，PO可以重新对故事的优先级进行排序，团队也将根据这个优先级安排开发任务的顺序。

如果不具备定期交付高质量代码的能力，就不可能建立起信任关系，因此，在优先级排序上具备影响力的可能性也会很小，也就无法进一步优化团队交付的价值。

总结

在敏捷管理方法中，前期的需求计划和讨论必不可少。而在正式的开发过程中，首先要学习构建高质量的代码，其次，减少进行中的工作项数量，缩短前置时间，并频繁发布。第三，根据交付速率来平衡需求请求量，对在制品设置限制，进而产生富余时间并释放个体的创造力，促进改善行为的发生。第四，随着软件开发的顺畅运转和能力优化，通过改善优先级排序来优化交付的价值。

期望一步实现优化业务价值，只是一种不切实际的美好愿望。遵循以上几点并采取行动，会让你的敏捷团队逐步达到期望的成熟度水平。

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

Choerodon猪齿鱼社区的架构师分别介绍了Choerodon猪齿鱼最新版本的各项核心功能，以及后续功能开发计划。比如在DevOps方面，会在已有部署、开发、构建相关的可视化图表基础上，增加新的报表，帮助用户直观了解开发情况。同时会增强分支管理与敏捷管理的任务可追溯性，更好地将开发过程融入项目管理。

双方在交流中，主要探讨了Choerodon使用过程中遇到的一些问题以及开发技巧。票易通团队从不同的角度提出了一些改进意见和需求，Choerodon猪齿鱼将从中汲取这些反馈，归纳出一些可以增加的功能和优化方向。

比如在部署实施方面，将权限进一步细化到单个应用、单个环境级别，使项目下的每个环境和应用可以单独授权给不同的成员；微服务方面，增加工具来进行K8S容器的监控和管理；基础组件应用方面，优化基础组件调度问题等。

本次两个团队的技术交流是Choerodon猪齿鱼社区首个团队面对面交流活动，Choerodon猪齿鱼社区致力于促进Choerodon猪齿鱼平台的创新与应用，提供分享与交流的平台，来帮助开发人员更好地了解和应用Choerodon猪齿鱼，使企业能够更快地构建出色的产品，最终实现敏捷化的应用交付和自动化的运营管理。

关于信息

欢迎通过我们的GitHub和猪齿鱼社区进行反馈与贡献，帮助Choerodon猪齿鱼不断成长，我们将持续迭代优化，敬请期待。

▌主要内容：

• 瀑布流开发模式弊端
• 敏捷需求管理
  • 如何获取需求
  • 如何管理需求
    • 史诗
    • 用户故事
  • 如何编写用户故事
  • 如何规划需求——故事地图
• 总结

瀑布流开发模式弊端

在介绍敏捷之前先介绍一下瀑布流模式，这是产品开发中非常常见的一种管理模式，它以文档为驱动，在整个开发过程中，开发人员根据需求文档进行开发。所以在项目初期，确定需求和文档至关重要，通常在项目初期整个项目和产品便已经有了较为明确的雏形，项目成员需要严格按照需求文档和项目计划完成各自需要完成的工作。

由于在开发的中后期才会看到软件原型，早期只能通过文档来了解系统的模样，因此在一定的阶段，需求文档看起来会比产品实际的代码要重要。

这样的需求管理方式在传统软件系统管理中的优势在于可以在项目初期确定开发内容，更便于确定产品范围、人天预估、难度确认等，可以大大地减少项目失败的风险，同时项目成员也能通过详尽的文档来确认自己的职责和范围。但是这种管理方式在日新月异的产品开发中显得越来越笨重，在实践的过程中产生了以下难以解决的冲突和问题，比如：

• 需求变更：需求变更是软件研发中经常遇到的一种情况，而在瀑布流的方式中，软件开发的后一阶段都是在前一阶段交付后才开始实施，流程多、周期长，这样的特点导致瀑布流在应对需求变更时需要付出很大的代价。

• 质量管理：瀑布模式的测试阶段往往在大块功能开发完成后才会开始，在产品开发的时间线上都会比较晚，若测出来比较大的缺陷，可能导致产品无法准时上线。

• 成员积极性：由于需求驱动性开发，开发人员容易形成“事不关己”的态度，机械性的等待设计人员或者前阶段的产出与设计，不会站在客户或者实际使用者的角度去进行功能开发，导致开发出的功能常常“很难用”，一旦形成返工修改的恶性循环，甚至导致项目延期，会进一步打击项目成员的积极性。

• 过度开发：由于需求划定早，但是实际产出较晚，大概率出现实际上线的功能不符合预期或者花了大量时间在使用度并不高的功能上。导致过度开发的时间成本浪费。

• 适应性：市场需求、客户需求等对于产品的实际预期大概率会产生变化，现在产品需求的灵活度、创新性和变化度变得越来越频繁，瀑布式的开发模式由于开发流程时间长的特点很难适应这种场景下的需求管理。

针对以上传统瀑布流开发模式的弊端，敏捷管理的思维应运而生。在下面的文章中，将会以需求的产生、管理和规划三个部分去详细描述敏捷团队如何来处理软件开发中的需求。

敏捷需求管理​

如何获取需求​

需求实际上分为业务需求和软件需求，业务需求由不一定熟悉IT的业务人员完成，来源很广，会脱离实际的实现方式，着重于功能的描述。而软件需求由开发人员根据业务需求编写，通过基于技术实现的角度对业务需求进行筛选、梳理、归纳，通过算法、架构、数据库等设计过程完成向软件需求的转化。

在此主要讨论业务需求如何获取，如果一个敏捷团队能够有现场客户，这当然是最理想的情况。但在大多数情况下，我们很难在实际操作中将敏捷团队与客户进行无缝结合，这时候，在敏捷团队中充当客户这个角色的人往往是敏捷团队的PO，PO最重要的职责就是与客户、实际使用者等“终端实际用户”进行交流，能够找到并制定软件系统的功能范围，充分了解和分析需求，找到并确定软件系统真正有用的需求，并将其转化为系统的业务需求，即后续的用户故事。

一个优秀的PO可以做到如下工作内容：

• 在产品积压列表（Backlog）中创建容易理解的、可行的故事。
• 根据优先级调整 Backlog 中故事的完成顺序，以最优的计划实现设定的目标。
• 优化并最大化scrum团队的输出。
• 通过尽可能梳理清楚团队内外所有相关的事项，以避免混乱。
• 帮助团队对后续的迭代进行规划。
• 为产品验收定义标准和关键指标

PO在规划产品需求的过程中，要对产品的商业价值有足够的理解，只有这样，才能把产品分解成小的独立交付价值体，同时也能够对产品待办列表进行优化和价值排序，以便团队能够始终将工作投入在价值最高的产品功能上。

如何管理需求​

在敏捷管理中，产品需求同样也是非常重要的环节和组成部分，团队的所有活动都会基于需求展开，由产品负责人维护和排列各自的优先级。在敏捷管理体系中，我们将需求映射为用户故事，同时使用史诗对需求进行更粗粒度的划分和规划。

史诗​

在项目开始，我们在定义一个产品的粗略范围的时候如果直接以用户故事作为唯一的细粒度标准进行划分的话，会非常混乱，因为一个系统往往非常复杂，直接对一整个系统进行分析拆分其实是很困难的。所以针对这种情况，猪齿鱼敏捷管理引入了史诗的概念。

史诗是有一个共同目标的大量工作，类似但是区别于系统的“模块”概念，通过定义史诗来划分产品的功能线，再基于史诗来详细讨论相关的用户故事，史诗通常需要多个冲刺才能完成。同时，史诗会随着时间的推移变化，并不是在产品规划的初期就能确定史诗的规模大小，他会通过一系列冲刺对范围进行修改以适应需求的变化，随着团队通过开发和客户反馈，团队成员会不断添加和删除史诗相关的用户故事，以优化团队的发布时间。

用户故事​

用户故事（User Story)是指用户通过系统完成的一个有价值的目标，用户故事只是描述系统的外在行为，完全忽略系统的内部动作。好的用户故事应该包括角色、功能和商业价值三个要素。一个完整的用户故事可以涵盖以下问题：

• 实际使用的角色是谁？——期望用户的类型
• 具体要使用的功能是什么？——我希望功能
• 完成这个功能的原因是什么？——产生的价值 和好处

因此，一个用户故事的经典格式为：作为一个角色 , 我想要功能 , 以便于功能价值。

如何编写用户故事​

用户故事的定义必须是从真正业务用户的角度，不可以是“技术用户（开发者本身）故事”，在编写用户故事之前，应该清楚地了解创建用户故事的用户是谁，所以，做一个适当的用户调查，区分所有的用户角色并根据用户角色对故事进行区分是非常必要的。通常，客户代表（如产品所有者）负责用户故事。尽管如此，用户故事并不是高层给团队的规范，而是产品所有者和团队之间的协作技术，这就是为什么如果用户故事是合作编写的更好。一个好的方法是成立一个故事编写研讨会，由团队合作编写。

为了构造好的用户故事，我们关注以下两个原则：NVEST 原则和 3C原则

INVEST 原则​

• Independent 相互独立的：用户故事之间应该是相互独立的，相互关联依赖的故事会导致故事的优先级和计划编排变得很困难，复杂的依赖更会导致故事的难以预估和控制。通常我们会通过组合用户故事、分隔用户故事的手段去减少用户故事之间的依赖性。用户故事的独立性越高，越能根据实际情况去确立故事的优先级以及预估故事完成的可能性。

• Negotiable 便于协商的：用户故事包含了一个需求的简短描述，而详情是通过相关人员（客户、需求人员、开发人员等）之间通过讨论阶段来完成，如果用户故事非常详细会导致故事的可讨论、可协商性大大下降，不便于更好地沟通及协商，也就不可能划分出既让客户满意，也能让开发认同的好的用户故事。

• Valuable 有价值的：用户故事一定是站在客户和使用者的角度去思考和编写的，描述的是产品的一个一个功能，而不是实际实现的任务。

• Estimable 能估算的：功能的实现者需要去评估一个用户故事，来确定他的规划。估算一个用户故事需要一定的领域知识，同时太大的故事也会导致估算的不准确。

• Small 适量小的：故事在评估时在工作量上要小一些，以不超过一个迭代周期为宜（我们实践中1-3天是一个比较合适的量），短小的用户故事可以减少划分过程中估算的误差，否则很容易在划分范围和估计时出现很多错误。

• Testable 可验证的： 这点用于确定用户故事是否完成，如果一个故事无法进行测试，那我们就无法确定这个用户故事是否完成了，在划分故事时，最好确定一个故事的验收标准，这一点很重要。

3C原则​

• Card 卡片：作为用户故事的书面描述，不会包含详细故事细节，更多的是一个提醒，一个必须跟进后续沟通的承诺。

• Conversation 交谈：与产品负责人和客户的交谈中获取故事背后的细节，可以通过一些文档进行补充。

• Confirmation 确认：使用验收测试来确认故事是否完成，是否符合工作要求。

在这里需要注意把握需求文档与敏捷故事的平衡点。需求文档属于产品级的文档，不论一个软件系统经过多少次的重构开发，它的核心功能是不会有太大的变化的，这类描述产品的需求文档是项目中不可缺少的一部分。而用户故事则是项目级的功能描述，类似于做完就会扔掉的“抛弃型”需求。很多企业和团队在实践敏捷流程时，对于是否需要编写需求文档经常产生疑问，在实际的操作中，可能部分强调快速交付，或者生命周期很短、业务模式高度可变的互联网、网游等项目，是可以减少甚至放弃需求文档而全部使用故事来管理需求，但是现阶段要求企业的IT项目全面接纳需求完全无文档化其实并不是很现实。

在这里我们认为更合适的方式是找到需求文档与敏捷故事之间的一个平衡点，理性的辨别两者的区别，一份需求用例加上用户故事，然后驱动开发这种方式可能更适合大型企业的敏捷需求实践模式。

如何规划需求——故事地图​

在上文，我们已经确定了软件系统的开发范围，找出了需要实现的业务需求，同时根据用户故事的编写原则生成大量对应的用户故事，并且在迭代规划中按照优先级挑选出迭代需要完成的用户故事，将这些故事放入了下图的待办事项（Backlog）中。

但是我们如何对这些需求进行规划管理？如何将待办事项（Backlog）的故事列表在时间轴上进行编排呢？

为了更好地对用户故事进行规划，敏捷中使用 故事地图（User map）作为故事管理方式。故事地图会将产品的backlog从简单的列表模式变为一张二维地图，从而能容易地看到整个产品规划的全貌，不仅能帮助业务人员整理产品需求，协助开发人员更快速便捷地了解客户的需求，同时还能够确定产品模块的实现优先级，实现最大用户价值。

在猪齿鱼敏捷管理系统中，我们将史诗、用户故事、发布版本、冲刺迭代紧密结合，以史诗为主轴，用户故事为核心元素，实现了发布版本和迭代冲刺两个维度的产品需求规划，更加直观、快捷地将用户故事也其他的相关任务进行编排规划。

通过选择故事地图的泳道类型，我们将故事地图区分为冲刺维度和版本维度两种编排方式。

冲刺维度​

• 以史诗作为地图的横轴坐标，将地图中的用户故事根据史诗进行分类。
• 冲刺迭代作为地图的纵轴子tab页，可以将地图中的用户故事放入对应的迭代。
• 未规划区的故事是指已经分配了史诗，但是没有编入任意一个冲刺迭代的用户故事。
• 需求池是指未完成的，并且未分配史诗、也未编入任意一个冲刺迭代的用户故事。

版本维度​

• 同样也是以史诗作为地图的横轴坐标，将地图中的用户故事根据史诗进行分类。
• 软件的发布版本作为地图的纵轴子tab页，可以将地图中的用户故事放入对应的版本。
• 未规划区的故事是指已经分配了史诗，但是没有编入任意一个发布版本的用户故事。
• 需求池是指未完成的，并且未分配史诗、也未编入任意一个发布版本的用户故事。

通过在故事地图中对用户故事进行操作，可以对用户故事的史诗、迭代、版本进行直观的编排，完成用户故事的规划过程。

总结

在软件系统的开发中，不论是瀑布流模式还是敏捷模式，需求管理都是开发过程中最重要的环节之一，细致深入的项目需求和有效的需求工程管理可以让项目成员所做的工作尽可能地明晰，每一分资源的投入都尽量保证有效地产出。开发者们花费了大量的精力开发的功能由于需求调研的失误发现最后并没有用户去用，或者在大量的开发之后业务人员一句没用便推倒了所有的设计，这些情况是项目管理中是十分常见和极为头疼的情况，不仅打击团队成员的积极性，激化产品和开发的矛盾，还会浪费大量的资源，导致返工频繁、质量低下等结果。

需求管理在敏捷中并不是在项目开始就全部盖棺定论的，在项目期初进行的是大致需求和核心功能的讨论确定，但是后续实现的细节会在每次迭代完成后尽早的反馈给客户，由实际的使用用户来讨论鉴定他们真正的需求，然后根据反馈的情况和效果进行针对性地修改，尽可能做到不合理的需求尽早发现修改，减少返工的成本，同时保证最终项目产出的结果是最为贴合用户需求的产品。

当然这种管理模式也会有一些弊端，比如在实际的项目管控中需要在项目开启时便完成人天的预估，大量的需求变更会导致项目时间的不可控。其实这个问题反过来看，如果真的有如此之多的需求变更，那按照原先确定的需求执着地进行开发可能导致的后果会更加严重。所以在实际项目的中，如何让需求管理也变得敏捷不是单纯地用敏捷理论来生搬硬套，我们要切实的明白敏捷的核心理念，然后贴合实际项目的情况来做出对应的变化。让敏捷管理真的能让我们的项目敏捷起来，让客户、产品、开发者在敏捷中产生享受的快感。

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

Choerodon猪齿鱼平台是一个PaaS平台，其本身不提供应用系统的运行环境，用户需要自主安装Kubernetes集群，一般来说一个应用系统需要有开发环境、测试环境和正式环境（如下图所示），每一个环境都是一个独立的Kubernetes集群。当然用户也可以根据具体的需求来调整，例如开发环境和测试环境共用一套Kubernetes集群。

所以，利用Choerodon猪齿鱼PaaS能力的第一项任务就是 搭建应用系统的运行环境。

准备服务器​

Choerodon猪齿鱼支持本地化部署，也支持公用云部署。Kubernetes集群的硬件要求与应用系统的要求一致，当然考虑到应用系统已经完全容器化，所以用户可以根据自身需求动态定制Kubernetes集群的规模（使用公有云可以非常方便的做到这一点）。

以下表格是一个最低配置要求。

安装Kubernetes集群​

Kubernetes集群的安装采用标准安装方式即可，Choerodon猪齿鱼整理了详细方便的Kubernetes安装文档，可供参考。用户可以根据自身需求选择。

1.Choerodon猪齿鱼整理了详细方便的Kubernetes安装文档。

2.在安装时，请详细阅读安装文档前部分，其中涉及到前置要求与约定、防火墙及端口检测、同步服务器时区和同步服务器时间等。

数据库迁移

如果原有环境没有数据，则可以忽略本节。

可根据情况选择以下两种方式：

• 如果新的集群能够连通原有数据库，则可以选择使用原有的数据库连接信息而无需对数据库作任何处理。

• 如果不能连通原有数据库，考虑备份数据库配置、数据等关键数据。

具体操作如下：

1. 确定需要备份的数据，如配置，数据等，具体内存请根据实际数据库进行调整。
2. 部署新数据库到新集群中。建议使用helm部署，具体操作可以参照mysql部署。
3. 使用数据库自带工具恢复数据到新数据库。
4. 检查数据库是否正常运行。

应用迁移

应用迁移主要是将应用系统的代码迁移到Choerodon猪齿鱼中，并通过Choerodon猪齿鱼的开发流水线、部署流水线等进行应用系统的开发和部署等工作。应用迁移主要包括Choerodon猪齿鱼系统的创建项目、创建应用、改造原代码库、将原代码库迁移到Choerodon、生成新的应用版本、创建应用系统环境、部署版本、创建网络、创建域名和测试访问等步骤。请用户按照此步骤顺序进行。

如果是SaaS版本的用户需要先申请开通组织。

创建项目​

项目是最小粒度的管理层次。在组织下创建项目，则创建的项目属于这个组织。

关于Choerodon猪齿鱼中项目的详细信息，以及相关操作等可以参考项目管理。

1.使用“组织管理员”角色登录系统

2.点击组织，例如“汉得研发”，进入到组织层的管理菜单。

3.在组织层的管理菜单中，点击：“汉得研发” -> 左上角的菜单 -> “组织设置” -> “项目管理”。进入到项目管理与创建功能界面

4.在“项目管理”界面，单击“创建项目”，在弹出的窗口中填写项目编码、项目名称。

例如，

• 项目编码：hand-rdc-halm
• 项目名称：汉得资产云平台

5.点击“创建”，即可创建完成。项目创建完成之后，用户就可以使用Choerodon猪齿鱼的系统功能，例如知识管理、敏捷管理、开发流水线、测试管理、部署流水线等。

创建应用​

应用是满足用户某些需求的程序代码的集合，一个应用可以是一个单体应用，也可以是微服务系统的一个服务。服务端相关应用，例如Java、Python、C/C++/C#、Go、.NET等应用，以及前端相关应用，例如ReactJs、VueJs、AngularJs等等，理论上讲没有什么限制。

关于如何创建应用，以及相关操作和信息等，可以参考Choerodon官网的应用管理。

1.切换到项目层，例如“汉得资产云平台”。

2.在组织层的管理菜单中，点击：“汉得资产云平台” -> 左上角的菜单 -> “应用管理” -> “应用”，进入到应用创建功能界面。

3.在创建应用的弹框中填写应用编码、应用名称和选择“应用模板”。

例如，

• 编码：halm-dev
• 名称：资产云应用
• 选择应用模板：MicroService

关于Choerodon的应用模板，可以参考应用模板。如果是迁移原库的代码，则随便选择一个即可。

4.创建完成应用之后，Choerodon会在Gitlab中创建相关的代码库。 例如：https://code.choerodon.com.cn/hand-rdc-halm/halm-dev

强烈建议不要直接在Gitlab中操作代码库，Choerodon已经封装了对Gitlab库的增删改查等操作，例如创建库、创建分支、删除分支、合并代码等，所以这些操作尽量在Choerodon上进行操作。

应用容器化配置​

Choerodon猪齿鱼秉承云原生的理念，基于平台的应用需要进行容器化改造才能够使用Choerodon进行开发和部署。在本节中将给大家介绍Choerodon容器化的一些概念、如何构建应用的基础镜像，以及为原代码库增加相关的配置使其满足Choerodon容器化要求。

应用的容器化配置是整个迁移过程中最难的部分，在此需要熟悉、掌握Kubernetes、Helm等。

Choerodon猪齿鱼应用容器化概念​

在Choerodon猪齿鱼中，使用Helm管理Kubernetes包等，Helm之于Kubernetes好比yum之于RHEL，或者apt-get之于Ubuntu。Helm使用Charts管理应用，Charts就好像RPM一样，里面描述了应用及其依赖关系。

所以， 在Choerodon的标准应用代码结构中一定要包含charts文件夹，如下截图，这是一个后端项目的标准结构。

• templates为模板文件，将模板文件渲染成实际文件，然后发送给Kubernetes。
• values.yaml为模板的预定义变量。
• Chart.yaml包含 chart 的版本信息说明，您可以从模板中访问它。
• deployment.yaml：创建 Kubernetes 部署的基本清单。
• service.yaml：为您的部署创建服务端点的基本清单。
• _helpers.tpl：放置模板助手的地方，您可以在整个 chart 中重复使用

构建应用基础镜像​

什么是应用基础镜像？先来看一张图，一般在应用基础镜像中预先安装了工具类、依赖包、系统基础一致性设置等应用程序构建、测试、运行等相关的基础依赖工具和系统配置。

资产云应用为PHP项目，那么应用基础镜像中就应该为PHP运行环境，首先去DockerHub上搜索是否有官方提供的公共镜像，可以对官方提供的公共镜像做进一步定制，生成需要的镜像，也可以从一个基础的只有系统的镜像进行定制。

具体的步骤如下：

1.编写Dockerfile定制基础镜像时，尽量将镜像大小往小的做，镜像层数往少的写，仅添加应用运行时必须的相关组件，不要添加不必要的东西进入。在项目根目录下新建名为Dockerfile.base文件，在文件中写入Dockerfile定义的信息，例如：

# 以ubuntu作为系统
FROM ubuntu:16.04
# 设置环境变量
ENV NODE_HOME=/usr/local/node8
ENV PATH=$NODE_HOME/bin:$PATH
ENV COMPOSER_ALLOW_SUPERUSER=1
ENV COMPOSER_HOME=/composer
ENV USER=root
ENV SASS_BINARY_PATH=/opt/linux-x64-57_binding.node

# 添加源并安装所需要的软件
RUN echo "deb-src http://archive.ubuntu.com/ubuntu xenial main restricted #Added by software-properties" > /etc/apt/sources.list \
    && echo "deb http://mirrors.aliyun.com/ubuntu/ xenial main restricted" >> /etc/apt/sources.list \
    && echo "deb-src http://mirrors.aliyun.com/ubuntu/ xenial main restricted multiverse universe #Added by software-properties" >> /etc/apt/sources.list \
    && echo "deb http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricted" >> /etc/apt/sources.list \
    && echo "deb-src http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricted multiverse universe #Added by software-properties" >> /etc/apt/sources.list \
    && echo "deb http://mirrors.aliyun.com/ubuntu/ xenial universe" >> /etc/apt/sources.list \
    && echo "deb http://mirrors.aliyun.com/ubuntu/ xenial-updates universe" >> /etc/apt/sources.list \
    && echo "deb http://mirrors.aliyun.com/ubuntu/ xenial multiverse" >> /etc/apt/sources.list \
    && echo "deb http://mirrors.aliyun.com/ubuntu/ xenial-updates multiverse" >> /etc/apt/sources.list \
    && echo "deb http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiverse" >> /etc/apt/sources.list \
    && echo "deb-src http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiverse #Added by software-properties" >> /etc/apt/sources.list \
    && echo "deb http://archive.canonical.com/ubuntu xenial partner" >> /etc/apt/sources.list \
    && echo "deb-src http://archive.canonical.com/ubuntu xenial partner" >> /etc/apt/sources.list \
    && echo "deb http://mirrors.aliyun.com/ubuntu/ xenial-security main restricted" >> /etc/apt/sources.list \
    && echo "deb-src http://mirrors.aliyun.com/ubuntu/ xenial-security main restricted multiverse universe #Added by software-properties" >> /etc/apt/sources.list \
    && echo "deb http://mirrors.aliyun.com/ubuntu/ xenial-security universe" >> /etc/apt/sources.list \
    && echo "deb http://mirrors.aliyun.com/ubuntu/ xenial-security multiverse" >> /etc/apt/sources.list \

    && apt-get update \
    && apt-get install -y gcc g++ make xz-utils axel libsass-dev libmcrypt-dev curl supervisor rpm libaio1 libaio-dev \
    && apt-get install -y nginx \
    && apt-get install -y php-fpm php-pdo-mysql php-pdo-sqlite php-curl php-redis php-mongodb \
                          php-gd php-mcrypt php-mbstring php-xml php-ldap php-imap php-zip php-dom php-soap php-dev phpunit \

    && apt-get autoclean \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* \
    && echo "daemon off;" >> /etc/nginx/nginx.conf \
    && sed -i "s/^user\swww-data;/user root;/g" /etc/nginx/nginx.conf \
    && sed -i "s/^user\s=\swww-data/user = root/g" /etc/php/7.0/fpm/pool.d/www.conf \
    && sed -i "s/^group\s=\swww-data/group = root/g" /etc/php/7.0/fpm/pool.d/www.conf \
    && sed -i "s/^;daemonize\s*=\s*yes/daemonize = no/g" /etc/php/7.0/fpm/php-fpm.conf \
    && sed -i "s/^;mbstring\.internal_encoding\s*=.*$/mbstring\.internal_encoding = UTF-8/g" /etc/php/7.0/fpm/php.ini \
    && sed -i "s/^;mbstring\.internal_encoding\s*=.*$/mbstring\.internal_encoding = UTF-8/g" /etc/php/7.0/cli/php.ini \
    && echo "[program:nginx]\ncommand=/usr/sbin/nginx" >> /etc/supervisor/conf.d/nginx.conf \
    && echo "[program:php-fpm7.0]\ncommand=/usr/sbin/php-fpm7.0 --nodaemonize --fpm-config /etc/php/7.0/fpm/php-fpm.conf -R" >> /etc/supervisor/conf.d/php.conf \
    && mkdir /run/php \

    && sed -i "s/\[supervisord\]/[supervisord]\nnodaemon=true\nuser=root\n/g" /etc/supervisor/supervisord.conf \

    && axel -n 20 https://getcomposer.org/download/1.4.2/composer.phar \
    && mv composer.phar /usr/local/bin/composer \
    && chmod +x /usr/local/bin/composer \
    && composer config -g repo.packagist composer https://packagist.phpcomposer.com \

    && cd /usr/local \
    && axel -n 10 https://nodejs.org/dist/v8.2.1/node-v8.2.1-linux-x64.tar.xz \
    && xz -d node-v8.2.1-linux-x64.tar.xz \
    && tar xvf node-v8.2.1-linux-x64.tar \
    && unlink /usr/local/node-v8.2.1-linux-x64.tar \
    && mv node* node8 \
    && chown -R root:root node8 \
    && npm install cnpm -g --registry=https://registry.npm.taobao.org \
    && npm install nrm -g -registry=https://registry.npm.taobao.org \
    && nrm use taobao
# 暴露端口
EXPOSE 80 443
# 设置默认启动命令
CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/supervisord.conf"]

2.在项目根目录下执行命令进行应用基础镜像构建，构建好之后推送镜像到镜像仓库，例如registry.choerodon.com.cn/hand-rdc-halm仓库下（注意：用户也可以根据自身具体的需求，选择镜像库地址，例如DockerHub等），这个仓库在Choerodon创建项目时会自动创建：

docker build -t registry.choerodon.com.cn/hand-rdc-halm/php:ubuntu-16.04 -f Dockerfile.base .

3.将构建好的镜像推送到镜像仓库中：

docker login registry.choerodon.com.cn
docker push -t registry.choerodon.com.cn/hand-rdc-halm/php:ubuntu-16.04

在原来代码库中增加Dockerfile、和Helm Chart​

1.Dockerfile​

在有应用基础镜像的基础上编写应用的Dockerfile那就很容易了，只需要将程序放入基础镜像特定的目录，设置好镜像运行前置处理和启动命令即可。

本事例中，应用运行时需链接数据库，但数据库相关信息是运行时才会知道的，那么解决方式是将这些信息配置为环境变量，镜像运行时从环境变量中获取这些信息并替换到对应的配置文件中去。

第一步：修改配置文件并编写启动脚本

在项目根目录下新建auto_devops文件夹，将配置文件拷贝至该文件夹下，下面为配置文件中数据库配置片段，将会改变的值全部使用大写的字母进行替换，替换时需保证在此文件中唯一。

'dbconfig' =>
    array(
        'db_host_name' => 'DB_HOST_NAME',
        'db_host_instance' => 'SQLEXPRESS',
        'db_user_name' => 'DB_USER_NAME',
        'db_password' => 'DB_PASSWORD',
        'db_name' => 'DB_NAME',
        'db_type' => 'mysql',
        'db_port' => 'DB_PORT',
        'db_manager' => 'MysqliManager'
    ),

然后在auto_devops文件夹新建docker-entrypoint.sh文件编写启动脚本，这个脚本将替换配置文件中大写的那些变量名。

#!/bin/bash

sed -i "s DB_HOST_NAME $DB_HOST_NAME g"  /var/www/config.php 
sed -i "s DB_USER_NAME $DB_USER_NAME g"  /var/www/config.php 
sed -i "s DB_PASSWORD $DB_PASSWORD g"  /var/www/config.php 
sed -i "s DB_NAME $DB_NAME g"  /var/www/config.php 
sed -i "s DB_PORT $DB_PORT g"  /var/www/config.php 

exec "$@"

第二步：编写应用Dockerfile 在项目根目录下新建名为Dockerfile的文件

# 应用基础镜像
FROM registry.choerodon.com.cn/hand-rdc-halm/php:ubuntu-16.04
# 将程序复制到/var/www/目录中
COPY . /var/www/
# 将配置文件复制到对应目录中
COPY ./auto_devops/config.php    /var/www/config.php
# 将替换环境变量的脚本复制到镜像中
COPY ./auto_devops/docker-entrypoint.sh      /docker-entrypoint.sh
# 默认运行镜像时执行的命令
ENTRYPOINT ["/bin/sh", "/docker-entrypoint.sh"]
# 启动服务
CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/supervisord.conf"]

2.Helm Chart​

在编写Helm Chart之前你需要了解Kubernetes中的对象及其概念，本事例中运行应用只需定义一个deployment对象即可。

第一步：创建目录

在项目根目录下创建如下目录结构，首先创建一个名为chart的文件夹，再创建一个与应用名相同的文件夹，本事例为Helm Chart，在halm-dev文件夹中再创建一个templates目录。

chart
└── halm-dev
    ├── Chart.yaml
    ├── templates
    │   ├── _helpers.tpl
    │   └── deployment.yaml
    └── values.yaml

第二步：编写_helpers.tpl文件 在templates文件夹下将一些公共的lable或值定义到 _helpers.tpl文件中：

{{/* vim: set filetype=mustache: */}}
{{- /*
service.labels.standard prints the standard service Helm labels.
The standard labels are frequently used in metadata.
*/ -}}
{{- define "service.labels.standard" -}}
choerodon.io/release: {{ .Release.Name | quote }}
{{- end -}}

第三步：编写deployment.yml文件 在templates文件夹下创建一个名为deployment.yml的文件，内容如下：

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: {{ .Release.Name }}
  labels:
{{ include "service.labels.standard" . | indent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
{{ include "service.labels.standard" . | indent 6 }}
  template:
    metadata:
      labels:
{{ include "service.labels.standard" . | indent 8 }}
    spec:
      containers:
        - name: {{ .Release.Name }}
          image: "{{ .Values.image.repository }}:{{ .Chart.Version }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          env:
{{- range $name, $value := .Values.env }}
{{- if not (empty $value) }}
          - name: {{ $name | quote }}
            value: {{ $value | quote }}
{{- end }}
{{- end }}
          ports:
            - name: http
              containerPort: {{ .Values.service.port }}
              protocol: TCP
          resources:
{{ toYaml .Values.resources | indent 12 }}

第四步：编写Chart.yaml文件 在halm-dev文件夹中编写Chart.yaml文件，这个文件中写明应用的的相关信息。

# api版本
apiVersion: v1
# 应用版本
appVersion: "1.0"
# 应用描述
description: A Helm chart for Kubernetes
# 应用名称
name: halm-dev
# 应用chart版本
version: 0.1.0

第五步：编写文件 在halm-dev文件夹中编写 values.yaml文件，这个文件中编写 templates文件夹中 deployment.yml文件会用到的变量及默认值。

# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: registry.choerodon.com.cn/hand-rdc-halm/halm-dev
  pullPolicy: Always

env:
  SITE_URL: http://localhost:8081/
  DB_HOST_NAME: 
  DB_USER_NAME: 
  DB_PASSWORD: 
  DB_NAME: 
  DB_PORT: "3306"

logs:
  parser: nginx

resources: 
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources,such as Minikube. If you do want to specify resources,uncomment the following
  # lines,adjust them as necessary,and remove the curly braces after 'resources:'.
  limits:
    # cpu: 100m
    # memory: 2Gi
  requests:
    # cpu: 100m
    # memory: 1Gi

CI持续集成配置​

在上节“应用容器化配置”中，有提到Choerodon标准的应用源代码结构中必须包含charts文件件。同样，Choerodon使用Gitlab-CI作为CI工具，所以需要在应用源代码中加上.gitlab-ci.yml文件。

在CI中主要的工作就是进行镜像构建并且生成Chart包，最后将Chart包上传至Choerodon，与Choerodon进行集成。

在项目根目录下新建.gitlab-ci.yml文件，粘贴以下内容：

# 设置CI运行时的环境镜像
image: registry.cn-hangzhou.aliyuncs.com/choerodon-tools/cibase:0.6.0

# 设置阶段，这里只进行镜像构建和生成Chart包，所以定义为一个阶段即可
stages:
- docker-build

docker-build:
  stage: docker-build
  # 阶段中需要执行的命令
  script:
  - docker_build
  - chart_build

# 这里是最为关键的，定义了一个全局脚本，在每一个阶段运行前都将执行下面代码从Choerodon平台中获取相应变量及封装的shell函数。
.auto_devops: &auto_devops |
    http_status_code=`curl -o .auto_devops.sh -s -m 10 --connect-timeout 10 -w %{http_code} "${CHOERODON_URL}/devops/ci?token=${Token}"`
    if [ "$http_status_code" != "200" ]; then
      cat .auto_devops.sh
      exit 1
    fi
    source .auto_devops.sh
    # 重写docker_build函数
    function docker_build(){
        docker build --pull -t ${DOCKER_REGISTRY}/${GROUP_NAME}/${PROJECT_NAME}:${CI_COMMIT_TAG} .
        docker push ${DOCKER_REGISTRY}/${GROUP_NAME}/${PROJECT_NAME}:${CI_COMMIT_TAG}
    }

before_script:
  - *auto_devops

更多如何配置符合Choerodon标准和要求的.gitlab-ci.yml文件，请参考Choerodon官网持续集成。

将原来代码库替换到Choerodon代码库​

经过了“应用容器化配置”和“CI持续集成配置”两步之后，将得到一个包含了charts和.gitlab-ci.yml文件的新的代码库（charts文件夹和.gitlab-ci.yml文件一定是放在代码库的根目录），现在就将代码库同步到Choerodon对应的代码库，替换生成的标准代码库。

Git相关的命令如下：

git commit -m "Change repo." # 先把所有为保存的修改打包为一个commit
git remote remove origin # 删掉原来git源
git remote add origin [YOUR NEW .GIT URL] # 将新源地址写入本地版本库配置文件
git push -u origin master # 提交所有代码

生成新的版本​

当在上一步“将原来代码库替换到Choerodon代码库”中提交代码到Choerodon的远程新库的时候，Choerodon会自动生成一个master分支上的开发版本，即“2018.8.27-234043-master”，这个版本是可以部署运行的，当然，往往生成的第一个版本会由于各种BUG等，需要经过反复地调试才可以。

可以进入到Choerodon系统中查看生成的版本，系统路径：“汉得研发”(组织)->“<你的项目>”->应用管理->应用版本。如下图所示。

创建一个环境​

有了可部署的版本之后，就可以把此版本部署到环境中去了。在步骤“应用系统环境搭建”中已经安装好了应用系统运行的Kubernetes集群环境，并且在“数据库迁移”步骤中已经安装部署好数据库。

1.进入到的Choerodon猪齿鱼创建环境页面，系统路径：“汉得研发”(组织)->“<你的项目>”->部署流水线->环境流水线。

2.单击“创建环境”按钮，在弹出框中输入环境编码、环境名称和环境描述。

例如，

• 环境编码：halm-dev
• 环境名称：开发环境
• 环境描述：开发环境

3.保存时，系统会跳出来另一个对话框，如下图，需要将这段命令在步骤“应用系统环境搭建”中创建的Kubernetes环境中运行，以安装Choerodon Agent。这一步是必须要执行的，关于Choerodon Agent可以参考官网Choerodon Agent。

4.命令是具体应用、具体环境而不同的，所以，以下是笔者的环境生产的命令，请不要复制执行。

helm install --repo=http://chart.choerodon.com.cn/choerodon/c7ncd/ \
    --namespace=halm-dev \
    --name=halm-dev \
    --version=0.9.7 \
    --set config.connect=ws://devops.service.choerodon.com.cn/agent/ \
    --set config.token=a932598f-8945-449a-9dc7-7a2db489eff6 \
    --set config.envId=162 \
    --set rbac.create=true \
    choerodon-agent

5.如果在Kubernetes中执行成功，则可以看到“开发环境”显示“运行中”，否则就是不成功。

部署新生成的版本​

可部署版本就绪，环境就绪，现在就还要把可部署的版本部署到环境中。

1.进入到的Choerodon猪齿鱼应用部署页面，系统路径：“汉得研发”(组织)->“<你的项目>”->部署流水线->应用部署。

2.选择应用及版本。

例如，

• 选择应用：资产云应用(halm-dev)
• 选择版本：2018.8.27-234043-master

3.选择环境及修改配置信息。

例如，

• 选择环境：开发环境
• 还有，下面的配置信息可以根据自身需求修改。

4.选择部署模式。

例如，

• 选择部署模式：新建实例
• 对于第一次部署，需要选择“新建实例”。

5.确认信息及部署。

6.最后，确认检查好信息之后，部署即可。可以在“实例”界面查看部署的情况。最终部署的实例名称为：“halm-dev-9fc8”。

创建网络​

部署完成应用之后，还不能够被外部访问，需要创建网络和域名。现在先创建网络。

1.进入到Choerodon猪齿鱼网络页面，系统路径：“汉得研发”(组织)->“<你的项目>”->部署流水线->网络。

2.单击“创建网络”，弹出创建网络界面。填写相关的字段信息。

例如，

• 环境：选择“开发环境”。
• 目标对象：选择“选择实例”。
• 应用名称：选择“资产云应用”
• 选择实例：选择“halm-dev-9fc8”，就是上一步部署生成的实例。
• 网络配置：选择“ClusterIP”
• 外部IP：NULL
• 端口：80 ，镜像内部应用的端口
• 目标端口：80 ，K8s中已经部署的应用对外提供服务的端口
• 网络名称：halm-dev-3491

创建域名​

有了网络还要有域名才可以。

1.进入到Choerodon猪齿鱼域名页面，系统路径：“汉得研发”(组织)->“<你的项目>”->部署流水线->域名。

2.单击“创建域名”，在弹出页面中填写相关信息。

测试访问​

创建好域名之后，使用URL：handalm.hand-china.com 访问。

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

在数字化浪潮席卷之下，很多传统行业的线上业务急速增长，其业务场景、用户行为都发生了转变，面对敏捷的业务和IT应变需求，如何快速地进行创新实验，提高IT部门的总体运营效率，高效融合开发和运维的能力等一系列问题，已成为企业需要直面的挑战。

2009年以来，DevOps越来越被重视，最开始是为了让开发和运维人员更好地沟通协作，后来逐渐成为打通软件产品交付过程中IT工具链和高效解决团队成员协作沟通问题的有效理念。但DevOps的整体发展是独木不成林的，现在已经有越来越多的技术支撑，微服务架构理念、容器技术等使得DevOps的实施变得更加容易。

我们研发团队从内部产品研发需求出发，将敏捷管理、CI/CD、自动化测试、运营管理、基于SpringCloud的微服务架构、容器编排等相关工具整合为一个PaaS平台，用来支持这些传统企业的数字化转型。

本文主要分析了项目研发团队在开发过程中存在的一些问题，介绍了Choerodon猪齿鱼对此的解决方法，最后解答了应用迁移到Choerodon猪齿鱼平台前的几点疑虑。

主要分为以下几个部分：

一、为什么要使用Choerodon猪齿鱼

• 一般研发项目现状分析
• Choerodon猪齿鱼能做哪些事情？

二、使用Choerodon猪齿鱼之前的疑问

• 编程语言
• 容器化
• 数据库
• 前后端分离
• 微服务
• 移动端支持
• 公有云、混合云

三、总结

为什么要使用Choerodon猪齿鱼

在Choerodon开发团队接触的大部分传统企业中，他们面临着业务创新的需求和压力，同时也面临着无法很好得使用新型技术和方法快速将创意转化为产品的困境，IT团队希望能够利用Agile/DevOps、微服务和容器技术帮助业务进行快速创新，相关的工具非常多，而且工具链条很长，把它们整合应用起来对IT部门来说要求非常高，很多传统的企业并不具备这样的能力。

一般研发项目现状分析​

应对易变的需求能力弱

传统的研发项目往往采用瀑布式的开发方式，从立项、需求、设计、开发，测试到最终运营管理，由于市场或者用户的需求经常性发生变化，瀑布式模型的能力比较弱；当然，现在很多项目并不是完全遵循瀑布式的开发方式，在进入运营期当需求变化时，会进行灵活地处理，尤其是持续更新的产品。但这种情况仍缺乏明确的管理策略，更多的是“东补西凑”的“理念”，与敏捷开发还是有所不同。另外，开发人员往往没有书面记录用户的变更需求，可能会导致无法追溯系统软件变更的历史。

缺乏有效的分支管理与版本控制机制

现在越来越多的项目使用Git作为版本控制的工具，通过Git进行分支和Tag管理，大多数情况这个过程都由手工完成，缺乏相应的规范，对于分支和版本号的控制也很随意，出现这样的情况往往是大家对软件交付过程中的软件版本控制不够重视，“只要确保软件是最新的版本即可”，甚至是项目管理的漏洞或者缺陷。

多采用手工或者半自动的部署方式

能否实现自动化和高效地部署是衡量一个团队工作能力的核心标志之一。很多团队采用手工的部署方式，有经验的“老司机”都知道，部署过程往往都是拉取源代码、编译、构建，然后上传到服务器、停止服务器、覆盖代码，最后启动，甚至还有各种系统设置等。每次部署都要经历这个过程，小到一个Bug的修复，大到发布一个大版本。这样直接会导致部署频率较低，进而降低用户需求或者价值的交付频率。

文档缺乏规范管理

文档是项目或者系统的积累和沉淀，包括项目初期的应用蓝图、架构图、分阶段实施计划，以及开发过程中的设计文档、产品功能文档等。在系统开发前期，大家可能对于维护文档还是比较积极的，但是随着产品不断迭代，慢慢大家就会疏于更新文档，导致文档与功能没有办法衔接对照。

缺乏驾驭微服务架构的能力

近几年微服务方兴未艾，尤其是Spring Cloud架构的不断成熟，以及Service Mesh的正式版本发布。由于微服务架构体系涉及到的技术种类非常多，几乎所有的微服务框架不能直接拿来使用，需要投入很大的人力物力进行前期研究、基础系统框架的搭建，这对于很多传统研发团队来说是一件很难的事情。

软硬件资源及交付过程缺乏统一管控

项目组在申请软硬件资源时，缺乏统一管控，各项目组独立部署，无法实现资源有效共享，资源利用率低，浪费严重。另外，在企业内部缺乏统一的支撑平台，每个项目组从开发到上线，基本上都是从零开始，项目交付过程中的沉淀很少，功能模块无法复用，交付过程也缺乏统一，交付周期长，需求响应慢。

以上是Choerodon团队在实践过程中遇到看到的情况，这些情况的存在可能导致研发团队效能的低下，进而影响到用户需求和价值的交付。对于研发团队效能的问题，国际上的一些组织也有相关的研究和定义，DORA 与 Google Cloud 合作发布的 2018 年《DevOps 现状报告》中，将团队根据 DORA 的软件交付效能基准划分为三种类型：高效能、中效能与低效能团队，以团队产出来进行评价，发布频率、变更响应时间、服务恢复时间，以及变更故障率等指标作为划分的参考标准。其划分标准如下：

​对于低效能团队如何改进才能进一步释放潜能，提高团队的效率，DORA 的研究强调技术转型实践至关重要。这些重要的实践包括版本控制，自动化部署，持续集成（CI），基于主干的开发以及松耦合架构。 今年DORA还发现，有助于持续交付（CD）的实践包括：使用监控和可观察性解决方案，持续测试，将数据库更改集成到这样的软件交付流程中，以及关注安全性。

Choerodon猪齿鱼能做哪些事情？​

对于一般软件研发类项目，往往包含产品立项、需求分析、应用设计，以及开发 、测试、持续部署与发布，生产运维等。本节将给大家阐述，Choerodon猪齿鱼是如何支持整个研发过程的，以及采用哪些手段来提高软件交付的效率。

产品立项

产品立项是启动产品研发的第一个阶段，最核心的工作是要确定产品的定位，包括目标用户、用户需要、产品名称、产品类型、关键优点、主要竞品、主要不同，以及相关成本投入、团队建设等。此时，可以使用Choerodon猪齿鱼的知识管理功能，方便的记录产品立项阶段的各种输出文档。

需求分析

针对产品立项中的要求（例如用户需要、关键优点）进行需求分析，做好用户访谈等。此时，可以使用Choerodon猪齿鱼的知识管理功能，方便的记录需求分析的各种输出文档。

应用设计

在应用设计阶段，将设计应用蓝图，构建整体系统架构和指定分阶段实施计划等。此时，可以使用Choerodon猪齿鱼的知识管理功能，方便地记录应用设计阶段的各种输出文档。

知识管理是一个轻量级的强大Wiki平台，允许用户根据自己的特定需求自定义Wiki，为企业、IT团队提供方便的项目协作平台和强大的项目内容管理平台，集中式管理产品相关内容等，例如需求收集、架构设计、功能设计、开发规范、命名规范、会议记录、计划安排等。

开发

在项目进入开发阶段，主要进行代码开发、单元测试、分支管理和版本控制等。Choerodon的开发流水线采用Gitlab CI作为持续集成工具，研发团队可以进行代码托管、分支管理、版本控制，有效简化应用开发、缩短应用生命周期，快速迭代。

测试

在测试过程中，团队需要进行测试用例管理、测试计划和执行，以及测试分析等。Choerodon的测试管理为用户提供敏捷化的持续测试工具，包括测试用例管理、测试循环、测试分析等，可以有效地提高软件测试的效率和质量，提高测试的灵活性和可视化水平，最终减少测试时间，让用户将主要精力放到软件功能构建上。

持续部署与发布

持续部署与发布是采用自动化的手段，持续地发布可部署的系统版本，并能够实现方便自动地将系统版本部署到目标环境中。此过程可以借助Choerodon猪齿鱼的部署流水线，方便地管理各种使用Choerodon开发部署的应用服务和资源，包括一键部署、应用启停、状态监控，以及应容器管理等。

生产运维

在生产运维阶段要对系统进行监控等，可以借助Choerndon的运营管理服务，其提供一整套完整的运营管理工具，在软件交付生产的各个环节建立数据收集和度量，监控主要包含开发类指标、服务器日志、应用系统日志和微服务调用链等信息；同时，提供各种分析报告，帮助用户优化IT资源配置。

另外，还有项目管理，项目管理贯穿整个产品的研发周期，借助Choerodon的敏捷管理服务，通过故事地图、用户故事来管理用户故事和发布计划，通过迭代来管理冲刺，最后通过看板来可视化冲刺的执行，让需求、计划、执行一目了然，使整个软件开发流程管理规范化。

并且，Choerodon猪齿鱼提供了一套基于Spring Cloud的微服务开发框架，在其中，做了大量的集成和封装，预置了权限、数据一致性、登录、前端UI 、审批、系统管理、个人中心等诸多模块，可以让用户专注基于业务的实现开发。

迁移之前的疑问

在迁移之前，系统架构师或者软件工程师对Choerodon猪齿鱼可能有一些疑问，例如，Choerodon是否有编程语言限制，对数据库的支持情况怎么样，是否支持公有云等。下面就对于普遍的疑问，一一作答。

编程语言

Choerodon猪齿鱼的核心部分是一个PaaS平台，采用Sping Cloud微服务架构进行开发构建。根据Choerodon猪齿鱼的设计思路，只要是能够容器化的应用都可以使用Choerodon的PaaS平台进行开发和部署，应用本身可以采用不同的编程语言，例如Java、C、C++、C#、Python、Go，以及由编程语言衍生出来的各种开发框架，例如Spring Cloud、Spring、Struts、Mybatis、Django、Flask、ReactJs、AngularJs等（这里不一一列举）。

容器化

Choerodon猪齿鱼一个核心的特性是通过镜像和容器实现“不可变架构”，不可变架构的好处是在程序开发阶段生成的可部署版本是镜像，在镜像中已经做过系统需要的各种设置，可直接通过镜像生成部署容器，不管是开发环境、测试环境还是正式环境，镜像不可变化，即所有环境的系统设置是一致的，避免不一致导致的各种系统问题。

Choerodon的开发流水线结束生成后将生成版本化的镜像和相关的配置文件，在部署阶段，直接将镜像部署到Kubernetes集群中，所以，如果要使用Choerodon猪齿鱼的部署功能，应用程序必须容器化。

数据库

软件系统一般分为应用层（前端、后端）和数据库层，以及部署相关，Choerodon猪齿鱼主要覆盖应用层，以及部署相关的容器层，现在还没有覆盖数据库层的相关内容。对于数据库层，用户可以选择自建或者是使用公有云的RDS服务。另外，程序中依然可以使用自动化的脚本构建数据库和初始化数据等，与原来没有任何区别。

前后端分离

目前很流行前后端分离的架构，例如后端使用SSM，前端采用React、Ant Design，移动端采用React Native等。Choerodon猪齿鱼完全支持这样的前后端分离架构，其实还是那句话“只要是能够容器化的应用都可以使用Choerodon的PaaS平台进行开发和部署”。

微服务

微服务是目前非常流行的技术之一，代表有Spring Cloud、Dubbo等。现在大家在谈微服务的时候一定要加上Agile/DevOps，貌似微服务+Agile/DevOps是不可分割的整体。根据实践经验，微服务的实施和落地需要从项目管理，开发，部署，运营监控，以及容器化等多个方面来考虑和配套。Choerodon猪齿鱼实际上是因微服务而生，有一整套完整的工具链条来支撑微服务的实施和落地。

移动应用支持

现在有各种移动应用技术，如React Native，Weex，PWA等。用这些或者别的框架开发的模块应用，只要能够打包成一个文件并且能够在原生应用中使用的，就可以通过Choerodon猪齿鱼进行移动微服务的版本跟踪、发布、回退甚至是根据不同主版本号进行个性化定制。

但是总应用的开发（一般用原生的Java或者OC或者Swift来开发原生应用）作为一个前置条件，是不通过微服务管理的（因为往往要涉及到应用的审核、推送、上架等），所以这里说的移动应用微服务化是指其中的模块应用。总应用只要能够实现文件的下载、覆盖，版本的对比即可。

如果总应用开发完成，在日常开发中开发人员要做的只是独立的模块开发，推送到Git库，触发CI，这时会生成模块的镜像并推送，然后在Choerodon猪齿鱼中选择是否可见和版本管理，即可在手机的应用上查看或者更新该模块。

公有云、混合云

Choerodon猪齿鱼是基于Kubernetes部署的，只要是能够安装部署Kubernetes就可以安装使用猪齿鱼，所以公有云、私有云或者混合云，只要安装了Kubernetes，就可以安装使用Choerodon猪齿鱼，另外，对于公有云中提供的RDS、NFS等服务Choerodon也可以使用，但是对于公有云提供的Kubernetes服务，阿里云、腾讯云的K8s服务是没有问题的，AWS的K8s服务可能有问题，因为AWS的Kubernetes服务是经过客户化的版本的可能有所不同。

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

随着企业业务创新和应用复杂度的升高，传统的“瀑布式开发模型”面临着需求变更、过度开发、适应性不强等诸多问题，亟待改善。不仅如此，企业内部程序复杂，业务发展快，开发效率也逐渐变得愈发重要。

本次直播将介绍Choerodon猪齿鱼如何助力华润置地实现中台化转型，基于真实案例和实践经验，讲解Choerodon猪齿鱼如何帮助企业利用微服务和容器技术构建中台架构体系，打造以Choerodon猪齿鱼为核心的敏捷研发体系，聚焦业务，快速迭代，持续交付。

华润置地有限公司是财富500强企业华润集团旗下的地产业务旗舰，是中国内地最具实力的综合型地产发展商之一，主营业务包括房地产开发、商业地产开发及运营、物业服务等。

华润置地一直重视企业的信息化建设，从最早期的采用ERP套件，到后面自主研发的一系列“烟囱式”应用，应用之间相互独立，系统功能重合，架构各异，伸缩扩展能力有限，服务器及人力资源浪费严重，产品交付周期长，运维工作繁重。

引入Choerodon猪齿鱼后，统一开发框架和平台，新的系统尽量采用微服务方式开发，基于敏捷迭代研发的思想，一般几周便可快速上线系统，部署周期从数周减少到几分钟，应用交付的效率提高了数十倍，容器平台由专门团队运维，项目组只需要专注于业务需求和交付，极大的降低了日常的运维成本，产品在设计、开发、运维等各个阶段均有改善。

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

本次直播主要介绍华润置地中台转型背景及落地过程。

• 华润置地中台转型背景和架构体系介绍
• Choerodon在华润置地的部署架构及业务架构
• 转型过程
• 单体应用架构向微服务应用架构转变
• 传统部署架构向容器部署架构转变--DevOps落地实践
• 瀑布式研发向敏捷迭代式研发方式转变
• 实践经验总结

关于信息

欢迎通过我们的GitHub和猪齿鱼社区进行反馈与贡献，帮助Choerodon猪齿鱼不断成长，我们将持续迭代优化，敬请期待。

什么是猪齿鱼

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

直播培训有什么？

本次直播培训将讲解和分享Choerodon猪齿鱼的核心功能和应用实践。

8月14日​

Choerodon 猪齿鱼敏捷管理​

1. 敏捷相关概念
2. 敏捷流程
3. 敏捷会议
4. 如何结合猪齿鱼平台进行敏捷管理

Choerodon 猪齿鱼持续交付​

1. 项目的创建
2. 项目角色的分配
3. 应用管理
4. 开发流水线
5. 应用版本
6. 部署流水线
7. 应用发布
8. 应用市场
9. 应用导入导出及相关资源扫回逻辑

8月15日​

Choerodon猪齿鱼后端微服务开发​

1. Choerodon微服务框架介绍
2. Choerodon环境搭建
3. 如何根据模板创建应用
4. 文件结构讲解
5. CI/CD
6. starters介绍
7. 初始化数据库
8. 实体类映射
9. 接口编写
10. 权限配置
11. 服务注册
12. 路由配置
13. 开发模式介绍

8月16日​

Choerodon猪齿鱼测试管理与知识管理​

测试管理​

1. 测试用例
2. 测试循环
3. 测试执行
4. 执行结果与缺陷关联
5. 报表的使用
6. 状态自定义

知识管理​

1. 空间的创建和其他操作
2. 文档的创建和编辑
3. 文档交互

Choerodon猪齿鱼前端开发​

1. 开发环境搭建
2. 开发新模块
3. 开发新页面

直播平台​

IT大咖说（搜索Choerodon猪齿鱼收藏直播间）

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

现在越来越多的项目使用Git作为版本控制的工具，通过Git进行分支和Tag管理，大多数情况这个过程都由手工完成，缺乏相应的规范，对于分支和版本号的控制也很随意，出现这样的情况往往是大家对软件交付过程中的软件版本控制不够重视，“只要确保软件是最新的版本即可”，甚至是项目管理的漏洞或者缺陷。其实软件的版本控制以及分支管理贯穿于整个软件产品的生命周期，日常的项目管理对于开发团队能否有节奏且顺利的交付软件也很重要。

的确！频繁的冲突搞的开发人员头晕脑胀，例如，一次项目在代码合并时出现了冲突，导致整个项目组挨个排查，花费了大半天的时间，影响开发效率还浪费资源；开发人员随意创建分支，各种不规范的合并使得Git Graph线条杂乱无章，完全看不出来主干发展的脉络；提交信息混乱，不知道这次提交是因为什么，实现了什么功能 ，解决了什么问题。

本文并不是一篇技术文章，其中也没有让别人耳目一新的观点或者论述。本文是为我们这些希望进行简单、有效地协作的人准备的。任何参与到软件开发的人，无论承担何种角色，都可能对其感兴趣——毕竟每个人都会用到分支和合并。本文将结合Choerodon猪齿鱼为大家阐述如何进行方便有效的分支管理和版本控制，以及如何选择适合自身的版本控制模型。

如何来解决这些问题呢？

有经验的老司机可能会说，“建立规范”。

是的，只有建立规范，才能抑制不好的事情继续在项目组蔓延。至于建立什么样的规范？我们不妨先制定一个目标。

目标

• 简单——所有的团队成员每天都会使用这些模式，所以相关规则和程序必须要简单明了。
• 灵活——可选择不同的分支管理模型，例如GitFlow、GitLabFlow或者GitHubFlow，甚至自定义。
• 可视化——界面化比命令行更安全可控，将分支管理模型的规则和约定固化到系统中。
• 需求与代码关连——分支需要和具体的任务需求关连。

作为一个有经验项目管理者，或者产品负责人，你一定会思考一个问题：我们项目组在开发过程中应如何管理分支？不错，分支管理将和项目组开发人员日夜伴随，如果采用了一个不合适的分支管理模型，那么可以想象兄弟们得多么的痛苦。

Okay，那么就从分支管理模型开始......

分支管理规范

GitFlow、GitHubFlow等都是已经被证明很有效的分支管理模型，但是这些更多的是书面的规则、约定，基本上是靠着程序员的自觉性和Git命令一起维持着这个约定，其实无数的经验告诉我们“这很脆弱”。所以，如何使用系统界面化操作将这些规则和约定表示出来，就变得很有意思。

分支管理模型​

不要着急，先来看看 Choerodon 猪齿鱼提供的分支模型，Choerodon使用 GitLab 进行分支管理，默认分支为 master。目前支持七种常见的分支类型：

1. master：主分支，用于版本持续发布；
2. develop：开发分支，即日常迭代使用的开发分支，用于日常开发持续集成；
3. feature：特性分支，用于日常开发时切出分支进行单功能开发；
4. bugfix：故障修补分支，通常用于修复故障；
5. release：发布分支，适用于产品发布、产品迭代；
6. hotfix：热修分支，用于产品发布后修复缺陷；
7. custom：自定义分支，用户可以自定义需要的分支类型。

注:

1. develop是GitFlow分支模型的重要组成部分。
2. bugfix旨在与敏捷的问题类型（故障）呼应，用于标识此分支的任务是修复某个故障。

这7个分支就是我们手中的7个魔方，通过这7个魔方的组合可以变化出无尽的分支管理模型，比如GitHubFlow。

GitHubFlow分支模型只存在一个master主分支，日常开发都合并至master，永远保持其为最新的代码。

• 在领到日常开发任务时，基于master创建feature特性开发分支，提交代码后，合并至master并删除feature。
• 在领到修复故障的任务时，基于master创建bugfix故障修补分支，提交代码后，合并至master并删除bugfix。
• 需要发布时，同样需要基于master创建release，生成的应用版本部署在UAT测试环境进行测试，若需要修改则提交至release。
• 产品上线后发现故障需要紧急进行热修复时，则基于tag创建hotfix，将修复的代码提交至hotfix；部署该分支上的版本通过验收后，基于hotfix打出热修版本的tag，如0.8.1。
• 由于新版本的迭代也同时进行，所以需要在hotfix上rebase master，变基至master分支最新的提交，再合并至master并删除hotfix，就可以将本次修改的提交应用至master上。

这个分支模型的优势在于简洁易理解，将master作为核心的分支，代码更新持续集成至master上。根据目前收集到的反应来看，得到了更多的好评，认为GitHubFlow分支模型更加轻便快捷。

如果GitHubFlow不合适，可以使用GitLabFlow或者GitFlow，也可以自行定义规则。这里没有“银弹”，只是相对比较灵活的配置。

分支命名规约​

有了分支管理模型，还需要命名规约，不同类型的分支命名方式应该不同，值得庆幸的是，猪齿鱼已经帮你完成了这个步骤。feature、bugfix分支的分支名使用的是关联问题的issue号（在猪齿鱼中打通了需求和代码分支的关连关系），对于release及hotfix，分支名可命名为需要发布的版本号，如0.8.0、0.8.1等。在这里使用到了类似0.8.0这样的版本编号规则，如果你对此不了解，没有关系，在下面将详细的介绍。

提交命名规约​

除了分支的名称需要规范，提交的命名也同样如此。不幸，猪齿鱼并没有把这个规则固化到系统中，需要团队共同遵守。

格式为：[操作类型]操作对象名称，如[ADD]readme，代表增加了readme描述文件。

常见的操作类型有：

• [IMP] 提升改善正在开发或者已经实现的功能
• [FIX] 修正BUG
• [REF] 重构一个功能，对功能重写
• [ADD] 添加实现新功能
• [REM] 删除不需要的文件

合并请求​

合并请求是开发过程中必不可少的一个环节，其中有如下一些重要的事情要做：

1. 代码Review
2. 启动CI
   • 单元测试
   • 代码质量检查

版本号规则

在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷，系统规模越大，加入的套件越多，你就越有可能在未来的某一天发现自己已深陷绝望之中。
                              —— Tom Preston-Werner 的《语义化版本2.0.0》

在这里我们不去解读到底什么是“依赖地狱”，大家可以到语义化版本2.0.0中了解。那么，我们的重点是什么呢？在这之前，先了解一下“语义化的版本控制”

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

1.主版本号：当你做了不兼容的 API 修改，
2.次版本号：当你做了向下兼容的功能性新增，
3.修订号：当你做了向下兼容的问题修正。

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

这就是“语义化的版本控制”最核心的规则，当然这不是全部，Tom Preston-Werner还详细的阐述了主版本号、次版本号和修订号的变化递增规则，不过这些规则很长，很复杂。

没有关系，猪齿鱼帮我们做了这些复杂的事情，将“语义化的版本控制”固化到了系统中，简而言之，

• 当进行代码打包时，而非发布新版本

将版本号规则定为年.月.日-时分秒-分支名。如：2018.7.20-152837-hotfix-0.8.1，这个时间是当前提交时间。当代码提交到各个分支上时会自动触发CI，生成版本号规则如上所示。

• 当需要发布新版本时，例如如0.8.0、0.8.1
  • 主版本号：当做了不兼容的 API 修改或功能强大的升级，可以将主版本号的数值增加1。
  • 次版本号：当做了向下兼容的功能性新增或是功能上的小迭代，可以将次版本号的数值增加1。
  • 修订号：当做了向下兼容的问题修正，但功能上没有很大的变化，可以将修订号的数值增加1。

需求与代码关连

一直以来，需求一般和系统的功能联系在一起，但是与代码关连却不常见，如果能将需求和代码联系在一起，奇妙的化学反应就发生了。

“我们可以追溯到一个用户故事对应了哪些分支，哪几个提交”， “甚至出现了一些BUG，可以找到是哪个分支提交的，当初为了发布XXX新的需求”， “不仅如此，我们通过需求与代码分支关连，能够查看到哪些需求已经部署到了测试环境，那些需求已经部署到了正式环境”， “可以做从业务到代码的整个链条的统计分析...”

...

这一切，猪齿鱼已经帮助项目管理者和程序员实现了。在猪齿鱼的敏捷管理服务中，可以通过用户故事、任务、缺陷等直接一键创建分支，然后，你可以从git checkout -b 开始愉快而又有挑战的一天。不仅如此，也可以在分支管理中，将现有的分支关连到用户故事、任务或者缺陷。

总结

回顾一下我们的目标，简单、灵活、可视化，以及需求与代码关连。版本控制一直都是一件说起来容易，做起来难的事情，但是我们做到了，重要的是猪齿鱼将这些特点和规则固化到了DevOps流程中，让我们忘记复杂易错的操作，把精力放到业务开发上。希望我们的分享能够给大家带来帮助。

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

2018年5月20日，Choerodon猪齿鱼正式发布 0.5.0 版本，同时汉得公司宣布发布Choerodon猪齿鱼平台，公司希望通过社区的力量不断完善和提升产品的体验，并为企业提供数字化转型的企业级应用容器PaaS平台支持。

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

Choerodon猪齿鱼诞生背景

企业持续的业务变革和创新，面对敏捷的业务和IT应变需求，如何快速的进行创新实验，提高IT部门的总体运营效率，高效的融合开发和运维的能力等一系列问题，已成为企业需要直面的挑战。

汉得公司的研发团队基于DevOps思想和微服务架构设计理念，利用容器技术将敏捷管理、持续交付、运营管理、微服务框架、容器编排等相关工具整合为基于容器的企业级应用PaaS平台，即Choerodon猪齿鱼平台。平台能够帮助企业实现敏捷化的应用交付和自动化的应用运营管理，并能够基于现有的大量业务组件来帮助企业加速业务创新。

Choerodon猪齿鱼的产品特性

Choerodon猪齿鱼作为企业级PaaS平台，基于DevOps敏捷化和自动化的理念和思想，主要包含敏捷管理、开发流水线、应用和部署流水线、微服务开发和运营管理等模块。

• 敏捷管理

  Choerodon使用敏捷模型来管理项目，包含故事地图、用户故事管理、发布计划、迭代和看板等功能，让需求、计划、执行一目了然，使整个软件开发流程更加高效和规范。

  

• 开发流水线

  Choerodon借助Gitlab CI作为持续集成工具，提供持续集成的流水线，简化应用开发、缩短应用开发周期，实现软件功能快速迭代。

  

• 应用和部署流水线

  方便地部署和管理各种使用Choerodon开发的应用服务，包括应用启停、状态监控，以及应用对应的版本控制、容器管理等。

  

• 微服务开发

  Choerodon提供一套基于Spring Cloud的微服务开发框架，借助它企业可以方便快捷地构建应用服务，简化开发，加速信息化系统的实施和落地。

  

• 运营管理

  Choerodon提供实时监控工具，监控软件交付生产中各个环节的数据和度量，并形成快速的反馈循环。同时，提供服务器、应用系统的分析报告，帮助用户优化IT资源配置。

此外，在未来的版本中，我们还将持续增加测试管理、知识管理等模块。

Choerodon猪齿鱼为企业带来的价值

1. 拥抱，帮助企业建立开放的技术体系

Choerodon猪齿鱼基于微服务、DevOps和容器等打造，同时作为PaaS平台，它同样支持企业方便地使用，搭建自身的业务系统，例如微服务、容器、Java、Web等。

2. 缩短交付时间和提升交付质量

Choerodon采用DevOps的原则和敏捷模型来管理软件的开发和运维，可以有效提高软件交付的质量，加快产品推向市场，并且提高组织的有效性，有效地帮助企业或者组织提升IT效能。

3. 提高应用系统的健壮性和稳定性

Choerodon借助容器技术，将企业专有云和公有云基础设施平滑地融合在一起，使混合云平台具有了良好的扩展性和延伸性，以及在发生任何部分损坏或宕机时执行自修复的快速响应能力，确保应用系统具有提供稳定高效服务的能力。

4. 加速企业信息化系统的实施和落地

Choerodon提供一套基于Spring Cloud的微服务开发架构，开发人员可以利用它快速开发和部署软件系统，不需要关注一些通用性功能和模块， 例如权限、用户、角色，以及菜单、标准UI样式等，而是将注意力放到业务开发上，从而加速企业信息化系统的实施和落地。

5. 降低企业创新门槛和成本

通过Choerodon猪齿鱼平台，企业可以搭建自己的PaaS平台，直接借助Choerodon的敏捷管理、DevOps工具链和微服务开发框架等快速地将创意转化成产品，免去企业自己研究、搭建的成本，从而更加高效地管理研发，让软件交付更加规范化。

Choerodon猪齿鱼案例

Choerodon猪齿鱼建立在多家大型企业应用实践的经验基础上，如华润置地、汉得信息、芝士网、汉得供应链金融等，Choerodon猪齿鱼帮助他们缩短软件交付周期，提高交付质量，减少运营支出，提高企业信息化系统对市场和需求反应的敏捷度。

摘要：敏捷转型并没有那么简单，不是把那一套运作模式运作起来就可以，毕竟每个公司的情况都有所差异，仅仅把敏捷那一套运作模式照搬过来是远远不够的。对于管理者来说，希望通过敏捷提升软件交付的效率和质量，并且希望通过敏捷转型打造一个高效、学习型的团队。其实，敏捷是一个很强大的工具，运用的好确实可以收到很好的管理和交付效果；但是运用的不好，很可能就会事倍功半。本文将总结在过去的一段时间里，我们自身在敏捷转型过程中踩过的坑，希望对大家在做敏捷转型或者实施的有一定借鉴意义和帮助。

随着互联网、大数据的发展和成熟，包括新零售等概念的提出、探索和落地，越来越多的企业开始进行敏捷转型，在软件开发过程中采用敏捷的方式，期望可以提升开发效率，改善交付质量。敏捷也不再局限于互联网行业，很多传统行业——包括银行、保险、电信、零售等等也逐渐开始认同敏捷的开发方式和流程，在企业内部的系统开发过程中把敏捷与原有的流程相互融合，以更好地适应高速、快节奏所带来的不确定性，进一步提升IT部门和系统更好地服务企业战略目的和满足市场需求的能力。

对于管理者来说，希望通过敏捷提升软件交付的效率和质量，并且希望通过敏捷转型打造一个高效、学习型的团队。其实，敏捷是一个很强大的工具，运用的好确实可以收到很好的管理和交付效果；但是运用的不好，很可能就会事倍功半。

为什么敏捷很好，但是我们却很难落地？​

本文将总结在过去的一段时间里，我们在转型过程中踩过的坑，以作前车之鉴。也聊聊在转型过程中，哪些优秀的实践可以尝试，走上渐进变革的道路。

1. 敏捷是不是可以缩短项目周期，或者说“敏捷就是快”?

   在接触敏捷之前，大家对敏捷都是一知半解，更多的停留在字面意思的理解上：“敏捷就是快”。一旦有人觉得不快时，就会发出质疑：我们的敏捷做对了吗？ 其实，敏捷并不意味着“快”，“敏捷”在百度字典中的解释是“反应迅速快捷”。在软件开发中，敏捷是使用各种管理的手段（例如，3个角色，5个事件）来确保软件开发人员能够对于外部或者内部的需求或者变化能够迅速的做出反应，保证软件系统的功能或者其他特性能够满足市场或者用户的要求。

   敏捷模型和瀑布式开发模型是对立的，瀑布式开发模型主要是“按部就班”的进行需求调研、系统设计、详细设计、功能开发、测试、上线，以及运维等，我相信大家对于瀑布式开发模型非常熟悉，现在大部分的甲方IT部门或者乙方公司都采用这样的交付管理手段。同样，大家和我也有相同的感触，系统的需求可能不断地在变化，或者是调研不清楚，亦或设计不能够满足用户需求，没有别的选择，只能硬着头皮加班加点修改，呵呵，这也是程序员经常吐槽的地方…本质上，瀑布式的开发模型是“非常害怕变化的”，一旦有“任何的风吹草动”整个项目组都紧绷神经，进而通宵达旦；而敏捷模型则是“拥抱变化的”，敏捷拒绝“一成不变”，崇尚软件系统功能“持续增强”，它是把整个软件交付周期“拆”成一个一个小的瀑布模型，每个瀑布模型持续一周或者两周，我们把它称作“冲刺”，在每一个冲刺中都要进行需求的讨论和确认，都要对交付的成果进行评审，并且项目组还要进行自身的反思和回顾，这样即使变化来了，我们通过敏捷模型能够“轻松的应对”。

   有一个例子，共享单车刚刚起步的时候，市场上共享单车的公司不多，共享单车的创新是通过互联网和手机支付的手段，帮助和方便用户完成 “最后一公里”的交通出行。起初共享单车业务逻辑是一辆自行车的成本大约200元人民币，设计寿命是3年，用户骑行一次大约需要支付1块钱，一辆自行车一年差不多可以收回200元的成本，第二年和第三年就可以实现盈利。但是，没有想到不到半年时间，其他的共享单车如雨后春笋般的出现，而且价格更低，并且有各种优惠活动。第一个吃螃蟹的共享单车企业原来的商业模式已经失效，但是他们发现他们有一个很大押金池子，如何有效的利用这笔资金成了他们“最后的救命蒿草”，他们的软件系统功能如何支撑“有效的利用这笔资金”成为了他们迫在眉睫要解决的问题。如果采用瀑布式的开发模型，按部就班，“3个月或者半年之后交付”，可能市场又不知道发生了什么变化。而敏捷的模型则可以在一定程度上很好的应对这样的突发情况。

   总之，敏捷的核心是快速地应对变化，本质上，它并不能缩短软件交付的周期。有时候我们感觉“敏捷快”是因为它能够快速的响应市场或者用户的需求变化，而不是以前瀑布模型中，用户和项目组都为“这个功能是这个样子的，而不是现在开发成的这个样子”而相互的扯皮，推诿…

   当然，我们在瀑布模型中也会主动或者被动地使用到“敏捷”，用户提出需求变更，今天晚上或者明天就可以看到结果。

2. 之前的项目管理一般先出文档，跟着文档来开发，现在实施敏捷之后，大家主要是以沟通为主，有些需求不是一定要有文档才能开发，可以说在开发过程中有些需求通过沟通取代了文档。是不是敏捷就不需要文档了？

   在敏捷宣言中四个核心价值观：

   • 个体和互动 高于 流程和工具
   • 工作的软件 高于 详尽的文档
   • 客户合作 高于 合同谈判
   • 响应变化 高于 遵循计划

   其中，“工作的软件 高于 详尽的文档”，对于这句话的解读，以及根据实践获得的经验，并不是实施了敏捷之后，就不需要文档，俗话说“好记性不如烂笔头”，有很多的文档，还是必须要做的，例如功能设计文档，DDD设计文档，UI设计文档等。从敏捷的思路来说，只是认为相互沟通的效果会比文档去理解的效果要好，所以大部分的东西主张以沟通为主，文字为辅，如果沟通可以解决，那么文档如果没有什么附加价值就不写，但是如果它还是很有价值的，比方说功能设计，是以后需要看的，那就要写，所以做与不做看价值。

   有价值的我们做，没价值的不做，举个例子，某银行去做敏捷转型之前，非常重视文档，每个文档都要思考很久才提交，他们一个项目的立项到结项要写55份文档，实施敏捷之后，从内部把文档裁剪到17个，从55到17个，而不是从55到0。那保留些什么，不保留什么，要看这些文档是怎么用的，有没有价值。

   所以我们要自己判断一下要的是什么，不要的是什么。总的来说，你用了敏捷之后不是没有文档，而是把没有价值的文档删掉。

   根据我们的经验，文档的更新也是一个敏捷和持续的过程，例如UI设计文档，我们会不断地与用户或者利益相关者沟通UI界面，每个冲刺都要沟通碰撞，直到某一个功能的设计满足美观、易用的要求。在这过程中，我们的UI设计师会根据反馈设计出不同的版本，甚至前端工程师要先实现这些UI设计，根据实践的效果不断地调整，直到项目组满意，再跟用户沟通，如果用户不满意，我们回来继续修改，就这样不断的“反反复复”，持续地更新。

3. 敏捷倡导以沟通来代替文档，但是团队不是一成不变的，有成员走有成员进，这时候我们如何要做好经验的传递？

   新人来直接看文档就可以很快了解融入到团队里面是很难的，大部分的敏捷团队是通过沟通融入进去的。

   比如：已经写好了一个文档，已经进行开发，突然间需求变更过来了，大部分的时候，需求突然变更，是不会先改文档再开发的，结果导致文档跟开发的情况不一致，新人看完文档后还是要再去理解代码，所以我们假设只要文档写好，后边的交接理解没有问题，新人都能理解文档里的内容，是不对的。

   团队人员的流动不会全部流动，可能是十个里面两三个的概率，团队的其他人和新人沟通交流就好，如果有些比较重要的系统设计等，那就把系统设计重要的几页写下来，比方说接口，如何调度等很紧要的东西写下来，不需要面面俱到。开发结束写文档，也不需要担心新人无法融入。

   如果真的觉得我们缺少了某些文档，应该在团队里说明，我们的开发过程应该做那份文档，比方说比较完整的测试用例，完整的需求场景描述等这些文档。

   还有一个做法，这个我们在新老交替经常使用，就是结对编程。我们会安排“师傅”带着新人，一起做一段时间，在这段时间，“师傅”会将我们这边的基本情况，系统架构，功能，技术栈，规范等教给新人。并且会分配给他一些编程的工作，这样持续1-2周左右，新人基本上能够融入到现有的团队。

   总之，通过纯文档的形式做新人的培训是很难的，应该采用沟通 + 文档的方式。

4. 敏捷过程中还是存在传统项目中项目经理这个角色？

   如果用的是scrum模型，是没有定义项目经理这个角色，这个职责被PO和scrum master分摊掉，如果不是用scrum的模式，比如用看板模型，就没有说不要项目经理，而是继续引用现有角色。从广义的角度来说，敏捷中“没有项目经理”这句话不是完全正确的，但如果你用敏捷scrum模型，确实没有定义这个角色，但只是敏捷scrum模型而已，敏捷还有n多模型，项目经理的角色剔除或者不剔除要看我们使用的敏捷模型是什么。

   根据我们的经验，Scrum模型中可以没有项目经理，这个职责被PO和scrum master分摊掉。PO主要对产品负责，他以产品为引导驱动整个开发Team，类似“连长”“排长”的角色；而Scrum Master则是对整个软件生产经营活动中的“规章制度”“流程”等负责，类似“政治委员”的角色。但是 ，我们在实际的操作过程中，还需要另外一个角色“技术负责人”，虽然说Scrum模型中定义的开发团队，应该是一个自组织、跨职能的团队，但是对于产品的架构、系统设计、开发规范等，都需要一个有经验的技术牵头完成，包括代码质量保证等，我们尝试过没有这样的一个人（说起来都是泪），最后前后端代码的质量非常差，而且后端出现了严重的性能问题，原因就是没有一个相对来说有一定技术权威的人，来配合项目组管理整个技术设计和规范。敏捷的转型本质上是要为每一个人赋能，但是实际情况是，项目组内部的人员能力、经验等会出现参差不齐的情况，如果是按照Scrum模型教科书式地推进，大家认为开发团队是一个“自组织、跨职能”的团队，让他们“完全自我管理”，那么就特别容易失败。所以，不管是使用哪一个模型都是需要根据实际的情况来操作，而不是完全教科书式的转型，但是刚开始的时候总是有一个摸索期。

5. 多组之间依赖性强，敏捷小组之间的协调，有一些团队是依赖于某一个团队的，这个团队自己的任务和故事还没进行下去的时候，可能就要帮其他团队的任务，就阻塞自身的敏捷进行，团队之间的协作应该怎么更好去处理？

   对于跨组协调，有很多模型可以使用，比如scrum的标配scrum scrum模型，scrum scrum模型能在跨组上面进行定期的沟通，以便沟通之后能尽快解决团队之间存在的问题，如果没有这样的机制，进行定时的沟通；请人吃饭，搞好关系也是可以的，呵呵…

   有跨组机制只是多一个方法和工具，无论你用新模型还是旧模型，跨组中肯定会存在协调问题。用了敏捷模型后，会给你一个沟通渠道，比如定时的会议，跟其他团队去协同沟通。在选择跨团队协作机制的时候，简单够好用就可以，不用太复杂。

6. 与传统的项目管理方式对比，客户方习惯了将开发拆分到任务层面并指定deadline，而且传统的项目往往瀑布式比较多，会有大量的文档，当以用户故事的方式驱动开发，客户方业务只能看到用户故事，看不到具体内容，心中没底，总是存在质疑。这样的情况，我们应该如何和客户进行沟通交流？

   首先，我们要看当客户是不是很了解，敏捷方法的推行是客户方提出，还是我们推荐的。如果是客户提出的，必然会按照这个方法去做，如果是我们主张，我们团队有能力完成这样的交付，我们就要给客户解释，消除客户的质疑。

   我们可以把以前的工作方法写一个flow给他，新的方法也写一个flow给他，进行一个简单演示，之前的flow，从需求到PRD，PRD到设计的一系列流程，以前的flow流程，和新的flow进行对比，敏捷化之后我们都会有与之对应或者替代的环节，比如计划会对应需求到PRD这一过程，可能以前的flow你会看到PRD，现在敏捷化之后被用户故事替代，其他也是一样，你虽然看不到之前的，但是依然可以从某个方面获取到进度以及其它方面需要的信息。

   总体来说，遇到这种情况，我们自身先学一点这方面的能力，实施的技术人员和业务人员如果没有完成敏捷相关培训和教育，敏捷推行的时候，我们要帮助客户简单了解敏捷的意义，推行敏捷能够带来什么样的好处，但是归根到底我们是做交付的，未必能给出一个很好的解释。要让客户知道我们之间少了一方沟通交流的人来解释敏捷实施过程遇到的问题，关于敏捷的教育培训，客户方自身那边安排一下会更好。

   总的来说，敏捷转型不是一蹴而就的，而是一个持续的过程，在这过程中会有各种各样的问题出现，而且不同的公司，不同的文化，遇到的问题也不尽相同。遇到问题很正常，我们只要“咬定青山不放松”，在问题当中不断的解决问题，就一定能够发挥敏捷真正的威力，不断提升软件交付的效率和质量。

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

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

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

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

故事地图

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

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

创建故事地图的8个步骤：​

1. 在公司或部门内找到最熟悉我们要开发的产品领域3-5人。之所以将范围定在3-5之间。因为少于三人很大程度上你没法得到足够的建议，而多于五人则讨论和协调会浪费很多时间，降低会议效率。
2. 使用头脑风暴模式，让每个人在便签纸上写下自己认为重要的“所要做的事情”也就是用户任务（user task）。每个人都用同样颜色的便签来书写自己的用户任务描述，这个阶段不要互相讨论。一旦大家都基本完成了准备，让每个人轮流大声读出自己的内容，并把便签纸全部放置在桌面上，这时如果出现重复的内容就可以省略掉：
   • 根据你的产品规模不同，这个过程可能需要3-10分钟的时间，通过观察实际状况而定
   • 这些便签组成了一级用户故事，Jeff Patton称为用户任务（user tasks）
   • 我们可以提示参与者：我们只用了很少的时间就完成了需求的收集过程，而且有些你可能没有想到内容，其他人帮你想到了
3. 将桌面上所有的便签进行分组，将类似的任务分为一组：
   • 分组过程最好不要以讨论的模式进行，速度会更快。如果发现重复的内容，就略过
   • 这时同样观察每个人的行为，判断大家是否已经做完，基本上这个过程需要2-5分钟
4. 选择另外一个颜色的便签，对分好每个组进行命名，贴在每组便签的上部。
5. 对这些分好组的便签进行排序，一般按照用户完成操作的顺序，或者是其他的方式等，从左到右摆放：
   • 如果大家无法决定顺序，那么顺序可能没有那么重要（明显）
   • 这一组便签，Jeff Patton称为 用户活动 （User Activities）
   • 这时你的地图应该类似于
6. 现在，从粉色便签这行开始讲述用户故事，确保你没有遗漏任何用户活动和用户任务。这时一般由组织者来进行讲述，其他人提出意见，甚至可以让最终用户来参与讨论。
7. 以上我们已经完成了用户故事地图的基本框架；可以在每个用户任务下面添加更加细节的用户故事（User Stories）了。我们仍然建议使用头脑风暴的模式来进行第一轮用户故事的产生，同时可以借助如Persona和Scenario等方式协助完成这个过程。当我们完成了用户故事的创建，就可以开始划定发布计划（Releases)：
   • 在第一个发布计划中只选择每个用户任务的2-3个用户故事。这对于帮助大家排定优先级和范围将很有帮助
   • 通常情况我们不必使用用户故事的标准句法来书写这些故事，因为每张便签都处于我们的地图的特定位置，很容易识别其所处的场景和角色
8. 最后，针对第一个发布的所有用户故事进行分解，确保我们的第一个发布越小越好，基本上你需要保证在1-2个迭代后就可以发布你产品的第一个版本。

Choerodon故事地图样例​

• 第二行所包含的内容就是“相应的角色对应的活动”，包括类似：用户角色管理，服务管理等等。
• 第一行说明有哪几类不同角色。
• 橙色和蓝色标签包含了目前整个项目整体规划的所有用户故事，但会随着项目进行进行适当调整和完善。

现在如果我们专注于完成导入冲刺的橙色便签，我们就可以确保很快发布一款具有用户价值小功能的产品。这样我们就可以验证我们正在开发或修改的小功能点（如：去掉发布管理员，将服务发布权限更改等）可行。同时也可以帮助我们对系统的功能进行端到端的测试，确保我们可以从用户处获取到反馈，知道我们是否解决了它们的问题（提供了商业价值）。

Choerodon用户故事样例​

• 点击“+”，查看每个用户故事（user stories）的相关用户任务（user tasks）有哪些
• 直接清晰看到用户故事相应负责人
• 用户故事（user stories）可以根据优先级自上而下排列，大家可以根据优先级和状态进行评估，对开发进程进行适当的调整

迭代

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

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

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

根据每个团队的实际情况，一般建议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”（完成）两列。

一旦测试人员完成了一个特性的测试，就会将卡片移走，并且在“测试”列空闲出一个卡片位置。

现在，“测试”列中空出来的位置可以用开发“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，对于讨论内容整理成会议记录，并发送给整个团队和有关同事。

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

关于猪齿鱼​

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

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon