敏捷开发及快速迭代

一、产品

  采用 FDD，即产品特性开发驱动的一种模式，腾讯的产品会有一个明确的产品经理这样一个角色，他会负责整个产品，包括产品的验证、产品的方向、市场调研、用户调研等。FDD 模式是一种很是适合产品经理来对产品作一些滚动的要求，设计上引入了相似 FDD 这样的模式，可是也不彻底是 FDD，只是参考 FDD，全部的开发团队都是由产品经理所概括出来的产品特性去驱动整个产品的研发。

FDD 的核心是面向产品的功能点，但这个功能点是从客户角度出发的，并非从系统角度出来的。功能点是用一个短句描述出一个业务需求，而这个业务需求的粒度是按开发时间来衡量的（通常不超过两个星期）。特征与用例的类似之处是，二者均可以用短句（动宾短语）来描述；二者的不一样之处在于，用例用 UML 的用例图来表示，而特征是用四色原型（类图）来表示。产品经理这个角色有点 Scrum 的 Product Owner 的味道。但产品特性和 backlog 相差甚远，由于产品特性只是一个动宾短语，而 backlog 倒是一个完整的故事（story）。

二、项目管理过程

  采起了 SCRUM 但也不彻底是 SCRUM ，根据本身的特色去总结的一些实践，大概的项目管理过程同 SCRUM 的过程比较相似，包括天天的晨会、迭代、timebox、每一个迭代完成的时候会有 showcase、回顾总结等。

三、开发实践

  参考了不少 XP 的实践  就 XP 完整的实践来讲会比较理想化，不少东西不必定在实际开发中可以采纳.其中的某些实践，好比自动化测试和持续集成，经过这样的实践就能保证产品有一个快速发布的过程。

一个完整的迭代过程包括概念、设计、开发、测试和发布五个过程。

在概念阶段，会采用 FDD 里面提到的一些好的最佳实践来支撑到咱们怎么样去敏捷的作需求开发，会制定一些产品发布的计划，好比产品在将来，某个迭代何时发布，要发布哪些产品特性，都是在这个阶段作的。在设计阶段，会作产品原型上的设计。对于互联网产品说更多的是经过快速原型法快速的让产品在不一样范围内去作一些体验，比方产品在某个迭代的一个小迭代里面，可能会在一个团队里面先去体验，可能就会采起发布到公司某一个部门去体验，或者发布到整个公司范围去体验，它会是一个不断放大的一个过程。在开发和测试阶段，更多的采起 XP 的一些实践，包括编码规范，代码走读，好比 1 周一次代码走读，构建持续集成的环境，包括自动化构建，自动化测试等，会有一些好的测试上的实践，如全员测试，就是将测试当作不只仅是测试人员的工做，更多的是整个团队的工做，固然也包括这个产品的其余同事的工做，经过全员测试来激发你们对产品质量负责。在发布阶段，采用的是灰度发布，同传统的软件发布不同。项目中整个迭代过程就经过相似 SCRUM 模式去管理，若有每日晨会，如何建设团队氛围，统一的管理平台，每次迭代完成时的总结回顾等等，这属于项目管理的工做。

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

还有一些基础的工做，如代码管理，版本管理，文档管理，异地开发管理，这些在整个管理体系里面都包含的，还有会制定一些相关的规范，不过规范不是很强硬的要求每个项目必须执行，更多的由团队本身选择，让他们根据本身团队的特色、规模去选择应该采起哪些实践。

如何作敏捷管理的？

一、故事墙

就是白板 story wall，平时工做中不少团队都会使用，这些团队会把天天开发的一些产品特性采用 story 的方式天天都在白板里面展现出来，整个团队天天都会围绕这个白板可以清晰的看到整个产品或者整个项目的一个过程，包括整个产品特性的过程。写在白板上比用 Excel 或者其它工具管理好，由于写在白板上让人感受更紧迫、更正式、更一目了然，有一种别人在监督、在注视的感受。

二、每日晨会

每一个团队天天大概花 15-30 分钟，回顾昨天作了什么、昨天有些什么问题、同时也会介绍每一个人今天计划作些什么工做。对 Team 而言这是检查进度、快速调整很是有效的形式。

最先是经过白板的方式去作，就是天天项目经理组织团队成员对着白板，白板上体现项目的进展状况，经过会议能够很明确的知道昨天你们作到什么样子，今天你们计划作什么，最先的时候每一个成员都是口头汇报的。实践一段时间就发现了一些问题：

