项目中需要时刻提醒自己的六件事

一些心得，写下来时刻提醒自己。

1.实现优先
这个问题很明显：无论如何，你都要先做出来。技术，性能，优化甚至代码对齐等等技术人员才会想到的东西是不应该按这个标题序号去考虑的。
记住：即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多。

2.以人为本
充分的衡量一下整个团队的能力，按照全队的综合能力去选型。项目负责人的任务就是把项目拆散了平摊到每个适合的人的头上。
记住：你必须详细的了解团队中的每一个人，说不定一个闷臊的程序员恰恰成为了最好的客户沟通专家......

3.demo驱动开发
天下最“敏捷”的事情莫过于让用户经常能知道你的想法。那么正式开始之前都给他们做个demo，哪怕功能都是伪造的......或许你会发现其实客户要求的比你想的要少得多....
记住：让客户看到，永远比让客户听到要好

4.每天都是一个成功
与其每天气急败坏的催促手下加快开发进度，不如建立多个短期目标，每个目标都实现了，你就会发现自己腰不酸了，手下腿不痛了，客户一口气上五楼，不喘气了。
记住：让团队不被压力压倒是每一个管理者最重要的责任。

5.量力而为
如果你在上一条里的目标每个都是难以实现的，团队的士气或许很快就会降到谷底...项目的失败是可预期的。如果客户的要求也超出了团队的能力，放弃绝对比硬撑要值。
记住：别妄图在项目中保持120%的开发能力，你或许会在项目完成的前一天倒下...

6.横向储备
只要有时间，一定要留意团队中缺少的知识和人才。没准下个项目就会用到。
记住：项目总是会照顾那些有准备的人...

评论

32 楼 sg552 2008-02-15  

严重同意LZ的观点。

看到前面的反驳意见，大部分集中在第一点。认为做出的“杂碎”以后用不了。

个人以为，我们国内的程序员，了解重构的人太少。能够在项目中写完整单元测试的人太少。 所以造成了对“杂碎”程序的恐惧感。

其实看国外很多大牛们写的跟软件工程开发过程相关的书，都是认为实现一个很简单的东西要比做一大堆华丽的设计要好的多。

而且在各位大牛的书中都提到，重构是避免让软件腐朽的方法。有了重构，我们还怕什么呢？

如果一个程序员的风格，是写好了一段程序之后就很不喜欢修改，我非常推荐《重构》这本书， gigix翻译的。

31 楼 gembler 2008-02-14  

xiaolin0105 写道

lzycxy 写道

写的啥呀？
一天写个杂碎，客户会“杂碎”你1个月。

一天写个杂粹至少可以让顾客审查提意见，之后可以修改。就怕你自以为是的花了n久搞了个以为很了不起的东西，结果顾客一看是个杂碎，你根本没时间修改。

设计现行，实现第一的思想是正确的。现在很多项目具都过度设计，真的很没必要。浪费时间而已。

过度设计-->就是个人水平问题.
一天写个杂粹至少可以让顾客审查提意见-->我把前期时间话在设计上同样可以让顾客审查提意见,除非你设计的时候是不考虑客户的感受.就怕你自以为是的花了n久搞了个以为很了不起的东西，结果顾客一看是个杂碎，你根本没时间修改-->什么叫沟通啊?什么就确定需求啊?
难道就不会先画一些带有静态数据的核心(注意:是核心)界面来让顾客审查提意见吗?

30 楼 xiaolin0105 2008-02-04  

lzycxy 写道

写的啥呀？
一天写个杂碎，客户会“杂碎”你1个月。

一天写个杂粹至少可以让顾客审查提意见，之后可以修改。就怕你自以为是的花了n久搞了个以为很了不起的东西，结果顾客一看是个杂碎，你根本没时间修改。

设计现行，实现第一的思想是正确的。现在很多项目具都过度设计，真的很没必要。浪费时间而已。

29 楼 xiaolin0105 2008-02-04  

一些心得，写下来时刻提醒自己。

1.实现优先
这个绝对支持。


我觉得楼主说的很对。

而且如果顾客没要求，就绝对不做。一份价格就是一份货。该做的我一定做，不该做的我绝对不做。头头是道说了很多设计啊，优化啊，都没有实现来的实际。

28 楼 Angel.John 2008-02-02  

横向储备是经常需要提醒自己的并去行动.

27 楼 jack 2008-01-25  

要这样做,实际上是考验 管理人员的控制能力. 不管是对项目,对客户需求,以及对人员的实际进度这些方面的控制力.

可以这么说, 如果自己没有规矩,那么客户会更加无礼.

26 楼 lzycxy 2008-01-24  

写的啥呀？
一天写个杂碎，客户会“杂碎”你1个月。

25 楼 jack 2008-01-24  

timerri 写道

一些心得，写下来时刻提醒自己。

1.实现优先
这个问题很明显：无论如何，你都要先做出来。技术，性能，优化甚至代码对齐等等技术人员才会想到的东西是不应该按这个标题序号去考虑的。
记住：即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多。

2.以人为本
充分的衡量一下整个团队的能力，按照全队的综合能力去选型。项目负责人的任务就是把项目拆散了平摊到每个适合的人的头上。
记住：你必须详细的了解团队中的每一个人，说不定一个闷臊的程序员恰恰成为了最好的客户沟通专家......

