敏捷软件开发强调人是最重要的.沟通才是王道.合作,自组织的团队有着更高的效率,开发出更优秀的产品.
人不像即插自适应的产品,人与人之间又磨合,需要不断的沟通.
软件开发没有一个统一的模式,因此显得特别复杂.我们不能完全照搬一套成功的理论不加分析地去应用到当前的情况中.软件开发的本质就是一种选择一种折中.
敏捷软件宣言:
1) 个体和交互 胜过 过程和工具
一个优秀的团队成员可能是一个平均水平的程序员,但是却能够很好的和他人合作.合作,沟通以及交互能力要比单纯的编程能力更为重要
团队的构建比环境的构建重要很多
2) 可以工作的软件 胜过 面面俱到的文档
过多的文档比过烧的文档更遭. 文档需要不停的同步才有意义.文档必须要短小的并且主题突出的.”短小的”是指最多一二十页.”主题突出的”是指应该仅论述系统的高层结构和概括的设计原理.
给新的团队传授知识最好的两份文档是代码和团队.代码真实的表达了它所做的事情没有二义性.
直到迫切需要并且意义重大时,才来编制文档
3) 客户合作 胜过 合同谈判
成功的项目需要有序的频繁的与客户反馈.成功的关键在于和客户之间的真诚的合作
4) 响应变化 胜过 遵循计划
需求的改变并不一定是坏事,至少它让你对系统有了更深的了解
计划不能考虑的过远.为下两周做详细的计划,为下3个月做粗略的计划….缩短计划的时间,计划以外的部分保持灵活性
原则:
Ø 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
初期交付的系统中所包含的功能越少,最终交付的系统质量就越高
交付的越频频,最终产品的质量就越高
Ø 即使到了开发的后期、也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
迎合变化,努力保持软件结果的灵活性
Ø 经常性的交付可以工作的软件，交付的周期可以从几个星期到几个月，交付的时间间隔越短越好。
关注的目标是交付满足客户需要的软件
Ø 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
人被认为是项目取得成功地最重要地因素
必须对软件项目进行持续不断地引导
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
Ø 在团体内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
Ø 工作在一个可以使整个项目开发期间保持最高质量标准地速度上
不断的关注优秀的技能和好的设计会增强敏捷能力。
Ø 保持代码的简洁健壮
Ø 简单－－使未完成的工作最大化的艺术－－是根本的。
总是更愿意采用和目标一致地最简单的方法.并不看重对于明天会出现的问题的预测,也不会在今天就对那些问题进行防卫. (不做过分设计,保持简洁)
Ø 最好的构架、需求和设计出自于自组织的团队。
整个团队共同承担责任
Ø 每隔一定时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整。
Ø 保持团队的敏捷性,随环境一起变化
其它要点:
设计应该尽可能多地照顾到维护和变更。
过程和方法对于结果只有次要影响，首要的影响是人。
人不是插入即兼容的编程装置，如果想要项目取得成功，就必须构建起具有合作精神的自组织的团队。
合作、沟通以及交互能力要比单纯的编程能力更为重要。
过多的文档比过少的文档更糟，编写以及代码的同步会花费更多的时间。直到迫切需要并且意义重大时，才来编写文档。
成功的项目需要频繁、有序的客户反馈。成功的关键在于和客户之间真诚的合作。
在“充满激烈讨论的屋子”里工作，生产率非但不会降低，反而会成倍的提高。
软件项目不是全速的短跑，而是马拉松长跑。团队必须有意识的保持稳定、适中的速度。Xp的规则不允许团队加班工作，在版本发布前一周是唯一的例外。
编写单元测试是一种验证行为，更是一种设计行为。同样，它更是一种编写文档的行为。
饭是要吃的，忽略掉清洁工作并不能真正加快用餐速度。（重构）
敏捷设计是一个过程，不是一个事件，它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的一个过程。它致力于保持系统设计在任何时间都尽可能简单、干净、富有表现力。
变化的轴线仅当变化实际发生时才具有真正的意义，如果没有任何征兆，那么去应用SRP或者任何其他的原则是不明智的。
抽象类和它们的客户的关系要比和实现它们的类的关系更密切。
开发人员应该仅对程序中呈现出频繁变化的那部分做出抽象，拒绝不成熟的抽象和抽象本身一样重要。