朝得银弹，夕死可矣！

孔子云：朝闻道，夕死可矣！ 我想说，朝得银弹，夕死可矣！可是，有银弹吗？没有！

    虽然我步入软件开发行业才半年有余，但是却有幸参与了一个开发团队有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)。多么纷繁复杂啊，然后这些文档和代码之间的一致性如何保证呢？
     我多想奋臂疾呼：给我们一个觉得爽的开发流程！

     PS:我只是菜鸟一个，说得不对的地方，还请大家多多批评指点了！

软件工程的祖师 Brooks 一开始就是强调 PM 应该写代码的（请看《人月神话》中“外科手术队伍”）：

不知道从哪个自以为聪明的徒子徒孙开始，居然认为 PM 不应该做开发。软件工程所引入的项目管理理论认为作为一个 PM 来说，I needn't do it, I just manage it. （我不需要去做，我只需要去管） 这个看似正确的观点恰恰是问题是最多的。问题就是很多 PM 自己根本都没有做过（可能作为一个程序员都是不合格的），又何谈能管好呢？ 我们的 PM 比别的公司的 PM 强就是因为我们都是要参与开发的，代码我们都写过，软件开发的全过程我们都跟过并且亲自从事过。软件开发究竟是怎么回事，其中的酸甜苦辣，我们的理解比你要深入的多。我们就是事必躬亲，身先士卒，你不肯写代码，能跟我们相比吗？你比的了吗？你实践过吗？你敢实践吗？

软件工程我认真读过的只有《人月神话》。儒家经典我认真读过的也只有《论语》，其它的孟子、朱熹等人的境界哪里能超过孔子？让我读他们的书，他也配？！研究软件工程的为什么只有 Brooks 得了图灵奖？ 最近国内有个张大师宣称自己已经找到了银弹，那么今年的图灵奖肯定是非他莫属了。赶快去申报吧，晚了就要等明年了！中国人民连飞船都造的出，得个图灵奖自然是小菜了，呵呵。

我这里有一个所谓写代码的PM的例子就很好的说明了这个问题另外一面。她在做项目的时候肯定会说，留一块给我，到时候我来做。而这位同志的技术决策也真的是莫名其妙，今天看到这个好，那么就用这个，明天发现了新东西，就用那个，框架总是不能稳定，总是不断的推倒重来。搞了几年还不能搞出一个产品，遇到项目就要派一堆人做现场开发。于是这个部门就有N多个程序员，不断的在全国各地以10多个人为一组，现场开发。
嘿嘿，如此PM，带着一堆高帽子，CMM3，RUP，而且我也确实考察过他们的流程都还算符合规程，但是最后的结果就是如此。
我想说的是流程确实很重要，但是绝对不是最重要。

这个只是一个个案，很难说有多少代表性。根据我的经验，完全不参与开发的 PM 是很难对项目进度和质量做出有效的控制的，尤其是在资源严重受限工期又非常紧的情况下。

我倒是不觉得是个别的现象，至少类似的事情我已经遇到过几个。很多问题是那些人即使参与开发，都把握不了方向，他们不参与我觉得就更没有能力把握。其实做设计和做编码还是有区别的，很多人编码是好手，但是设计的整体思想却很差。而那些没有编码基础的人，我认为设计也肯定好不了。设计的过程就是权衡的过程，很多时候就是没有理由只有体验，你没有那些做编码的经历做基础，这些体验能来自什么地方？
其实说来说去，软件开发还是一件社会化的工作，希望建立一个包罗万象的模型，我认为不现实，就更谈不上依赖一个建立在这个模型上的过程了。

所以楼主就不用死了，万幸万幸。

要是真的有银弹，恐怕一大半程序员也该失业了。再次万幸万幸。