这篇文档是研究心得，有些部分是自己的发挥，请搭配《腾讯敏捷框架TAPD 》原文进行阅读，注意甄别原文和感想。

1         框架结构

1.1         产品

TAPD采用FDD模式开发，FDD即特征驱动开发。

FDD的核心是面向产品的功能点，但这个功能点是从客户角度出发的，并不是从系统角度出来的。功能点是用一个短句描述出一个业务需求，而这个业务需求的粒度是按开发时间来衡量的（一般不超过两个星期）。

特征与用例的相似之处是，两者都可以用短句（动宾短语）来描述；两者的不同之处在于，用例用UML的用例图来表示，而特征是用四色原型（类图）来表示。

注意，TAPD只是参考了FDD，不是完全的FDD。所有的开发团队都是由产品经理所归纳出来的产品特性去驱动整个产品的研发。

产品经理这个角色有点Scrum的Product Owner的味道。但产品特性和backlog相差甚远，因为产品特性只是一个动宾短语，而backlog却是一个完整的故事（story），包括一系列的元素：

1.        ID（统一标示）

2.        Name（名称）

3.        Imp（重要程度）

4.        Est（初始估算）

5.        How to demo（如何做演示）

6.        Notes（其它）

1.2         项目管理过程

TAPD参考了Scrum，项目管理过程同Scrum的过程比较类似，包括每天的晨会、迭代、timebox、每个迭代之后会有showcase、回顾总结等。

Scrum中的timebox是指迭代要有固定的时长，不能超过六个星期。

1.3         开发实践

参考了很多XP的实践，因为XP的完整实践比较“理想化”，所以只采纳了某些部分，比如自动化测试和持续集成。

2         框架实现

2.1         故事墙

把正在开发的系统功能与在白板上，让团队所有成员都知道大家在做什么。

写在白板上比用Excel或者其它工具管理好，因为写在白板上让人感觉更紧迫、更正式、更一目了然，有一种别人在监督、在注视的感觉——增加适当的压力并不是坏事。

2.2         每日晨会

晨会上每个人的发言不超过3分钟为宜，整个会议15分钟为宜。这是按照5人团队来制定的。如果团队人数超过5人，甚至达到10人、20人，那么建议成立两个团队。

Scrum的晨会是站立着开的，一方面是为了不让会议拖沓，另一方面也是为了让大家注意力集中（如果坐下肯定有人会顺便打开电脑，然后开始上网）。

在每天的晨会上，团队成员每人都叙述对昨天的工作做一个总结，总结由Scrum Master记录在白板上。

总结的内容包括：

1.        工作完成的情况。只需要选择以下状态即可：未开始、正在开发、已完成。

2.        工作遇到的难点（如果未按时完成）；工作中值得注意的地方（可以是系统框架的体会、业务的特殊性、封装了哪些公共功能等）。

3.        今天要做什么（如果昨天的工作已完成）。

当某人遇到问题的时候，其他成员如果有解决办法或者建议，那么可以“举手”，但不用说出解决的办法，由Scrum Master安排两人结对编程。

2.3         时间盒

一切任务都有timebox。Scrum的时间盒最长可以达到6个星期（一个半月），感觉太长了，建议时间盒按照FDD的建议，不超过两个星期为宜（半个月）。

2.4         一个完整的迭代过程

包括分析、设计、开发、测试和发布五个过程。

1.        分析过程决定了本次迭代过程的工作目标（系统要达到什么效果）、工作内容（FDD的功能点）、发布日期。

2.        设计过程采用快速原型法。快速原型法对业务复杂度不高，着重客户体验的项目有着很好的效果。

3.        系统后台（业务模型）的设计，无论是采用数据库模型还是领域模型，都由主力程序员/系统架构师负责。之所以要主力程序员全程设计，是因为他要走读（review）其他人的代码，在没有理解设计思路的情况下，是无法review的。而且成员的水平和风格参差不齐，每个人都参与设计，最后一定会乱套。

4.        做好测试计划，除了猴子测试，还要有业务模拟测试。

5.        提倡单元测试，为以后自动化测试做准备。

6.        考虑到TDD太复杂，需要面向接口编程的思想，以及转换原来的编码思想，并非短时间内能改变，所以不强制使用。

7.        使用持续集成。持续集成除了降低代码合并的成本，还保障了提交上来的代码至少在语法上是可以通过的，不会导致别人下载了新版本的代码之后编译失败。

其中分析、设计、开发、测试、发布这五个过程可以内部再迭代，而且这五个过程不是分阶段开展的，即不是分析完了之后才设计，全部设计完了才开发，开发结束了才测试，测试通过了才发布。而是边分析边设计——在业务不复杂的情况下，这是可行的——边设计边开发，开发完一个功能就测试一个功能，同时开发下一个功能。

考虑到小团队不会配备专人测试，所以可以直接让客户进行测试，即测试与发布（不是最终发布）合并，由客户决定是否测试通过（最终发布）。

2.5         灰度发布

发布并不是一口气全面铺开，所有用户同时使用，面是先挑出有代表性的用户试用。

2.6         迭代总结

每一次系统发布的时候都会有一个总结，把做得好的发扬光大，做得不好的注意改进。总结是团队所有成员都参加，并且需要记录所有发言，会后发给每个人。

2.7         用户研究

这是腾讯，或者说是网站建设的独有特点。