对于一个 20、30 人的团队，天天要怎样作晨会，这是目前遇到的比较大的困惑；晨会很容易形式化，究竟带来什么样的效率和效果，目前也在经过一些方式去研究，去探讨。有一些形式上的呆板，刚开始作会以为比较有意思，以为这跟传统作法不同，天天这样作而且作多了就感受很枯燥，这也是面临一个挑战。一些改进办法，好比为了让成员的参与程度更强一些，包括形式上会更强一些，如今有些团队就会采起每一个人轮流主持的方式，刚开始晨会的时候咱们也会经过一些好玩的东西去刺激一下某些东西，可是如今看来的话，感受改进的仍是不是很透。有些项目也开始不采用站起来开晨会的方式，以为站起来效率也不高，就会经过即时通讯软件天天去交流，最后由一我的去统一输出，这样能解决一些分布式团队的合做。所谓分布式团队就是这个团队中有些同事在这个大楼，有些同事是在那个大楼，经过这种实时交流的方式能够解决一些问题。

三、规划游戏

对敏捷的一种常见误解是不要计划，其实在敏捷的体系中不只强调计划，甚至区分 Release 计划、Iteration 计划和 Task 计划等多种不一样粒度、不一样时长的计划。规划游戏突出的是让用户表明参与，由用户表明评估用户故事/特性的优先级，开发人员评估任务的开发时间，由用户表明+项目经理+核心成员三方共同排序、组合，肯定本次迭代计划须要实现的特性列表。用户表明就是产品经理。强调的是并行迭代，即多个版本并行，最大程度发挥资源的效率。Release（发布）可理解成当实现的产品特性累积到必定用户价值时的正式发布，它是比迭代更大的概念；迭代是在固定时间内开发特性的过程，Release 通常包括屡次迭代

四、时间盒

在产品研发中，产品的每个迭代都有一个明确的时间盒。在每一次迭代开始的时候会召开一次 IPM 会议，即本次迭代的计划会议，会议中团队中的全部成员包括产品人员、开发人员、项目经理、总监、部门领导，一块儿去敲定本次迭代要完成的任务，一旦任务敲定下来，本次迭代就会严格按照这个去落实执行。TimeBox 反映了敏捷开发的节奏，即在固定时间内实现不固定特性的周期，抛开需求定义阶段，从设计-实现-测试到部署，通常一至两周时间居多。

五、产品演示

提交测试前由开发人员演示实现的功能，产品经理到场 Review 是否符合当初的设想，避免接近发布时才反溃

六、迭代总结

在每个产品发布的时候都会有一个总结。具体的作法是，把作得好的、很差的总结出来，作得好的在下一次迭代发扬光大，作得很差的在下一次迭代就要注意改进。这样的总结是要求项目的全部成员都必须参加，包括项目的开发人员、测试人员、QA、项目经理、产品经理等，每一个人都要去去总结他在上一个迭代中碰到了什么问题，经过便签纸的方式贴出来，项目经理实际上能够当作是 Scrum Master
，包括站起来总结这样一些东西，包括咱们下一次迭代继续发扬什么，必需要注意什么东西，最后就会得出一个 excel 的文档，包括上一个迭代中出的问题，具体的解决办法，都会有

七、自运转团队

早期的项目，为了能提升效率，项目经理但愿每一个角色都能尽心尽力的提高本身的效率，因而本身承担起来大量沟通和推动的工做，那个时候的都在被 PM 推着走，一旦 PM 休假，项目基本没有什么产出，当时去了之后，发现问题很严重，团队的主动性必须被调动起来才行。

自运转团队，是将需求开发过程详细划分红开发的各环节，并明确每一个环节的负责人，由该负责人来驱动上下游的负责人，而再也不由项目经理来链接各个环节，再配合上高效的项目协助工具平台，实现开发过程自运转。这时项目经理则由指挥者变成服务者，观察环节之间产生的瓶颈，并及时采起措施扫除障碍。

3、如何进行敏捷开发的？

一、用户研究

如何增强用户的参与度，这是一种成本比较低的用户研究方法。经过抓取一些用户数据作分析，分析用户在这个产品上整个体验的过程是怎样的，经过后台的数据能够看到整个活动的曲线，同时 CE 也能够经过一些科学的手段去保证，包括市场调研、用户研究、数据挖掘、产品体会等，这就是经过一些对用户反愧用户观察的工具去配合去对用户作研究。好比  一个用户的研究，咱们能够到现场去作的一个调研，常常会由产品经理和用户研究人员到用户的实际办公地点进行调研，作一天的反馈，经过观察用户一天是如何使用你的产品，配合一些相关的工具去科学的分析。由于互联网是很是强调同用户的这种反馈的，本身内部的一个 CE 反馈平台，在这个平台上能够收集到全部用户的反馈，产品经理能够天天都会看到他所负责的产品有哪些反馈，包括内部的、外部的，而后他就能够根据这些反馈对产品进行一些快速的调整，包括开发一些什么样的产品特性，内部同事也能够踊跃的在平台上反馈，内部同事自己就是 用户。

