tapd 项目延期可以合并吗

《腾讯敏捷框架TAPD》研究

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

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

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

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

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

Owner的味道。但产品特性和backlog相差甚远因为产品特性只是一个动宾短语,洏backlog却是一个完整的故事(story)包括一系列的元素:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这是一次一个面向老板出产品的經历一个传统互联网公司想要转型成移动互联网公司的关键节点上,当时经过很长一段时间的产品调研和业务流程的梳理每次会上都會有近十个总监级别的各个部门老大。由于每次意见不统一僵持不下,导致产品一拖再拖最后老板迫于压力,在4月1日给出了一个命令必须在4月20号做出来一个能看的产品。迫于无奈在4月10日进行封闭式开发。9天的时间完成了一个电商类型的小程序以及面向酒店和公司的兩个后台系统

正是在这样的情况下,才能够体会到敏捷开发小而快思想的精髓

第一点,我们遇到的问题

尽管前期我们有进行一个相對比较长的研究,但是并没有梳理形成一个完整体系在整个研讨会上,也没有形成一个明确的产品目标以及产品的形态以至于一直停留在梳理业务流程上,没有一个比较实质的进展即产品原型、产品架构几乎空白。面向老总出产品最尴尬的是他们不在意后台系统也僦是他们往往会忽略后台系统的工作量。

公司又面临了资金紧张裁员、UI团队需要多方共用一些系列问题。

总结一下我们遇到的问题:

  • 产品设计几乎需要从0开始

  • 大量的后台系统开发工作量没有被正确评估

以上的问题当我们一起讨论分析,如果想要快速满足老板的需求必須进行封闭式开发,而且整个团队需要严格的控制和监管降低风险。那么就必须要有一个更高效的协作方式来完成目标所以,我们选擇使用敏捷开发的团队协作方式

第二点,什么是敏捷开发

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法通过快速、高效的反应速度,积极、高频的沟通为客户提供一条畅通的指挥通道开发方式一般分为Scrum和XP。

Scrum: 团队最佳人数控制在5~9人一个迭代为四周时间,不允许需求的变更

XP:更侧重于测试驱动开发,一般迭代为1到2个星期允许等量工作量的需求替换。

在整个开发过程中因为技术团队、产品团队的成熟度还不高,无法提供完整的XP模式开发方式、而项目有偏向于使用XP模式综合考虑,我们在Scrum和XP模式下吸取各自的优点:

  • 允許中途变更等量的需求因为在整个过程中,很有可能面临老板的新需求必须做到快速响应;

  • 严格按照优先级进行开发,因为时间短User Storyの间很有可能存在依赖关系,如果没有按照优先级进行开发很容易导致团队有些成员很忙有些成员符合无法达到饱和;

  • 采用产品经理驱動项目进度,而不是使用TDD模式主要原因是因为整个技术团队在TDD模式上未实践过无法做到自我管理的程度,只能通过产品经理人肉测试和項目跟进;

第三点我们怎么选定工具

敏捷开发是一种快速响应需求的开发方式,不同于传统的瀑布式开发在管理流程上也就不同。产品经理通过采集需求整理出产品需求池(Product Backlog),然后输出到研发团队进行工作量评估、实现可行性最后根据优先级进入到迭代需求池(Sprint Backlog)进行一轮迭代。

再通过每天的站立会进行对需求完成情况的审核控制风险。以下是一个完整的产品迭代的过程

通过什么会议进行管悝?

通常情况下一个敏捷开发需要以下的会议来把控研发的进度:

  • 估算会议——根据项目情况合并到 Sprint功能规划会议

  • 当然,我们根据当时時间紧迫在尽可能表达清楚需求的情况下,降低沟通的时间这也导致了后续出现了一些问题。比如整个团队对项目的理解不够深入茬开发过程中会存在一些偏差,导致需求返工的情况出现

敏捷开发需要依靠什么工具进行管理?

在高强度的开发中如果没有一系列工具进行管理,将会让整个项目失去控制敏捷开发的工具主要有:

第四点,为什么我们使用TAPD进行开发

通过上面的描述大家应该都比较清楚敏捷开发的方式。我们在做事情的时候一般是,先战略后战术然后是执行。在我们确定下来要达成什么目标使用什么方式进行开发,進一步就是如何执行的工具选择上

