在 Azure Boards 中实现看板时使用最佳做法

Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020 |Azure DevOps Server 2019 |TFS 2018

完成 看板基础知识中提供的四个配置步骤后,你已做好了实施看板六种核心做法的大部分操作。

  1. 可视化工作流。 Teams 使用 Kanban 开发板跟踪他们的工作,该板映射到工作原理。 Teams 讨论如何以最佳方式集中资源来交付最重要的工作。
  2. 限制正在进行的工作。 团队 (WIP 设置并坚持正在进行的工作,) 针对每个工作阶段设置的限制。 他们使用 WIP 限制来保持专注于完成他们启动的内容,并确定其流程中发生的瓶颈。
  3. 管理流。 Teams 监视正在进行的整体工作和提前时间,这让他们了解交付速度。
  4. 明确策略。 团队将说明他们同意遵循的标准和流程,并使其易于访问。 例如,通过将团队的每个工作阶段的“完成定义”明确化,可以避免浪费时间和精力。
  5. 创建反馈机会。 Teams 定期开会,以反映工作内容和需要改进的内容。
  6. 协作改进,以实验性进行改进。 Teams 确定如何根据关键指标改进持续交付流。 他们涉及整个团队来收集见解和想法。 而且,当出现永久性瓶颈时,它们会确定有助于解决这些更改。

随着时间的推移,Kanban 可以提供团队见解,了解他们当前流程的端到端工作程度以及如何改进它们。 看板实践的增量采用往往产生更大的成功,并建立在第六个实践的基础上,以实验方式发展。 这些做法源于精益制造和系统思维的原则。

WIP 限制、挑战和解决方案

团队偶尔会超过一两个项目的 WIP 限制。 但是,如果你的团队经常超过三个或更多项的限制,他们应查看流程或调整限制。

在团队与 WIP 限制合作了几周后,讨论团队成员面临的挑战。 然后,确定他们想要使用哪些解决方案,并根据需要调整限制。 以下列表虽然并不详尽,但表明团队遇到了一些常见的挑战,并证明了他们克服的解决方案。

WIP 挑战

  • 社交动态。 在遵循规则方面,团队成员可能会感到挑战。 有些人自然想叛逆。 其他人看不到规则适用于它们,或者看不到它们作为违反规则执行的操作。 一些团队成员可能会承担超出同意范围的额外工作。 而且,仍然其他人不想放弃多任务,因为他们相信这是他们的生产力和个人成就的关键。

  • 正在进行的工作可变性。 工作项(用户情景和 bug)大小的广泛变化可能会对整体工作流产生负面影响。 例如,估计大小从 4 小时到 14 天(或 2 到 55 个故事点)的项目在限制正在进行的工作方面无法计算相同。

  • 忽略系统性问题。 团队不解决瓶颈发生时的工作流问题,而是投入更多时间来克服瓶颈。

  • 文化变化。 采用 WIP 限制会对系统、文化和团队进行更改。

用于管理 WIP 的解决方案

  • 构建团队工作效率文化。 解决个人生产力与团队生产力之间存在的自然紧张关系。 确定团队成员能够提高团队和工作流流程的整体工作效率的方式。

  • 大小工作,以最大程度地减少可变性。 在开始任何项目之前,团队应讨论所需的工作的总体大小,并确定是否可以将其分解为较小的任务。

  • 重点介绍高优先级项流。 空闲时,团队成员询问他们如何帮助将上游项向前移动。 当被阻止或质询按时交付项目时,团队成员请求帮助完成项目。

  • 每个工作阶段的资源团队容量。 当没有足够的专家在特定阶段工作时,可能会出现瓶颈。 确定在每个工作阶段增加团队技能的方法,或根据需要添加资源以满足未参与的工作阶段。

  • 生成共享理解。 不断努力提高团队对如何使用看板做法的理解。 执行允许团队成员参与处理更改的操作。 考虑安排定期回顾或团队会议,讨论哪些工作良好以及需要更改的内容。 记录团队策略以限制歧义性。

  • 使用指标调整进程。 定期检查正在进行的工作看板指标和提前时间,以确定何时需要进行更改。

  • 注意管理区域性更改。 人员想尽最大努力——一个核心原则基础看板及其相关学科。 采用新做法时,应用变更管理原则。 为实现 WIP 限制的成功,在团队中创建更大的所有权。