二、故事卡片/故事墙/特征列表

StoryCard 是 XP 中推荐的需求定义方法，要求符合 Invest 和 Moscow 原则；故事墙则用于跟踪故事卡片的变化状态，而特征列表是沿用的需求表达形式，在 TAPD 工具中已经实现了相似 ThoughtWorks 的 Mingle 的故事卡片管理功能，对于需求跟踪而言这是不错的方法，一目了然。

三、结对编程

理论上结对编程能够提升代码的质量，并且并不会下降开发效率，但若是业务繁忙，资源上不容许两人结对。可是在一些团队里面仍是一直在尝试着作结对编程的工做。一个在编写程序，旁边还有一我的，同时记录编写过程、编写思路、碰到的问题、本身的想法，编写完之后一段时间他们会交换一下，就是互相交换着进行编程，这是一个结对编程的一个过程。

四、测试驱动

“测试驱动开发”在执行地并不太好，产品以 Web 形式居多、业务逻辑相对简单，C++下的单元测试有些力不从心。相反自动化测试比较盛行，由于有测试部门专门的自动化测试 Team 在推进，并且连接的是正式生产环境，能够即时反映产品当前的状态。

五、持续集成
持续集成能够下降发布前集成阶段的难度与成本，自动化构建系统推行的比较早，覆盖了大多数产品，并且正在朝自动化构建-自动化测试-自动化发布三者协同的目标迈进。做为加快产品的发布的能力，持续集成在如下几个方面做用明显。

自动编译输出报告，维护代码可运行，及时暴露风险，下降集成成本。Dailybuild 日构建系统，让产品经理、测试人员能够尽早进行体验和测试。做为一个自动化系统，利用静态代码检查、单元测试报告等手段为团队提供报告，促进编码质量不断获得重视，下降缺陷解决成本、缩短解决时间。

六、灰度发布

灰度发布是一创新，它将产品试用扩大到海量用户一端，在小范围及时吸收用户反馈，分析用户行为和喜爱，持续修正本身产品的功能体验。在互联网行业，灰度发布已经成为最重要的发布控制手段。有时咱们但愿经过向小部分用户开发新功能，让他们先来体验新功能、新特性。经过用户反愧数据运营的手段及早得到反馈，及时改进。以此方式，既能够下降发布风险，也能够提高发布频率，加快发布节奏。

简单说就是，将一项业务不是一下发布给全部用户，而是分批分期的发布，目的有两个方面，一是减轻服务器压力，二是期间能够在小范围收集到用户的反馈，若是业务出现问题，不会让大范围用户受到影响。随着经验的累计，咱们有了许多种灰度策略和方法，灰度也有了更多的应用，甚至引入到了测试环境，即选择一些热心用户，将功能首先发布给他们，经过他们的使用，来帮助进行一些现网测试，这使得一些难于模拟的测试场景变得简单，测试人员的压力大大下降；更重要的用户是最好的测试人员，测试结果更加真实；同时他们也享受到了优先体验的特权，可谓一举三得。发布的时候也有策略，好比发布时如何放量，对用户有些什么样的实验，技术上怎样作一些后台开关，运营上怎样跟进，怎样保证 4 小时人员的留守，发布完后怎样收集用户反馈等等都会有一些统一的规则。

七、发布汽车

过于频繁的发布会打破团队节奏，有效的发布管理是必不可少的，根据业务特色，咱们一般会采用三种发布模式，咱们管它叫“发布汽车”。

班车模式：像班车同样，固定周期进行，好比每两周发布一次，这周比较适合特性规划比较好的产品，好比 QQ 客户端基本每月都会发布一个版本。

的士模式：与 QQ 客户端不一样，QQServer 做为一个平台，它的需求来源很是多，所以它采用多线并行的方式，根据需求来源分红十多个子项目，根据每一个子项目若是想要发布，就像打的同样随叫随发布。他的好处是快，可是协调发布的成本是比较高的，比做班车花钱要多。

警车模式：顾名思义能够不按法规来开车，所以对于一下特别紧急的需求或运营事件，必须采用警车这种模式，紧急发布，但这样作成本更高，会把交通秩序搞乱，开发节奏打破。

八、重构

好的代码不是设计出来的，而是重构出来的。

4、总结

固然流程和开发方法肯定了还远远不够，更难的是如何将它推进落地。首先腾讯组织开发了承载敏捷思想的 TAPD 项目管理工具，它相似 ThoughtWorks 的 Mingle；而后推出了敏捷能力模型，相似 CMM 成熟度模型同样对 Team 评级加以引导；同时还推出了敏捷指数排行榜造成竞争，营造你追我赶的声势氛围。