TL日记

十一长假干啥？原本计划购物+电影+游戏+运动，今早起来忽然回忆起半个月之前工作中的问题，很多问题想不明白，Google了一下到了JE，拜读了不少高人的大作，感觉就像蒸了一个桑拿，痛快淋漓。从中发现自己很多不足，感觉和高人差距太大，于是心中愤慨，工作8年了还有这么多不懂的地方，一定要振奋起来，看看从我现在的状况达到高人的境界需要几年，计划将今后的工作日志一一在这里贴出来，根据每天所发生的问题，希望能与高人实时互动，得到高人的指点。

先说一下个人情况。81年，中专，2000年开始工作，最初做美工，过了一年转php，过了一年转java，至今。期间有过2年创业，1年部门经理。当前在一个150人的公司，软件部门50人左右，我在一个Java组（3人）。

部门将计划在半年左右扩招Java组到10-20人左右，这给我提出了严峻的挑战。而无论半年后是否会扩招到20人，从个人成长来看也非常有必要提高各项水平。

我个人当前存在的问题：
1、软件工程只是略懂理论，没有真正的实践经验；
2、Java技术只是停留在应用开发阶段，对OOP思想没有真正贯彻，在进行大的系统设计时感到很吃力；

小组内另外两个人的情况：
1、A君：本科，7年经验，Java2年；
2、B君：硕士，半年经验；

小组当前工作情况：
1、我：负责公司主要软件的版本；
2、A君：另外一个软件的版本；
3、B君：配合我和A君的工作；

小组内用到的工具：
IDE:MyEclipse
版本控制：VSS(因为整个软件部门很多C++代码，领导用惯了vss)
Bug跟踪：JTrac

部门内常用的文档：
规格，概设，详设，修改。

回顾前两周工作中存在的问题：
1、一个我自认为我可以5天搞定的项目（项目A），直接给了A、君（我去修改另外一个软件的UI和实现新功能），结果做了10天（包括每天加班到11点）都没有作出合格的版本；领导很生气，后果很严重。部门领导认为我在这个项目中计划、人员分配上有严重的失误。
2、A君和B君在开发过程中没有文档、设计；

针对以上两个问题，部门计划：
1、项目A重写；
2、Java组建立一套严格的规范（我已经草创了一套《JavaWeb开发规范》，但感觉执行起来很困难）

国庆7天之后，我将把每天工作中遇到的问题和心得贴出来，希望高人能够解惑。

整个小组先做个回顾会议,群策群力。

可以参考 SCRUM的retrospective的方式。

谢谢。
头一次听说SCRUM。之前看过一些RUP，其中的每次迭代最后的“评估会议”和你说的retrospective可能类似。我也有此想法，打算过完10.1就和A君、B君来一次retrospective，回顾一下项目中的过程，总结一些教训。

有几个问题请教一下：

1、RUP和敏捷开发有哪些区别？

2、每一次的迭代是否可以理解为一个“版本计划”。当前我们部门还没有正式的版本发布流程，部门领导也意识到这一点，比如版本目标等，都不是最初设计的，而是忽然市场有哪些需要了，临时确定在某天要出新版本，其目标、需求、规格都是很模糊。上一个项目中的失败中，我们三个人对需求规格理解不够清晰是一个最为显著的原因。

3、每一次迭代都有需求、设计、编码、测试，如果是增量的、在当前版本上进行的新功能增加，那么其中的“设计”是否可以理解为在某一版本基础之上的“修改设计”？那么这个“设计”的输出就是一份“修改设计文档”？

这些问题也都不是两三句能说明白的。
推荐一下Crystal Clear，假期有空可以看看，也许能回答这些问题。

水晶项目管理体系（Crystal Clear）
http://tuti.iteye.com/admin/blogs/243678

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

对进度的可视度不够,
可以提高工作量来增加可视度
也可以自管理来增加可视度

主要看你想不想花这个精力来作了.

试着回答这几个问题



下面Agile,以Scrum为例。

1. 看看RUP和Agile的书可以从理论知道他们的区别，具体的需要自己去实践才知道。 总的来说Agile是轻量级的过程，对<10个人的项目很合适，项目如果很大的话也是可以的。 像我们项目，>70人，也采用Scrum。 Scrum of Scrum，Scrum of Scrum of Scrum呗。 Agile最适合前期需求不明确或者需求变化快的项目，短时间推出一个可以work的版本，对项目成员来说有成就感（激励？），同时也可以得到客户的及时反馈。发现问题可以早解决。
从你们项目来看，Agile应该是一种不错的选择，当然最好自己先学学Agile,理解它的一些Principle,Rule,然后慢慢实践摸索，找到适合的应用Agile的方式。比如说Scrum Daily meeting, 原则早上来了开比较好，我们组是下班前看，因为大家上班时间不太一致，经常10点还有人没到。 又比如一般一个Sprint是4周，我们组4周实行了半年，现在变成了2周。

2. 一次迭代可以认为是一个版本计划，但这个版本并不一定发布，但最好可以Demo，可以看到这个迭代的进展。

3. 是“设计文档”而不是什么“修改设计文档”。 设计文档尽量精简。 我说说我们的情况。一般我们1个人月的工作量，设计用3－4个PPT页面可以涵盖，主要是用来交流讨论用，有high level的设计就可以了（功能是什么，大概怎么做，和其他模块有什么依赖，影响等），真正的detail设计在代码中体现。 注意增加单元测试的覆盖率，虽然有时候这个很难。

另外retrospective貌似很好，发现不足，提出改进意见嘛。 从实际看，这个也很难。有些问题要解决执行很困难。我记得去年提的问题还有很多没有解决。：）  但还是强烈推荐你试一次。

谢谢各位的意见。

ladofwind，在发现存在问题的第三天的同时，我正在另外一个软件上，同样是急事。我当时就想干脆我一个人来干，2天内一定解决。当然，对此错误的说法领导严厉的批评了我。后来我想介入，可是发现里面太乱。灰心之余也无济于事。

抛出异常的爱，管理的可视度怎么理解？

ewon，Agile是TDD吗？我找了些资料，还是了解不多。我曾跟领导反映过采用TDD的方式来开发，领导表示以前有过类似的失败案例，不想冒险。另外，领导制定了在产品修改时一定要有非常详细的“修改设计文档”，堪比详设。

国庆之后的一周，新招了一个实力较强的人（C君），以前做过TL。同时，另外两个同事也在忙着自己独立的软件。看着他们那么痛苦，我也是爱莫能助。因此铁了心，下次新的版本时，无论哪个软件，都必须给我把详设和修改设计统统写完整，文档一次不能通过评审就一直重复。

最近领导计划把JTRAC推广到全公司各个开发部门，但需要对JTRAC作一些修改，领导就安排C君负责修改。现在小组内的态势是：
A君：独立负责某软件的1.0；
B君：对上一个失败的产品进行代码整理；
C君：JTRAC修改；
我：某软件的最新版本；

如果是一个人负责一个产品，我就不用花那么多心思了。但这绝不是理想的开发模式，没有团队协作可言。

五天完成的东西，还称得上项目吗，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天做完，他也必须五天作为，因为，还有一件事情，你拿的工资和他拿的相信以不一样，如果你真的这么想，那可以预见的是，你们这个团队不会久远。

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

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