Scrum和XP团队没有时间进行理论研究。不花时间用建模工具来画UML图、编写完美的需求文档，也不为了应对在可预计的未来中所有可能发生的变化而去写代码。

Scrum和XP都关注如何把事情做好。

Ken Schwaber说，Scrum不是方法学，而是一个框架。

Scrum团队尺寸（3-12人）、sprint长度（2-6个星期）；定义“完成”的不同方式；不同形式的产品backlog和sprint backlog（Excel、Jira、索引卡）；多种测试策略、演示方式、多个Scrum团队的信息同步方式……。 

XP实践：每日构建，结对编程，测试驱动开发，等等。 

产品backlog是Scrum的核心,是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序，包含客户想要的东西，用客户的术语描述。通常存放在共享的Excel文档里面，使多个用户可以同时编辑它。其它所有的制品都放在版本控制仓库。

故事（story），也称backlog项，包括字段：

ID——统一标识符;

Name（名称）——简短的、描述性的故事名;

Importance（重要性）——产品负责人评出一个数值（仅指故事的重要性）;

Initial estimate（初始估算）——团队的初步估算，最小的单位故事点（story point）,相当于一个“理想的人天（man-day）”;

How to demo（如何做演示）——描述了这个故事应该如何在sprint中演示，一个简单的测试规范；

Notes（注解）——相关信息、解释说明和对其它资料的引用等；

准备Sprint计划

1）必须存在产品backlog；

2）一个产品只能有一个产品backlog和一个产品负责人；

3）所有重要的backlog条目都已经根据重要性被评过分；

4）产品负责人应当理解每个故事的含义； 

Sprint计划评估方式

1）可使用Jira（bug跟踪系统）存放产品backlog；

2）可使用Excel简单方便，直截了当；

3）可使用VersionOne、ScrumWorks、XPlanner敏捷过程工具

制定Sprint计划（Scrum中最重要的活动），应产生的成果：

1）Sprint目标；

2）Scrum Team成员名单；

3）Sprint backlog（Sprint中包括的Story列表）；

4）Sprint演示日期；

5）Daily Scrum Meeting的时间和地点；

每个Story都含有三个变量：Scope（范围）、Estimate（估算）、Importance（重要性），其中：

Scrum Owner：负责Scope和Importance；

Scrum Team：负责Estimate；

第四个变量Quantity（质量），包括外部质量和内部质量：

外部质量：用户可以感知的；

内部质量：用户看不到的要素，可维护性等问题； 

打断没有成果的Sprint计划会议；

Sprint长度：就是Sprint演示日期（Sprint 计划会议的产出），时间越短越好，公司就越来越“Agile”，时间最长为三周。

短的Sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错误方向上花的时间更少=学习和改进的速度更快。 

故事是可以交付的东西，是产品负责人所关心的。

任务是不可交付的东西，产品负责人对它也不关心。 

处理“我不知道今天干什么”的情况:

1）羞辱式做法： “如果你不知道怎么帮助团队，我建议你还是回家去，或者看书，或者怎么都行。要不也可以找个地方坐下，等别人需要帮忙的时候你就过去。”

2）守旧式做法：简单给他们分配个任务了事。

3）施加同事压力的做法： 对他们说，“Joe，还有Lisa，你们两个可以放松点，我们会站在这里慢慢等，直到你们找到帮助我们完成目标的事情为止。”

4）奴役式做法：对他们说，“你们今天可以给大伙儿干干杂活。倒咖啡、做×××、清理垃圾、做午饭，一切一切大家今天让你们做的事情。”你会惊讶的发现Joe和Lisa在霎那之间就找出了有用的技术任务

演示也叫回顾； 

坚持所有的sprint演示的理由：

1）团队的成果得到认可；

2）其他人了解你的团队在做些什么；

3）演示可以吸引相关干系人的注意，并得到重要反馈；

4）促进不同的团队相互交流，讨论各自的工作；

5）做演示会迫使团队真正完成一些工作，并发布。

 

Sprint演示时的注意项：

1）清晰阐述sprint目标；

2）集中精力演示实际工作的代码，少讲废话；

3）演示时节奏要快；

4）只说业务功能，不说技术细节；

5）可让观众自己体验一下产品；

6）尽可能少演示细碎的bug修复和微不足道的feature。

如果没有演示，你就会发现团队在不断重犯同样的错误。

如何组织演示：

1）根据要讨论的内容范围，设定时间为1至3个小时；

2）owner，master，team；

3）在不受干扰的地方框图讨论；

4）指定某人做秘书；

5）master展示sprint backlog，团队帮助对sprint做总结；

6）轮流发言；

7）对比预估生产率和实际生产率，并分析差异原因；

8）master总结并给出下一sprint的改进。

可将sprint backlog分为三类，并进行讨论：

1）Good；

2）Could have done better；

3）Improvement；

其中，1）和2）是回顾，3）是展望未来。

团队通过头脑风暴决定下一个sprint将进行哪些改进，根据最终结果选出合适的数量，不然得不偿失，不一定要完成所有的改进；

在团队间传播经验

1）指定一个人会参加所有的sprint回顾会议，充当知识桥梁；

2）让每个Scrum团队都发布sprint回顾报告。

 

学习中...

《硝烟中的Scrum和XP》下载地址：http://down.51cto.com/data/205762