!@敏捷开发
!@#敏捷开发引入
许多人都经历过由于没有实践的指导而导致的项目噩梦。
缺乏有效的实践会导致不可预测性、重复的错误以及努力的白白浪费。
延期的进度、增加的预算和低劣的质量致使客户对我们丧失信心。
一个由平均水平程序猿组成的团队，如果具有良好的沟通能力，将要比那些虽然拥有一批高水平程序猿，但是成员之间却不能进行交流的团队更有可能获得成功。
过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。
如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言。
客户合作胜过合同谈判。
告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能交付一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。
成功的项目需要有序、频繁的客户反馈。
合同，一个功能模块通过了客户的验收测试时才支付该功能块的报酬。
成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作。
计划不能考虑得过远。较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就极为粗糙的计划。
!@#敏捷开发原则
1.尽早的、持续的交付有价值的软件使客户满意。
交付得越频繁，最终产品的质量就越高。
努力在项目刚开始的几周就交付一个具有基本功能的系统。然后，努力坚持每两周就交付一个功能渐增的系统。
2.即使到了开发的后期，也欢迎改变需求。
敏捷过程的参与者不惧怕变化。
努力保持软件结构的灵活性。面向对象设计的原则和模式有利于保持灵活性。
3.经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4.在整个项目开发期间，业务人员和开发人员要保持密切的联系。
（麻痹，我们公司全能）
5.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面交谈。
6.工作软件是首要的进度度量标准。
只有30%的必须功能可以工作时，才可以确定进度完成了30%。
7.敏捷开发提倡可持续的开发速度。
敏捷项目不是50米短跑，而是马拉松长跑。
8.优秀的技能和好的设计会增强敏捷能力。
力争写出最好的代码质量。
9.简单，不构建华而不实的系统。
10.最好的架构、需求和设计出自于团队。每个人员都可以参与讨论。
11.每隔一段时间，反省，如何更好的工作。