Skip to main content

· 5 分钟阅读

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

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

Scrum和SAFe之间的主要差异

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

Sr. No.ScrumSAFe
1.适用于小型的、阵列的、跨职能的团队适用于大型的、多区域的团队
2.它主要被敏捷团队采用被整个企业采用,而不仅仅是一个团队。(Scrum的扩展)
3.中层管理人员起不了任何作用项目群和投资组合层是SAFe的两个重要层次
4.基本组成部分是Scrum团队.基本组成部分是敏捷发布火车(ART)
5.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的扩展框架。

· 13 分钟阅读

在敏捷软件开发中,史诗&故事都是常用的术语。对于管理敏捷软件开发来说,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. 使用增量来定期检查并调整项目进度;

总结

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

· 10 分钟阅读

原文作者:Jeff Hale

原文地址:https://towardsdatascience.com/learn-enough-docker-to-be-useful-b7ba70caeb4b

翻译:付新圆

容器对于提高软件开发和数据科学中的安全性、可重复性和可伸缩性非常有用。容器的崛起是当今科技领域最重要的趋势之一。

Docker是一个用于在容器中开发、部署和运行应用程序的平台。Docker本质上是容器化的同义词。对于有抱负的软件开发人员或数据科学家来说,Doc​​ker就是他们的未来。

如果您还不适应最新技术,请不要担心——本文将帮助您理解Docker的概念,了解Docker的过程可以想象成是制作披萨的过程。

在本系列有五篇文章,之后的四篇文章我们将会讲解Docker术语、Dockerfiles、Docker镜像、Docker命令和数据存储。阅读完这个系列(再加上一点练习),你将会了解很多Docker发挥的作用😃!

Docker的类比

首先,阐明一下Docker的类比。

谷歌中对类比的第二个定义是:

象征物被认为是其他事物的代表或象征的事物,尤指抽象的事物。

类比可以帮助我们理解新的事物。例如,物理容器的类比可以帮助我们快速掌握虚拟容器的本质。

图为物理容器

容器

以下是塑料容器对照Docker容器的类比:

  1. 容纳东西——东西要么在容器内,要么在容器外;
  2. 便携式——可在本地计算机、远程计算机或云提供商的服务器(例如AWS)上使用。就像盒子一样,你可以随时移动。
  3. 具有清晰的访问接口——物理容器有一个盖子,用于打开和放入物品以及取出物品。同样,Docker容器具有多种与外界交互的机制。它具有可以通过打开浏览器进行交互的端口,您可以通过命令行将其配置为与数据交互。
  4. 可以从远程位置获取——当您需要用到塑料容器时,您可以网购一个,这些塑料容器是商家从制造商那里购买的,这些制造商通过一个模具就能将数千个塑料容器冲压出来。对于Docker容器,异地注册表会为容器保存一个像模具的镜像。然后,当您需要一个容器时,就可以从图像中制作一个。

与虚拟Docker容器不同,网购的塑料容器需要花费钱,并且商家也不会提供商品副本。

实例

Docker容器的第二种类比是可以将其视为一个有生命的的实例。实例是以某种形式存在的东西,不仅仅只是代码,正是这些代码赋予了Docker容器生命。像其他生物一样,实例最终将死亡-这意味着容器将关闭。

Docker容器是Docker镜像的生命表现。

软件程序

除了容器类比和实例类比,您还可以将Docker容器视为软件程序。毕竟,Docker容器确实是软件,在最基本的层次上,容器是一组操纵其他位的指令。

图为容器是代码

当Docker容器运行时,通常会有程序在运行。容器中的程序执行操作,应用程序也对应执行相关操作。

例如,Docker容器中的代码已经实时将网页上读取的内容发送了您,或者可能会将您的语音命令带到Amazon Alexa,并将其解码为另一个程序并在不同容器中使用的指令。

使用Docker,您可以在主机上同时运行多个容器,和其他软件程序一样,Docker容器可以运行、检查、停止和删除。

概念

虚拟机

虚拟机是Docker容器的前身,它可以隔离应用程序及其依赖项。但是,Docker容器优于虚拟机,因为它们占用的资源更少,非常便捷,并且启动速度更快。

Docker镜像

在本文中,术语“ 镜像 ”的含义无法很好地映射到物理镜像。

Docker镜像更像是蓝图、饼干切割机或模具。镜像是不可变的主模板,用于抽取完全相同的容器。

