敏捷开发实践
是近在家里再翻了一下敏捷开发这本书，受益匪浅哦。总结一下，也让这个种敏捷思想在后续项目推广开来。
敏捷软件开发宣言
1、个体和交互 胜过 过程和工具
合作，沟通非常重要。一个优秀的团队未必就是一个一流的程序员，一个优秀的团队成员可能是一个平均水平的程序员。合适的工具对于成功能来说是非常用重要的，可以提生产力，但是过分夸大或使用庞大而笨重的工具，反正降低生产力，而且导致项目成本偏高。
2、可以工作的软件 胜过 面面俱到的文档
没有文档和测试用例的软件是一灾难，可维护系数为0,对以后扩展功能更难。小步交发布软件模块，比成天做出漂亮的文档然而又不能工作的软件强N倍。客户只关注软件是否可以用，是否满足需求，是否易用等，不是成开瞪你的文档。软件为客户创造利润才正解。
3、客户合作 胜过 合同谈判
软件的开发应该让客户参于或者精业务的人员对与，功能不是程序员自己拍脑袋开发出来的。运气好就那可能还挂上点边，这只是投机取巧，然而项目中要避免这样，因为这样没有成功的机率。我们应该与经常与业务人员时时沟通，有条件的话，业务人员可以参与开发。这样业务功能不可能走偏。另一方面在也可节省成本。开发软件要达到双赢，客户用软件创造利润，我们呢得在软件开过程中节省成本。
4、响应变化 胜过 遵循计划
“变化才是不变的”这一直是软件行的坐右铭。我们应该要响应客户需求变化，而不是遵循那些跟不上变的软件需求文档。能够响应变化的软件也体现出软件结构设计的比较好。软件工程中的“开放-封闭原则（OCP）”就很好的说明这点：
I）对于扩展是开放的
II）对于更改是封闭的
要记住的原则
1、我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意
在软件合同上签完字这一刻起就得按计划交换可以使用的功能模块，最好是核心模块。当然一般软件公司在竞标时就已经有原型了，有的是在一个可能软件上改造出来的原型，有的是从零开始研发的，仅仅是为了应付竞标的，更本就不可用。合同一生效，其实客户比你还急，这可能影响他的政绩，影响他升迁（国有单位或政府机构），可能影响大量利润的产生。因此在短期交付一个可能的核心功能模块，让客户看到一点希望，这样对软件开商以后的沟通打下一个良好的铺塾，但是不忘记重要的一点，不要不为了赶工期就将软件结构搞乱，这个性质是很严重，不遵守后期付出的代价想当的大，在灵活性，可扩展性，健壮性方面种下隐患。
2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
需求是一直在变的，这也程序员感最恐惧的。一个程序员开发相应的功能，代码结构很优雅，结果客户说不要了，或改成那样，此时这个程序员的表情你可想想。他可能在背后骂娘。这个就是我们搞敏捷开发中必须具备的心态，能够乐观的接受变化。
3、经常性地交付可以工作的软件，交付的间隔可以从几击到几个月，交付的时间间隔越短越好
一个软件的上线应该做到小版本发布，最好两周发布一次，迭待开发功能。实质内容其实与原则一差不多。
4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
敏捷开发最要的一点就是沟通
5、围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信息他们能够完成工作
《人件》中以人为核心，在敏捷开发也充分体现这一点。将合适的工作交接合适的人，并相信他能够很好的完成功能开发。当然敏捷开发中没有指派这个概念。
6、在团队内部，最具有效果并具富有效率的传递信息的方法，就是面对面的交谈
7、工作的软件是首要的进度度量标准
进度度量非常重要，如果能够精确那是最好不过的事了。这是肯定做不到的，搞软件的都知道这是一个可能实现的想法。但是对够对一个功能的核心模块做到比较精确的进度度量那就非常不错了。这个就要靠团队成员坦诚，不能隐蛮进度，否则只是一个没有什么参考价值的数据。
8、敏捷过程提倡可持续的开发速度。责任人，开发者和用户应该能够保持一个长期的，恒定的开发速度
9、不断地关注优秀的技能和好的设计会增强敏捷能力
10、简单——使未完成的工作最大化的艺术——是根本的
11、最好的架构，需求和设计出自于自组织的团队
12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
软件设计原则
1、单一职责原则（SRP）
2、开放-封闭原则（OCP）
3、Liskov替换原则（LSP）
4、依赖倒置原则（DIP）
5、接口隔离原则（ISP）
这五大原则对软件设计有非常大的帮助，充分运用OOP思想进行软件设计。没有完美的设计，只有最合适的设计。需要提高性可能影响期局部代码结构，提高扩展性，灵活性但引影响性能等，这个需要设计师们自己去权衡了。
