关于敏捷软件开发

最近在看<敏捷软件开发>,对其中的原则和实践非常感兴趣.顺便记录下来....

1. 敏捷软件开发宣言
 个体和交互          胜过   过程和工具
 可以工作的软件  胜过   面面俱到的文档
 客户合作              胜过   合同谈判
 响应变化              胜过   遵循计划

2. 12个原则:
  2.1 我们最优先要做的是通过尽早的,持续的交付有价值的软件来使客户满意
  2.2 即使到了开发的后期,也欢迎改变需求.敏捷过程利用变化来为客户创造竞争优势
  2.3 经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交互的时间间隔越短越好
  2.4 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作
  2.5 围绕被激励起来的个人来构建项目.给他们提供所需要的环境和支持,并且信任他们能够完成工作
  2.6 在团队内部,最具有效果并且富有效率的传递消息的方法,就是面对面的交谈
  2.7 工作的软件是首要的进度度量标准
  2.8 敏捷过程提倡可持续的开发速度.责任人,开发者和用户应该能够保持一个长期的,恒定的开发速度
  2.9 不断地关注优秀的技能和好的设计会增强敏捷能力
  2.10 简单-使未完成的工作最大化的艺术-是根本的
  2.11 最好的架构,需求和设计出自于自组织的团队
  2.12 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整

3. 极限编程(XP)实践
  3.1 客户作为团队成员 (XP中的客户是指定义产品的特性并排列这些特性优先级的人或者团体)
  3.2 用户素材(user stories) (它是一个计划工具,客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间)
  3.3 短交付周期
    3.3.1 迭代计划  (每次迭代通常耗时2周)
    3.3.2 发布计划  (XP团队通常会创建一个计划来规划随后大约6次迭代的内容,一次发布通常需要3个月的工作)

 3.4 验收测试 (验收测试使用能够让它们自动并且反复运行的某种脚本语言编写,这些测试共同来验证系统按照客户指定的行为运转)
 3.5 结对编程
 3.6 测试驱动的开发方法
 3.7 集体所有权
 3.8 持续集成
 3.9 可持续的开发速度
 3.10 开放的工作空间
 3.11 计划游戏 (planning game:的本质是划分业务人员和开发人员之间的职责)
 3.12 简单的设计
   3.12.1 考虑能够工作的最简单的事情
   3.12.2 你将不需要它
   3.12.3 一次,并且只有一次
  3.13 重构
  3.14 隐喻