不加班真好，最近终于有时间看看自己想看的书了，为了不让自己有机会偷懒，每次读完一篇文章或一本书的一个章节，又或是偶尔有所想法，都在园里写个日志以记录之。

随着软件业的不断发展，软件开发的规模变得越来越大，这对于广大开发者来说，既是一个好消息，同时也是一个坏消息，好消息是：程序员的前景还是一片光明啊！坏消息是：加班吧，哥们。

随着软件规模的增大，随之而来的是软件开发复杂度的增加，需求难以控制（总是变），开发人员数量的增加也带来来管理难度的增加，与代码同步的文档还需要时刻更新（文档，三座大山之一，其他两座大山：强制性个人工作总结、强制性个人工作计划）。使用传统的开发过程（如瀑布模型）往往无法有效地应对需求上的急剧变化。综上所述，敏捷应运而生，其实质上可以概括为：把复杂的事情简单做。

2001年，一批业界专家成立敏捷联盟，发表了如下敏捷宣言：

• 个体和交互 胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作 胜过  合同谈判
• 响应变化 胜过 遵循计划

在软件开放中，人、团队永远是最重要的，项目需要的不是一堆不断重复劳动的机器，而是一群有着创作力的人。过程和工具应该以是否适合团队开发做为评价标准，太过复杂的过程和工具和太过简单、落后的过程和工具一样没有意义。项目的成败在于人，首先构建团队，然后改变环境以使之适应团队。

如果项目规模很大，面面俱到的文档维护起来会花费很多时间，一旦文档不与代码同步，文档便起到了负面作用，得不偿失。敏捷开发建议：必要的文档包含系统原理和项目结构（当然，这也随着不同的项目而不同），且文档要尽可能保持简洁和扼要。一个是否创建文档的标准就是：“直到迫切需要，并且有重大意义时才编制文档”。那么，文档如此简单，如何培训一个新人来参与到项目中呢，文档倒是少了，可是培训怎么办？敏捷开发提出两种解决方法：

• 代码
• 团队

代码是没有二义性的，阅读源码是了解项目的{zh0}方法，不过毕竟源码不是传递信息的最快方式，那么，就让团队来起作用，敏捷开发强调个体和交互，面对面的交流永远是xxx地沟通方式，同时加之阅读代码，可以使口头交流产生误解的可能性降低。另外还可以加之一些必要的文档，如用例、概念模型（我觉得用例和最基本的概念模型不能省略，这些文档不算是繁文缛节，而是帮助开发人员发现需求、做好分析、完成设计的好助手，当然其详细程度可以控制，其{zd0}目标是帮助团队发现需求和分析设计，其次的目标才是保存需求和设计的备份）

尽快的、频繁的交付可执行的软件（部分功能），并取代客户的反馈，这样做的好处是：

• 较早的发现问题，并能够快速的应对之
• 帮助客户发掘真正有价值的需求

每次交付时，客户总会说：“不错，但是。。。。”；在很多次“不错，但是。。。。”，后，软件越来越接近用户的需求，最终十分轻松地整体交付。期间，每次交付一个可执行软件前都包括：记录需求、分析设计、编码测试。迭代的周期尽可能的短，优先选择风险大，具有架构意义的模块开发并交付（有道是：失败越早越好；成功越晚越好）。如果一个团队在做完整个需求分析后花费数月在设计开发上，然后把辛辛苦苦做好的软件给用户一看，用户大惊，说这个也不对，那个也不对。那么，只好加班了，做了这么多，可能都需要返工。需求的变化用户有责任，但是开发人员应该明白：用户有时自己也不知道自己到底需要什么，也许他提供的只是表象，用户也需要在一个不断犯错纠正，再犯错再纠正的过程中发现自己真正的需求。另外，这个世界上所有的东西都在不停地变化，需求不断变化也是理所当然的。我们所能做到的是频繁微调需求，而非突然大动干戈。要做到这一点，就需要不断地交付可执行软件并接受客户的反馈。

计划永远没有变化快,谁能xx地判断下一秒将要发生什么？敏捷开发欢迎变化，并以此为客户打造更富有竞争力的软件。敏捷开发推荐合理的计划如下：

• 为下两周做详细的计划
• 为下三个月做粗略的计划
• 为更长的时间做极为粗糙的计划

这样做既有章可循，又不失灵活（只有下两周有详细的计划，接下来的时间可以根据实际情况再做详细的安排）

                                                                    -------bo be continue

参考：《敏捷软件开发--原则、模式与实践》

         《UML和模式应用》

附图：

.mm文件下载地址：http://docs.google.com/leaf?id=0B3yEIOhscNaANmI2Y2IxNDYtYWFhYy00YzMxLTk4N2MtMzQ0Yjg4NDFiZjcy&hl=zh_CN