最近为了完成java设计模式和uml的大作业算是花了不少时间来动脑理解和动手编写代码，也开始发现代码的神奇和美妙，java竟然可以开发简单的小游戏，而且代码并不向想象中那样难以理解，其中的规律似乎很神奇。带着这种愉悦美好的心情读《构建之法》，或许会比以前收获更多。
继瀑布模型之后又前辈们提出了“敏捷”，1.敏捷这个词听起来就是反应灵敏迅速而有效，而在软件按工程里，敏捷不同于现有做法之处在于：敏捷的价值观和流程是个人和交流、可用的软件、与客户合作、响应变化，而现有做法的则是流程和工具、完备的文档、为合同谈判、执行原定计划。
2.敏捷的开发原则是尽早并持续交付有价值的软件以满足顾客需求；只有不断关注技术和设计，才能越来越敏捷；只有能自我管理的团队才能创造优秀的架构、需求和设计。
3.敏捷的流程可以分为以下四步：第一步－找出完成产品需要做的事情；第二步－决定当前的冲刺需要解决的事情，整个产品被划分成几个互相联系的冲刺，产品订单上任务被进一步细化，被分解为以小时为单位，订单上的任务是团队人员根据自己的情况来认领；第三步－冲刺，在冲刺阶段，外部人士不能直接打扰团队成员，一切交流只能通过scrum大师来完成，这一措施较好地平衡了“交流”和“集中注意力”的矛盾，冲刺期间，每日都开个例会，每日例会强迫大家向同伴报告进度，迫使大家把问题摆在明面上，同时启动每日构建，用建民的图表来展现整个项目的进度，图表可以是燃尽图，想象我们把一堆待完成的事完成了，冲刺阶段是时间驱动的，时间一到就结束，这个特点看似不起眼，其实有效地断了各种延期的想法，很棒啊；第四步－得到一个软件的增量版本，发布给用户，并在此基础上又进一步计划增量的新功能和改进。
4.但理论遇上现实或多或少都会出现问题，比如在第一步中我们应该怎样体现各个需求和任务间复杂的依赖关系呢，第二步中成员认领任务不均怎么办呢，第三步中每日例会都是流水账怎么办呢，以及燃尽图只列出任务的数目，无法展示项目的拖延情况；这时就可以有更好的改进了，应该明确定义好一个任务，还应记载完成这个任务还需要多长时间，已经花了多少时间虽然重要，但那不是管家（已经是沉没成本了），关键是我们离目标还有多远。还有燃尽图，书中作者提出了以时间来度量，比如实际剩余时间，预估剩余时间，实际花费时间等。
5.敏捷适用于产品可靠性不高，容忍经常出错，需求经常变化，团队人员数量不多，有资深的程序员带队，公司鼓励变化等情况，而不是必须有较高可靠性、不容许出错的商业情况，也不是要有极高可靠性、精益求精的科学计算、复杂系统的核心组件，这两种应该用计划驱动和形式化的开发方法。
最后，我觉得敏捷是一个有自己应用场景的好方法，能提高团队成员开发的积极性和团队凝聚力，思维也非常明确简介，简单粗暴，直奔主题，强调可用的软件、可度量的进度、每日例会、面对面的交流等直接有效的流程和方法，不仅在软件开发方法中占据一席之地，在生活中应用也能有很好的效果，短学期的开发实践很期待用这个方法。