软件过程管理的几点体会（转老大最后发的）

1） 用例驱动<o:p></o:p>

按照RUP的理论，软件开发过程是以架构为核心、用例驱动、迭代增量的开发过程。用例是RUP中非常重要的工件，用于描述系统最终用户与系统交互的过程，是制定迭代开发计划的惟一依据，并可直接转化为测试用例。<o:p></o:p>

用例从功能上等同于XP中的Story，但是表现形式更正规、描述手段更丰富。在开发过程中，用例起到了指导设计、普及业务知识、统一业务术语的作用。用例确定了，就等同于确定了业务接口（Biz Interface），即确定了业务接口的方法、异常（错误码）；同时在一定程度上确定了业务接口的实现方式，即通过抽象类、帮助类等描述业务方法的实现过程。因此用例质量的高低在很大程度上决定了整个系统或项目的成败，特别在项目团队中整体缺乏业务背景的情况下。<o:p></o:p>

用例重点不在于用UML描述用例之间的关系，而在其文本内容；用例的核心是描述参与者与系统的交互过程及其后置条件，从效果上看采用Craig Larman的两栏式更好些。用例要起到指导没有业务背景、缺乏领域知识的团队成员进行设计、开发和测试的作用，因此必须详细到足够程度。对于复杂的用例，可以采用活动图来描述状态迁移。<o:p></o:p>

写用例的过程本身也是个迭代的过程，有些用例因为复杂程度较高、需求模糊、执行路径较多等问题，在初期无法详尽描述；可以采用迭代的方法来处理，不可能、也没有必要一次就完整地描述清楚。<o:p></o:p>

XP中提倡用Story的方法来描述需求，其目的是减少写用例的时间；但是必须注意到前提是XP中的另外一条原则：用户须在现场。因为用户在现场，可以随时进行交流，因此用例的描述更多时采用口头方式进行。如果开发全过程中没有用户在现场，采用Story方式是不明智的、也是行不通的。<o:p></o:p>

2） 迭代开发<o:p></o:p>

迭代开发的目的是尽早确定系统体系架构、有效规避风险、及时获取用户的反馈意见等，其中要点：获取用户反馈、不断地校正需求；及早发现风险，并把风险规避到每次迭代开发过程中；提高团队士气，避免因为开发周期过长导致人员过渡疲劳。<o:p></o:p>

迭代开发的核心问题是合理制定迭代计划。制定迭代计划要以用例为单位，根据用例的优先级、技术风险、用户关注程度等条件将用例合理分配到各迭代过程中。对于较为复杂的用例，可以分配到多个迭代计划中，逐步完善和实现。迭代计划的制定应发挥用户参与的积极性。<o:p></o:p>

制定迭代开发计划，对子系统或模块来说，应以2~3周为一个周期；如果在时间范围内，无法完成开发任务，则应该减少本周起内开发任务，绝对不要延长开发时间。如果这样做了，势必导致迭代开发计划失去效果，并逐步丧失管理的依据和威信。<o:p></o:p>

迭代开发周期之间的分界线应该清楚、明确，在每个周期内流出30%左右的缓冲时间、代码重构时间、集成构建时间、用户交流时间等。在每个周期结束时，应完成部署和Acceptance Test；如果有用户在现场，应向用户演示系统并获取反馈意见。每次迭代结束时，都应该得到一个可以输出的可以运行的版本。<o:p></o:p>

     迭代计划制定后应分解为开发任务并分派到人，按照Scrum/XP的理论，这个过程应该由团队成员决定，而不应该由项目经理或其他管理人员分派任务。这样做不无道理，如果执行上没有问题，可以照此办理。任务分解的核心是：应尽量细化、按照每个人工作效率，分配的任务应确保在1个工作日内完成；任何超过一天的任务，都应继续细化分解。这样做的目的是确保每天下班后，代码能按时提交并进行日构建。如果任务分解不够细化，将导致日构建无法实现。另外细化的一个好处是可以测量，切记无法测量则无法管理。<o:p></o:p>

     另外要特别注意，每次迭代过程中要保持设计和代码的一致性，丧失设计和代码的一致性必然导致开发过程的混乱。<o:p></o:p>

3） 日构建<o:p></o:p>

日构建是开发过程的脉搏，至关重要；同时实现起来也是特别特别困难。微软公司拥有一流的开发团队，实现日构建尚且困难重重、颇费周折，可以想见日构建实现起来难度有多大。打个比喻，日构建就像杂技里的高难度动作，身体虚弱的人想玩非得吐血不可；但是即便如此，日构建还是要实现。日构建体现了一个公司、一个团队的综合素质，综合能力，是一个团队成熟度的体现。没有日构建，微软公司怎样管理庞大的系统和代码，怎样保证开发质量，或许也走不到今天了。<o:p></o:p>

技术上实现日构建没有什么问题，特别是B/S结构中各个层面都可以做单元测试；在C/S结构中，除GUI层面的自动化测试比较困难外，其他层面也没有问题。因此，如何实现日构建从本质上说是一个管理问题，需要管理层采取严厉的措施，保证日构建的推行。例如微软采用一些小的惩罚措施例如帖个猪头等，对违反日构建的人员进行惩戒。<o:p></o:p>

日构建的内容包括：代码符合规范性检查（Check Style、pmd）；Unit Test；Acceptance Test等，这些内容应全部采用自动化测试方式进行。测试结果应通过email方式通知相关人员；其统计结果可以作为管理依据（再次强调没有测量就无法管理）。<o:p></o:p>

日构建程序的建立是一个团队战斗力由若到强的必经之路，是一个团队无往不胜的必杀绝技。（或许这才是微软的秘密。）<o:p></o:p>

4） 代码详查<o:p></o:p>

按照统计分析结果，单元测试、集成测试只能发现60%左右的bug，而代码详查可以发现70%~80%的bug，并且效率更高。另外，代码详查可以发现不好的编程习惯、不良的代码风格、不合理的设计或实现等诸多问题，这里面有些深层次的问题是无法用自动化工具检查出来的。代码详查也是微软这样一流公司的必备措施。<o:p></o:p>

代码详查的另外一个好处是促进交流，代码Review的过程也是一个交流的过程；通过此过程，有经验的程序员能够言传身教地将项目实战经验传授给新手，能够快速提高真个团队的技术水平。<o:p></o:p>

<o:p> </o:p>

   参考书目：<o:p></o:p>

1）  微软的秘密<o:p></o:p>

2）  敏捷迭代开发过程 Craig Larman<o:p></o:p>

3）  代码大全（CC2）<o:p></o:p>

4）  UML和面向对象模式 Craig Larman<o:p></o:p>

5）  敏捷开发过程 Kent Beck<o:p></o:p>

<o:p> </o:p>

工具：<o:p></o:p>

1）  CheckStyle<o:p></o:p>

2）  PMD<o:p></o:p>

3）  CruiseControl/AntHill<o:p></o:p>

4）  CVS/SVN<o:p></o:p>

5）  JIRA<o:p></o:p>

6）  WIKI<o:p></o:p>