Skip to main content

· 16 分钟阅读

现在越来越多的项目使用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、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。

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

· 12 分钟阅读

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

2018年7月20日，Choerodon猪齿鱼发布0.8.0版本，为了使您的应用交付更加敏捷化，运营管理更加自动化，本次更新加入了知识管理、测试管理等新服务，并且大量的功能优化也在新版本中得以实现，特别感谢社区中的朋友给Choerodon猪齿鱼提出的诸多中肯意见，让我们一起做的更好！

  • 发布版本：0.8.0
  • 发布时间：2018年7月20日
  • 功能范围：知识管理、测试管理、敏捷管理、持续交付、运营管理，以及微服务开发框架等

下面就为大家带来详细的版本更新介绍！

新发布的服务​

1.知识管理

知识管理服务是一个轻量级的强大Wiki平台，允许用户根据自己的特定需求自定义Wiki，为企业、IT团队提供方便的项目协作平台和强大的项目内容管理平台，集中式管理产品相关内容等，例如需求收集、架构设计、功能设计、开发规范、命名规范、会议记录、计划安排等。

主要特点：

  • 知识沉淀——沉淀软件开发过程中的需求、设计、规范等知识文档。
  • 项目协同——有效管理项目中的计划安排，会议记录等，加强项目成员之间的合作。
  • 产品文档——便捷地编写软件产品的概念说明、用户手册、快速入门等产品文档。
  • 培训教材——方便地编写软件功能使用等培训材料，甚至视频教程等。

2.测试管理

测试管理主要为用户提供敏捷化的持续测试工具，功能包括测试用例管理、测试循环、测试分析等，可以有效地提高软件测试的效率和质量，提高测试的灵活性和可视化水平，最终减少测试时间，让用户将主要精力放到软件功能构建上。

主要特点：

  • 敏捷化 ——测试管理与敏捷管理集成，为用户提供无缝的敏捷体验。
  • 自动化——与主流的自动化测试框架集成，显著提高测试的自动化覆盖率。
  • DevOps——提高DevOps全流程端到端的测试可视化程度，提高软件交付的质量和资源利用率。
  • 测试分析——最大限度地利用自动化，优化测试用例实现，以及缺陷趋势预测，提高软件交付质量。

新增功能​

1.敏捷管理

敏捷管理服务新推出了新功能方便对版本和问题的管理，主要新增功能如下：

  • 版本报告功能：通过版本报告来详细展示团队在完成版本方面的进展，同时报告会根据剩余预估时间、故事点、问题计数进行筛选，还会根据您的团队自版本开始以来的平均进度（速度）以及估计的剩余工作量向您显示预测的发布日期。

  • 累积流程图功能：累积流程图是一个区域图，显示应用程序、版本、sprint的各种工作项状态。水平x轴表示时间，垂直y轴表示问题计数，图表的每个彩色区域等同于面板上列的问题变化，累积流程图可用于识别瓶颈，如果您的图表包含随时间垂直加宽的区域，则等于加宽区域的列通常会成为瓶颈。

除此之外，敏捷管理服务还增加了问题导出Excel功能，问题转换为子任务，问题复制，以及版本界面新增查看发布日志等功能。

2.持续交付

  • 增强分支管理功能，支持更多的分支管理模型，0.8版本的分支管理功能比原来更加灵活，例如，支持gitlab-flow和github-flow模型，实现分支与敏捷管理的问题关联，实现敏捷问题管理及持续交付代码管理一致性，以及分支管理集成push、merge request webhook。

  • 在实例部署阶段日志中增加阶段执行相关事件日志。在输出阶段Job pod中日志之前，增加了Job启动详细过程的日志记录，例如该阶段Job开始，分配节点，拉取镜像，执行。以便于在部署实例时，排查各个阶段的执行日志，方便部署人员快速的定位问题。

  • 应用管理增加sonarqube代码质量检查链接跳转，方便用户查看代码质量检查的结果。

