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


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

三、腾讯是如何做敏捷管理的？

1、故事墙

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


2、每日晨会

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

早是通过白板的方式去做，是每天项目经理组织团队成员对着白板，白板上体现项目的进展情况，通过会议可以很明确的知道昨天大家做到什么样子，大家计划做什么，早的时候每个成员都是口头汇报的。实践一段时间发现了一些问题：

    对于一个20、30人的团队，每天要怎样做晨会，这是目前遇到的比较大的困惑；
    晨会很容易形式化，究竟带来什么样的效率和效果，目前也在通过一些方式去研究，去探讨。
    有一些形式上的呆板，刚开始做会觉得比较有意思，觉得这跟传统做法不一样，每天这样做并且做多了感觉很枯燥，这也是面临一个挑战。

后来腾讯也做了一些改进，比如为了让成员的参与程度更强一些，包括形式上会更强一些，现在有些团队会采取每个人轮流主持的方式，刚开始晨会的时候我们也会通过一些好玩的东西去刺激一下某些东西，但是现在看来的话，感觉改进的还是不是很透。在腾讯内部有一个交流通信的软件，有些项目也开始不采用站起来开晨会的方式，觉得站起来效率也不高，会通过即时通信软件每天去交流，后由一个人去统一输出，这样能解决一些分布式团队的合作。所谓分布式团队是这个团队中有些同事在这个大楼，有些同事是在那个大楼，通过这种实时交流的方式可以解决一些问题。


3、规划游戏

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


4、时间盒

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


5、产品演示

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


6、迭代总结

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


7、自运转团队

早期的项目，为了能提高效率，项目经理希望每个角色都能全力以赴的提升自己的效率，于是自己承担起来大量沟通和推进的工作，那个时候的都在被PM推着走，一旦PM休假，项目基本没有什么产出，当时去了以后，发现问题很严重，团队的主动性必须被调动起来才行。

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