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

安排他们学习java15天,代码走读15天

开玩笑,他们都会"java",简历上白纸黑字写着的

说句或许与题无关的。这么一个组，我根本就不会去带，我也不会接受这么一个项目。带这么几位做事，还不如我一个人做来得方便。这种项目从第一天就注定了失败，唯一避免它失败的办法就是不要开始。

此项目注定会失败.这就好像你说我需要1个小时之内从北京到达纽约,但是你只能跑着去.
作一个项目首先就需要判断这个项目是不是会成功,然后按照成功的可能性进行策划,以选择一个最优解.也就是成功可以尽量造成更大的收益,失败也可以减少最多的损失.

谁说一定会失败？？我就是这样，手下两个北大青鸟刚出来的，一个南方职业学院出来的，一个由lotus刚转过来，再一个做delphi3年，也是刚学java，做一套审计实时监控系统。说实话，的确是苦，但是还好，目前还算成功。
   我对他们进行前期培训，然后过程中，每周都进行组内培训，一到三次左右。整个框架代码是我设计，也是自己一个人实现的。
   他们都很不错，至少能够统一思想，把握目标，并且也还有一定学习能力。我告诉他们什么该学，什么不该学。四个月下来，他们现在的实际工作能力完全可以超过其他用java半年左右，什么都去学，什么都去搞的人。
   一个好的项目经理，当然希望手下有强将，但是很多不是自己能决定的。除了好的计划与跟踪、控制外，更重要的是懂得怎么去合适地用人，怎么去培训人了。
   当然，这样的工作也属于无奈，整个过程下来，我感觉人都精力下降很多，谁都不想这么苦的。

     任何一个团队都需要协作，需要磨合，并不是说你手下有很多非常厉害的人，你就能订好计划，不是这样的。要做好计划，必须要有比较好的预估，工作量、开发能力、风险，各方面都需要。
   在面临一个新 的团队时，除了你自己以往的经验外，你需要采取的是先松后紧的方式。也就是同一类型的任务的时间安排是不均匀的。这样，可以方便你及时了解和变更。同时，任务的计划切忌算上加班时间，否则，你的项目缺乏一个良好的调节机制。
   最好，也是最重要的，就是第一阶段失败（比如这个月原型没有完成，可能性非常大），要进行总结。一个好的项目总结对整个团队都是非常有意义的。现在很多所谓的项目经理，都是做一个丢一个，以往的项目工作根本形成不了经验。很多的计划与实施完全是拍脑袋。

关于这个问题，我很赞同凤舞凰扬的说法。

很多时候你是无法选择你的同事的。《人月神话》中推荐按照外科手术队伍的方式来组建开发团队。就是说经验最丰富 PM 应该承担大部分核心代码（那些可重用的部分，或者是最难的部分，做出来可以让其他人参照着做）的开发工作。其他经验不足的程序员做一些外围的难度较小的开发工作。《软件工艺》同样推崇这样一种类似手工艺作坊（什么？作坊？你又皱眉了不是，我早就料到你会这样）的师傅带徒弟的开发团队组织方式。

根据我和我同事的经验，我本人确信这样的开发团队组织方式其实才是软件团队最有效率的一种组织方式。有些人总是指望混到个什么 PM 后就可以脱离编程的苦海。如果是在我们这里，对不起，我们不养完全脱离编程的懒汉。你仍然需要负担最重要的那部分编程工作，可以说你的责任更重了。当然除了编程你还要做一些其它的重要工作。但是一旦到了编程阶段，大家一起上阵，都可以担任程序员的工作。兵熊熊一个，将熊熊一窝。软件项目成败的关键就在于这个 PM 能否身先士卒，吃苦在前，享受在后（那位又说了，我们讨论的可都是高深的软件工程问题，这个不伦不类的党国宣传家是从哪里冒出来的啊）。作为一个 PM，你不冲上去就别指望会有人冲在前面。

《人月神话》、《人件》、《软件工艺》这三本书足以让我确信这是一种最有效的团队组织方式了。

非常同意凤舞凰扬,dlee的说法.
再说这个这个团体一点都不差呀.
一个项目成功不单止看技术,看经验.

还有就是很赞成凤舞凰扬的那句话:但是很多不是自己能决定的.老板要你带又有什么办法呢?
难道别人真得不好吗?还是自己认为自己很强,带这种队很难过?你也有过很水的时候,你也有很多不好地方,你忘记你曾经了吗(啊,你一开始就是PM,喔,那就当我没有说过)?

还是一个老办法吧,多交流,多相信,好的东西就是这样做出来的.

我的看法和各位不同，比较倾向于凤舞凰扬。

ozzzzzz说：“此项目注定会失败。”
gigix说：“这么一个组，我根本就不会去带，我也不会接受这么一个项目。”
dlee说：“我本人确信这样的开发团队组织方式其实才是软件团队最有效率的一种组织方式。”

而我的看法是，这几个家伙是你唯一的选择，你不是老板，你只能和他们“同舟共济”。有一次看到一本书，讲管理学的，《这是你的船》。虽然没有细翻，但却觉得很有道理。

尽人事，而听天命。如果项目到最后真的完不成，那也只能由他去了。在项目没有宣布失败之前，你总要尽自己的全力，而且还要鼓励、带领其他几个家伙，一起尽自己的全力。

这样的过程，就是我们最经常遇到的软件开发。

实际上这里有一个问题,似乎dlee和风舞飞扬采取了一种向上的态度,也似乎他们收到了良好的效果.然而实际上情况并非如此.
中国软件行业的问题,很少是出自地下干活的人身上,关键还是企业的决策者和经营者出了问题.就这个情况来看,如果一个PM得不到一个令人满意的团队,这样的事情正常吗?军队在上战场前不经过严格的训练这正常吗?拿着客户的钱搞自己的内部培训这正常吗?如果一个公司经常性的是这个状况,这样的公司有存在的可能性吗?
人不能选择自己的同事?如果真的不能事情就好办了,但是同事的选择这件事情我看多数还是你不能选择和你喜欢的人共同工作,但是你确实可以选择不同你不喜欢的人共同工作.
一个团队之所以叫团队,就是大家都为实现目标出了正面的力.但是很多时候软件开发这个事情上,特别是在国内,众多的人有意无意的在给项目的成功作后腿.这个时候最好的办法就是把这些拖后腿的人干掉.团队的内聚力在于大家有一个共同的利益基础,如果没有这个基础这样的团队就很难存活.
对于一个项目我接不接的底线,是我的项目组中有至少有一个人可以在项目最大时限能独自完成这个项目.这一点我想对大家都有参考价值.