另外，持续交付服务还增加了版本升级的时候通过请求API实现版本间的平滑升级，用导出时默认获取所有应用的最新版本，以及置文件信息支持保存新增的参数等功能。

3.微服务开发框架

微服务开发框架增加了如下的功能：

  • 新增微服务功能，可以查看平台中的所有微服务。
  • 新增API测试，可以查看微服务下的controller以及controlller下面的API接口。
  • 新增个人中心的组织和项目信息，可以查看在不同组织或者项目中被分配的角色以及这些角色的权限。
  • 客户端新增了作用域和自动授权域字段。

功能优化​

1.敏捷管理

在敏捷管理中，0.8版本还修改优化了如下部分功能：

  • 更新问题的版本关联，不能删除已经归档的版本关联。
  • 优化搜索接口，修改触发逻辑。
  • 报告界面可以关联查看问题列表和每个问题详情。
  • 发布版本问题可以通过点击链接到问题管理中。
  • 还有其他诸多细节的优化。

2.持续交付

在持续交付中，0.8版本还修改优化了如下部分功能：

  • 修改CI生成版本号的命名规则。
  • 配置文件信息存储方式修改为只保存修改内容。
  • 优化部分页面字段长度及显示方式。
  • 修改Agent默认返回消息行数。
  • 完善网络唯一性校验及域名地址校验规则。
  • 还有其他诸多细节的优化。

3.微服务开发框架

在微服务开发框架中，0.8版本增强了部分功能：

  • 创建组织优化为组织列表跳转到第一页。
  • 删除自设目录时提示优化。
  • 创建用户、修改用户页字段优化与密码取值修改。
  • LDAP组件合并优化。

缺陷修复​

1.敏捷管理

0.8版本修复了如下的缺陷： 简易创建问题卡顿。 问题详情锚点定位不准确。 问题标题为编辑状态时切换时，编辑框内容会被清除。 富文本编辑器在多英文的情况下断词失败。 还有其他已知bug。

2.持续交付

0.8版本修复了以下缺陷： 修复Select框的全选取数据问题。 Table组件的筛选条件，从父组件刷新无法清空。 修复网络管理修改网络切换版本未清空实例值的问题。 修复实例详情日志阶段切换内容未改变的问题。 修改Agent多余时间戳的问题。 还有其他已知bug。

3.微服务开发框架

0.8版本修复了以下缺陷：

  • 修复添加权限时，如果进行了权限过滤，再次进入没有清空搜索结果的问题。
  • 修复项目无法停用成功的问题。
  • 修复后端配置https不跳转的问题。
  • 修复用户全局过滤时后端没有返回数据的问题。
  • 修复密码策略无法保存的问题。
  • 修复实例管理在选择微服务之后，不能查询对应的实例的问题。
  • 修复个人中心页修改头像之后，再次保存用户时失败的问题。
  • 修复无法更新用户的问题。
  • 修复移动端无法登录跳错误页的问题。
  • 修复实例详情元数据标无过滤表文字的问题。
  • 修复liquibase工具包如果excel的某一行有空值的问题。
  • 还有其他已知bug。

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

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

· 10 分钟阅读

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

2018年6月29日，全场景效能平台——Choerodon猪齿鱼发布0.7版本。0.7版本主要新增敏捷管理服务、持续交付和微服务开发框架的部分功能，并对他们的服务进行了优化，同时修复了0.6版本若干bug。

敏捷管理​

敏捷管理服务新增了如下的功能:

  • 冲刺报告功能：记录进行中以及结束的冲刺的问题统计，包括冲刺期间已完成的问题、未完成的问题、从冲刺中删除的问题，用户选择冲刺后，可以查看当前选择冲刺的报告记录以及当前选择冲刺的简易燃尽图。
  • 冲刺燃尽图报告功能：记录进行中以及结束的冲刺中问题的操作事件并生成报告以及图表信息，选择冲刺后可以通过剩余预估时间、故事点、问题计数对问题（包含子任务）进行统计。
  • 版本合并：撤销归档，版本状态回到上一个状态。
  • 活动日志：问题的更新操作都将被记录在活动日志中，可以在问题详情中查看，冲刺统计信息都从活动日志中生成。
  • 问题链接：用户可以在问题详情选择链接类型链接对应的问题，创建项目会默认3个类型：阻塞、复制、关联，支持在设置功能自定义链接类型。

