TL随笔(一)

    从程序员转型担任TL也有将近一年的时间了，在此记录下期间的思考和获取的知识，也算是一个总结与积累。

1.项目管理

1.1 过程
    在这个产品线，项目的过程基本是瀑布式的。
    项目的过程究竟该是瀑布？RUP？敏捷？这应当是根据项目、公司的实际情况来决定，
他们只是PM手中的螺丝刀，当遇到一个螺丝时，应当根据是否适合的原则来决定用哪个螺丝
刀，而不是觉得这个螺丝刀很强大就到处使用。

    例如在这个产品线，通常都是1-2个4年以上工作经验的主程序员搭配上几个1-2年的开
发人员就组成了一个小的开发团队，人员流动较为频繁，大部分人员能力和意识都不强，而
已公司没有对敏捷比较精通的人员，也没有团队实践过，这种情况下，使用敏捷显然就不太
适合。

    对于RUP而言，它的迭代过程会贯穿流程的每个阶段，而目前在公司，流程被划分成了
几个独立的部门去协作完成，其中包括解决方案部、产品研发部、测试部，要完成迭代，就
需要几个部门配合工作，但这在公司没有相关流程制度的情况下，难度无疑是很高的。对于
小项目而言，如果从需求到测试，一个团队内部都能并且允许自己搞定的话，那么裁剪一下
做小范围的迭代看起来还是不错的选择。但实际上，测试部门只能检查BUG，对于功能上是
否满足需求，还需要用户来做决定。而用户参与的测试（UAT）是需要去申请的，由于我国
国情，实际用户一般都很忙，能有时间参与UAT就不错了，想在迭代里加入UAT不大现实，但
不加入的话，迭代的意义可能就不是很大了。

    目前项目的典型流程为：“计划-建设方案-需求细化-设计-编码-内部集成测试-部署-
测试部门测试-用户测试-上线”。

1.2 文档
   要交付的文档有：
《项目计划》
《建设方案》
《详细需求说明书》
《设计文档》
《测试报告》
《上线说明文档》

   项目中文档的主要作用是规范行为、知识传递以及统一认识。

   实践过程中发现很多开发人员是以写完了交差这样的心理去应付布置的文档任务。原因
有以下几种：
1.自身技能缺乏。不知道怎么写，不会表达。
2.认识不到位。认为文档无用，写出来也没人看，代码与注释就足够了。
3.该文档确实没起到作用，仅仅是作为制度上的交付物而存在，白费工作量。

    对于情况1，应当通过组织培训、组织文档评审等办法来提高人员素质，通过制定相关
的文档模板来提高文档质量与写作效率。

    对于情况2、3，其症结都是相似的，应当想办法使每一个交付文档起到应有的作用，并
使每个成员明白该文档的意义。对于流于形式徒耗工作量的文档，应当毫不留情的砍掉。当
然，可能并不是因为该文件完全无用，有可能是因为相应配套的人员、制度、素质跟不上，
而使其无法起作用，如果配套难以跟上，那还不如砍掉，以后可以跟上了再恢复。