呵呵,dian刚刚在团队描绘了TM的美好生活,结果就加班了,有点像一个传说很高尚的家伙,正在众人夸耀的时候,突然间拉下裤子,肆无忌惮的开始小便

不过,加班也不算坏事,至少可以调休吗。第一个礼拜上班,对windows mobile的调试环境实在是不熟悉,而且文档也缺得很,一个礼拜下来只在about对话框上添加了几行字,暴汗!即使项目组不安排加班,我也准备周末来补补课的。TM的代码跟以前smant在软件组留下的代码有几分相似——几乎没有注释,不过代码质量真的不错,几乎可以做到70%的自注释,所以看起来不是很累,再加上一些很成功而且常见的设计模式的运用,使得研究代码的过程充满乐趣。上次与llyy聊天,谈到团队继承的两大要素:团队和代码,的确很有道理,TM这两大要素都有,只是文档还不够完备,Dian团队在团队方面有着“流水的兵”之先天缺陷,要始终注重梯队建设;在代码方面,Dian团队还有很多事情要做,最起码的,要统一代码编写风格和注释风格(至于设计,更多是考验组内的architech的能力);在文档方面,Dian团队做得很漂亮,只是别只注重给甲方看的文档,自己看的文档更要做好,做漂亮,不仅要做好技术手册,更要注意配置文档,使用手册等等过多依赖言传身教的资料的文档化

再说说开发模式,TM的开发模式还是比较传统的(相对于目前流行的敏捷模式而言),瀑布模型,实施细节与Dian团队的相似度非常大。TM的具体过程非常自由,不会过多限制细节,所以RD可以有很大的自由空间,单元测试都是RD自己保证,不会像H3那样做那么正规的覆盖率检查,总的来说,相比与H3,TM是假设一堆牛人在干活,责任心和个人能力是这种看似松散的开发模式能够玩得转的两大法宝。与Dian团队饿开发相比,TM最大的不同在于QA职能和重要性的放大。QA与RD相比,编码能力和设计能力肯定不如,但是知识面宽,测试经验丰富,沟通能力强,QA的职能范围贯穿项目开发的整个过程,与RD基本持1:1的比例,主要负责测试工作,参与review,监督RD输出,协调测试资源,保证项目按照TM流程进行。Dian团队可以考虑借鉴这一点。团队不是每个人都具备强悍的编码能力,也不是每个人都想做开发人员,我们必须有人专门来关注项目的质量问题!