并且，在敏捷管理中，0.7版本还增强了如下部分功能：

  • 冲刺与问题的一对一关系改为多对多。
  • 创建问题子任务状态与父问题状态相同。
  • 支持删除计划中的冲刺。
  • 待办事项的史诗、版本可以通过问题是否完成展示进度条。
  • 创建冲刺时定位到新创建的冲刺。
  • 可以在问题详情中对问题状态进行修改。

持续交付​

持续交付服务新增了如下的功能：

  • 新增应用导入和导出功能，以便于跨平台的迁移应用
  • 网络管理、域名管理的不可用验证，以及网络端口合法性验证和域名管理Path地址重复性验证。
  • 支持中英文模式。
  • 停用环境时校验该环境下不能存在网络及域名设置。

同时，在持续交付中，0.7版本还增强了部分功能：

  • 后台报错支持中英文翻译。
  • 修改两个API命名使其符合命名规范及权限检查规范。
  • 优化用户获取预定义应用模板获取方式，无需再手工创建。
  • 表格列宽自适应。
  • 统一页面中表格表头的命名标准。

另外，还增强了其它功能，例如：

  • 优化网络管理代码质量。
  • 网络名称不可修改。
  • 去除应用的仓库地址相同部分的冗余显示。
  • 应用图标上传使用相对路径。
  • 优化实例单应用界面选择应用的展示方式，默认显示项目应用及应用市场两个分类，可扩展显示更多。

最后，0.7版本修复了0.6版本的缺陷：

  • 应用部署时Values替换错乱。
  • 持续集成流水线时长不准确。
  • 应用市场中应用详情README在部分情况下无法获取。
  • 优化持续集成分步请求API导致的界面延迟问题。
  • 个别表格分页的缺陷。
  • 根据应用筛选对应应用版本时，值集过多的缺陷。
  • 完善应用版本页面的提示语。
  • 持续集成流水线缺少tag类型最新流水线Latest标识的缺陷。
  • 了解详情链接点击后在本页打开的缺陷。
  • 配置信息页面在页面缩放时yaml行高计算不准确的缺陷。

微服务开发框架​

微服务开发框架增加了如下的功能：

  • 新增实例管理，可以查看微服务框架中的所有正在运行的实例。
  • 新增配置管理，可以管理微服务中服务的配置，并对配置进行修改，创建，设为默认等。
  • 个人信息页字段丰富，用户修改头像添加裁剪功能。
  • Select组件新增 loading 属性，获取异步数据时，可置为loading状态。
  • 增加 isModifiedFields, isModifiedField 方法。
  • 增加文件服务配置属性fileServer。
  • 增加注入环境变量配置属性enterPoints函数。

同时，在微服务开发框架中，0.7版本还增强了部分功能：

  • 个人信息修改了界面样式
  • 页面菜单样式修改，由之前的固定在左侧变为可以收缩展开。
  • Table: 排序图标样式调整。
  • Select Input Radio DatePicker: 样式调整。
  • 完善多语言文案。
  • 菜单初始化逻辑修改。

