随读笔记
1 客户作为团队成员
客户：指定义产品的特性并排列这些特性优先级的人或者团体
如何寻找能和团队在一起工作的客户？寻找能够在一起工作愿意并能够代替真正客户的人。可以从公司里找一个业务熟悉或者需求分析人员作为客户方代表，愿意跟团队一起开发。
2 用户素材
了解需求只需要做到能够估算它的程度就够了。用户素材就是正在进行的关于需求谈话的助记符。它是一个计划工具客户可以使用它并能够根据它的优先级和估算代价来安排实现该需求的时间
3 短交付周期
敏捷项目每两周交付一个可以工作的软件，每两周的迭代可以称为重复周期或者循环周期
3.1 迭代计划
迭代计划的内容是有用户素材组成的，迭代耗时两周，一次迭代期间，客户就同意不再修改当次迭代中的用户素材的定义和优先级别
3.2 发布计划
一次发布通常需要3个月的工作，6次迭代
4 验收测试
用户素材的验收测试是在就要实现该用户素材之间或实现用户素材的同时进行编写，编写脚本实现验收测试。
5 结对编程
两人共同编程，一人控制键盘并输入代码，另一个人寻找代码中的错误和可以改进的地方。
结对的关系每天至少要改变一次，以便每一个程序员在一天中都可以再不同的结对中工作。结对中的两个人和团队中的所有其他人结过对，结对可以降低缺陷率。
在实际的开发中，我至今没见过结对编程的模式，可能在外国比较常见吧，我们国家为什么不能试试呢，或者两个人共同负责一个模块，共同完成一个功能。
6 测试驱动开发的方法
由错误导向成功
由单元测试代码导向系统中的代码。为使测试用例通过而编写代码，会使程序员去解除各个模块之间的耦合。
7 集体所有权
每一个人要参加与各个模块的开发
8 持续集成
前面已经提到
9 可持续的开发速度
敏捷开发的规则是不允许团队（不是当个的程序员）加班工作。在版本发布前一个星期是该规则的唯一例外。
10 开放的空间
应该为团队一个比较开发的空间，有专门的技术资料库，上网方便，办公方便，开会方便等等，尽量使用面对面的交谈和讨论问题。
11 计划游戏
每天有计划的完成用户素材。
12 简单的设计
以实现最简单的（但是必须完整）用户素材为标准，来设计软件。
1 考虑能够工作的最简单的事情，尽量考虑用最简单的方法来实现，当前用户素材
2 你将不需要它； 至少有十分明确的迹象表明现在引入这些基础结构比继续更加合算时，团队才会引入这些基础结构。
3 一次并且只要一次；敏捷编程不能容忍重复的代码，无论在哪里发现重复的代码，他们都会被消除
13 重构
重构是持续性的，每次都是一点小的改变。
开发速度的计算规则：为每次迭代中完成了31个素材点，那么他们应该计划在下一次的迭代中也完成31个迭代点，他们的开发速度是每次迭代31个点。
开发人员把素材分解成开发任务，一个任务就是一个开发人员能够在4-16小时之内实现的一些功能，开发人员在客户的帮助下对这些素材进行分析并尽可能的完全的列举出所有的任务
迭代中任务分配：确保每一个人都有任务可供完成，任务的交换，任务的取舍。
迭代中点：在迭代期间，责任人应该在迭代中点检查团队的任务完成是否达到半数素材的内容。我们应该完成一个素材而不是90%的素材点或者90%的任务。
图示何时不需要？在创建了他们而没有验证它们的代码就打算去遵循它们时，图示就是无益的。源代码就是设计，其他都是源代码的附属物。
如何刺激变化（针对开发-封闭原则）
a 首先编写测试用例，迫使系统成为一个可测试的系统。在一个具有测试性的系统中发生变化时，我们能够应对变化，做出反应。
b 使用很短的迭代周期进行开发，一个周期为几天而不是几周。
c 在加入基础结构前就开发特性，并且经常性把那些特性展示给用户。
d 首先开发最重要的特性
d 尽早地经常性的发布软件
2173
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
