Agile PPP 第1章到第5章 读书笔记

第1章 敏捷实践

1.1 敏捷联盟

Agile PPP 第1章到第5章 读书笔记_第1张图片

  1. 个体和交互胜过过程和工具
  2. 可以工作的软件胜过面面俱到的文档

直到迫切需要并且意义重大时,才来编制文档。

  1. 客户合作胜过合同谈判
  2. 响应变化胜过遵循计划

原则

  1. 我们最优先要做的时通过尽早的、持续的交付有价值的软件来使客户满意。

初期交付的系统中所包含的功能越少,最终交付的系统的质量就越高。

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

1.3 结论

第2章 极限编程概述

2.1 极限编程实践

  • 客户作为团队成员
  • 用户素材
  • 短交付周期
  • 验收测试
  • 结对编程
  • 测试驱动的开发方法
  • 集体所有权
  • 持续集成
  • 可持续的开发速度
  • 开放的工作空间
  • 计划游戏
  • 简单的设计
  • 重构
  • 隐喻

结论

第3章 计划

初始探索

在项目开始时,开发人员和客户会尽量确定出所有真正重要的用户素材。随着项目的进展,客户会不断编写新的用户素材。素材的编写会一直持续到项目完成。

开发人员共同对这些素材进行估算。

  • 探究、分解和速度

发布计划

迭代计划

开发人员和客户决定迭代规模,一般需两周。

即使没有完成所有的用户素材,迭代也要在先前指定的日期结束。

任务计划

在新的迭代开始时,开发人员和客户共同制定计划。

  • 迭代的中点

在迭代进行到一半的时候,团队会召开一次会议。

迭代

在每次迭代结束时,给客户演示当前可运行的程序。

第4章 测试

编写单元测试是一种验证行为,一种设计行为,更是一种编写文档的行为。

测试驱动的开发方法

如果能够在设计程序前先设计测试方案

  • 程序中的每一项功能都有测试来验证它的操作的正确性。
  • 必须从程序调用者的有利视角去观察我们将要编写的程序
  • 迫使自己先把程序设计为可测试的。
  • 测试可以作为一种无价的文档

验收测试

第5章 重构

你可能感兴趣的:(敏捷软件开发)