最后，0.7版本还修复了0.6版本中的bug。

  • 修复了表格中样式对齐和行间距的问题。
  • 修复了403、404页面自适应的问题。
  • 修复了组织管理中由于多语言引起的组织管理启停用提示错误、编码字符限制无提示、修改功能不可用等问题。
  • 修复了菜单配置中目录编码重复无提示、空目录保存后消失、提示样式不固定等问题。
  • 修复了角色管理中创建角色没有跳转到列表页、权限为空报错提示触发条件错误等问题。
  • 修复了角色分配中过滤角色跳转到白页、将成员角色全部删除后未清除成员数据、列表中角色与成员未对齐等问题。
  • 修复了Root用户设置中滤时查询的不是root用户而是所有用户、点击刷新后倒序消失的问题。
  • 修复了微服务管理中ChoerodonExtraData路由刷不进去、yml文件显示null的问题。
  • 修复了用户管理中由于多语言引起的时区没有默认值、登录名和密码输入框报错提示为英文的问题。
  • 修复了LDAP无数据时同步用户一直处于loading状态、测试连接数组越界等问题。
  • 修复了项目信息项目名称为空无判断的问题。
  • 修复了个人中心修改密码的新密码与原密码相同时后端报错的问题。
  • 修复了后端框架中验证码区分大小写、更新网关配置出现的异常、快码查询接口500错误等问题。

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

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

· 8 分钟阅读

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

2018年6月10日，全场景效能平台——Choerodon猪齿鱼发布0.6版本。0.6版本主要新增敏捷管理服务，并对已有的服务进行了优化，同时修复了若干bug。

敏捷管理​

敏捷管理服务主要用来管理项目的需求、计划和执行，包括问题管理、待办事项、版本发布、活跃冲刺、模块管理等。

  • 问题管理：用户可以以模块、修复版本、标签、史诗、冲刺等方式管理项目中的问题，支持问题查询、创建、编辑、协作处理和添加子任务。
  • 待办事项：管理史诗、版本和冲刺，用户可以构建一个新的待办事项，或者对现有的待办事项进行处理，包括创建、排序和筛选。
  • 发布版本：管理追踪项目版本，查看版本状态，编辑版本详情，并对一个版本进行发布。
  • 活跃冲刺：通过看板来观察和管理工作，展示团队目前正在进行的冲刺，支持问题的创建、更新、筛选、删除和时间追踪，支持问题状态更改，以及列的自定义配置。
  • 模块管理：通过模块对项目问题进行分类管理，例如“后端任务”，“基础架构”等。

持续交付​

持续交付服务新增了如下的功能：

  • 增加发布管理，包括应用发布及应用市场。
  • 在网络/域名管理中，增加网络/域名状态和操作类型及状态，以便跟踪网络/域名的运行情况。
  • 增加容器日志，以便追踪容器运行情况。
  • 在环境客户端上增加资源对象一致性机制，同时增加消息发送失败及超时确认机制。

同时，在持续交付中，0.6版本还增强了部分功能：

  • 重构应用部署页面，移除实例查看功能，增加应用实例页面。
  • 在网络管理中区分自身端口和目标端口。
  • 改进应用部署方式，从纵向步骤条到横向步骤条。
  • 提升实例用户体验使得更简洁直观。
  • 修改三个预定义应用模板使其能顺利生成版本及部署成功。

另外，还增强了其它功能，例如：

  • 改善values的替换方式及yaml主题配色使得用户体验更佳。
  • 基于更规范的命名规则修改一些API。
  • 为了修改传值模式重构gitlab-service。
  • 优化了首次用helm部署的实例扫回机制。

微服务开发框架​

微服务开发框架增加了如下的功能：

  • 新增Root管理员，可以管理平台的设置以及平台中所有组织和项目。
  • 新增用户修改头像、用户名和邮箱功能，用户个人中心页面优化。 新增微服务路由管理功能，用于可视化管理微服务的后端路由。
  • LDAP 支持自定义用户属性，增加页面测试连接和同步用户功能，目前支持OpenLdap 和 Microsoft Active Directory两种目录类型。
  • 认证服务添加redis作为存储登录session，用于保证认证服务开启多实例时的用户会话。

同时，在微服务开发框架中，0.6版本还增强了部分功能：

  • 平台权限校验逻辑完善。
  • 注册中心支持指定namespace的服务注册。
  • 菜单icon替换，文字间距调整。
  • 页面图标间距统一，添加提示文案，按钮操作提示文案优化。
  • 页面增加删除确认提示，降低误删几率。