3.demo驱动开发
天下最“敏捷”的事情莫过于让用户经常能知道你的想法。那么正式开始之前都给他们做个demo，哪怕功能都是伪造的......或许你会发现其实客户要求的比你想的要少得多....
记住：让客户看到，永远比让客户听到要好

4.每天都是一个成功
与其每天气急败坏的催促手下加快开发进度，不如建立多个短期目标，每个目标都实现了，你就会发现自己腰不酸了，手下腿不痛了，客户一口气上五楼，不喘气了。
记住：让团队不被压力压倒是每一个管理者最重要的责任。

5.量力而为
如果你在上一条里的目标每个都是难以实现的，团队的士气或许很快就会降到谷底...项目的失败是可预期的。如果客户的要求也超出了团队的能力，放弃绝对比硬撑要值。
记住：别妄图在项目中保持120%的开发能力，你或许会在项目完成的前一天倒下...

6.横向储备
只要有时间，一定要留意团队中缺少的知识和人才。没准下个项目就会用到。
记住：项目总是会照顾那些有准备的人...

我就是如此做的.也许方法上有所偏差，但是以上的6条，都是我目前遵循的。有部分细节在我和o6z的问答中提到过
http://www.iteye.com/topic/145145

24 楼 wangpx 2008-01-23  

很实在的经验，管理好自己，让成员管理好自己，教他们如何管理好自己，项目就好做了

23 楼 zhuxinyan0824 2008-01-18  

第三条，demo中一定要有客户最为关心的的需求，围绕着这些客户的需求去做，尽量不要自作聪明，做一些多余反而会让客户疑惑和误解的工作，这样只会给项目带来没必要的麻烦。

22 楼 chengren 2007-12-29  

唯一的问题是
6.横向储备
只要有时间，一定要留意团队中缺少的知识和人才。没准下个项目就会用到。
记住：项目总是会照顾那些有准备的人.

这个不是特别好做到：（
尤其俺们公司，不太容易的。。。。

21 楼 chengren 2007-12-29  

在很多公司里楼主的建议很好啊。。。

和我们很多做法都不谋而合哈

20 楼 leadyu 2007-12-28  

呵呵，每个人经历不同，见解也会不同，只能说，不敢苟同

19 楼 timerri 2007-12-27  

抛出异常的爱 写道

timerri 写道

抛出异常的爱 写道

简单是以不停重构做为补充.....的

核心价值中的简单说的应该是不做额外功.....吧

我有一只猪时,要一个猪圈,做一顿猪食
我有二只猪时,要一个猪圈,做二顿猪食

当我有N只猪时,要N/5个猪圈,做N/1.5次猪食.

这叫简单{
我有一只猪时,做一个猪圈,做一顿猪食
我有二只猪时,copy一个猪圈,copy2顿猪食（当今世界copy不要钱）
当我多了只羊，先试试往猪圈塞，不行再作羊圈。
}

这叫重构{
我有一只猪时,做一个猪圈,做一顿猪食
当我有N只猪时,先做N/5个猪圈,做N/1.5次猪食.
然后拆了N/5个猪圈换个大的，再换口大锅煮猪食.

}

18 楼 抛出异常的爱 2007-12-27  

timerri 写道

抛出异常的爱 写道

简单是以不停重构做为补充.....的

核心价值中的简单说的应该是不做额外功.....吧

我有一只猪时,要一个猪圈,做一顿猪食
我有二只猪时,要一个猪圈,做二顿猪食

当我有N只猪时,要N/5个猪圈,做N/1.5次猪食.

17 楼 timerri 2007-12-27  

抛出异常的爱 写道

简单是以不停重构做为补充.....的

核心价值中的简单说的应该是不做额外功.....吧

16 楼 timerri 2007-12-27  

movingboy 写道

个人认为把“实现优先”的说法改成“原型法”更好理解......

原型法是一种方法论，而实现优先是一种侧重。我在这里只是想强调这个侧重，而不是想强调一个方法论.....

这几条大家可以看作是对我自己的一些微调参数，因为我自己存在着与这几条对应的一些缺点。如果大家没有这些缺点，也就不必在意我的这几条是对是错了。

15 楼 movingboy 2007-12-27  

个人认为把“实现优先”的说法改成“原型法”更好理解......

14 楼 抛出异常的爱 2007-12-27  

简单是以不停重构做为补充.....的

13 楼 timerri 2007-12-27  

看来这个实现优先还是没有讲清楚啊。

实现优先并不是说完全的实现整个系统后再去重构，而是在项目最开始的时候尽快建立起一个能满足项目中最关键需求的原型系统(哪怕你得到是一个由shell,script,java等等拼出的大杂烩，但只要还能跑就足够了)，随后的沟通，设计都基于原型来进行。通过构建原型系统，你将最早的了解到项目中的难题。此外，由于原型的存在，你有了一个最好的沟通基础，无论是对客户还是对组员，你的描述和设计都将言之有物，你对于需求的收集也将更明确和详细。


喜欢xp的朋友应该更容易理解，还记得xp的4个核心价值么？交流，简单，回馈，勇气......

还有plan design...simple design.....

其实这里所谓的实现优先与xp并没有冲突，只是侧重的部分不同罢了。