镜像包含应用程序运行所需的Dockerfile、库和代码,所有这些都是捆绑在一起的。

Dockerfile

Dockerfile 是一个文件,其中包含Docker应如何构建图像的说明。

Dockerfile引用用于构建初始镜像层的基础镜像。流行的官方基础镜像包括pythonUbuntualpine

然后,根据Dockerfile中的说明,可以将其他层堆叠在基本镜像层的顶部。例如,用于机器学习应用程序的Dockerfile可以告诉Docker在中间层添加NumPy,Pandas和Scikit-learn。

最后,根据Dockerfile代码,在其他层之上堆叠了一个可写的薄层。(薄层的尺寸很小,在这里薄是一种类比)

在本系列的后续文章中,将会更深入地探讨Dockerfiles。

Docker容器

Docker镜像加上命令docker run image_name,可从镜像创建并启动容器。

容器注册表

如果希望其他人能够从自己的镜像中创建容器,则可以将镜像发送到容器注册表。Docker Hub是最大的注册表,也是默认的注册表。

用Docker烹饪

图为景观类比

  • 配方就像Dockerfile一样。它告诉您如何实现最终目标。
  • 成分是层。这个比萨饼有皮、酱汁和奶酪。

将食谱和食材想像成一体的披萨制作套件。这是Docker镜像。

配方(Dockerfile)告诉我们我们要做什么。计划如下:

  • 外壳是预成型且不可变的,就像基本的Ubuntu父镜像一样。它是最底层的,是首先被构建的。
  • 然后添加一些奶酪。将第二层添加到比萨饼就像安装一个外部库——例如NumPy。
  • 然后撒一些芝士。芝士就像运行应用程序的文件中编写的代码。

图为烤箱

  • 烤披萨的烤箱就像Docker平台一样。搬进烤箱并将烤箱安装到了自己的房子里,就可以制作东西了。同样,在计算机上安装了Docker,就可以制作容器了。
  • 通过旋转旋钮可以启动烤箱。该docker run image_name命令就像烤箱的旋钮一样——它可以创建并启动容器。
  • 煮熟的比萨就像一个Docker容器。
  • 吃披萨就像使用您的应用程序一样。

就像制作披萨一样,在Docker容器中制作应用程序需要一些工作,但最终您会拥的是非常有价值的。

总结

以上就是Docker概念的内容。在本系列的第2部分,将阐明在Docker生态系统中常用的一些术语。希望本文对您了解Docker有所帮助,同时也希望您看到类比在理解新技术中的价值。

· 8 分钟阅读

本文介绍了Choerodon猪齿鱼中配置 Webhook 的方法,帮助大家了解如何将Choerodon平台中各种事件的相关消息推送到钉钉、企业微信或其他支持Webhook的第三方平台或应用,从而使团队协作更加敏捷高效。

功能背景

Webhook是Jeff Lindsay在2007年提出的概念,它是一个web自定义的回调函数,当程序发生特定行为时,会自动回调指定的url。Webhook的回调url可以是第三方平台或应用,也可以是Webhook内的应用。

在Choerodon猪齿鱼中,Webhook扮演了一个跨应用、跨平台传递事件消息通知的角色。用户可以将Choerodon猪齿鱼中发生的事件通过Webhook的方式通知到钉钉、企业微信或其他支持Webhook的第三方平台。

功能使用介绍

Choerodon自V0.20.0之后便支持在“项目层-设置-通知” 中配置钉钉、企业微信与Json类型的Webhook,若想在此版本中配置Webhook,首先需要平台管理员在“平台层-通知-消息服务”菜单下为目标事件配置Webhook的默认模板,之后才能在项目层创建Webhook时选择到这个触发事件。

而在V0.22.0中,Choerodon新增了组织层配置webhook的功能,并支持查看所有Webhook的执行记录。此外,还在平台中为大部分常用触发事件预设了消息模板,避免了平台管理员手动添加消息模板的繁琐操作。下面,我们将以Choerodon V0.22.0项目层(组织层操作相同)Webhook配置的功能为例进行介绍。

创建Webhook

  • 创建钉钉类型的Webhook

若想将Choerodon猪齿鱼中的某些特定事件的消息通知通过webhook发送到钉钉群,首先需要在对应的钉钉群中添加一个自定义类型的群机器人。