最后，0.6版本还修复了0.5版本中的bug。

  • 修复组织下创建项目时，项目编码不是组织内唯一，而是全局唯一的问题。
  • 修复新增角色分配时，会将用户已有的角色的标签清除的问题。
  • 修复注册中心发送事件异常，kafka消息不带有时间戳的问题。
  • 修复manager-service有时候权限刷新不进去的问题。
  • 修复火狐浏览器下菜单配置功能无法使用的问题。
  • 修复角色分配中，无法按照角色查看成员的问题。
  • 移除页面中不正确的权限编码，该bug会导致页面无法按照应有的权限。
  • 修复菜单配置中，一个自设目录放在另一个自设目录下时，会导致两个目录消失的问题。
  • 修复分支管理的版本判断逻辑错误及前台提示错误。
  • 修复url出现双斜杠导致代码库无法拉取。
  • 修复标记列表不能分页。
  • 修复devops和choerodon-agent重启后各对象状态不一致。
  • 修复组织管理员不在gitlab template group中的问题。

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

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

· 9 分钟阅读

自5月20日Choerodon猪齿鱼平台发布以来，得到了社区成员的积极关注，很多人好奇我们的PaaS平台为什么会使用“Choerodon猪齿鱼”这个名字：

“猪齿鱼是一种鱼吗？真的有这种鱼吗？”

“这个名字很特别，我喜欢！”

“这个名字很难记，怎么会取这么一个名字呢？”

“我猜你是看过纪录片《蓝色星球2》！”

“猪齿鱼怎么和产品联系起来？”

......

下面让我和大家一起聊聊“Choerodon猪齿鱼”这个名字诞生的故事：

容器家族：从“船长”到“鹦鹉螺号”​

最初我们想要打造这样一个企业级应用PaaS平台：基于容器技术，整合DevOps工具链、微服务应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理。同时团队确定了技术堆栈的要求是充分的使用主流成熟的组件，利用工具的扩展机制来构建平台，为企业打造开放的技术平台和体系，让企业享受到社区带来的收益。

由于平台是基于容器技术的，一开始我们想取一个和容器相关产品有关的名字，对Docker、Kubernetes、Harbor、Helm等产品的名称进行了一些分析和研究，希望能从中得到一些灵感。

docker.png

Docker名如logo，是装载在“蓝鲸”这条大船上的集装箱，容器就是通过集装箱将“应用程序”封装在一起，同时保证集装箱之间不会互相影响且方便调配。

k8s.png

自动化部署和操作应用程序容器的平台Kubernetes，名称来自古希腊语，有“掌舵手”的意思，logo是一个船舵，如“舵手” 一样为“集装箱货物”掌舵护航。

Helm就更有意思了，作为Kubernetes应用的一个包管理工具，Helm是“舵柄”的意思，“Kubernetes舵手”操作着“Helm舵”，驾驶着装满“Docker集装箱”的船在大海里航行。

Harbor是存储和分发Docker镜像的服务器，标志是一个字形艺术化的灯塔，名称英译为“海港”。

我们的PaaS平台是基于以上工具来帮助企业聚焦于业务，更关注的是如何去使用好这些容器技术，那应该要取一个比这些更厉害的角色才行，已经有了集装箱、舵手、舵和海港了，缺少一个领航者“船长（Captain），这个看上去和我们的平台定位有较高的吻合度。

团队讨论之后觉得“船长（Captain）”这个名字不够具象，无法让人很容易地和某个具体的事物联系起来，无法使人产生好奇而想去了解它。并且这么多容器相关的项目也不曾使用它，我们使用“船长”可能会给人一种狂妄自大的感觉，所以决定还是不采用这个名字。

“船长（Captain）”取名失败后，Choerodon猪齿鱼架构师叶德华提出，自己小时候很喜欢《海底两万里》故事书中的主角尼莫（Nemo）船长，他制造并驾驶世界上独一无二的潜艇鹦鹉螺号（Nautilus）在海底进行惊险刺激的冒险旅行，他利用鹦鹉螺号攻击侵略者的军舰，并帮助那些被压迫的民族和穷苦的民众。

