Skip to main content

4 篇博文 含有标签「看板

View All Tags

· 17 分钟阅读

“我们使用敏捷开发。”在与软件开发团队交流时,你会听到很多这样的说法。根据统计,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、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

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

· 13 分钟阅读

在敏捷开发中,大家经常会提到看板(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、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

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

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

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

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