《敏捷开发》-札记

第一章 敏捷实践

一、敏捷开发宣言——价值观

1、个体和交互胜过过程和工具

p3下面：合作、沟通以及交互能力要比单纯的编程能力。。。。

　　　　我们的建议是从。。。。。

P4上面：记住，。。。。

 

2、可以工作的软件。。。

p4中间：对于团队来说，编写。。。。

　　　　在给新的团队成员面授。。。。

　　　　许多团队因为注重文档。。。。

3、客户合作胜过合同谈判

p4下面：成功的项目需要。。。。

p5上面：客户和我们如此紧密地。。。。

　　　　成功的关键在于和客户之间的真诚的协作。。。

 

4、响应变化胜过遵循计划

p5中间：响应变化的能力常常决定着一个软件项目的成败。。。。

p5下面：较好的做计划的策略是。。。。

　　　　计划中这种逐渐降低的细致度。。。。

 

二、敏捷开发原则

1、我们最优先要做的是通过尽早的。。。。

p6上面：交付得越频繁，最终产品的质量就越高。

 　　　　敏捷实践会尽早地、经常地进行交付。。。。。

 

2、即使到了开发的后期，也欢迎改变需求。。。。

p6下面：改变需求是好的事情，因为那些改变意味着团队。。。。

　　　　我们会学习一些面向对象设计的原则和模式，。。。。

 

3、经常性地交付可以工作的软件。。。。

我们不赞成交付大量文档或计划，这不是真正要交付的东西。。。。。

 

4、在整个项目开发期间。。。

软件项目不是发射出去自动导航的武器，需要持续不断地引导和纠正。

 

5、围绕被激励起来的个人来构建项目。。。

p6下面：在敏捷项目中，人被认为是，，，，，

6、在团队内部，最具有。。。。。

p7上面：文档虽然重要，但不是默认的沟通方式，沟通方式是交谈。

 

7、工作的软件是首要。。。

敏捷项目不是根据所在阶段、文档数量、基础架构代码数量来度量开发进度的。而是按可工作的模块代码数量。

当30%的必须功能可以工作时，进度完成30%。

 

8、敏捷过程提倡可持续的开发速度。。。。

p7中间：跑的过快会导致团队精力耗尽、出现短期行为。

　　　　他们工作在一个可以使在。。。。。

9、不断地关注优秀的。。。。。

高的产品质量是获取高的开发速度的关键。。。。

10、简单--

敏捷开发团队不会试图去构建那些华而不实的系统。。。。。

11、最好的架构、需求和设计出自。。。。

p7下面：敏捷团队是自组织的团队。。。。。。

　　　　不存在单一的成员对系统架构、需求、。。。。。。。

 

12、每隔一定时间，团队会在。。。。。

 

 

 

第二章 极限编程

1、极限编程——敏捷开发的方法

极限编程（XP）是敏捷方法中。。。。。。

1.1客户作为团队成员

XP团队中的客户是指定义产品。。。。。

1.2用户素材

p10上面：为了进行项目计划，必须要知道项目需求。但做计划时只需要可以估算即可。

你要知道存在很多细节，以及细节的大致分类就行，不必知道特定的细节。

 

p10中间：我们希望客户在索引卡片上写下一些我们许可的词语。。。

用户素材就是正在进行的关于需求谈话的助记符。。。。

 

1.3短交付周期

xp项目每两周交付一次可以工作的软件。在每次迭代结束时，会给涉众演示。。。。

一旦迭代开始，开发人员将用户素材分解成任务（task）,并依据最具技术和商务。。。

 

p10下：xp团队通常会创建一个。。。。。。

 

1.4验收测试

p11上：用户素材的验收测试是在就要实现。。。。

验收测试使用能够让他们自动并且反复运行的。。。。。

一旦通过一项验收测试，就将。。。。。

 

1.5结对编程

p11下：所有的产品代码都是。。。。

两人频繁互换角色。

结对的关系每天至少。。。。。

这将极大地促进知识在团队中的传播。

 

 

1.6测试驱动的开发方法

p12上：编写所有产品代码的目的都是。。。。

这会非常有利于重构。

当为了使测试用例通过而编写代码时。。。。。。

 

1.7集体所有权（迁出）

结对编程中的每一对。。。。

 

1.8持续集成（迁入）

程序员每天会多次。。。。

为了避免合并的时间过长。。。

结对人员会在一项任务上工作1-2小时。。。。

 

 

1.9可持续性的开发速度

p13上：xp的规则是不允许团队加班。。。。

 

1.10开放的工作空间

在充满积极讨论的屋子里工作，生产率非但。。。。

 

1.11计划游戏

计划游戏的本质是划分业务。。。。。

p13下：采用短周期迭代和频繁的发布。。。。

 

1.12简单的设计

p14上：xp团队的工作可能不会从基础结构开始。。。。。

三条xp设计的指导原则：

（1）考虑能够工作的。。。

我们尽量考虑用最简单的方法来。。。。

（2）你将不需要它

只有在有证据，或者至少有十分。。。。

（3）一次只有一次

极限编程者不能容忍重复的代码。

当发现那些重复的代码时，我们会通过定义。。。。。

消除重复最好的方法就是抽象。并进一步减少了代码间的耦合。

 

1.13重构

重构是在不改变代码行为的前提下，。。。

在每次细微改造之后，我们运行单元测试。。。。

重构是持续进行的，而不是在项目结束时，。。。

 

1.14隐喻

隐喻将整个系统联系在一起的全局视图；它。。。。

隐喻通常可以归结为一个名字系统。。。。。