昨天读完了Fowler的UML Distilled的前两章（以前—05年下半年开始—稍稍读过、做过一些关于敏捷、XP的资料、实践），回头看看此书印刷信息处注明的“Second Edition August 18, 1999”，总有种不太敢相信的感觉，当前正迅速发展（应该讲在国内）敏捷开发相关的process、pratice，在1999年的这本书中的outline process时已阐明（那运用肯定更加早了），又一次体会到发展的差距，同时也感觉到什么叫“相逢恨晚”，本文整理出其中学习到的点以做参考，也算作outline吧。
其中软件过程概括如下图：
Inception主要指确定business前景及project scope的阶段，Elaboration阶段即细化，主要完成gather more detaild requirement（as use case、user story）、high-level analysis and architecture及construction段的plan，Transition阶段指完成不适于开发阶段完成的如beta test、performace tuning（may reduces the clarity and extensibility of the system）、user traning等
关于Elaboration阶段四类风险的处理，其一、dealing with requirements risks，经由business expert的参与由use case驱动build conceptual domain model（describe any model whose primary subject is the world that the computer system is supporting, whatever stage of the development process you are in.），这其中class diagram和activity diagram非常有帮助（Fowler提倡在此使用activity diagram而非interaction diagram，主要用于发现该做什么，后者主要用于发现由谁来做什么—who do what）；其二、dealing with technological risks，其中要注意的一点是将实现需要用到的技术together然后评价risk，而不可仅仅单独的评价每一项技术就作为risk assess，虽然此阶段出来的architeture是brief sketches not comprehensive，但还是要定出架构性的决策（如c\s还是b\s等），同时关注一些在常理中不可能变化的area，让系统的design change elements raletively easily。此阶段将常用到class diagram、package diagram和deployment diagram；其三、dealing with skills risks，找知识、经验丰富而又不呆板的人做培训，当然培训是要有目的、有针对性的（也就是只做必要的培训），否则不能将所学习到的用于实际项目中，时间长了也就忘了，当然Fowler的另一建议就是在企业中找一个你所佩服和尊敬的指导者（以前kflee也有这样的建议），Fowler作为指导者的本质讲的好“my goal as a mentor is to render myself unnecessary”，当然，实在满足不了需求也可以读书、交流，这都是学习的方法；其四、关于dealing with political risks就算了。此阶段的finish标志：
1. The developers can feel comfortable providing estimates, to the nearest person-week of effort, of how long it will take to build each use case. 2. All the significant risks have been identified, and the major ones are understood to the extent that you know how you intend to deal with them
为construction阶段做plan，其实其描述的操作大概遵循XP的制定release plan的plan game（计划游戏）操作，让客户对use case派出优先级（XP建议不使用high-medium-low，而采用1…n），developers 对use case assess risk level（XP中会有developers和tester validate user story），并且estimate 每一个use case的development需要的时间长度，定下了iteration的length后，可以计算出在一个iteration中team所能做的development（XP中以ideal day做单位）
(No. of Developers/Load Factor ✕ Length of Iteration in Business Day) (Truncated) =Iteration Team Velocity
用Iteration Team Velocity ✕ iteration‘s length即可，接下来将use case assign to iterations，当然，要分配可以完成的工作安排，不可过量，同时comlex、high-risk use case要适时拆分、调整（don’t put risk until the end）。从construction阶段为transition阶段预留tuning、packaging时间等等安排，这样就形成了一个release plan，指示各个iteration所需完成的use case。
Construction阶段，each iteration is a mini-project. You do analysis, design, coding, testing, and integration for the use cases assigned to each iteration，其中属xp的实践如unit test、refactor及continuous integration，测试先行，编写自我测试的代码，并于下一个iteration中运行之前iteration的测试、refactor之前iteration的代码（于修改bug时也是），integration当然不仅仅于每个iteration结束之际执行，如此方能称CI。这一阶段将能使用所有uml tech，用CRC卡片和interaction diagram暴露类职责、操作，讨论、评审设计，直到you are comfortable，就可以coding了。一旦你做了东西，你可以用uml表明你都做了些什么，detailed documents should generated from the code（such as JavaDoc），你需要写额外的文档阐明重要的概念和特性，相当于进入系统detailed document前的概述，可以用package diagram表现系统的逻辑结构及各部分的依赖关系，用deployment daigram表现high-level physical picture，如果类有复杂的生命周期行为（complex lifecyrcle behavior）你可以画state diagram to discribe it，这种情况较少，较多的是有复杂类之间的交互，通常用interaction diagram表示。如果用activity diagram可以更好的描述清一个复杂的算法，那就画出来。当然这期间iteration的各个阶段会用到许多patterns，此处pattern不单指design所使用的23种patterns，其他部分如domain analysis、data design都有其各自的patterns，ref pattern home
虽说参加的项目实践还不是太多，但现在读一些关于过程、方法学的方面的书籍和以前的感觉已是学多不同了，现在至少有一点就是，在读这些的时候可以将之与经历过的实际项目过程做对比来分析、学习