完成以上步骤后,在Choerodon猪齿鱼“项目层-通知-Webhook配置”页面,点击顶部操作栏的“创建Webhooks”按钮,右侧会弹出添加Webhook的页面。选择Webhook类型为”钉钉“,将刚添加好的群机器人的密钥与Webhook地址粘入界面中对应的输入框,并在其中勾选对应的触发事件(事件的通知消息模板需在“平台层-通知-消息服务”菜单中进行设置,此处仅会展示出有消息模板的触发事件)。

Webhook创建成功后,已勾选的事件发生时,便会按照消息模板,发送通知到webhook地址,也就是群机器人所在的钉钉群。例:勾选了敏捷通知的“问题已分配”和“问题已解决”后,在这些事件发生后,便会通知到钉钉群,并@出对应的人员。

  • 创建企业微信类型的Webhook

创建企业微信类型的Webhook与钉钉类型的步骤相似,首先也需要在企业微信群中创建一个Webhook群机器人,并复制其Webhook地址备用。

完成上述步骤后,回到Choerodon猪齿鱼“项目层-通知-Webhook配置”页面,点击创建“Webhooks”按钮,选择Webhook类型为”企业微信“,将刚添加好的群机器人的Webhook地址粘入界面中对应的输入框,并在其中勾选对应的触发事件即可。而企业微信类型的Webhook创建成功后,已勾选的事件发生时,便会按照消息模板,发送通知到webhook地址,在这里也就是群机器人所在的企业微信群。

  • 创建Json类型的Webhook

至于Json类型的Webhook,则是用于向支持Webhook的第三方平台或应用发送事件通知。同样也需要指定Webhook地址和密钥,选择触发事件。步骤与钉钉、企业微信类型的Webhook类似。

管理Webhook

Webhooks创建成功之后,会展示在主页的列表之中;通过列表,可以看到Webhook中的触发事件、Webhook地址、Webhook类型以及Webhook状态(包括启用与停用状态)。

项目所有者可在列表中,对所有Webhooks,进行修改、启用/停用、删除的操作;同时,还可以查看某个Webhook的所有历史执行记录及其详情。

查看Webhook执行记录

当列表中的Webhook执行后,会产生对应的执行记录,目前可通过在列表中选择某个Webhook来查看执行记录;或者直接点击顶部的“Webhook执行记录”的按钮,直接查看所有Webhook的执行记录;此外,还可直接点击查看某条执行记录的详情,其中包括:该记录的基本信息以及在发送webhook时的详细日志。

而对于执行失败的Webhook记录,用户可在记录的详情界面中查看错误日志,并能对当前记录执行重试的操作。

总结

Webhook是一种支持跨平台、跨应用发送消息的方式,Choerodon通过配置钉钉、企业微信与Json类型的Webhook,将平台与工具串联起来,以此来实现灵活高效的团队协作。

关于猪齿鱼

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

更加详细的内容,请参阅Release Notes官网

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

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

· 11 分钟阅读

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和官网。 大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

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

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

· 12 分钟阅读

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

更加详细的内容,请参阅Release Notes官网

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

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

· 13 分钟阅读

原文作者: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指南的一部分。正因为如此,人们对如何使用故事点有不同的看法。术语“故事点”本身已经令人困惑,因为您也可以将它用于用户故事以外的工作类型,在这个“点”字上,说明一个故事点代表了价值。正如一位同事指出的那样,或许用“计划因素”一词来说故事点会更容易让人理解。本文旨在帮助大家了解在使用故事点时可能会犯的错误,并以正确的方式应用它们。

· 9 分钟阅读

通过之前的文章《Choerodon实践之集群管理(一)》,我们了解到了Choerodon集群与k8s集群之间的关联、集群权限管理以及节点详情查看的功能。那如何更加灵活便捷地对k8s集群进行监控呢?又怎么对监控组件进行安装、配置与管理呢?本文旨在为大家介绍Choerodon平台中的组件管理以及集群监控的功能。

功能背景

因为集群管理员或运维人员需要知道集群中所有节点以及节点下各个Pod的资源使用情况,为了收集与展示这些指标,Choerodon集群管理模块主要使用了Prometheus来实现对集群的监控。同时,Choerodon还在界面中提供了直接安装、配置与卸载Prometheus等监控组件的入口,用户可在此通过界面化的形式高效快速地在集群中完成各组件的安装与配置。

