可能是由于主办方也缺乏主办经验吧，到会的人员不多，像我这样缴费参加的就更少了，所将的内容由于涉及面太广，翻译的水平又很一般，基本上说两句就停下来等翻译翻译，然后再说，连贯性无从谈起，翻译的很多内容也没有翻译出来，实际讲授时间大概只有半天吧（翻译占用的时间基本上占了一半以上），本来还以为有同声翻译的，最会讲到Scrum和XP以及敏捷建模就只能寥寥数语简单带过，实在是遗憾。
虽然如此，还是消除了原来认识上的一些误区。
Craig以一个笑话开始了自己的演说，接着回顾了迭代软件开发的历史，也提到一个成熟的程序员应该有10年到15年的编码经验（这点是让国人难以想象的，我们工作两三年的程序员都以老程序员自居了）。以中世纪迷信放血可以治疗百病的例子（用对放血员进行等级认证的例子对现实进行了讽刺）对比如今软件工程的发展过程，指出了自50年代开始占统治地位的Waterfall（瀑布模型）这一错误的根本来源是源于人们基于臆想，脱离现实实践作理论研究的结果。追根溯源，当年首先提出瀑布模型概念的Dr. Winston W. Royce，被认为是瀑布模型的创始人，在其第一篇关于瀑布模型的论文中提到"I am going to describe my personal views about managing large software developments."，就是这样一篇文章，其主要论点居然还是说瀑布模型是一种不好的开发模型，迭代式开发才是他认为合理的开发方式（这个我以前也不知道）。然而这样一个错误观念统治了学术界30多年。直到以1987年DOD否定了Waterfall软件工程模型为标志，近三十年的理论都提倡迭代开发。
软件开发不像生产制造过程，更像新产品研发过程。遗憾的是，就算到了今天，我们大量客户方代表、项目经理、软件公司中高层管理人员有意无意的受瀑布模型支配，在实际过程中盲目追捧CMM、ISO9000，那些复杂冗长的过程管理模式。
中间Craig介绍了迭代开发的基本过程，指出了运用迭代开发过程的常见错误：
- 迭代周期过长。一般应该是2~6周。
- 强加瀑布模型的做法。比如要求完整需求确定后再编码。把组织人员分为专么的分析、设计、编码人员（我倒是觉得适当的专业分工还是必要的，特别在目前的环境下，设计主体构架和核心构架实现的程序人员应该和普通的编码人员分离开来，这样容易管理，也能够降低开发组对全体人员的技能要求）。
- 在项目开始就指望能做出详细的计划（开始如果不做详细的计划，这个项目经理、程序员容易接受，公司的中高层管理人员是最不能接受的了，不知道老美的软件公司实际情况怎么样）。迭代开发一般只制定一个迭代周期的详细计划，计划是在一个周期前两天的需求研讨会上确定的。
把项目任务分解成若干个部分，然后分期实现并不是迭代开发
需求研讨会是每个迭代过程中的第一个步骤，一般需要两天时间，用半天跟客户讨论，找出需要实现的关键需求，剩下一天半对需求进行分析，核定工作量，确定下一个迭代周期的目标。其中关键需求应该是具有关键商业价值的需求和影响系统构架的需求。做计划时计划的时间重点考虑的是IEH（一个人一日的理想工作时间），指出一个工程师的一日IEH不过是4~5个小时（XP强调每周工作40个小时也是有基于这个统计数据的考虑吧）。
第一次迭代结束后开始第二次迭代，同样是两天的需求讨论会，需求提取是个持续的过程，第一个阶段能提取10%，选择其中20%作为第一次迭代的任务就可以了，项目最后阶段可能就没有这个讨论会了。每个迭代过程最后保留一天做系统集成，一天给客户演示Demo。
接下来重点介绍了Scrum这个敏捷过程，其中很多方法还是值得借鉴的。
Scrum过程中没有中心控制者，强调发挥个人的创造力和能动性，项目组成员自行选择任务。PM的职责不是检查和监督团队成员的日常工作
，而是主要消除团队开发的外部障碍，指导团队成员工作，对内部成员进行培训。通过Scrum meeting来保证项目组成员了解其他所有人的工作进度。Scrum meeting是每天早上进行的15分钟的会议，大家必须站立在白板前开会；项目经理确保每个人回答5个问题：
1、到今天做了什么
2、今天做什么
3、有什么障碍和困难
4、整个项目是否遗漏一些开发任务
5、你学到了什么经验可以分享和交流
同时项目经理保证每个人只回答这5个问题，如果一个成员的问题涉及到其他成员，由他们会后自己安排临时小会讨论。
有一个成员自愿担任Daily Tracker负责项目进度信息的收集，据此跟踪项目进度。Daily tracker负责问每个人各个任务还剩下多少天，因为迭代开发的每个迭代周期的任务截至日期是固定的，关键是调查剩余任务的完成时间。信息收集、成员之间交流最好不要采用E_mail和Web的方式，应该面对面的交流。
也介绍了XP，介绍XP强调了只有完全应用了XP的12个过程才是真正使用了XP，只是简单使用了其中一个方法并不代表使用了XP。
1、现场客户（On-site Customer）
2、计划博弈（Planning Game）
3、系统隐喻（System Design）
4、简化设计（Simple Design）
5、集体拥有代码（Collective Code Ownership）
6、结对编程（Pair Programming）
7、测试驱动（Test-driver）
8、小型发布（Small Release）
9、重构（Refactoring）
10、持续集成（Continous integration）
11、每周40小时工作制（40-hour Weeks）
12、代码规范（Coding Standards）
不同的项目需要不同的方法论。
最后提到了敏捷建模。
模型是对现实的简约描述。
模型的表现形式可以是图也可以使文字，关键是要直观。形式不重要，目的是在于交流。
建模的主要工具其实还是白板和笔，为了方便记录可以采用数码相机。Case 工具没有必要。
只需要对系统20%的复杂需求进行建模。
建模最好也是两个人一起做。
