【读书笔记】AgilePPP——XP实践

完整团队

•客户、管理者、开发紧密工作在一起。

•客户

–指定义产品特性并排列特性优先级的人或团体。

–同一公司的业务分析师、质量保证专家、市场专家；用户团体的代表；支付开发费用的人。

–都是能和团队一起工作的成员。

•客户或能代替客户的人最好和开发在同一个房间工作。

用户故事

•了解需求只要做到能估算的程度就够了。

•必须知道存在很多细节及细节分类，但不必知道特定细节。

•看到新系统的问世是关注需求的最好时刻。

•和客户反复讨论获取需求细节，但不记录细节，只记录一些有共识的言语在卡片上用来提醒这次交谈，并作相应的需求评估。估算是基于在和客户交谈时得到的对细节的理解进行的。

•客户根据故事优先级及估算代价来安排时间。

短交付周期

•迭代计划

–每次迭代2周。

–迭代是一次小交付，可能会被加入到产品中，也可能不会

–迭代由一组用户估算组成，这些故事是客户根据开发人员确定的预算选出来的

–迭代开始，客户就同意不再改变故事的定义和优先级

–开发人员将故事分解成任务并按优先级开发

•发布计划

–3个月（6个迭代）的工作量一次大的交付，加入产品中

–发布计划是可变的。客户可以随时改变发布内容，但尽量不要更改一次迭代

验收测试

•记录用户故事的细节，描述每个特性的细节

•在用户故事实现之前或同时编写

•可自动、反复运行

•成为真正的需求文档

•故事的所有验收测试通过，故事才算开发完成。

•一旦一个测试通过，就不允许其再次失败

•系统不能工作的状态不允许超过几小时

•单元测试验证了系统中小的组成单元的正确性，是白盒测试

•验收测试是用来验证系统满足客户需求的黑盒测试

•验收测试由不了解系统内部机制的人编写。如客户、业务分析师、测试、质量保证。

•验收测试能自动执行，通常使用一种特定的规格描述语言编写，这种语言比较适合非技术人员阅读和使用。

•验收测试是真正的需求文档

•验收测试使系统在架构层面解耦

•促使作出优良的架构决策

•在未作任何设计和未写任何代码时，写验收测试

•基于意图编程，即按想象的样子去编写

•FitNesse

•单元测试和验收测试是可执行的需求文档

结对编程

•代码由结对的人在同一工作站完成

•一个写代码、一个观察并发现错误和改进的地方

•频繁互换角色

•结对的搭档要经常轮换

•极大促进知识在团队的传播

TDD

•TDD三定律

–在写产品代码前，先写单元测试

–一旦在写的单元测试不通过或编译失败，就停止写

–一旦单元测试通过，就停止写产品代码

•先写一个失败的单元测试，再写代码使其通过

•编写测试代码和业务代码之间的更迭在几分钟

•测试代码循序渐进的对代码编写进行指导

•有利于重构

•为提高可测性，有利于解除各模块的耦合

•保证行为正确，放心修改代码

•从调用者角度去观察将开发的代码，开发的接口更易于调用（使用）

•提高可测性

•测试是API使用手册

Collective ownership

•任何人可以签出任意模块进行修改

•不对某一特定模块负责，需要参与各个不同方面的工作

•不会被限制在自己的专业领域

持续集成

•每天进行多次构建

•所有测试都通过才算完成签入

•需要合并代码和解决冲突

可持续的开发速度

•软件项目是马拉松长跑

•有意识到保持稳定、适中的速度

•不允许加班（发布前例外）

开放的工作空间

•开放的房间

•两把椅子

•状态图、任务明细表、UML

•嗡嗡声

•了解对方工作状态

•激励讨论

•在充满积极讨论的屋子里工作，工作效率不会降低反而会成倍提高

计划游戏

•确定项目持续时间、花费成本

•客户发现特性->分解成用户故事

•开发用“点数”估算

•开发估算初始速度->几个迭代后获得平均速度

•速度

–已经实现的故事的估算之后

–跟踪速度是最为重要的管理手段之一

•当开发速度变得准确时，可调整发布计划

迭代计划

•迭代周期1-2周

•用户故事的实现顺序由开发决定

•迭代开始后，客户不能改变迭代期内的故事

•即使没有实现所有的故事，迭代也要在指定的日期结束

•计算本次迭代的速度，用于下一次迭代

任务计划

•开发将故事分解成任务，一个任务在4-16小时能完成

•迭代到一半时，应有半数故事已完成

•迭代要完成的是故事，不是任务

跟踪

•速度图

•余量图

•这2图是所有敏捷方法的真正实质所在

简单设计

•尽可能简单、有表达力

•仅关注本次迭代中的用户故事

•不断变迁系统设计，使之达到最优

•XP团队的系统可能不从基础设施开始，先以最简单的方式实现第一个用户故事，但迫切需要时才引入数据库、中间件等基础设施

XP设计指导原则

•考虑能够工作的最简单的事情

–能使用文件，不使用DB

–能使用socket，不使用ORB、WS

–能不用多线程就不用

•你不需要它

–只有在有证据，或者有十分明显的迹象表明现在引入这些基础设施比继续等待更加合算时，才引入

•消除重复

–不能容忍重复代码

–使用函数、基类、抽象、模板方法

重构

•是一些小改造，改进系统结构

•改造后跑单元测试

•持续进行，每隔一个小时或半个小时就要去做的

•软件模块的三项职责

–能完成所需的功能

–能应对变化

–能使阅读者易理解

隐喻（metaphor：比喻）

•隐喻是系统的全局视图，是系统的愿景

•归结为一个名字系统，提供系统组成元素的词汇表

•给某个模块命名、打比方

TDD、设计、编程

•TDD与设计

–TDD——自上而下的测试优先设计

–关注具有实际行为的对象（上），而不是仅仅存储数据的对象（下）

–

•与TDD相关的两种编程方式

–基于意图的编程

–基于巧合的编程