icech：在博客园看到这篇文章，写的非常棒！贴在西部E网中，但是不知道该属于那一栏目，就先放这里吧！

        虽然我步入软件开发行业才半年有余，但是却有幸参与了一个开发团队有80多人的大型项目的开发。作为一个初出茅庐者，本该抱着学习的心态，学习项目成功的经验，可是我却在挫败的痛苦不断地总结，不断的幻想。通过这半年多的开发体验，我得出了一个结论：项目中的人的因素是最重要，而作为项目管理者，能够打造一个让程序员觉得爽的开发流程，能够在实际开发当中给予开发人员以具有指导性的建议，才是成功的。 

        我所期待的开发团队是这样的：
        1.作为系统分析人员（System Analyst），除了要从商业逻辑上把握，还要能够从技术上做整体把握。 他们需要对整个系统做详尽的分析与设计，要考虑模块之间的关系，也考虑如何构造对象，说到底，就是得有大局观。把握需求的分析人员，应该参与到实际开发中来，写UT Case就是他们的任务，这样他们就没有办法逃脱写Code了，就可以真正让自己跟开发人员打成一片，而且也能够把握好需求。除此以外，SA还要负责对技术的整体把握，他需要在不同的实现方式上做出抉择，而不是放任自流。
        2.作为高级开发人员（Advance Programmer），除了要熟悉某个模块的商业逻辑，还要为Programmer继续完备UT Case，因为SA所写的UT Case可能更多是覆盖Business Logic，而AP而要从系统实现角度上去完善这些Case。同时，他们需要对整个模块进行设计，关注与其他模块的接口，同时重要的商业逻辑由他们来做Coding和Test，并且给予Programmer以足够的支持。
        3.作为开发人员（Programmer），除了要严格按照业务逻辑的要求去做好Coding之外，还要能够懂得做好代码的优化，善于总结良好的Develop Style，并且及时与其他开发人员Share。

        我所期待的开发过程是这样的：
        SA做好整体设计，针对业务逻辑写好UT Case —> AP 继续完善 UT Case，并实现核心业务逻辑 —> Programmer 根据所有的UT Case进行开发

        这样的流程最大的好处就是目标明确，分工明晰，避免了有人只说话不做事。至少Programmer知道自己要做的就是让这些UT Case都通过，SA通过写UT Case去保证业务逻辑的完备性。

        聪明的你们或许会发现怎么没有提到文档呢？呵呵，在我看来，这些完善的UT Case就是文档，而且开发团队需要的是一份能够充分阐述业务逻辑的文档，在我们的项目中就是LPS(Logical Processing Specification)。我想只需要这个就足够了。可惜的是，我们在开发过程中还要写AMDS(Application Module Design Specification) 和 APCS(Application Program Class Specification)。多么纷繁复杂啊，然后这些文档和代码之间的一致性如何保证呢？ 
      
        我多想奋臂疾呼：给我们一个觉得爽的开发流程！

        [前言]：今天是7月30日，离开公司也正好一个星期。而今天也是我呆在深圳的最后一天，再过不到24小时就要踏上北上的征途了。离职之后，在深圳的窝里呆了几天，对于软件开发，尤其是项目的管理，有了一些新的想法，遂延续前篇^[1]，将项目中的不足之处记于此，以作日后警醒之用。

        1、需求不明确；项目进行到现在，也有一年有余了，而进行需求分析和概要设计的时间也有近一年了。虽然我们有很多的文档，文档也是洋洋洒洒数千字，上万字，然而我们对于用户需求把握的程度还是很糟糕的。最明显的一点，由于我们所要做的系统第四版了，在此之前的第三版是十年前开发的。那么我们是对原有的系统进行升级呢？还是重新设计一个系统呢？我们的SA一开始都号称着要做一个全新的系统，然后都去跟客户做interview，去收集需求，可惜的是能力有限，时间又急迫，使得需求分析的结果还不足以指导进行概要设计。结果在开始做概要设计的时候，业务逻辑不清楚也没有采取进一步的措施。也不知道是谁提出了由旧系统的源代码去提炼业务逻辑，接下来公司就组织了很多SA，乃至AP去读源代码，然后根据这些源代码去写概要设计文档。说实在的，我觉得很不可思议，大家也许会说，读旧系统的代码没有问题啊。没错，以旧系统的代码作为参考是没有问题，可是如果是将旧系统的源代码直接转换成概要设计文档，我们前期做的业务需求分析不就一点用处都没有了吗？况且这样做，是不是也正好违背了做一个全新系统的想法呢？在我看来，根据源代码去提炼需求，并且做概要设计，无异于盲人摸象。缺少了整体考虑的需求分析，恐怕就是头痛医头，脚痛医脚，而人还是照样over了；

        2、缺少一个完善的training和学习的体系；我觉得这是一个很糟糕的问题。虽然大家会觉得一个小型公司要建立一个完善的training体系几乎是不可思议的，可是我想说，我们必须需要这样的一个体系，即使这个体系仅仅是针对现有的项目的。因为会随着项目的进行，有人会离开，也有新人会进来，如果没有一个完善的体系的话，人员流动对于项目的影响将是非常的大。而且在促进大家去学习的过程也可以提高大家的学习能力，也能够筛选出人才来；
    
        3、缺少激励机制；在项目当中，公司会有很多的惩罚措施，譬如会有一个所谓的红黑榜，然后只有人受罚，却没有人得到奖励。我曾多次表示反对这样的方式，因为我觉得人性总是本善的，应该通过激励的方式去促动大家努力工作。因此，我会想，如果有一个Expert排行榜，会不会更好呢？上榜人员是通过全体程序员投票选举出来的，公司将会对他们给予奖励。给予Expert称号的最大好处就是树立了在开发过程中的权威与榜样。如果有问题，可以找相应的expert解决，正所谓，闻道有先后，术业有专攻，他们既然是专家，就会对在解决相应问题的效率上和结果上都会有过人之处；同时也可以激励其他员工向他们学习，起到了模范作用；

        4、SA与代码脱离，与技术脱离；这是我最百思不得其解的问题。SA是什么的缩写呢？是System Analyist。那什么是系统？我没有办法给出准确的定义，但是我想一个系统必须是为实现某个既定任务而存在的，业务需求就是“任务”，确实是最重要的。那么，如何“实现”是不是也很重要呢？没有了可行的实现手段，所有的“美丽任务”都变成了Mission Impossible了。我觉得两者都是具有相同的分量的，SA要关注需求，更要关注实现。然而我们的SA更多时候是充当着行业专家的角色，可是他们并不是行业专家。结果这个角色耗费着项目的大部分资源，却鲜有贡献。既做不了设计，又做不了coding，到了我将要离开的时候，他们充其量只是一个工头了，问程序员，“什么时候能够做完啊？”，“我只要结果”。这多么的可笑啊！SA是可以不直接参加做coding ，但是他们不能够对技术几乎一无所知，否则，他们如何做分析呢？System的组成不仅仅是业务逻辑，而且业务需求最后也转化为一行行的代码，一个个能够运行的模块啊。为什么就只有SA给大家培训业务逻辑，却没有人为SA培训技术呢？可笑！

        5、缺乏诚信，缺乏敢于承担责任的勇气；在项目当中，从程序员到SA，都有一部分人员缺乏诚信。尤其是SA。我曾经听到三位subteam的老大关于保证业务逻辑的对话：
        A问B：“你怎么保证业务逻辑都已经OK了呢？”
        B马上说：“review代码咯。”回答得一点迟疑都没有。
        C听了，接着说：“你真的一个一个class去看，一行行代码去看？”B也表示了怀疑：“你知道一个模块里面有多少的class，多少的代码吗？你怎么可能看得完呢？”
        A显出一副无可奈何的神情点了点头：“没有办法啊，为了保证逻辑只好这么办啦。”
        哇，我听了都快吐出来了。先不说保证业务逻辑根本就不是通过review代码可以实现的，光说A的诚信就TMD的有问题。他作为SA，首先不可能有那么多的时间将我们所有的代码进行review，而且，我也能保证他从来都没有看过，因为他根本就没有办法对我们系统的整个架构说出个所以然来。还记得《程序员修炼之道》上的第一条：Take responsibility。与之相应的那一节的前面还有这样的一句名言：
        The greatest of all weaknesses is the fear of appearing weak.
        作为程序员，作为SA，乃至每一个做IT的人，都应该懂得承担责任，为自己的每一行代码，每一句话。我想这是做程序员的最基本要求吧。

        [后记]：今天是8月1日，随笔终于都写完了。一部分是30日写的，而大部分则是在北上的大巴上写的。离开了，放弃了，然后徘徊了，痛心了，最后惊醒了。到了一个新的地方，期待着新的开始。写得不当之处，还请各位多多批评。