“过程和方法对于项目的结果只有次要的影响,首要的影响是人”。
“如果想要取得项目的成功,就必须构建起具有合作精神的,自组织的团队”。
个人认为敏捷方法的目的是:最大释放团队及团队中每个人的潜力。团队中的每个人都向着同一目标前进,相互协作,共同进步,使整个团队整体工作效率达到1+1>2的效果。
第一章 敏捷实践
- 敏捷出现的背景:许多公司的软件团队陷入了不断增长的过程(流程)的泥潭。
- 敏捷要解决的问题:让软件开发团队具有快速工作,响应变化能力。
- 敏捷价值观(敏捷宣言)
- 个体和交互 胜过 过程和工具。
- 可以工作的软件 胜过 面面俱到的文档。
- 客户合作 胜过 合同谈判。
- 响应变化 胜过 遵循计划。
- 敏捷原则
- 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
- 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
- 要不断交付可用的软件,周期从几周到几个月不等,且越短越好
- 项目过程中,业务人员与开发人员必须在一起工作。
- 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
- 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
- 可用的软件是衡量进度的主要指标。
- 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
- 对技术的精益求精以及对设计的不断完善将提升敏捷性。
- 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
- 最佳的架构、需求和设计出自于自组织的团队。
- 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。
第二章 极限编程概述
极限编程(XP)是敏捷方法中最著名的一个。由一系列简单却相互依赖的方法组成,这些方法结合在一起形成了一个胜于部分结合的整体。
- 客户作为团队成员。
- 用户素材(user stories)note:可以理解为用户功能需求。
- 短交付周期。
- 迭代计划。 note:每次迭代通常耗时两周,这是一次小的交付。
- 发布计划。 note:通常为6次迭代计划的内容,一次发布计划通常为三个月的工作,这是一个较大的交付。
- 验收测试。
- 结对编程。
- 测试驱动的开发方法。
- 集体所有权。 note:每个人都需要参与项目的所有部分
- 继续集成。
- 可持续的开发速度。
- 开放的工作空间。
- 计划游戏。note:可以理解为做计划。
- 简单的设计。
- 考虑能工作的最简单的实现方式。
- 你将不需要它。note:可以理解为提前做好准备。
- 一次,并且一次。note:可以理解为需要把代码重构,抽取出公共部分,提炼抽象,减少重复代码,减少代码间的耦合。
- 重构。note:重构是需要持续的,最好每隔半个小时去做一次重构。
- 隐喻。note:可以理解为充分理解系统的角色,并能准确形象的表述,帮助我们更好更准确地实现系统功能。
第三章 计划
在项目开始时,开发人员和客户会尽量确定出所有真正重要的用户素材(对用户有价值的需求)。开发人员共同对这些素材进行估算。
- 探究,分解和速度。
- 发布计划。
- 迭代计划。
- 任务计划。
- 迭代。note:客户可以经常看到项目的进展。
第四章 测试
编写单元测试是一种验证行为,更是一种设计行为。同样,它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环,尤其是功能验证方面的反馈循环。
- 测试驱动的开发方法
- 单元测试可以给以后的开发提供支援,以后向程序中增加功能,或者更改程序结构,就不用担心在这个过程中会破坏重要的东西。测试可以告诉我们程序仍然具有正确都饿行为。这样,我们就可以更自由地对程序进行改进。
- 从调用者的视角去观察我们将要编写的程序,能帮助我们设计出便于调用的软件。
- 迫使我们解除软件中的耦合。
- 验收测试
- 作为验证工具来说,单元测试是必须要的,但是不够充分。单元测试用来验证系统的小的组成单元应该按照所期望的方式工作,但是它们没有验证系统作为一个整体时工作的正确性。单元测试是用来验证系统中的个别机制的白盒测试。验收测试是用来验证系统满足客户需求的黑盒测试。
- 验收测试可以促使在打的方面做出优良的系统架构决策。
第五章 重构
- 重构是需要持续的,最好每隔半个小时去做一次重构。
- 别让随着时间积累的“干硬的”比特影响程序的扩展和可修改。