腾讯敏捷框架TAPD》研究

标签: 腾讯 敏捷 框架 | 发表时间:2015-11-19 12:47 | 作者:hulefei29
分享到:
出处:http://www.iteye.com

这篇文档是研究心得,有些部分是自己的发挥,请搭配《腾讯敏捷框架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         用户研究

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

 
 


已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [腾讯 敏捷 框架] 推荐:

腾讯敏捷框架TAPD》研究

- - 移动开发 - ITeye博客
这篇文档是研究心得,有些部分是自己的发挥,请搭配《腾讯敏捷框架TAPD. 》原文进行阅读,注意甄别原文和感想. 1         框架结构. 1.1         产品. TAPD采用FDD模式开发,FDD即特征驱动开发. FDD的核心是面向产品的功能点,但这个功能点是从客户角度出发的,并不是从系统角度出来的.

企鹅快跑——腾讯敏捷历程揭秘

- 三十不归 - 《程序员》杂志官网
腾讯这只企鹅在13年的成长历程中,不断长大,但却并不笨拙,这其中的秘密就在于研修了敏捷方法. 本文就将为您揭开其中不为人知的敏捷故事. 企鹅出生在极速变化的互联网行业,出生之时便面临着四大挑战. 海量用户的需求:企鹅服务于数以亿计的互联网用户,在保证业务稳定的前提下,更要满足海量用户不断变化的需求,因此企鹅必须要竭尽全力快速实现一个个新需求,如果采用传统的开发方法,用户是无法接受的.

腾讯敏捷开发及快速迭代

- - 标点符
从2006年开始,腾讯的研发规模开始膨胀,开发模式急需规范和标准化,到底走IPD(集成产品开发)还是Agile(敏捷)的开发路线,公司管理层也在为拿不定主意而犯愁,之后研发管理部开始与ThoughtWorks公司接触,逐渐将敏捷产品开发引入进来,并正式命名为TAPD(Tencent Agile Product Development).

腾讯敏捷项目管理平台TAPD初探

- - 标点符
腾讯开发了自己的敏捷项目管理工具 TAPD,整个工具类似于ThoughtWorks的Mingle;同时借鉴了jetbrains的youtrack. 由于不是腾讯的内部人员,所以整体都是通过网上的信息拼凑起来的. 对TAPD平台的Story、Bug、Task的作用进行明确划分. 在此前对TAPD的使用中,对三个工具的使用有些混乱,经常出现将需求提在Bug列表中的情况.

Web App 框架选择之百度&腾讯

- - 标点符
GMU(Global Mobile UI)是百度前端通用组开发的移动端组件库,GMU是基于zepto的mobile UI组件库,提供webapp、pad端简单易用的UI组件. 具有代码体积小、简单、易用等特点,组件内部处理了很多移动端的bug,覆盖机型广,能大大减少开发交互型组件的工作量,非常适合移动端网站项目.

腾讯移动前端框架 mt 2.0 发布

- - 开源中国社区最新新闻
MT是手机腾讯网前端团队开发维护的一个专注于移动端的js模块管理框架. mt介绍文档: http://mt.tencent.com/mt1index.html. 1.  本地存储异常,统计回调. 通过设施g_config的storeInc对象的statFunc,storeExFunc两个函数,可以设置统计和本地存储异常回调 , statFunc在请求每个js的时候触发,便于统计每个js的请求情况,storeExFunc在写本地存储异常回调, 将脚本内容写入本地存储出现异常的时候调用,用来提供给业务清理本地存储.

敏捷

- - 人月神话的BLOG
对于敏捷开发,我前面其实已经有很多文章提到了,再次强调下敏捷的核心思想个人理解为三个重要的方面. 其一是需求的条目化并以需求点进行的全程追踪和跟踪;其二是短周期迭代;其三是基于持续集成思想的进度和质量可视化. 对于敏捷开发本身,对于很多内容我仍然坚持自己的观点,具体如下:. 对于大型全新系统的开发,如果是以底层数据为核心的业务系统,则不能单纯的应用敏捷开发.