之前瞎写一气，谈了谈人，其实随便聊聊而已，现在回头看幼稚的想笑。
我在项目中有个兼职，就是打版本，也就是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就没体现出来。这个例子是不是不好，容我在想想。。。。。
本文地址：http://com.8s8s.com/it/it33694.htm