过程改进日记之学习Scrum2010-8-19：预备看板管理

这个日志晚了一天，自我批评下

昨天例会，会后和PM商量了一周来的实践成果。觉得例会中反馈出一些现象

1、一些任务比预计的多花费了时间，这些应该是任务外延不清，导致额外增加了一些活动

2、个别任务遇到障碍，需要其他Team支持的，有可能到忙碌到周五，被大家遗忘了

3、和产品工作无关的活动，或者工程师请假，会降低工作节奏。

这些问题的档案应该是很确切的，用看板管理就可以了，我们只花了不到五分钟就达成一致了。

每日晨会制度一周了，如果没有更新的改进，这件事情又变成形式主义了，重要的是马上行动，当我们把这些消息告知老大，老大把PM和我叫去办公室。

 

老大自然有老大的问题要考验我们：

“看板是一个形式，当然马上可以做， 但没有内容的支撑，再好的方法都会流于形式，我们现有的需求分解是最重要的内容，这是前提，否则对于资深工程师尚没啥大问题，但对于经验不足的工程师，会感觉无从下手，作为PM， 得确认我们把需求都准备好了”

PM：“这个没有问题，我 确保工程师明确他们的需求，DPM会和工程师一起分解任务”

 

老大：“ 如果我现在要看到整个产品所有详细的功能点，我能够从哪里获得？”

PM：“这个不行，还有几个模块没有细分，我们现在已经把这阶段要做的所有功能细分后做为需求写到了禅道的系统中，你可以看需求的分模块视图， 我们可以保证你随时都可以在系统上看到最及时的需求分解”，同时登录演示。

 

老大抽取了几个需求，并问了些我觉得比较细节的问题，以考验PM，PM应答如流，功德圆满。

 

…………（半小时交流）

 

老大：“系统中只有本阶段的，以前几个阶段完成的模块呢。”

PM：“之前我们在Excel中管理，公司原有的系统中有更高级别的Feature List，我们在本阶段完成后会把Excel上的信息保存在禅道系统上，但这 不是本阶段的目标，现在不考虑做 这个”

 

……

布置的事情简单了，就老大办公室隔壁的会议室吧，钉上白纸，按照Scrum的标准看板依样画葫芦，然后发了个消息给PM：“好了，就是字写得太差了，讲究着用吧 ”

PM观摩了下，跑来说“这字写得真不是一般的差 ”

我恼羞：“等下周末我们看看燃尽图像不像样， 看实质不要看表面，字写得好，不等于我们的项目做得好 ”