细粒度的迭代计划到底要做到多细?

同感啊!gigix最后讲的精彩,基本上明白了,但是我觉得XP真要流行起来,大学里应该开这门课程.给大家贴个笑话,不知道对不对
三个关于计算机科学的最大真理：
计算机软件工程就象是在漆黑的屋子里寻找黑猫；
计算机系统工程就象是在没有猫的黑屋子里寻找黑猫；
计算机知识工程就象是在没有猫的黑屋子里寻找黑猫，却有人大声说：“我抓到它了！”

既然你来自CSDN（那个大肠帖子日本和中国人写代码的差别，你都记得。不过你记忆有问题，那个不是说两国之间的重构差别，而是说对程序结构的要求的区别。小日本的那个代码臭味熏天，中国人的代码也是味道浓郁，都是该重构的代码），那么就应该知道原来有个慢鱼的在国外的大学（似乎是欧洲的，而且他对xp的态度并不友好），他说的xp已经成为很多大学的本科学生的课程。
回到这个问题上来，你的组织只要可以坚持做到持续集成，哪怕最低的做到日构建，那些人就不会拖累你的。而在我看来scm是任何软件工程的方法基础，而坚持在这个集体强制性推广持续集成，投资只是最初的两天，随后那些人会自动地被鉴别出来。

最近一个项目我介入的比较晚，集成上出了很多问题，经常是每日构造不能正确地build出来

一个是时间上的问题，当项目进行到一定程度以后，如果程序员需要花费很多的时间进行workspace上的测试，那么他就会慢慢地不愿意在commit之前做一个build和smoketest，如果不在commit之前做一个smoketest,那么集成被broken的机会就会非常大

另外是一个反向回馈的问题，如果集成构造一旦失败，那么信心就会受到打击，如果信心受到打击，那么下一次集成构造就不愿意去做，如果不愿意去做，那么集成构造失败的可能性就更大，最后项目组会关掉集成构造服务器

目前还存在着一些问题，例如spring的启动时间过长，每个独立的单元测试应该能够在ide里面方便地执行，所以spring的启动应该在每个testcase里面做，但是如果做一个完整的测试，我们希望spring和hibernate的映射只启动一次，另外第三方模块的介入需要一些处理，例如第3方的数据库初始化应该独立进行，这些问题由于我介入得比较晚，而且没有在开发组一直在一起，所以一直没有得到很好地解决。而这些问题应该在项目已开始就进行很好地设计，我在自己的blog里面都有这方面的模式，但现在项目主体开发已经不到20天就要抵达结束，所以非常困难。

我一以前的项目都有机会在开始之前对整个SCM和build的方式进行一个很好的培训，但现在看来，项目开始之前的培训不作好的话,没有针对具体的技术和项目模块组成进行build设计，持续的build甚至是每日度非常难。

没想到有这么多回复的帖子了，呵呵。
    o6z和gigix的看法是好的，我也多么希望上层能这么体贴人，可是一点，你只能尽量提出你的意见，而无法对你的团队进行全面的选择。
    像o6z和gigix提出的自己做，呵呵，好轻松的一句话，上十万行的代码，那么多页面，一个人做得来？一个好的PM，应该懂得发挥每一个人的所长，分配给他们能做的任务，如果什么都是自己揽，那只能是一个senior coder，而不是manager了。
    我们面对的是团队的能力不够，这是事实，而作为一个PM，更重要的是降低这个风险，同时去面对这个风险，如果，只是强调队伍不行，就逃避或者放弃，那么我想问，你又怎么不去判断这个队伍是否能面对这个问题呢？（中国在造原子弹之前难道团队就有这样的能力？各位看官，呵呵，我不是把自己比喻这么大，呵呵，不要朝我扔鸡蛋，但是最基本的道理是这样的。）如果只是碰到一点困难（这点困难和风险并非完全不能解决）就退缩，我个人觉得在“批判”公司的同时是否也要“批判”自己的职业精神呢？
    任何一个团队，只要是可以学习的团队，在一定范围内是完全具有解决问题的能力的（当然这意味着PM要付出很多，意味着存在很大风险）。这里澄清一点，这样的项目肯定是没有拿到具体钱和项目的，所以谈不上用客户的钱为公司培训，不过再说了不用客户的钱，那公司哪来的钱给员工培训？另外，一个受open source影响的人，更应该具有开放的思想（不是那种的开放，而是将自己的思想与他人共享），所以公司没有做任何的培训要求或者培训经费投入的情况下，我都主动义务地给他们进行培训，因为我相信，他们能力提高，不会给自己带来什么竞争（一个人的对手永远都是自己，从来不要害怕别人超过你），相反，他们能力的提高可以给我带来更多的帮助，减轻我更多的工作。一个真正的PM，他的工作不应该困于编码的。
    楼主提出这样的问题，是问我们怎么样去解决问题，是假设每一个人遇上了这样的情况，怎么去解决？我给的答复自己亲身经历罢了，当然，如果换成我事先（进入该公司前）就了解这样的情况，呵呵，我也会和gigix和o6z一样，不去接受的。唉，只是人生难料啊～～～～～～～

