评一个失控项目

评一个失控项目

“ 我宣布 项目失控” 描述了一个正在进行中的项目和项目中的感受。
其中有许多可以讨论的内容。


> 客户方指定这位实习生来做联络员，结果老板与其争吵后不经我同意就决定把设计权全部移交给他，成了噩梦的开始。

做客户代表没有问题，需求分析最好应由该客户代表做。
在客户代表不具备软件需求分析能力的情况下，由他协助系统分析员做需求分析，因为他直接接受用户需求。
需求分析能力不足，是造成项目返工多的最主要原因。
将需求分析交给一个新手是一个重大错误。

老板不经项目主管同意指定设计人员是越权干涉。
项目主管若抗义无效，只能暂时假定老板指定的设计师具有相应能力。
从风险管理角度出发，需求分析和系统设计成为最高风险，应加大复核的强度。

需求分析员参与概要设计是好的, 减少了需求与设计之间的交流.


> 项目启动一周后我发现软件设计存在极大的缺陷，向项目经理协调，结果他在QQ上回了一句：“客户拿着钞票上下摆动，我的头也跟着上下摆动。”

对于需求，当然是听客户的。
“客户拿着钞票上下摆动，我的头也跟着上下摆动。”极具形象性。
对于设计，则不受客户干预。
即然发现了缺陷，应及时更正。
在设计评审会议上，任何小细节都不可放过。
有疑问的需求同样也是要确认下来的。


> 整个儿项目是用工作单来传递需求和变更的，好像是迭代式的开发。

看来缺少一份需求说明和概要设计文档，迭代式开发也需要文档。
文档可以简单的一到两页，太细节化了反而没用，因为需求预计会不断变更。


> 但实际上，这位联络员常常抓住几个细节不放，对于用户的可操作性、实际业务流程的完整性完全不加理会。

操作流程不是实现者特别关心的，客户怎么要求，开发人员就怎么实现。
工作单的描述简单又细致，不知道为什么没心情去实现。
似乎心里认定该需求肯定将来会变更或废弃。
还是一句话，有疑问就先去确认它。


> F:如果XX功能这样做了，可能会引发YY的问题。
> W:你先做完XX，我们再去解决YY。

实现者质疑设计，而设计者努力压制这些质疑，存在这种紧张关系的情形下，不适合迭代式开发。
如果是先设计，后代码，设计师就无法回避这种质疑，必须是设计方案通过后才会有代码。
遇到这种情形，应该先沟通一下，确定问题是否真会出现，出现时对设计的变更有多大，而不是走一步算一步。


> 项目进行近一个月了，昨天他才去实际用户那里了解到：“一张PO单只对应一个物料”的重要的需求信息。
> 这个结果直接导致了我四个页面的相关功能模块成了废弃代码。

这四个页面的相关功能在某个假定的条件下完成，当然有可能被真实的需求废弃。
只有确定了需求才能完成相应的功能。提前设计与实现都是无用功，而且还有害。


> 到目前为止，约有70%以上的代码作废，页面和模块的返工平均有五次以上，有些更是无法修改直接重写。
> 设计缺陷导致的问题也逐一浮出水面，于是带来的是更多的返工，修改，重写。

迭代式开发与传统开发方式不同，代码不会停止修改。
好的设计支持代码轻松修改，差的设计无法适应需求变更，代码难以修改，可能必须重写。
一般在一次迭代后产生一个小版本, 听取客户意见, 为下一次迭代作准备.
每一次迭代都有可能废弃上一次的部分代码, 甚至全部代码.


总评：

纵观该项目，可能项目并没有失控有多厉害，因为
“项目拖得越长，项目资金就会越多，而且应该是由客户来承担”。
如果没有预定进度计划，也就没有什么失控了，只是心里的一种混乱的感觉。

大多数项目都处于需求变更当中，因为客户也不知道最终他需要一个怎样的产品。
所以XP这样的敏捷式开发因为包容这种需求变更而大行其道。
在这样的开发方式下，一个小的开发周期就可以发布一个版本，实现了客户所要求的最高优先级的需求。
客户根据这个版本，提出下一个版本的需求及对以前需求的变更。
这应该是一种愉快的开发体验。

项目失控的感觉更多得缘自于传统开发方式和敏捷式开发的观念冲突。
对需求变更的抵制，对代码修改的恐惧，以至于心情大坏，满心悲观。

一个新人明显地得到管理高层的认同与支持，也得到客户的极大支持。
他实质上获取了项目的控制权，一切都按他的调度进行着。
他施行了与以前不同的开发方式，一种迭代式开发。
而小组成员对这种开发方式没有经验，也没有经过培训。
自然对新的行为方式有一种抵触。
而倡导者认为这是更适合的开发方式，不需要培训就能自然接受。
他认为一切都可以在自己的控制下，即能成功完成项目，又能以项目的成功转变传统的开发方式。

至少出现了以下问题：
小组成员的茫然，不知道最终会怎样。
不愿意接受工作任务，或不理睬任务安排。
积极性受到打击，认为工作成果被否定了。
对进度心中无数，不知何时是结束。
怀疑自己的工作是否是有意义的。

这些都是敏捷式开发中项目失控的征兆。
尽早发布一个可用的版本, 可以改变这种茫然的状态.