`

腾讯敏捷框架TAPD》研究

    博客分类:
  • ios
阅读更多

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

1         框架结构

1.1         产品

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

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

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

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

产品经理这个角色有点ScrumProduct 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         时间盒

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

2.4         一个完整的迭代过程

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

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

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

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

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

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

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

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

 

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

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

2.5         灰度发布

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

2.6         迭代总结

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

2.7         用户研究

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

 
 
分享到:
评论

相关推荐

    腾讯敏捷框架TAPD(TencentAgileProductDevelopment)

    采用FDD,即产品特性开发驱动的一种模式,腾讯的产品会有一个明确的产品经理这样一个角色,他会负责整个产品,包括产品的验证、产品的方向、市场调研、用户调研等。FDD 模式是一种非常适合产品经理来对产品做一些...

    关于腾讯的敏捷开发框架

    其敏捷框架TAPD(Tencent Agile Product Development)是针对互联网行业特性的定制化实践,旨在实现高效、灵活的产品开发。以下是腾讯敏捷开发的核心要点: 1. **关注用户行为**:腾讯强调以用户为中心,通过不断...

    腾讯公司真实敏捷开发经验

    腾讯公司在敏捷开发领域有着丰富的实践经验,特别是在产品设计、项目管理和开发实践中融合了多种敏捷方法,形成了独特的腾讯敏捷框架——TAPD(Tencent Agile Product Development)。以下是对腾讯敏捷开发经验的...

    敏捷软件开发模型-Scrum

    腾讯在2006年开始尝试敏捷开发,推出了TAPD(腾讯敏捷产品开发);在QCon 2007 (London)会议上,Jeff Sutherland分享了Scrum在Google的应用;诺基亚西门子网络(NSN)和赛门铁克也在各自的领域尝试使用Scrum模型,...

    敏捷软件开发模型

    - **腾讯TAPD**: 在2006年开始引入敏捷产品开发路线,正式命名为TAPD。 - **Google**: Jeff Sutherland在QCon2007会议上介绍Scrum在Google的应用情况。 - **赛门铁克**: 在bug处理方面试用了Scrum模型。 #### 五、...

    敏捷软件开发模型--Scrum

    2. 腾讯在2006年面临产品开发路线选择时,逐渐引入了名为TAPD的敏捷产品开发流程。 3. 在QCon 2007会议上,Google的Scrum实践情况由Jeff Sutherland介绍。 4. 赛门铁克在bug处理方面尝试使用Scrum模型。 七、Scrum...

    敏捷软件开发模型—Scrum

    例如,淘宝RDC(Research & Development Center)在日常发布测试流程中融入Scrum特色,腾讯则通过TAPD(Tencent Agile Product Development System)平台实践敏捷开发。这些企业通过Scrum的实施,显著提升了项目成功...

    敏捷软件开发模型—Scrum.pdf

    最终决定采用敏捷开发方式,并正式推出了TAPD系统。 - **Google**:2007年伦敦QCon会议上,杰夫·萨瑟兰介绍了Scrum在Google的应用情况。 - **诺基亚西门子网络(NSN)**:虽然没有详细说明,但NSN也采用了Scrum进行...

Global site tag (gtag.js) - Google Analytics