凤舞凰扬

这样的认识是一个巨大的错误,项目的成功才是最重要的,而不是你到底是不是一个manager.

这个观点又是一个极大的错误.风险的避免应该主要是管理层要考虑的问题,作为一个做具体工作的PM,没有相应的权利去做这样的风险评估和决策的工作.而国内的众多企业的问题也就是出在这个地方.PM只是在管理层作出的风险规避决策的基础下,具体的实现这个工作.

实际上刚好相反,逃避和放弃的是你,而不是我们.你明明看到这个风险,就应该无保留的汇报给管理层,而不是扮演一个英雄的角色.很多事情是不能试验的,,如果你偏偏要等到失败以后才去承认,那么造成的损失就完全是你的责任.

最基本的道理恰恰就不是这样的,两弹一星是在特殊情况下的特殊事情,如果你的公司天天在这样一种状况下工作,我看就只能认为你的公司非常的不正规.

你前面强调你是一个manager,可是你说的这个话却一点都没有管理的思想.一个管理者的最基本的职业道德就是分清责任.其实我们一直批判的就是你这种没有职业道德的精神.

你说的对.但是你怎么能在最初就知道这个组织是不是一个有学习能力的团队呢?而且如果按照你前面的说法,一个PM是不是应该去努力避免这样的"很大风险"呢?这又是一个职业道德的问题.

如果真的是没有收到钱的话,我想你的组织的水准就真的值得怀疑了.这样的企业可以说连最基本的风险管理都没有,其他的就更别提了.
企业经营的利润来自客户,所以从这个意义上说,培训费用也是来自客户.但是这个逻辑,我们大家都知道是一种狡辩.

这段话就更加显示你没有起码的管理者的职业道德,也没有做企业的素质.一个企业如果是依靠它的员工无私奉献的基础上,这样的情况下不会持续的发展.你可以自己学雷锋,但是你不能依靠学雷锋的精神来做企业.一个企业如果不能给客户和企业内部的所有员工创造经济价值,这样的企业根本就没有存在的必要.
提高人员的素质不应该也不能够依赖于员工个人的付出,而是要依靠企业的人力资源经营.

最后说说职业道德的问题,这个问题尤其重要.在中国似乎根本就没有客户意识,而只有老板意识.你的做法只是表明你有足够的效忠于老板或者企业的思想,但是缺乏一个行业从业人员的基本从业素质---对客户负责的基本态度.
实际上我也是经历过这样的事情的,最初我也是什么事情都自扛,自己付出.但是有一次我和l大脑袋聊天,说起了我的种种付出,他给我一句:"你是不是认为我是一个傻瓜和无赖,这些事情你不说我怎么能给你解决."中国人似乎觉得吃苦耐劳,任劳任怨就应该是一声不吭.其实这大大的错了,我们太小看了老板的素质,也太小看了他们的胸怀.而且很多问题我们往往喜欢让老板自己体会我们的想法,但是我们忘记了,老板要的是忠诚的员工,而不是忠实的奴才.反映问题,并不代表我们就是要逃避,而是要让领导层掌握最真实的情况.

