他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)敏捷转型16个月，总结期间得与失
稿源：woshipm
本文将总结在过去的一段时间里，我们在转型过程中踩过的坑，以作前车之鉴。也聊聊在转型过程中，哪些优秀的实践可以尝试，走上渐进变革的道路。到今天，我们已经在敏捷转型的路上已经磕磕碰碰的走了16个月。从启程时的兴奋到现在的淡然，回想起来还是“图样图森破”，原以为把敏捷那一套运作模式拿过来，随着时间的推移，一切就会好转起来。然而，并没有那么简单，受限于组织架构，仅仅是把敏捷那一套运作模式照搬过来我们就做不到，更别说照搬过来后能不能适应我们的产品研发了。虽然，目前敏捷转型和预期比起来进展不够理想，但是在期间我们还是运作起来部分优秀的实践，提高了产品研发效率。本文将总结在过去的一段时间里，我们在转型过程中踩过的坑，以作前车之鉴。也聊聊在转型过程中，哪些优秀的实践可以尝试，走上渐进变革的道路。1.敏捷初识，我们的敏捷做对了吗在接触敏捷之处，大家对敏捷都是一知半解，更多的停留在字面意思的理解上：“敏捷就是快“。一旦有人觉得不快时，就会发出质疑，我们的敏捷做对了吗？另外一方面，由于刚接触敏捷，我们开始变得理论化，严格遵循敏捷定义的方式方法，条条框框，带着对敏捷的敬畏，天真的认为敏捷规定的都是好的，敏捷之外的方式方法都是不完美的，有缺陷的。对，这就是我在刚接触敏捷时，最大的两个误区。1.1.目光不要只关注敏捷的快快，仅仅是敏捷带来的一个结果而已。单纯的只关注这个结果，并不能对我们的转型带来什么帮助。关于快的定义，我们习惯性的参考别人做产品是什么样的节奏，找到业界的优秀企业作对比，认为做到那样才是快。然而，我们却很少去关注对应产品的品类和复杂度，忽略他们的组织文化、组织架构、人员素质、开发过程中的取舍等各种细节。看到别人家的孩子全是优点，自家的孩子一堆问题，却不去了解别人是如何解决那些问题的，付出了什么代价，只想取别人的优点，忽略别人的缺点。欲思其利，必虑其害，欲思其成，必虑其败。–《便宜十六策·思虑》我们在做敏捷转型时，引入了外部咨询培训，培训过程中老师举了一个例子：“他们以前做产品时，一天可以发20几个版本。”，这样的例子对于我们来说简直是太刺激了，我们的产品要一个多月才能发出去一个版本。虽然我们知道老师举例的产品是web端产品与我们的产品完全不一样，我们还是不由自主的认为我们是不是可以做到1周发一个版本，甚至更快，毕竟别人一天20多个版本啊。对，我们的目光完全被“快”吸引了，于是什么都围绕怎么能更快去开展改革，想方设法的充分利用资源，各种并行，反而导致混乱。1.2.不忘初心，实事求是我们是一家销售消费类硬件产品为主的公司，在引入敏捷之前，我们采用的瀑布开发模式，在产品复杂度低，研发人员较少的情况下，运作还比较良好。但是，随着产品复杂度的增加，研发人员增多，人员依赖度的增加，这样的研发模式变得十分笨重，连一个基本的信息传递都出了问题，集成一个版本变得十分困难，发布日期也总是一拖再拖。从结果上看就是我们不能按时发布，发布的周期比较长，产品研发变得“不敏捷”。然而要实际落地解决问题我们需要在这几方面改善：建立新的沟通机制，保障跨领域协作的有效沟通。需求要进行有效的优先级排序，并控制数量，并承诺对应优先级需求的交付率。避免建立过大的团队组织，如果存在，需要根据业务的独立性，拆解为适当规模的小团队。团队之间人员要解耦，尽量避免一个人在多个项目团队。信息透明，尽量让团队成员能基于已有的信息自己做出决策，而不是询问上级。建立跨领域团队，并对团队进行敏捷开发知识的宣导和指导。引入持续集成。限制在制品，避免一个人同时开展多项工作，原则上不能超过2个未完成的任务。等等……我们不再纠结于是否一定执行了敏捷里面规定的活动，又或者说我们现在的项目过程，也谈不上是完整意义的敏捷开发，我们更注重什么样的招式能有效解决我们当下的问题。1.3.我们的绊脚石本文开篇讲到了组织架构导致我们并不能完整的引入敏捷开发的各项机制。我相信，做过敏捷转型的人应该都遇到了这样的问题。以下是我们在敏捷转型中遇到的一些实际问题，当你遇到这些问题时，不要惊讶，对于一个传统的成熟组织来说很难改变，尤其在没有上层领导积极推动的情况下。没有产品经理，敏捷团队只关注开发与发布，不管开始，不管结果。在我们公司的组织架构采用了弱矩阵形式，敏捷团队更多的起到协作开发前端需求的作用，他们不需要对产品直接负责，也不会关注产品在市场上的反馈。测试与开发职责界限清晰。在理想的敏捷中，在开发过程中就开始做测试，而我们还是需要开发完成后再进入测试，走上了“小瀑布模式”之路。无法进行短周期迭代，放弃迭代。由于走上了“小瀑布模式”之路，根本没办法做到较短周期的迭代，对于一个月一个版本来说，超过2周的迭代周期已经失去了实际的意义。做好的功能都会发出去，基本没有功能灰度验证，功能越堆越多，维护越来越难。需求人员都会认为自己想法是完美的，能有效提高产品的价值，他们更关注自己提的需求，而不是这个产品。没有项目经理，只有项目负责人，项目负责人不专注，不专业。由于公司项目是弱矩阵形式，项目更多的是协作作用，项目负责人更多的是起到拉通团队协作的作用，由于项目负责人往往身兼多职，并不能有效的持续投入精力优化项目过程。等等……2.成功的每一小步固然，我们在转型中问题众多，还有很大的优化空间，但是和以前比起来我们还是取得了不小的进步，以下招式在实际项目开展过程中具有明显的实际意义，并不受传统组织架构排挤：2.1.跨职能团队对于传统企业来说，一般根据职能属性进行部门划分，各部门互相协作完成项目。然而，跨部门的协作成本明显过高，当产品需要频繁的跨部门协作时，这样的模式明显无法胜任。而在这时，公司必然也会暴露出由于这样的缺陷，导致的开发效率低下的问题。此时，以事业部或核心部门主导，建立虚拟的跨职能团队，也就顺理成章，一气呵成。跨职能团队能有效解决产品在开发时，频繁协作沟通的问题。在这样的团队里，沟通由实际的开发、测试、需求人员直接当面沟通，频率更高，信息失真也比较少，也避免了部门之间扯皮的问题。2.2.每日晨会晨会，是跨职能团队进行沟通的标准活动，每天在固定的地点、固定时间花10分钟左右举行，是一种很有效的团队同步机制。然而晨会看上去简单，但是要开好，却没有那么容易。敏捷里面的推荐晨会内容主要包括以下三方面。昨天做了什么？今天要做什么？有什么问题？对于敏捷小白的我们，刚开始照本宣科的组织晨会，但是采用标准的模式，我们却始终都开不好这样的晨会，下面会详细的说说我们都遇到了哪些问题。晨会沟通时，大部分信息对改善项目进展的实际意思很小，口水话太多。当一位同事在描述自己昨天做了什么，今天要做什么时，大部分人并不在意。大部分工程师晨会都是自顾自说，不关心自己表达的内容是否有效传递。推广晨会轮流组织时，发现大部分人并没有这个能力有效的组织晨会，并不太好实践。晨会讨论的内容很离散，看不到整个项目的进展。2.2.1.怎么开好晨会正如敏捷宣言里面提到的“个体交互胜过流程和工具”一样。晨会，需要将当前项目的进展透明到整个团队，并促使团队成员基于各自目前的情况，通过沟通及时主动的解决问题。那如何才能做到快速有效的沟通呢，我认为需要做到以下几点：团队成员都清晰的知道项目的目标和当前的状态。项目中的各项工作内容都有清晰的优先级，以及明确的责任人和当前的进展信息。晨会有明确的规则，每个人都知道在何时做何事。参与晨会的每一个人都能随着轻松的了解到与他相关人员的任务进展状态。要做到这些，当然就少不了一面合理的看板墙了。它是整个晨会的核心载体，晨会时，所有的项目成员都基于看板墙的信息进行讨论并更新看板墙的信息。2.3.看板墙看板墙，看似只是简单的将项目中要展示的信息帖到一个版本上面去，但是如果贴得不合理，整个晨会就会一团乱麻，思路离散，最终导致晨会的失败。接下来，我将谈谈我们看板的演进过程。刚开始，我们采用上图那样的看板墙，纸片上仅仅写了用户故事，每天晨会的时候，大家围成一圈，按顺序每个人讲自己昨天做了什么，今天做什么，有什么问题。当发现某项用户故事改变了状态时，就挪动到对应的列里面去。渐渐的问题就暴露出来，我们发现看板墙上的卡片会有很多，而且会越来越多，因为我们总是想做更多的用户故事，一旦某项用户故事在开发过程中受阻，我们就会考虑开展一项新的用户故事，我们不能接受一个人“闲下来”。另外，由于每个人讲的内容，并没有和卡片直接关联起来，导致我们并不能很好的把讲的信息和看板墙结合起来，以至于看板墙成了一个背景，没有起到太多的实际意义，我们开始质疑，轮流讲问题是不是不合理，转变为由一个人主持，根据看板墙上的信息逐个询问探讨，为了实现轮流主持，我们定期换不同的人进行询问探讨，但是有时候有的人却完全不知道如何有效的主持，导致晨会下来的有效沟通很少。由于看板卡片上记录的信息很有限，卡片数量又比较多，以至于项目负责人都难以清晰的了解当前项目的进展，更别说其他团队成员了。于是我们把看板改成了下图的样子：这样子，看上去比以前的看板清晰了一点，能比较清晰的知道目前视觉、软件、测试的任务情况，可惜还是存在不断的向后面推用户故事的问题，导致看板的在制品过多。另外，还是存在部分用户故事较大，在某个位置停留过长时间的问题，并且我们并不能清晰的了解到该用户故事目前的进展情况。这里附带提一下，总会有人提要把需求的粒度拆分得更小，把一个用户故事拆分到1到3天的工作量，可惜我们一直没有实现，或者我们勉强把一个大的用户故事拆分成了几个小的用户故事，但是在我们这种敏捷并没有完全转变过来的团队，我们还是喜欢一个需求完整的交付。因为只有这样我们的黑盒测试才能有效的测，不然会让测试重复测，浪费测试资源，前端需求对于一个没有做到发布状态的需求，也觉得不好体验。为了有效的跟进较大的用户故事的进展，我们开始进行任务拆分，我们规定一项任务的粒度最大不能超过三天的工作量，我们趋向于团队成员尽量把任务都拆解到小于一天工作量的粒度，因为这样有利于我们每日晨会进行跟进，于是看板上的卡片就分为了两类，出现了下面的看板。我们将看板上的卡片分为用户故事和与用户故事对应的任务，当所有与用户故事相关的任务都完成时，将用户故事挪到待发布中。用户故事与任务之间使用编号进行关联，这使得我们的晨会过程讨论的内容更加具体，而不是简单的汇报工作，项目进展情况也比以前更加清晰。然而，问题依旧存在，当任务卡片较多时，任务与用户故事的对应关系找起来相对麻烦，不能一目了然的了解到用户故事的进展情况。同样的，这样的看板依旧会存在前端需求大量的向后端涌入，导致后端负荷过重，效率降低的情况。得益于精益的限制在制品概念，结合我们之前的各种经验，我们最终使用了下面这种看板墙。在这个看板墙里，只有用户故事卡，用户故事卡上拆分了用户故事的不同任务，我们不再追求多个领域能针对一个用户故事并行开展任务，而是一个领域做完后，再流入到下个领域。表面上并行开展工作看起来效率更高，但是那样各领域信息并不一致，返工较多，反而导致效率低。由于任务和故事在同一张卡片上，我们可以从看板上一目了然的看到用户故事当前的状态。另外，我们将卡片分为三种颜色，对应于三个优先级，这样大家在领取任务时，能更加自主。还有一点十分重要，每个领域我们根据他们的人数设置在制品限制，目前规定一个人同时开展的工作不能超过两项。我们由推的模式转变为拉的模式。这样能清晰的暴露领域边界的资源匹配情况，同时也能保护相关领域不至于任务过多引起混乱，进而导致效率降低。我们由要做更多的需求转变为“停止启动，聚焦完成”。一个人的同时工作项不超过两项并不是一个标准答案，我们内部也未完全按照该标准执行。对于基本不会出现阻塞的领域，也许一项也是一个合适的选择。2.4.版本规划由于我们的产品包括iOS应用、Android应用、手表端、服务器、H5这样5个技术领域。在初期，我们遭遇了各领域互相依赖，因某个领域有bug未能及时修复，导致整体发布延期的问题，而且还经常发生。因此，我们采用了版本火车的概念，以发布为主，功能为辅。也就是在固定的时间节点必须发布，如果对应功能没有达到发布要求，就推迟到下一个发布版本。这样做却带来了几个比较揪心的问题，我们版本没有明确的主题，仅仅是一堆已完成的需求而已，导致每个版本的亮点不够。另外，由于没有规划版本，因此无法给到前端明确的心理预期，他们不知道他们的需求在什么时候能发布，他们也不知道我们的下一个版本将会携带哪些需求。而对于开发而言，也缺乏明确的目标感，给人一种来了需求我就做，做多少算多少的感觉。于是，我们最终还是放弃了版本火车，改为版本规划的方式进行整个产品的研发。版本规划，最头痛的问题就是选哪些需求进入该版本进行开发的问题。要知道，需求永远都是源源不断的来，需求的总量总会远远大于你当前版本能开发完成的总量。因此就涉及到一个需求收集和筛选的问题。如果每次版本都要筛选那么多需求，需要耗费很大一拨人大量的时间来进行需求优先级讨论，以及该需求是否在该版本做的问题。另外，在这么短的时间内也得不到太有效的讨论结果。在《看板实战》中，有一个“优先级过滤器”的实践方案，如下：在这个看板上，明确了一个团队的产能，以及接下来要做的需求。当一个需求被挪走后，就会触发后续需求的进入和讨论，这样每次只需要讨论少量的需求，更加聚焦。这固然是一个好的实践，可是我们现阶段的团队并不能适应它，因为我们并没有真真的做到精益里面提到的拉动式开发。于是我们在进行版本规划时，采用了如下方案：在下一个版本开展前两周开始收集需求。一个版本一定要有一个明确的主题。版本有明确的时间节点。需求要明确必须、应该、可以三个优先级，比例要适中。必须的需求未按期完成时，版本发布时间后延。应该的需求要保障至少80%的交付率。可以的需求要保障至少50%的交付率。需求收集完后分为多次进行版本规划讨论会议。分多次进行版本规划讨论会议很关键，由于需求收集的量比较大，另外参会的人比较多，大家很难一次性达成一致。当一次会议结束后，需要给到整个团队一些线下时间做更多的思考以及了解更多的附加信息来进一步评估。我们一般会开2到3次这样的会议，每次会议时间为1到2个小时，这是一个逐步收敛和达成一致的过程。3.未来我们的项目过程，还有很多值得优化的地方。到目前为止，我们的项目开展过程只能说做到了有序。而在接下来的日子里，我们还需要加强项目的度量。做到，不凭感觉规划版本内容的多少，不凭感觉说项目做得好还是差。通过度量数据，更客观和明确的暴露项目中的问题。4.推荐书单对于我自身，经历过公司组织的一次敏捷咨询后，就踏上了部门敏捷转型的道路，期间踩坑无数，幸得以下书籍把我从一个一个坑里面拉了出来。推荐的书单中，部分书籍还未读完，大部分书籍阅读完一两遍后还不得其道，还需要反复阅读和实战，这里就不好意思写自己的感悟和对这些书的评价了，以免误导大家。但是，这些书都是在我转型的道理上，给予我不少启发和帮助的书籍，我相信读过这些书的人都能有所收获。《敏捷软件开发实战-估算与计划》《敏捷软件测试》《精益创业》《精益创业实战》《看板方法》《看板实战》《网易一千零一夜》《人月神话》《四步创业法》《目标》《卓有成效的管理者》《最后期限》《思考，快与慢》文章作者系 @小蚂蚁 未经许可，禁止转载。
有好的文章希望站长之家帮助分享推广，猛戳这里
本网页浏览已超过3分钟，点击关闭或灰色背景，即可回到网页腾讯敏捷开发及快速迭代 敏捷开发和瀑布开发
腾讯敏捷开发及快速迭代 敏捷开发和瀑布开发
项目经理职业发展热线：400-666-0609公众微信号：mypm_net转载：从2006年开始敏捷开发和瀑布开发，腾讯的研发规模开始膨胀，开发模式急需规范和标准化，到底走IPD(集成产品开发)还是Agile(敏捷)的开发路线，公司管理层也在为拿不定主意而犯愁，之后研发管理部开始与ThoughtWorks公司接触，逐渐将敏捷产品开发引入进来，并正式命名为TAPD(Tencent Agile Product Development)。接触是从一次3天15W的培训开始的，ThoughtWorks派来了一个4人讲师团队，由此也诞生了腾讯日后推行敏捷的第一批种子。接着总结腾讯本身是怎么样子的，有这样一个框架之后就搞一些团队去实践，通过实践以后再不断改进，本身也是一个不断迭代的过程。敏捷开发 pdf整个实施阶段大概分成几个阶段：试点期：组织很多专题研讨和内部培训，树立标杆，更大范围内进行培训。推广期：内部建立一个顾问团队，开发一些扫盲的课程，不断的到一些团队里面去介绍去培训，让大家接受这些理念。同样腾讯在推广敏捷的过程中也面临一些挑战：1、团队非常多，每个团队特点都不一样，比如规模不一样，应用方法不一样;2、产品非常广，互联网上所有的产品腾讯几乎都有，这种多元化的产品它本身产品的研发模式会有一些不一样，那么敏捷、TAPD怎么样去适应这种多元化产品的研发;3、敏捷在腾讯也是存在一个过程改进，这样就会存在一些不适应性，针对这种不适应性应该怎么样去做才能更好;4、腾讯人员本身的素质也是参差不齐，每年校园招聘大概会招聘1000多个毕业生，这些毕业生从毕业到能上手工作敏捷开发的迭代测试，他们对敏捷的了解，融入到团队中都需要一个过程;5、一些长周期的项目，比如QQ客户端，一个版本的发布可能要半年到1年的时间，像这样一个产品怎样去做敏捷开发，也许它就不适合敏捷开发。正是由于这些挑战，才孕育出了独特的腾讯敏捷模式。以下为收集的一些资料整理：一、整体的框架结构简言之，腾讯的TAPD是吸收了XP+SCRUM+FDD三者特点的并行迭代开发模式，涉及范畴包括敏捷项目管理和敏捷软件开发。1、产品小步快跑 快速迭代采用FDD，即产品特性开发驱动的一种模式，腾讯的产品会有一个明确的产品经理这样一个角色，他会负责整个产品，包括产品的验证、产品的方向、市场调研、用户调研等。FDD 模式是一种非常适合产品经理来对产品做一些滚动的要求，腾讯在产品设计上引入了类似FDD这样的模式，但是也不完全是FDD，只是参考FDD，所有的开发团队都是由产品经理所归纳出来的产品特性去驱动整个产品的研发。FDD的核心是面向产品的功能点，但这个功能点是从客户角度出发的，并不是从系统角度出来的。功能点是用一个短句描述出一个业务需求，而这个业务需求的粒度是按开发时间来衡量的(一般不超过两个星期)。特征与用例的相似之处是，两者都可以用短句(动宾短语)来描述;两者的不同之处在于，用例用UML的用例图来表示，而特征是用四色原型(类图)来表示。产品经理这个角色有点Scrum的Product Owner的味道。但产品特性和backlog相差甚远，因为产品特性只是一个动宾短语，敏捷开发的迭代测试而backlog却是一个完整的故事(story)。小步快跑 快速迭代2、项目管理过程腾讯采取了SCRUM，但也不完全是SCRUM ，腾讯根据自己的特点去总结的一些实践，大概的项目管理过程同SCRUM的过程比较类似，包括每天的晨会、迭代、timebox、每个迭代完成的时候会有showcase、回顾总结等。3、开发实践参考了很多XP的实践，就XP完整的实践来说会比较理想化，很多东西不一定在实际开发中能够采纳，所以腾讯也是采纳其中的某些实践，比如自动化测试和持续集成，通过这样的实践就能保证产品有一个快速发布的过程。二、腾讯的快速迭代过程一个完整的迭代过程 包括概念、设计、开发、测试和发布五个过程。敏捷开发 pdf在概念阶段，会采用FDD里面提到的一些好的最佳实践来支撑到我们怎么样去敏捷的做需求开发，会制定一些产品发布的计划，比如产品在未来，某个迭代什么时候发布，要发布哪些产品特性，都是在这个阶段做的。在设计阶段，会做产品原型上的设计。对于互联网产品说更多的是通过快速原型法快速的让产品在不同范围内去做一些体验，比方产品在某个迭代的一个小迭代里面，可能会在一个团队里面先去体验，可能就会采取发布到公司某一个部门去体验，或者发布到整个公司范围去体验，它会是一个不断放大的一个过程。在开发和测试阶段，更多的采取XP的一些实践，包括编码规范，代码走读，比如1周一次代码走读，构建持续集成的环境，包括自动化构建，自动化测试等，会有一些好的测试上的实践，如全员测试，就是将测试看成不仅仅是测试人员的工作，更多的是整个团队的工作，当然也包括这个产品的其他同事的工作，通过全员测试来激发大家对产品质量负责。在发布阶段，腾讯采用的是灰度发布，同传统的软件发布不一样。项目中整个迭代过程就通过类似SCRUM模式去管理，如有每日晨会，如何建设团队氛围，统一的管理平台，每次迭代完成时的总结回顾等等，这属于项目管理的工作。其中分析、设计、开发、测试、发布这五个过程可以内部再迭代，而且这五个过程不是分阶段开展的，即不是分析完了之后才设计，全部设计完了才开发，开发结束了才测试，测试通过了才发布敏捷开发和瀑布开发。而是边分析边设计——在业务不复杂的情况下，这是可行的——边设计边开发，开发完一个功能就测试一个功能，同时开发下一个功能。还有一些基础的工作，如代码管理，版本管理，文档管理，异地开发管理，这些在腾讯的整个管理体系里面都包含的，还有会制定一些相关的规范，不过规范不是很强硬的要求每一个项目必须执行，更多的由团队自己选择，让他们根据自己团队的特点、规模去选择应该采取哪些实践。三、腾讯是如何做敏捷管理的?1、故事墙就是白板story wall，平时工作中很多团队都会使用，这些团队会把每天开发的一些产品特性采用story的方式每天都在白板里面展示出来，整个团队每天都会围绕这个白板能够清晰的看到整个产品或者整个项目的一个过程，包括整个产品特性的过程。写在白板上比用Excel或者其它工具管理好敏捷开发活动，因为写在白板上让人感觉更紧迫、更正式、更一目了然，有一种别人在监督、在注视的感觉。2、每日晨会每个团队每天大概花15-30分钟，回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作。对Team而言这是检查进度、快速调整非常有效的形式。最早是通过白板的方式去做，就是每天项目经理组织团队成员对着白板，白板上体现项目的进展情况，通过会议可以很明确的知道昨天大家做到什么样子，今天大家计划做什么，最早的时候每个成员都是口头汇报的。实践一段时间就发现了一些问题：对于一个20、30人的团队，每天要怎样做晨会，这是目前遇到的比较大的困惑;晨会很容易形式化，究竟带来什么样的效率和效果，目前也在通过一些方式去研究，敏捷开发和瀑布开发去探讨。有一些形式上的呆板，刚开始做会觉得比较有意思，觉得这跟传统做法不一样，每天这样做并且做多了就感觉很枯燥，这也是面临一个挑战。后来腾讯也做了一些改进，比如为了让成员的参与程度更强一些，包括形式上会更强一些，现在有些团队就会采取每个人轮流主持的方式，刚开始晨会的时候我们也会通过一些好玩的东西去刺激一下某些东西，但是现在看来的话，感觉改进的还是不是很透。在腾讯内部有一个交流通信的软件，有些项目也开始不采用站起来开晨会的方式，觉得站起来效率也不高，就会通过即时通信软件每天去交流，最后由一个人去统一输出，这样能解决一些分布式团队的合作敏捷开发 pdf。所谓分布式团队就是这个团队中有些同事在这个大楼，有些同事是在那个大楼，通过这种实时交流的方式可以解决一些问题。3、规划游戏对敏捷的一种常见误解是不要计划，其实在敏捷的体系中不仅强调计划，甚至区分Release计划、Iteration计划和Task计划等多种不同粒度、不同时长的计划。规划游戏突出的是让用户代表参与，由用户代表评估用户故事/特性的优先级，开发人员评估任务的开发时间，由用户代表+项目经理+核心 成员三方共同排序、组合，确定本次迭代计划需要实现的特性列表。在腾讯用户代表就是产品经理。腾讯特别强调的是并行迭代，即多个版本并行，最大程度发挥资源的效率。Release(发布)可理解成当实现的产品特性累积到一定用户价值时的正式发布，它是比迭代更大的概念;迭代是在固定时间内开发特性的过程，Release一般包括多次迭代。4、时间盒在腾讯的产品研发中，产品的每一个迭代都有一个明确的时间盒。在每一次迭代开始的时候会召开一次IPM会议，即本次迭代的计划会议，会议中团队中的所有成员包括产品人员、开发人员、项目经理、总监、部门领导，一起去敲定本次迭代要完成的任务，一旦任务敲定下来，本次迭代就会严格按照这个去落实执行。TimeBox反映了敏捷开发的节奏，即在固定时间内实现不固定特性的周期，抛开需求定义阶段，从设计-实现-测试到部署，在腾讯一般一至两周时间居多。5、产品演示提交测试前由开发人员演示实现的功能，产品经理到场Review是否符合当初的设想，避免接近发布时才反馈。6、迭代总结敏捷开发的迭代测试在每一个产品发布的时候都会有一个总结。具体的做法是，把做得好的、不好的总结出来，做得好的在下一次迭代发扬光大，做得不好的在下一次迭代就要注意改进。这样的总结是要求项目的所有成员都必须参加，包括项目的开发人员、测试人员、QA、项目经理、产品经理等，每个人都要去去总结他在上一个迭代中碰到了什么问题，通过便签纸的方式贴出来，项目经理实际上可以看成是Scrum Ma ster，包括站起来总结这样一些东西，包括我们下一次迭代继续发扬什么，必须要注意什么东西，最后就会得出一个excel的文档，包括上一个迭代中出的问题，具体的解决办法，都会有7、自运转团队早期的项目，为了能提高效率，项目经理希望每个角色都能全力以赴的提升自己的效率，于是自己承担起来大量沟通和推进的工作，那个时候的都在被PM推着走，一旦PM休假，项目基本没有什么产出，当时去了以后，发现问题很严重，团队的主动性必须被调动起来才行。小步快跑 快速迭代自运转团队，是将需求开发过程详细划分成开发的各环节，并明确每个环节的负责人，由该负责人来驱动上下游的负责人，而不再由项目经理来连接各个环节，再配合上高效的项目协助工具平台，实现开发过程自运转。这时项目经理则由指挥者变成服务者，观察环节之间产生的瓶颈，并及时采取措施扫除障碍。四、腾讯是如何进行敏捷开发的?1、用户研究如何加强用户的参与度，这是一种成本比较低的用户研究方法。通过抓取一些用户数据做分析，分析用户在这个产品上整个体验的过程是怎样的，通过后台的数据可以看到整个活动的曲线，同时CE也可以通过一些科学的手段去保证，包括市场调研、用户研究、数据挖掘、产品体会等，这就是通过一些对用户反馈、用户观察的工具去配合去对用户做研究。比如QQ拍拍的一个用户的研究，我们可以到现场去做的一个调研，经常会由产品经理和用户研究人员到用户的实际办公地点进行调研，做一天的反馈，通过观察用户一天是如何使用你的产品，配合一些相关的工具去科学的分析。因为互联网是非常强调同用户的这种反馈的，腾讯有自己内部的一个CE反馈平台，在这个平台上可以收集到所有用户的反馈，产品经理可以每天都会看到他所负责的产品有哪些反馈，包括内部的、外部的，然后他就可以根据这些反馈对产品进行一些快速的调整，包括开发一些什么样的产品特性，内部同事也可以踊跃的在平台上反馈，内部同事本身就是QQ用户。2、故事卡片/故事墙/特征列表StoryCard是XP中推荐的需求定义方法，要求符合Invest和Moscow原则;故事墙则用于跟踪故事卡片的 变化状态，而特征列表是Tencent一直沿用的需求表达形式，在腾讯的TAPD工具中已经实现了类似ThoughtWorks 的Mingle的故事卡片管理功能，对于需求跟踪而言这是不错的方法，一目了然。3、结对编程理论上结对编程可以提高代码的质量，而且并不会降低开发效率，但腾讯的业务繁忙，资源上不允许两人结对。但是在一些团队里面还是一直在尝试着做结对编程的工作。一个在编写程序，旁边还有一个人，同时记录编写过程、编写思路、碰到的问题、自己的想法，编写完以后一段时间他们会交换一下，就是互相交换着进行编程，这是一个结对编程的一个过程。敏捷开发的迭代测试4、测试驱动“测试驱动开发”在腾讯执行地并不太好，腾讯的产品以Web形式居多、业务逻辑相对简单，C++下的单元测试有些力不从心。相反自动化测试在腾讯比较盛行，因为有测试部门专门的自动化测试Team在推动，而且链接的是正式生产环境，可以即时反映产品当前的状态。5、持续集成持续集成可以降低发布前集成阶段的难度与成本，腾讯的自动化构建系统推行的比较早，覆盖了大多数产品，而且正在朝自动化构建-自动化测试-自动化发布三者协同的目标迈进。作为加快产品的发布的能力，持续集成在以下几个方面作用明显。自动编译输出报告，维护代码可运行，及时暴露风险，降低集成成本。Dailybuild日构建系统，小步快跑 快速迭代让产品经理、测试人员可以尽早进行体验和测试。作为一个自动化系统，利用静态代码检查、单元测试报告等手段为团队提供报告，促进编码质量不断得到重视，降低缺陷解决成本、缩短解决时间。6、灰度发布灰度发布是腾讯的又一创新，它将产品试用扩大到海量用户一端，在小范围及时吸取用户反馈，分析用户行为和喜好，持续修正自己产品的功能体验。在互联网行业，灰度发布已经成为最重要的发布控制手段。有时我们希望通过向小部分用户开发新功能，让他们先来体验新功能、新特性。通过用户反馈、数据运营的手段及早获得反馈，及时改进敏捷开发 pdf。以此方式，既可以降低发布风险，也可以提升发布频率，加快发布节奏。简单说就是，将一项业务不是一下发布给所有用户，敏捷开发和瀑布开发而是分批分期的发布，目的有两个方面，一是减轻服务器压力，二是期间可以在小范围收集到用户的反馈，如果业务出现问题，不会让大范围用户受到影响。随着经验的累计，我们有了许多种灰度策略和方法，灰度也有了更多的应用，甚至引入到了测试环境，即选择一些热心用户，将功能首先发布给他们，通过他们的使用，来帮助进行一些现网测试，这使得一些难于模拟的测试场景变得简单，测试人员的压力大大降低;更重要的用户是最好的测试人员，测试结果更加真实;同时他们也享受到了优先体验的特权，可谓一举三得。发布的时候也有策略，比如发布时如何放量，对用户有些什么样的实验，技术上怎样做一些后台开关，运营上怎样跟进，怎样保证4小时人员的留守，发布完后怎样收集用户反馈等等都会有一些统一的规则。7、发布汽车过于频繁的发布会打破团队节奏，有效的发布管理是必不可少的，根据业务特点，我们通常会采用三种发布模式，我们管它叫“发布汽车”。班车模式：像班车一样，固定周期进行，比如每两周发布一次，这周比较适合特性规划比较好的产品，比如QQ客户端基本每个月都会发布一个版本。的士模式：与QQ客户端不同，QQServer作为一个平台，它的需求来源非常多敏捷开发活动，因此它采用多线并行的方式，根据需求来源分成十多个子项目，根据每个子项目如果想要发布，就像打的一样随叫随发布。他的好处是快，但是协调发布的成本是比较高的，比作班车花钱要多。警车模式：顾名思义可以不按法规来开车，因此对于一下特别紧急的需求或运营事件，必须采用警车这种模式，紧急发布，但这样做成本更高，会把交通秩序搞乱，开发节奏打破。8、重构好的代码不是设计出来的，而是重构出来的。五、总结敏捷开发和瀑布开发当然流程和开发方法确定了还远远不够，更难的是如何将它推动落地。首先腾讯组织开发了承载敏捷思想的TAPD项目管理工具，它类似 ThoughtWorks的M然后推出了敏捷能力模型，类似CMM成熟度模型一样对Team评级加以引导;同时还推出了敏捷指数排行榜形成竞争，营造你追我赶的声势氛围。本文转载自标点符的《腾讯敏捷开发及快速迭代》。项目管理者联盟专注于项目管理、工程管理与研发管理领域，在工程、制造、IT通信等行业具备丰富的咨询与培训服务经验。项目管理者联盟多次主办和协办全国性的项目管理学术与应用高峰论坛及会议，2003年开始常年举办项目管理培训课程、国际项目经理（PMP、PgMP、PfMP）认证课程，产品经理NPDP课程，技术经理PBA商业分析课程与ACP敏捷开发课程、工信部项目经理课程，为企事业单位培养超过30000名项目经理。欢迎您电话咨询预约我们的PMP、PgMP、PfMP、PBA、NPDP等课程试听体验。咨询电话：400-666-0609
点击排行榜