软件工程及改进经济学--过程篇

  之前瞎写一气，谈了谈人，其实随便聊聊而已，现在回头看幼稚的想笑。
  我在项目中有个兼职，就是打版本，也就是daily build啦。这个看似简单，不过对于我目前这个挂了20多个项目的solution来说，每天的编译不得不说是个大问题，尤其是微软那个破IDE，真的是 I fu le you。现在二次开发了buildit，还好半工具化了。可是，项目中经常有人不自觉，到了时间不把代码check in，每次都要编译3、4次才可以完成任务。有时候气的想抽他，真不明白，为什么稍微用点心可以做好的事情非要以这样双输的结局收场？这其实是管理中的尤其是团队合作中的大问题，每个人该干什么？
  我们在招人的时候通常要求有项目经验，行业经验等等。其实也不是非要他精通到什么程度，而是大体上知道当今的软件开发看上去是个样子。我上面提到那个人。。。埃，还有一个是和他同期进公司的，我个人对他的印象非常好，为什么呢？就在于它进入公司后，没有问什么技术阿业务阿等等问题而是问了很职业的问题：可否把公司的规范先给我熟悉以下。我立马肃然起敬，暗挑大拇指，罢了罢了阿（偶爱听评书，单老师常用的）。这才叫高手，这才叫职业选手。相反，那个动不动捅娄子的人，我到现在问他还看过规范的时候，他还回答看规范干吗？哎，项目经理五大职责之一就是“招募”，我以后再聊。
  对于个体来说，规范是说编码规范（引用规则、命名统一之类），设计规范（符号统一、工具一致）等等。从软件开发项目级别来说，我个人觉得流程最重要，目前来说主流的是RUP了。其实它是一个系列的最高境界，其中还包含PSP、TSP这两个前置流程。TSP是必须以PSP为必选前提，我个人认为TSP也应该是RUP得必选前提。我印象最深的就是TSP中提出的process script概念。因为TSP中反复强调了一个概念operational.就是流程的可操作性。这也许对于经验丰富的人来说或许是不必要得，但是对于一些新手，或者是彼此间缺乏磨合的成员来说，是一个难得的指导性材料。如果你遇到问题的时候有一个很明确的手册告诉你怎么做，应该是一件快慰的事情。这个概念有点像“大M方法集”，不过比他要简化，更实际，毕竟哪个是以公司级别为主，写个几百页都不在乎。TSP 得script需要精确到开几天会，每个会讨论什么，达到什么思想统一，非常具体可操作。在这样的流程中，每个人都很轻松。

      再说说RUP吧。我印象中是从刚上大四就开始看它，反正也不懂，就背了三个核心概念。现在回头看那本书3遍了，每遍都有不同的收获尤其是结合项目的进展，发现真的有道理（我知道我的意见不重要）。我感慨最深的就是这个U了unified。这个词应该是核心形容词，精华所在，也是所有项目最头疼的事情了。每个概念每个知识点无不可以从这个u来解释。像做到统一，首先必须使用use case driven。我们做需求分析，设计，编码都得有个来由吧。这个来由必须追溯到某个use case。尤其是在做变更的时候。例如客户要把某个按钮的功能去掉，我们RD接到电话，就把这个按钮删了，多简单。可是此时如果往上追溯，就和这个use case不统一了。这个U就没体现出来。这个例子是不是不好，容我在想想。。。。。我个人始终决的“统一”是一个很好理解很好计划但是很难执行的管理目标。且不说达到磨合的高度统一，单单是形式上的统一就已经是难上难了。每个人都有思想每个人都有个性，尤其是程序员，还记得cfront小组说过，管理程序员就像放牧一群骄傲的猫。是的，这些以技术为重的特殊人群，在技术更新如此之快的大环境下，有谁可以忽视先进技术对个人的冲击，谁不想在项目中运用越新越好的东西。相反，从管理角度来说，越成熟的东西就越受欢迎，谁都输不起。看看，项目可能还没完全启动，management goal和tech goal就已经不一致了，你说整个baseline怎么可能汇聚，大多数都是平行线，各忙各的。这些都是管理学上的矛盾，需要项目经理高超的协调技巧，平和管理和技术创新上的权重。
    RUP处理这个问题，是一个“迭代”的方式。先说说我碰到的情况，我发现自从RUP发明了迭代的观念并被业界广泛接受的时候，我们RD的恶梦就此开始了。迭代成了不负责任的代名词。每当我针对spec中的问题提出疑惑的时候，总是能听到这样的声音，我也没想过来，你先作吧。一开始我们还是抱着理解的态度，可是我发现这样的结果是我手上两个模块都是已经release了，都被要求重新立项。要不是路费太贵，我真想冲到总部去抽他。
    其实，我个人对迭代的出现一直是抱着既欢迎又抵触的情绪。欢迎是因为，他的确从管理角度弥补了个体或者说是技术上的不成熟，就类似于我们常说的好的管理可以弥补技术的不足，但是技术上的强项绝对弥补不了管理的缺陷。那为什么抵触呢？很简单，我们都是半熟的技术人员了，谁都不想自己的代码，自己的设计动不动就被迭代回去了。碰到会说话的吧，会告诉你你为项目作了很大的贡献，不会说话的就是硝烟弥漫了。同样地时间同样的精力，一遍一遍的迭代，很少会带来个人或者组织技术上的突破，只是管理上的成功，所以从比较私利的角度说，我并不喜欢迭代，就像每个人都喜欢write而非maintain。
    说说迭代把。从RUP的过程框架来说，是以框架优先的。什么是框架？简单说是一个系统表现出的特性和行为。他和需求之间的关系就是鸡生蛋或者蛋生鸡的关系。这个比喻其实非常经典，为什么呢？因为迭代强调的是整体进化，而非局部关系。一次次的迭代使你的项目的框架更加优秀更加成熟。而非简单的把设计改良这么单一的事情。