TL日记

5天完成的,最后10天完了还做的不好,第二天第三天您干嘛呢?

五天完成的东西，还称得上项目吗，A君被你害死了~~~~，超时这么长时间，要么是A君对需求没吃透，思路不清楚，要么就是对公司的类库或开发资源不熟悉。
因为我看你说的，好像A君是新招来的，这说明A君处在磨合期，你就用熟手的标准来下任务~~~，唉

再个，不要把时间耗在无意义的文档和讨论会上，否则会让人有拖延进度的借口，
文档最好有模板，有例子，问答式或填表式的文档模板效率最高，出错最少

正如上面的dx所说，RUP和敏捷开发的区别不是三言两语就能说明白的，而且这些东西也不是一天两天你就能深刻领悟的，也不是说看一两本书就能掌握的，这些东西绝对不想什么SSH，struts之类的，一个礼拜可以掌握，而是需要长时间的理论及实践，同事还要不断的反思才能不段的去领悟。

这也是通用技术与工具（SSH，struts，这些在我看来算不是技术，仅仅是工具而已）的区别。

对于需求、设计、编码、测试，我还记得我在大学做毕业设计的时候，当时严格的按照RUP的方式来开发，结果就是很多文档，后来单单设计论文就把老师吓坏了，让我少打点。可是，通过这些年的经验下来，我绝对需求最好的纪录方式莫过于bug跟踪系统，即便你采用简单的todo-list都要比那些标准的需求文档要高效的多。因为需求总是不段的变化，你需要的是能够灵活轻便的工具来节省时间，而不是把那些时间都耗在那些所谓的标准文档上。等系统构建完备（如一次迭代完成），再来把这些文档标准化，比如把todo-list转换成标准的需求文档。因为毕竟那些所谓的标准的文档只是用来方便大家阅读。想想看吧，你打开一个txt的todo-ist是不是比打开一个word文档快很多？

同样的，架构设计之类的也是一样，先简单的纪录下来，后面在标准化。

总之一句话，简单的工具能够最灵活的面对变化，因为修改起来也很简单。在变化很频繁之前，我建议先从简单的工具开始。这也是软件开发里简单就是美的一种提现之一。

通常，我不喜欢详细设计，当然架构设计必须要有。因为，在你开始编码之前，简单的设计总是需要的。

当然，我是习惯于TDD的开发方式，也许这样的方式并不适合你，因此，也许你需要做详细设计。



和上面描述rup，敏捷开发一样，和SSH，struts等不一样，像TDD这样的通用技术，不是短时间内能够学会的，从你的言语来看，好像你对Agile和TDD的关系还不是很清楚，从这点来讲，我可以判断你至少还不习惯于TDD的这种开发方式，更何况Agile(如果我看错了，请恕我眼拙)，可是，你对TDD都了解的不多，你就跟领导反应采用TDD的方式来开发，我觉得这个问题比较严重。很显然你并没有考虑过风险，也许你考虑过了，但是你不知道。不管怎么样，每个开发人员都应该知道这一点，越新的技术，风险越到，你越不懂的技术，风险越大，就比如，如果你的C++掌握的很好，很精通，可是现在跑出个什么ruby来，人家说怎末怎末好，然后你就要抛弃c++而采用ruby，我是觉得这个很可怕，记住，你不知道的东西，风险往往都是最大的，我原以为对于你这样工作8年的，这些应该都知道，而且，对于一个优秀的开发人员，这些也是必备的。

我建议楼主还是多看看软件工程理论的东西，在你实践之前，理论并不是想象当中的那么没用，否则，这个世界也就没于书了。

最后，我把我以前的一个同事的话转给你，“你评估任何开发时间，一定要以你正常的开发时间 X 3 ”，就如你上面的，你分配给A 君的，应该是5 * 3=15天才对，而且，你应该还要考虑其他情况，比如，你的5天他是否能5天作为，也许你5天做完的东西，他要7天呢。你千万不要这么想，我5天做完，他也必须五天作为，因为，还有一件事情，你拿的工资和他拿的相信以不一样，如果你真的这么想，那可以预见的是，你们这个团队不会久远。

说的比较多，希望对你有所帮助，这仅仅只是偶的想法，仅供参考。

哎，要预见风险啊，偶就是没预见到金融危机这么严重，然后就贸然离职，搞得现在都还在失业呢 ，痛苦。

有几个问题：

1、对于工作量评估的经验不足；
2、对于团队成员的能力了解不足；
3、对于领导的关注点理解不足。

严重同意！！！为什么到第10天才得出这个结论？计划的执行进度跟踪至少要细到天，楼主说说这10天自己在干吗，就知道问题出在哪里了...

会做的越来越好的。BBS 起到发泄和减压的作用。

如果我把开发评估时间*3，领导会直接拍死，