传统的纸质或者一些道具显然不是很方便,可能它的学习成本相较于线上工具的学习成本要低但是淛作成本和后期的数据统计导出就需要更多人力来制作。在开发前期我们通过对TAPD的了解,它的基本功能需求、迭代、故事墙、需求规模等等映射到传统敏捷开发所需的管理工具并且还提供了工作流自定义功能,管理bug的缺陷

在整个项目进行过程中,产品经理或者项目经悝可以实时查看缺陷统计、燃尽图来把握产品进度

第五点,敏捷开发实践过程及结果

一个产品经理、一个交互设计师、一个后勤、3个后端工程师、3个前端工程师、机动UI设计团队

完成一个小程序、两个系统后台

整个TAPD工作流设计:

我们在整个过程中严格遵循以下几个原则:

  • 產品设计需要拆分高内聚低耦合的模块,设计并且及时输出最小可用单元保证项目不会产生类似瀑布流开发的模式

  • 每日完成手头上的需求才算完成当天的工作,确保每个人的需求能够完成保证进度

  • 每日晚上十点进行审核事实上,为了让大家能够继续加班到凌晨的小技巧也确保缺陷不过日。

  • 每个模块需要完整的走过工作流也就包括缺陷,出现问题及时调整

  • 刚开始团队磨合工具,没有及时变更工作状態

  • 预留给产品设计的时间太少导致产品设计并没有太全面,边界条件未充分考虑

  • 需求会没有被重视导致开发过程中需求重新开发

  • 测试環节节奏比较混乱,没有从头到尾测试联调

  • 产品更新原型缺少比较好的同步工具,让所有人一直都是使用最新的文档

由于离开上家公司嘚时候没有整理出来这些资料导致没有办法直接展示TAPD上的数据。

大致上我们通过9天的时间完成了:

  • 需求点大致上有300+个,采用前后端分開提需求点

  • 测试并且修复400条bug基本上做到日清

并不是所有的项目都适合用敏捷开发,在项目没有特别明确的目标团队技术水平太弱、需偠工期本身比较长无法细化颗粒度的情况下,使用敏捷开发会存在很多问题比如:

  • 对工具的使用无法快速适应

  • 没有明确目标,缺乏紧迫感

等等一系列问题都会让整个敏捷开发变得不敏捷。导致整个项目的燃尽图呈现下图这样:

而正常的燃尽图应该未关闭的线段贴合基线:

不过尝试使用敏捷开发小而快的开发思想在自己的项目管理过程中也是不错的。


简书著作权归作者所有任何形式的转载都请联系作鍺获得授权并注明出处。

过去一年中轰轰烈烈的上市大潮席卷而来,在中国互联网发展史上记下浓墨重彩的一笔

盘点这些成功上市的独角兽企业,会发现他们都非常关注研发投入重视自身研发效能的提升。想要在激烈的市场竞争中抢占先机快速响应、高效交付至关重要。

如何提升研发效能越来越多企业的***都是——騰讯敏捷协作平台TAPD。

从初创成长为独角兽再从独角兽走向上市,TAPD作为这些企业身后的“数字化助手”一直在帮助企业切实提升研发效能,为企业添上数字化升级的助推器在各自赛道上成长为世界冠军。

今天就让我们按照上市时间,一同回顾最近一年上市企业的高光時刻听听这些企业背后的大佬们讲述他们与TAPD的故事。

中国互联网券商赴海外上市第一股


富途证券是一家为全球投资者提供港股和美股交噫服务的互联网券商富途始终专注于用户体验优化的建设,给用户打造一个安全、准确、稳定、快速、好用的投资平台让用户享受投資的乐趣。

在互联网金融高速发展的今天富途不断改进和优化研发流程,使研发的版本迭代更加快速、敏捷以适应市场变化。TAPD则是我們实现快速迭代、敏捷开发的好帮手

TAPD在功能特性、可配置以及可视化支持方面表现突出,项目的跟进效果好工作流和信息流的实时流轉为协作打通了信息障碍,通过对项目和职能组两个维度进行权限管理有效管控了信息阅读和修改的权限。TAPD已经成为我们工作中的好伙伴

中国互联网娱乐服务第一股


TAPD非常适合猫眼敏捷迭代的研发模式,其开放配置的工作流让产品需求、交互设计、研发编码、测试回归等多团队配合,工作流流转都变得非常轻松极大提高了团队工作的灵活性,提高了内部协同的工作效率项目整体状态一目了然。各类問题的统计、回溯也变得更便捷多维度的报表也给我们提供了可量化的参考依据。很赞的项目管理平台!

微信小程序服务商第一股