除此之外,为了实现在Kubernetes集群中使用 HTTPS 协议的功能,Choerodon在环境资源中支持了对证书的管理,同时为了确保集群中的证书有效且是最新的,并能在到期前按照配置的时间续订证书,Choerodon又提供了对cert-manager组件的支持,用户在组件管理界面即可实现对cert-manager组件的安装与卸载。

组件管理功能

集群管理中组件管理模块目前支持对cert-manager和监控组件(Prometheus、Grafana、AlertManager)进行安装与管理,用于管理集群下所有组件

CertManager

cert-manager 是一个云原生证书管理开源项目,用于确保集群中的证书有效且是最新的,并能在到期前按照配置的时间续订证书,支持 Let’s Encrypt, HashiCorp Vault 这些免费证书的签发。而在Kubernetes集群中,我们可以通过 Kubernetes Ingress 和 Let’s Encrypt 实现外部服务的自动化 HTTPS。

在Kubernetes集群中使用 HTTPS 协议,需要一个证书管理器、一个证书自动签发服务,主要通过 Ingress 来发布 HTTPS 服务,因此需要Ingress Controller并进行配置,启用 HTTPS 及其路由。

安装cert-manager

在“集群管理-组件管理”页面,选中CertManager组件,点击安装按钮,即可在集群中安装该组件。(此操作仅能在“运行中”状态的集群下执行)

对于Choerodon 0.20版本之前已安装CertManager组件的集群,此处会直接展示出该组件是已安装的状态。若是在升级0.20后新建的集群,则需在此处自主安装CertManager组件。

若集群未安装CertManager组件,将不能在集群对应的环境下进行“创建证书”的操作。

卸载cert-manager

在“集群管理-组件管理”页面,选中CertManager组件,点击卸载按钮即可。(此操作仅能在“运行中”状态的集群下执行)

监控组件

监控组件用于帮助监控集群中资源的使用情况,该组件包括了Prometheus、Grafana和AlertManager。其中Prometheus用于实现对监控数据的获取、存储以及查询;Grafana可作为可视化界面来展示监控数据;AlertManager则是Prometheus体系中的告警组件。

监控组件的结构图如下:

安装监控组件

在“集群管理-组件管理”页面,选中监控组件,点击安装按钮,右侧会弹出安装监控组件的配置页面,需填入:admin密码(即Grafana组件admin账户的登录密码)、域名地址(即Grafana的访问地址)、并且为其中的3个组件分别选择一个满足条件的PV(对应组件需要使用到的PV,需要提前在PV管理中创建)。配置完成后,点击安装即可。(此操作仅能在“运行中”状态的集群下执行)

监控组件安装成功后,即可在“集群管理-集群监控”页面看到集群监控的数据。

修改监控组件

监控组件安装成功后,仅支持修改域名地址(即Grafana的访问地址)。

卸载监控组件

在“集群管理-组件管理”页面,选中监控组件,点击卸载按钮即可。(此操作仅能在“运行中”状态的集群下执行)

集群监控功能

集群监控功能用于展示集群中所有节点以及节点下各个Pod的资源使用情况,如CPU、内存、网络吞吐和带宽占用、磁盘I/O和磁盘使用等指标。

在“组件管理”页面中成功安装了监控组件后,只要在页面中成功登录Grafana(此处可以使用有集群权限的Choerodon账号直接登录),即可查看集群监控数据。

集群监控界面如下:

若想查看集群下某个节点以及节点中Pods的CPU、内存的使用情况,须在树结构中点击对应的节点,最后选择“节点监控”Tab页即可。

总结

组件管理与集群监控使得Choerodon集群管理的功能更加完善。集群管理员与运维人员可以通过界面更高效地对各个组件进行安装、配置与管理。而通过集群监控功能,集群管理员与运维人员又能更便捷地监控到集群中资源的使用情况。

关于猪齿鱼

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

更加详细的内容,请参阅Release Notes官网

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

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

· 8 分钟阅读

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官网

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

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

· 9 分钟阅读

集群是用于运行k8s的托管群组,一个Choerodon集群对应一个k8s集群。有了集群,我们就能以此来统一调配资源,管理环境。结合Choerodon中的层级结构,一个集群又可以被同组织下的多个项目共同使用。