每次说到最后，还是 o6z 说的最正确，呵呵。
问题不提出来，高层就永远不会认为这个问题存在。作为 PM 如果不提出问题，对于上级或者客户只知道好好好是是是，一味压下面的程序员，其实就是一种失职。PM 肯自己揽在身上，做一个 senior coder 的毕竟是极少数，一个原因是很多 PM 其实并不是合格的程序员，另一个原因是很多人做了 PM 后就万分不情愿再去写代码。于是我们的软件工业就建立在这样一种恶性循环之中：

一个程序初哥工作了两三年后，因为其勤奋，刚刚积累了一些宝贵的实际开发经验，就被升任为一个所谓的 PM。要注意，这可不仅仅是头衔的改变，在某种特殊企业文化的影响下将直接造成他心态上的巨大改变。这种改变的后果就是他不愿意再去写代码了。他要 100% 脱离编程，他找出了 10 种冠冕堂皇的理由来证明他现在不应该再去编程。这些理由看起来是如此充分，于是不懂技术的高层便默许了他的这种观点。在有些公司（特别是在那些文档工作极为繁重的外包企业），一线的 PM 不写代码几乎是天经地义的事情。由于不写代码，他的技术逐渐生疏了。有一天他甚至也不愿意再去读其他人写的代码，因为读代码同样是费力的工作。至于更加辛苦的重构，那是程序员需要学习的东西，关我堂堂的 PM 什么事？！
这样下来，我们的软件代码永远都是只有一两年编程经验的程序初哥水准的垃圾。如此难用，bug 如此之多，以至于使用了一年以后就成为了一个即将被淘汰的“遗留”系统。

这种事情发生的太多了，我看到的也太多了。

你所说的这种PM存在，而且还为数不少，这是另一个极端，不代表全部。但是减少PM的技术部分我认为是应该的，读下属的代码的工作未必一定要PM做，让系分做，高程做更合适，例如每个高程负责一到两人的代码甚阅。PM的职责所在是制定计划， 整合资源， 沟通客户， 汇报领导， 制定决策， 解决冲突，质量监督， 建立气氛的。这些工作有的非常的琐碎，但每一个都很重要，都需要花费足够的精力，在这种情况下如果再把具体的技术压在其身上，他的担子是否也太重了？项目经理不做技术细节的工作不是对技术的藐视，而是他有自己的职责。如果项目经理要具体到技术细节（注意我说的是细节，不是一点都不管），那部门经理是不是也需要管，公司老总是不是也要管，董事长是不是也应该亲自过问，你下属的信心从何建立，你下属的积极性怎么发挥？

我不知道你见过的PM都是什么样的，都有多少，反正我在做PM的时候都作了80%的技术工作，有的时候甚至是全包，但是我越来越反感这样做，在我看来，这恰恰是中国软件业不成熟的标志，我向来喜欢编码工作，因为去研究，去探索一个问题它的成就感来的是那样的快，但是我越来越感到一个人能力的不足和精力的有限，我知道很多coder都轻视管理，甚至讨厌技术不如自己的PM，认为你要是相管我，先把优于我的技术拿出来！我想说的是，这是非常错误的，管理做得好了，比你一人去单打独斗能创造出更好的价值，有一个运作良好，管理有效的团队，其创造力是很高的。我初期在一个团队里面,PM绝对是个牛人，但是他整天就知道自己写代码，别人写的他嗤之以鼻，什么都是自己做，我们都不知道自己要干什么，互相之间缺乏协调和沟通，最后是整个项目的失败。因为他专了，过于看重个人技术而忽视群体力量。

秦始皇统一六国的原因是因为秦国有一套比其他六国更先进的国家制度。（可参见秦国历史）
成吉思汗能建立世界上最大的帝国也是因为当时他创立的军事制度优于其他部落，其他国家（可察看元史）
现在的西方文明也建立在其三权分立的制度基础上
反面教程就是西楚霸王，能力不可谓不强，武力不可谓不高，败在那里？


