落地敏捷典型问题之项目透明：固定的白板模式是失败的起点 敏捷开发XP项目管理scrum软件测试

落地敏捷典型问题：固定的白板，失败的起点

在Scrum的模式中，白板被用来发现风险、团队协作、透明化等，确实是一种简单实用的手段，很多团队在使用白板后获得了直接的效果。但是，白板的使用过程中经常会出现以下问题，例如：

 

1)      一种固定模式的白板，对应一种固定模式的协作方式，但是在不同的实际场景中行不通

2)      白板上的关键信息不做持续记录和更新，失去存在的意义

3)      白板只是被研发团队的成员在使用

4)      没有分析流程中的瓶颈、浪费、问题，无助于改进的白板作用就褪色很多

 

 

这里重点想讨论和分享我们如何解决第一种问题。解决方案就是不同的场景，用不用的协作方式，对应的白板也会随之不同。我们实际工作中有很多场景，举例如下：

#1：固定迭代周期交付，迭代周期内需求无变化

#2：固定迭代周期交付，迭代周期内有一些新增变化

#3：固定迭代周期交付，迭代周期内有很多新增变化，或者团队内部是强分工

#4：无固定迭代周期交付，即按需交付，可能是有固定周期（例如一周一次），也可能没有固定周期

#5：固定迭代周期交付，同时迭代周期内需要临时按需交付

#6：资源紧张，每个人同时负责多个任务，不清晰的协作导致无法快速交付重要的功能，混乱无序

#7：多团队协作，但团队之间或者和第三方的依赖非常强

 

 

这里重点介绍#1、#2、#4场景的具体白板。

 

 

对于#1的场景，我们用的是Scrum标准白板，加入了我们的具体实践，白板如下：

 

 

 

 

 

对 于#2的场景，我们用的是ScrumBan类型的白板，即借鉴了Scrum的要素，并结合Kanban的要素。由于只是一些新增变化，所以在迭代开始时还 是会进行迭代计划会议。#2的白板如下。但是对于#3，在迭代开始时没有统一的计划会议，对于要进行的需求进行即时计划。

 

 

 

 

对于#4，我们用的是比较标准的Kanban，加入了我们的具体实践，白板如下：

我们用过两类Kanban，一种类似这样的：

 

 

 

 

另一种把需要协作的点都放在了白板上，并增加了适当的细节，以便于更快更准确的发现风险，消除瓶颈和障碍，类似如下的样子：

 

 

需要说明的是，如果团队较为成熟，磨合时间长，效率高，第一种Kanban为推荐，甚至可以更为简单；如果团队磨合时间短，交付出现的问题较多，第二种Kanban为推荐，即展示更多的细节。