本文旨在为大家介绍Choerodon v0.19及以上版本的集群管理功能。与k8s集群相关的更多详情介绍,请查看之前的《从0到1使用Kubernetes系列》文章。

集群管理功能的改动

在介绍Choerodon V0.19及以上版本的“集群管理”功能之前,先为大家讲解该功能相较于之前版本做了哪些改动,以及改动的原因。

在Choerodon V0.18及之前的版本中,集群管理的功能在组织层,组织管理员负责管理整个组织中的集群,并通过对集群进行权限配置以此来管理组织下各个项目对集群的使用。而组织下的各个项目通过创建环境与组织层的集群相关联(Choerodon中的环境对应为k8s中namespace)。这样的层级结构,从Choerodon V0.11一直保持到了 V0.18,但在组织的实际使用场景下,还是存在着一些需要优化与改进的地方。

  • 集群管理者的权限问题,因为只有组织管理员才有集群管理的权限,所以当集群出现问题后,集群管理者需要拥有“组织管理员”的权限才能前往组织层查看集群的情况,这就造成了集群管理者权限过大的情况。
  • 组织下的一个集群可能会有多个项目进行使用,这样又会造成一个组织下多个项目中的集群管理者都拥有“组织管理员”的权限。
  • 平台层与组织层更多的是管理与监控的功能,且与项目层的业务功能没有了过强的关联关系。

为了解决以上问题,从而满足更多的实际应用场景,从0.19版本开始,Choerodon猪齿鱼平台便将集群相关的所有功能从组织层移到了项目层,即集群管理者在项目下就能完成集群的创建、管理与监控等操作。而对于之前版本中组织层已有的集群,我们在各个组织下预置了一个“默认运维项目”来进行集中的管理,集群管理者只需拥有“默认运维项目”下项目所有者的权限即可。为了使平台功能与业务结构更加清晰,从而来满足更多的使用场景,在Choerodon V0.19 中,我们对各个层级的功能进行了重新的整理。

怎样使用集群管理功能?

在Choerodon猪齿鱼平台中开发一个应用服务,跑完CI,生成版本之后,我们需要将其部署到对应的环境之中。而Choerodon中的环境是与集群进行关联的,因此部署一个应用服务的必要条件是存在一个可用的Choerodon集群。目前我们建议在“默认运维项目”中去集中管理组织下的集群。

创建集群

在Choerodon项目层“集群-集群管理”菜单下,使用项目所有者角色,点击创建集群的按钮,输入集群名称、集群编码以及描述。点击创建后,界面会自动生成可执行的shell脚本命令,其中各个参数已经由后端服务自动生成,只需将此脚本命令复制至kubernetes中运行,以此来连接Choerodon平台与k8s集群。执行成功后,便能看到页面中集群变为了“运行中”的状态。

集群权限管理

集群管理者成功创建集群之后,可以通过权限管理为同组织下所有项目或特定项目分配该集群的权限,配置后,只有被选中的项目在创建环境时才能选择与此集群关联。

查看节点详情

一个Kubernetes集群由Master和Node组成,Master是集群的网关和中枢,负责为客户端暴露API、跟踪其他服务器的健康状态、以最优方式调度工作负载,以及编排其他组件之间的通信等任务,它是客户端与集群之间的核心联络点,并负责Kubernetes系统的大多数集中式管控逻辑。Node是Kubernetes集群的工作节点,负责接收来自Master的工作指令并根据指令相应地创建或销毁Pod对象,以及调整网络规则以合理地路由和转发流量等。

在集群激活之后,我们可以通过集群管理中的“节点列表”查看到集群下所有节点的状态、类型以及CPU与内存的请求值和限制值。以此来实时监控集群下所有节点的资源分配情况。

总结

在Choerodon V0.11刚上线集群管理功能时,我们将之前“利用单个环境客户端管理单个环境”的模式变为了使用“单个集群客户端可以统一管理多个环境”的模式,以此来避免资源浪费的情况。在此基础上,我们在后面的版本中不断对此功能进行优化与完善,除了上文中提到的结构与层级的优化、权限管理和节点管理功能,Choerodon集群管理中还陆续新增了组件管理、集群监控、健康检查等集群功能。关于健康检查功能,可以参考《Choerodon猪齿鱼实践之健康检查》,至于组件管理与集群监控的功能,将在后续文章中详细介绍。

关于猪齿鱼

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

更加详细的内容,请参阅Release Notes官网

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

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