朝得银弹，夕死可矣！
2004-06-04 00:49 FantasySoft 阅读(3674) 评论(12) 编辑 收藏 举报
孔子云：朝闻道，夕死可矣！ 我想说，朝得银弹，夕死可矣！可是，有银弹吗？没有！
虽然我步入软件开发行业才半年有余，但是却有幸参与了一个开发团队有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)。多么纷繁复杂啊，然后这些文档和代码之间的一致性如何保证呢？
我多想奋臂疾呼：给我们一个觉得爽的开发流程！
虽然我步入软件开发行业才半年有余，但是却有幸参与了一个开发团队有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)。多么纷繁复杂啊，然后这些文档和代码之间的一致性如何保证呢？
我多想奋臂疾呼：给我们一个觉得爽的开发流程！