尼莫船长沉着机智的正义形象和鹦鹉螺号无限海上航行的能力用到我们的平台应该是个挺不错的主意，得到了大家一致的认可。只可惜的是鹦鹉螺号（Nautilus）相关的名称和域名都已经被注册使用，这个取名以失败告终。

动物家族：“猎豹”到“深海鱼​

大家都深感取名是个技术活，有种山穷水尽的感觉。

有人分析认为产品名称和动物界有很深的渊源，很多产品都是以动物来命名，动物的名称能够让人很容易记住并产生亲近感，大家可以挑选一些特别的动物来作为名称。

有成员提议用陆地上奔跑速度最快的动物“Cheetah猎豹”这个名字，猎豹迅捷快速飞奔的身姿给人一种灵敏潇洒的印象，很容易让它人喜欢和记住，但是好像和我们的PaaS平台无法很好的结合起来。

Choerodon猪齿鱼高级架构师蒋尚勤提出，《蓝色星球2》中记录了一种深海鱼，这种鱼使用工具来获得食物，颠覆了人类对鱼的认知，但是不记得他叫什么名字，可以查一下使用它......

通过观看纪录片确定这个鱼叫做Tuskfish，中文名翻译为“猪齿鱼”，影片中的这条鱼每天到海底利用鱼翅和嘴巴去除障碍物寻找蛤蜊，咬住蛤蜊后游过很长的距离去利用礁石来撞击蛤蜊壳，经过多次不懈的努力最终吃到最喜欢的食物蛤蜊肉。

猪齿鱼，善于利用工具、行动灵活富有条理、有思想有毅力，和我们PaaS平台整合工具来提供服务能力，帮助企业聚焦业务，最终提升企业数字服务能力的定位相吻合。

但有一个问题是，Tuskfish感觉不够神秘也不够酷，我们希望能够像Kubernates这样有一个古希腊的名字，这样才能够有一种神秘感，我们通过鱼库网站www.fishbase.org 了解到，猪齿鱼属学名“Choerodon”，源于希腊语，单词由两部分组成，choiros 是希腊语“猪”的意思，odous则代表牙齿，一个词就概括了猪齿鱼的形象特征，很有特点，单词结构有记忆点，读起来也比较顺口，还带有一丝神秘色彩。

同时Choerodon相关的名称和域名都没有被使用，最终选定“Choerodon”猪齿鱼作为我们平台的名字，真是“众里寻他千百度”。

“Choerodon”这个词看着倒也顺眼，但是每次拼写是不是有点太长了？

那就给他取个小名吧：c7n

Choerodon = c7n

· 8 分钟阅读

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猪齿鱼帮助他们缩短软件交付周期，提高交付质量，减少运营支出，提高企业信息化系统对市场和需求反应的敏捷度。

· 24 分钟阅读

摘要：敏捷转型并没有那么简单，不是把那一套运作模式运作起来就可以，毕竟每个公司的情况都有所差异，仅仅把敏捷那一套运作模式照搬过来是远远不够的。对于管理者来说，希望通过敏捷提升软件交付的效率和质量，并且希望通过敏捷转型打造一个高效、学习型的团队。其实，敏捷是一个很强大的工具，运用的好确实可以收到很好的管理和交付效果；但是运用的不好，很可能就会事倍功半。本文将总结在过去的一段时间里，我们自身在敏捷转型过程中踩过的坑，希望对大家在做敏捷转型或者实施的有一定借鉴意义和帮助。

随着互联网、大数据的发展和成熟，包括新零售等概念的提出、探索和落地，越来越多的企业开始进行敏捷转型，在软件开发过程中采用敏捷的方式，期望可以提升开发效率，改善交付质量。敏捷也不再局限于互联网行业，很多传统行业——包括银行、保险、电信、零售等等也逐渐开始认同敏捷的开发方式和流程，在企业内部的系统开发过程中把敏捷与原有的流程相互融合，以更好地适应高速、快节奏所带来的不确定性，进一步提升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、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。

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

· 23 分钟阅读

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、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。

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