读书笔记--敏捷软件开发(1)

敏捷实践

敏捷开发解决的问题：由于开发过程的复杂导致项目的不可控。

敏捷软件开发宣言:

人和交互重于过程和工具
可以工作的软件重于面面俱到的文档
客户合作重于合同谈判
随时应对变化重于遵循计划

敏捷开发的12条原则

我们最优先要做的是通过尽早地，持续地交付有价值的软件来使客户满意
我们欢迎需求的变化，即使到了开发后期，敏捷过程能够驾驭变化，为客户创造竞争优势
经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好
在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起
围绕斗志高昂的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作
在团队内部，最有效率也最有效果的信息传递方式，就是面对面的交谈
可以工作的软件是进度主要的度量标准
敏捷过程提倡可持续开发。出资人，开发者和用户应该总是保持稳定的开发速度
对卓越技术和良好设计的不断追求有助于提高敏捷性
简单–尽量减少工作量的艺术是至关重要的
最好的架构，需求和实际都源自自我组织的团队。（每个成员都参与系统架构，需求，测试）
每隔一定时间，团队都要总结如何更有效率

已经有许多的敏捷过程可供选择。包括:SCRUM,Crystal,特征驱动软件开发（FDD）,自适应软件开发（ADP）以及极限编程(XP).常用的做法是把SCRUM和XP结合起来，其中使用SCRUM实践来管理多个使用XP实践的团队.

极限编程

完整团队

客户管理者和开发人员紧密地工作在一起

用户故事

必须了解需求，但是却无需了解得太多

短交付周期

迭代计划 每次迭代耗费两周，迭代开始后，客户不在修改用户故事
发布计划 3个月的工作，表示较大的交付。客户根据开发人员给出的预算，选择并排好用户故事的优先级。

验收测试

使用程序员，客户以及业务人员都容易阅读和理解的语言编写验收测试，验收测试成为真正的项目需求文档，测试成功后不允许再次失败

结对编程

代码由结对的程序员使用同一台电脑编写，一人编写，另一个观察

测试驱动开发

先编写单元测试，再编写代码

集体所有权

每个人都参与所有功能的开发

持续集成

开发人员可以同时修改同一个模块，最后签入的人负责合并

可持续的开发速度

软件不是全速的短跑，而是马拉松

开放的工作空间

在充满讨论的屋子里工作，生产率不会降低而会增加

计划游戏

业务人员确定需求的重要性，开发人员确实需求的时间

简单设计

重构

持续的进行重构，每天，每个小时

隐喻