《敏捷软件开发：原则、模式与实践》一书只读了前三章，读了三遍，结合在公司实践时获得的一点经验和遇到的一些问题，写下来与大家共享并供以后翻阅。斜体字为本人添加的注释，有不同意见的欢迎拍砖。 转载请注明出处。
正文开始...
《敏捷软件开发宣言》
* 个体和交互 胜过 过程和工具
* 可以工作的软件 胜过 面面惧到的文档
* 客户合作 胜过 合同谈判
* 响应变化 胜过 遵循变化
虽然右项也有价值，但我们认为左项具有更大的价值。
极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。
12原则：
１．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
也是为了得到客户的反馈意见，以便更符合客户要求。
２．即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
需要良好的架构来保证需求变化不会导致项目结构发生大的变动。 以前公司就应为没有好的架构设计，需求变化稍大一点就要全部从来
３．经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
应该遵循发布计划，不可一味地赶时间。
４．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
这个很有必要，但是业务人员必须先推敲出产品的大致模型，不能一天一个样。
５．围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
制度都是为人服务的，不要制定一些限制员工发挥的制度，但员工也要以团队的利益为重，不能一意孤行
６．在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
最好是手舞足蹈，哈哈．．．
７．能工作的软件是首要的进度度量标准。
能工作才能给客户演示，客户才能提意见。
８．敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
就是不要加班，耶~加班多累呀，还没加班费。
９．不断地关注优秀的技能和好的设计会增强敏捷能力。
但是也要分阶段的使用新技术，不能觉得这个好马上就用，要评估改动量。
１０．简单－－使未完成的工作最大化的艺术－－是最根本的。
但良好的架构也还是要的吧，明知是个大项目，不能就在ASP页面里连数据库吧。
１１．最好的构架、需求和设计出于自组织团队。
这个对团队的实力要求有点高哦，不知道有多少公司能有这个水平。反正我们公司是失败了的。还是要一个有经验的架构师才行啊。
１２．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
实践、分析、总结、再实践。。。
一些关键的论点
人不是即插即兼容的编程装置，对软件开发影响最大的是人，人是获得成功的最重要的因素。
合作、沟通以及交互能力要比单纯的编程能力更为重要。
过多的文档比过少的文档更糟。
编写并维护一份系统原理和结构方面的文档是个好主意。
直道迫切需要并且意义重大时，才编写文档。
成功的项目需要有序、频繁的客户反馈。
相应变化的能力，决定一个项目的成功。
为下两周做详细的计划，为下三个月做粗略的计划，再以后有一个想法就行了。
人与人之间的交互是最复杂的，并且其效果从来都难以预期，但却是工作中最为重要的方面。
过程即目标！
总结：
1．在软件开发中人是最重要的，人与人之间的交互也是最复杂的。
2．不要追求最炫的技术，最强大的工具，如果你没有很好的掌握它们，它们带来的麻烦会比帮助更多。
3．尽可能早和多地和客户沟通，来确定你所做的事是不是客户想要的。
4．良好的设计和架构会在需求变化是游刃有余，如果你因为害怕麻烦或想节约时间而不使用好的架构，那么你的程序将会变得一团糟。
5．阶段性地集成系统和整理代码是很有必要的，虽然看上去那会占用一些额外的时间，但是也会让项目的进展情况更加清晰，代码也会更加简洁。
用几个词来讲就是
沟通 简单 反馈 架构 迭代