帮助敏捷团队交付工作软件

敏捷软件开发的 12 项原则之一是“频繁交付工作软件,从几周到几个月,优先于较短的时间刻度”。

所有敏捷团队都必须确定他们在说“工作软件”时的含义,这通常被称为完成的定义。 在高级别上,仅当功能通过所有测试并且可由最终用户操作时,功能才会完成。 至少,团队必须超越单元测试级别,并在系统级别进行测试。 最佳团队还在其定义中包括集成测试、性能测试和客户验收测试,即使用一部分功能完成。 — 杰夫·萨瑟兰

团队未能实现敏捷的主要原因之一是,他们缺乏良好的完成定义。

每个阶段都表示向将工作的人交出。 流序列中下一个人员需要快速成功的信息。 不完整的工作或未通信的信息可能会导致延迟和浪费工作。

作为一个起点,请考虑以下一些条件,因为你与团队合作,以确定在整个开发过程中完成哪些工作。

阶段

完成的条件

在工作开始于功能、用户情景或要求之前

  1. 用户情景的范围和估计范围正确。
  2. 验收标准定义良好。
  3. 团队了解客户需求。
  4. 已识别并跟踪依赖项。

Bug 归档

  1. Bug 游戏清楚地标识了问题。
  2. 重现步骤清晰且最少。
  3. Bug 指定单个问题。
  4. 相关问题链接到相关问题。
  5. 在团队中清楚地了解所使用的术语。

代码完成,已准备好进行测试

  1. 完成代码、进行注释并针对当前版本运行。
  2. 已审阅代码同级,满足团队标准。
  3. 无错误生成。
  4. 通过单元测试和系统测试。
  5. 将任务剩余小时数设置为零,并关闭任务。

测试完成,已准备好发布

  1. 针对所有新功能或函数实现的单元测试。
  2. 单元测试全部通过。
  3. 接受/故事测试是书面和通过的。
  4. 回归测试为绿色且存在已知故障。
  5. 已完成足够的探索性测试。
  6. 功能/函数按预期正常工作。
  7. 未解决的缺陷已记录为 bug。
  8. 代码覆盖率稳定或改进。

随着团队的进展,重新访问“完成”条件的定义。

开发团队的“完成定义”旨在随着时间的推移而扩展。 新组建的团队一定会比具有共同改进历史的成熟团队更严格和更小的完成定义。 扩大团队的完成定义在于 Kaizen 的核心,这是一个日语术语,这意味着专注和不断专注于改进。 虽然团队最初可能只需要在签入之前生成代码,但随着时间的推移,它们应发展更精确的标准,例如需要单元测试来随附新代码。 — 大卫·斯塔尔

接受条件与完成的定义

接受条件对应于客户在实施用户情景、功能或要求时应期望的内容。 团队与客户之间的对话以确定验收标准有助于确保团队内部的共识,以满足客户的期望。 验收条件可用作验收测试的基础,以便团队可以更加高效地评估项目是否圆满完成。

验收条件定义何时可交付功能。 捕获 Scrum 产品积压工作项的“验收条件”字段中每个积压工作项的条件 () 或敏捷用户情景和 CMMI 要求) 的“说明”字段 (。

工作项窗体上的“验收条件”字段

不过,完成的定义是提供功能增量部分,因为它从不开始到完成。 敏捷团队在每次交接时都处于就绪状态,让收件人开始工作时,都会取得更大的成功。

敏捷性需要交付完成的现成工作软件增量,每个 Sprint。 然而,大多数 Scrum 和敏捷团队都会生成部分完成的不完整增量。 当一个 Scrum 团队被问及为什么产品积压工作要求在冲刺中没有完全完成时,团队成员经常回答道:“我们没有时间——肯·施瓦伯和大卫·斯塔尔。

其他资源