发布于 由xbull

第一个礼拜上班，就加班了～～

呵呵，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团队可以考虑借鉴这一点。团队不是每个人都具备强悍的编码能力，也不是每个人都想做开发人员，我们必须有人专门来关注项目的质量问题！

“第一个礼拜上班，就加班了～～”的9个回复

  2. 听XBull的说法，感觉TM的QA和RD应该是有分工、但高度合作的统一团队在开发项目：在这一点上H3C是与之则大相径庭了。
    博主 对 llyy 的回复: 2007-08-05 20:14:25
    QA和RD是同一个项目组的成员，QA主要关注质量，以便将产品开发的后期维护成本降到最低，与H3C相比，最实在的例子就是系统测试样例（其他很多细节就不讲了），在这里，系统测试样例是QA来写，我觉得这样很正确，RD开发的时候，QA可以并行写测试样例，效率提高的同时，也让RD专注于创造，各尽所能。
    当然，项目流程本身不能说一定要这样，一定不能那样，关键在于实践以及实践过程中的问题，解决问题才是硬道理。我觉得我们现在的问题，一是我们的质量控制还没有做到最好，质量部的工作尚在探索当中，如何建立我们的质量保障体系，大家还没底，我只是给大家提供一种思路；二是我们的团队太过于专注于技术，评价一个人的标准基本上还是先看技术能力，这是有问题的，尤其是我们要产品化，如果总是以这种标准来评价队员们，就很难说我们到底有多少人真正去关心质量，我们的质量控制到底能够做到多好。

    回复

  3. 我们不一定有专门的测试工程师,但是一定要有质量保证机制
    当然幸福吧,同优秀的人一起工作

    回复

向llyy进行回复 取消回复

您的电子邮箱地址不会被公开。