这一切的一切，无不在体现管理的重要性，制度的重要性，无论你讨不讨厌，这是个群体的社会，个人的能力再强，你死了后也无法复生，相反，一套有效的制度却可传之永恒，今天你的技术很强，可能明天你的技术就过时了，因为有更先进的东西出来了，你个人永远学不完，这是没有止境的。而制度就不一样，它可以存在一个很长的时期。

中国向来不缺乏牛人，缺乏的是有效管理这些牛人的人。为什么国外鄙视中国人说个人是条龙，合起来是条虫，因为我们鄙视管理者，认为管理都是些虚假的东西，认为管理不如直接创造更能体现价值！体现在软件上就是很多牛人抵触管理哲学，尽管因为各种原因作上了PM的位子，但改变不了他本身对PM的技术定位和管理的歧视。

能够合理的利用手下去完成目标，远比你自己去创造能够给公司最大的利益，因为你有一天不在公司了，公司就像丢了半壁江山，反之，即使你离开公司，公司依然能有效的运行，这也是职业道德。

作为程序员的未来，不是做一个合格的PM,更不是一个合格的CTO,我认为是创办自己的公司，建立一份属于自己的企业，给后来人提供更多的offer,只有这样才能生生不息。

说的大了，呵呵

其实最根本的问题在于技术人员很少会想到管理层需要技术上的强有力的支持,而且在困难面前公开的表达困难,会让很多人觉得自己很无能.而实际上对困难的讨论,是风险管理的最基本要素.国内的很多企业确实缺少有技术能力的管理层,但是我很少发现缺少有倾听技术人员意见的管理层.多人很多时候管理层会把技术人员的意见不接受,但是我确实发现没有几个企业会把这些的意见不听取.他们不接受,往往是他们认为他们可以承受技术上的这些风险,而这些风险不是他们自己能发现和解决的.因此上说,技术上的风险规避,最重要的还是技术人员可以在早期提供一些说服人的证据.这样即使在一个项目中造成了失败,今后的项目中技术人员的意见就会更有分量.
我们说到团队,似乎就总是有人想到,大家和平共处,接到命令就无条件的执行.其实这不是团队的做法.团队中也会有斗争,也会有分歧,这些都需要进行充分的交流.一个命令是不是应该得到执行,是要看这个命令到底有没有执行的必要.一言堂是绝对没有可能在软件行业得到长期的发展的,因此国内的软件企业往往是各领风骚三五年.

blackhost
管理是重要的,但是管理的手段要在软件开发中落实成为一种制度,就必须依靠技术.这是我们这个行业与其他行业相比一个明显的不同.
在中国从来就没有什么技术牛人,就更别说什么管理这些牛人的人了.软件行业的制度其实就是一牛人为核心组成的团队,进行手术小组一样精细的工作.
管理是一种基础性的工作,它不是一种凌驾于技术之上的手段,而是一种服务于技术,服务于技术人员完成工作,并且使他们能够健康工作的手段.牛人会死去,为之服务的管理方法也会随着牛人的死去会死去,这并不奇怪.就好像你没有奥尼尔和姚明,只有一个180的中锋,你却偏偏说战术是不死的,坚持打中锋战术.制度其实是因时因地因事因人的,秦国的制度拿到齐国肯定会失败,成吉思汗的制度拿到今天也注定会失败.每一个制度都是有其实现的基础的,软件公司的制度最大的基础就是软件公司中的技术人才的能力.脱离这个基础谈制度是毫无半点意义的纸上谈兵.

所以说你提的这些就是上文我提的到项目经理职责的一项：“汇报领导”，说服领导听从技术风险，作出必要的决策，当然谈到现在已经离题有点远了。还是回到正题上来，我感觉在这时候，做为PM在无法说服领导（领导明白，但是也有自己的苦衷）的情况下，如何有效的利用现有的资源，找到一条最适合这个团队的开发方法。能够发挥每个人最大的能力去完成这个任务，而不是让其中的某个人拖项目的后腿，难道就真的象各位所说的，没有任何其他办法，只能PM负责其全部吗？