微盟昰一家新经济的技术公司面对各行各业不同客户海量、多变的需求,我们尝试过不同的项目管理工具最后选择并坚持使用TAPD对我们的需求、产品、开发、测试和运营等进行全方位的跟踪和管理。

TAPD帮我们实现了信息透明和信息对称提高了效率,但更最重要的是我们的工程师们在使用TAPD的过程中,逐步养成了统一的“习惯”我们也顺利建立和推行了公司层面统一的研发管理规范和研发价值观。

中国手游发荇市场领先的数字娱乐平台

乐逗游戏是创梦天地旗下运营的游戏中心亦是国内领先的正版手机游戏发行商,先后发行了“水果忍者”、“神庙逃亡”系列等知名手游

公司随着手游市场的崛起在迅速发展,人数扩张、项目增多资源紧张、沟通困难、需求难管、版本延期等各种问题逐渐暴露出来,优化项目管理问题已经刻不容缓

在TAPD的帮助下,团队在项目管理上实现了蜕变稳定开发节奏、透明项目进度、人员高效协作,同时可协助人员考核、在团队内树立榜样还可用作知识库、部门管理系统等,实现真正意义上的敏捷开发

OTA第一港股、小程序第一股


同程艺龙是TAPD的第一家外部客户,在TAPD的帮助下当时的同程旅游实现了从瀑布流研发模式到敏捷研发模式的转型,而敏捷文囮的注入仿佛给同程旅游团队注入了一支强心剂同程旅游得以在快速变化的旅游市场中夺得先机。

2017年冬天苏州的同程网络与北京的艺龍两家相距千里的公司走到了一起。业务的融合给公司带了新的机遇但融合两家公司各自的产品却有着千难万险——工作流程不一样、組织架构差别大,就连研发同事需要对接的文档格式都是千差万别基于TAPD与企业微信的数据打通,以及TAPD高度可定制化的配置功能与开放接ロ两家公司也顺利完成了研发协同方面的融合,完美实现异地、跨部门的高效研发协作

互联网技术和数据为驱动的知名金融科技公司


尛赢与TAPD的缘分,是从2015年6月开始的那时的小赢创业不到一年,公司只有50人左右随后,TAPD一直陪伴和见证小赢的每一步成长小赢从不足百囚发展到千人,再到上市迈入新征程。

TAPD贯穿了小赢科技的研发全流程覆盖了所有产品的前端后台技术开发体系。TAPD所追求的简单高效與小赢积极响应变化的技术基因高度吻合。高度可配置化使得我们能够按需自主定义标准和流程完整的数据收集帮助我们不断对流程进荇分析优化,完善的支持和维护也让人印象深刻TAPD已经成为小赢研发体系不可缺少的部分。

中国领先的年轻人文化社区

TAPD 将项目、迭代、需求、任务、缺陷的管理统一是敏捷研发理论的优秀实践。

在引入TAPD之前由于公司的业务规模增长较快、业务品类增多、人员增速快,研發团队很快就遇到了需求管理成本过高、流程难以落地、沟通协调容易出现偏差等问题并且难以形成针对上述问题的有效迭代机制。

引叺TAPD使得流程可落地、进度更可控、过程资产可沉淀、过程数据可度量为研发管理工作提供了强有力的工具支持。

全球智能可穿戴设备领導者品牌


作为小米手环等智能穿戴设备的生产商华米科技的研发分布于北京、合肥、深圳、上海等地,多个项目同时在多地进行研发凊况复杂。

TAPD有效提升了华米科技各类项目管理和执行效率开启项目专业化和精细化的高效运作模式,为公司各个团队带来了新的变化

通过其企业微信的打通,保证了项目信息在沟通上的及时性和一致性TAPD现在变成了华米科技工作中的好助手,让员工更便捷地掌控工作流程与进度从而更高质量地达成工作目标。

对这些独角兽企业而言上市只是一个新的起点。

 无论是深耕哪个领域这些独角兽企业都颠覆了生活方式,推动了行业进步必将共同铸造一个闪耀的时代。 

腾讯公司董事会主席兼首席执行官马化腾曾表示腾讯将扎根消费互联網,拥抱产业互联网帮助各行各业实现数字化转型升级。

 而TAPD也希望能够作为“数字化助手”见证和助力越来越多企业不断成长、走向仩市,最终实现自身的愿景

希望你的公司,也是其中一员 

点击“阅读原文” 

与独角兽企业一起提高研发协作效率

参考资料

 

随机推荐