日志

过程改进日记之学习Scrum2010-10-15：设计不足的原因？

已有 1798 次阅读2010-10-18 16:10 |个人分类:过程改进|

在Sprint3的反思会中，我们有这么一条不好的实践

前期设计和技术评估不够充分，导致后期改动较大，所以我们有个改进措施

5.新模块在开发前一定要经过设计。

Sprint5不再象之前一样写出任务让工程师估算，而是请工程师自己对需求进行分解，考虑到新员工未必了解如何分解任务，于是我一个个去询问他们如何分解，观察到这些现象。

1、工程师打开禅道上的需求，点击”分解任务“，然后冥想、敲入文字，冥想，调整文字。

2、有个需求，后面是个疑问句，要……？还是不要……？，工程师正常分解，貌似没有影响

3、只看分派给自己的需求，不关心其它人的

我大为惊讶，尤其是对于第一第二点，我问了他们一些问题

1、你真的了解需求的含义么？

2、需要设计吗？

对于第一个问题，他们往往会说一些已经了解的信息，这时候他们表现得相对有信心，但是当我进一步补充我的问题时，他们并不能很快的回答我，而是陷入一种不确定，我问得越多，工程师越不确定。

于是，我建议工程师在纸上画出他对于需求的理解和任务的分解，可以用任何形式，比如鱼刺图、发散图，也可以是简单的罗列，但是，工程师还缺乏这方面的技能，但他们并不认为这是种很必要的能力。而且，他们不怎么愿意花太多的精力来分解。

和PM聊这种情况，PM的判断比较精准

这其实是个值得回味的现象，我们都知道设计不足，而设计不足的原因是时间不够，时间不够的原因是任务太紧。

但实际上，这次让工程师自己分解任务，可以判断设计不足的内部原因

首先工程师应该先判断需求信息是否充分，对于不充分的要及时沟通来确保自己了解需求。但这方面做的还不够好。
其次，他们觉得需要设计，完全可以单列一个设计任务，这个任务可以输出哪怕最简单的设计草案，不过从现在的情况看，可以说工程师还不习惯设计。也就是说，工程师拿到需求的第一反映不是设计，而是编码。

这是工程师自治分解任务中的发现，设计应该是一种习惯。就好比饭前洗手一样，习惯比规则更重要。

后续补充

010-10-19补充

今天立会，提到一个抽象类的任务，PM问，这个有文档可以拿来review吗？工程师回答：”只有一个头文件，东西不多，不需要文档。“

PM提出：“回顾的时候不是大家都说设计不足吗，现在有时间做，我们要尽量做充分“

工程师：”这个的确不多啊，这个类抽象出来复杂度不高的。“

DPM也觉得够了。

我只能补充下：“那好吧，如果大家确认这个复杂度不高，抽象出头文件就够了，但我们要经常提醒自己养成设计的习惯。”。