大型项目的敏捷项目管理探索

1、大型项目的敏捷项目管理探索 即通研发管理组 Eagleluo2敏捷大会感受22 1. 业界在敏捷方面已经在前面跑了 2.路已经有人走了 ，我们可以借鉴 3.敏捷管理不可复制，需要自己找寻 4.增强我们继续探索的信心Agile is nothing special不是发明，而是发现聪明的人做正确的事程序员修炼之道，不变的规则破窗理论：Fix problems as soon as they occurDRY原则：Dont Repeat Yourself如何变得敏捷工具：故事墙、度量管理：经理融入团队、充分授权人：技能提升、更多地学习如何推行敏捷从一个团队开始搞定高层和底层敏捷大会内容大师的话4D

2、o One Thing Well（Dave Thomas）从试点到推广容易产生的障碍过度承诺：导致不可持续的速度、忽视学习人的惰性：导致精细管理、过多控制专业化：导致单一职能，效率重于价值部分完成：迭代结束时牺牲质量或功能不全缺少自动化测试：导致独立的测试团队，非跨职能跨越障碍合理承诺：增强可视性合理估计，减少遗留问题人员培养：培养scrum master、引入持续集成等实践改变组织：分解项目管理职能、转变团队结构敏捷大会内容诺基亚-西门子QQ团队怎样做敏捷尝试呢？6 1. 总结教训和过程，不断完善 2.选取适合的实践，深化实施 3.大团队，小规模 ，化整为零 4. 技术改造，控制整体流程，保

3、证执行 我们曾经的设想与尝试789建立以PM为主导，包含产品、设计、前后台开发和测试的feature team，快速进行产品迭代开发通讯录Feature teamGUIFeature teamEmailFeature team无线 Feature team日历 feature teamserverClient产品UI交互测试QAFeature TeamVoIP feature team评审组体验设计评审组技术架构评审组App feature TeamBasic IM最早的Feature Team设想我们现在的方案1011组织结构和项目结构12研发模型图示1、产品规划2、业务发展2、用户反馈3、

4、领导意见产品需求池需求评审需求需求开发功能测试QQ版本规划合入当前开发版本每周需求Review需求短线版本1短线版本2长线版本13 以需求为中心，整合产品、开发、测试等资源版本节奏：一个季度一个大版本，两个小版本，基本保证一个月一个版本，每个季度初PM确定各个版本的发布时间。每个版本初始阶段都可以看作一个空箱子，随着需求的不断开发、合入，逐渐形成各个版本的Featurelist。需求管理：需求的收集放入日常工作中由产品统一管理和规划，并输出到TAPD需求池需求的合入：需求合入前需要通过合入申请，进入系统测试前都可以申请，如果没有评估通过，那么放入下一个版本中。研发流程需求为中心研发模式流程示意

5、图14高层、团队、市场、运营需求评审会待开发的需求List（创意、业务、运营反馈.）最高优先级需求产品负责人按小组划分各小组迭代特性List各开发团队进行需求开发最大的问题是什么？15整合、分解、再整合161717（人员上）化整为零，（版本需求上）聚沙成塔”。 hummer架构的特点，实现了每个FT可以独立负责一个大功能模块 每个FT都有自己的开发、产品、测试，形成小的项目团队组织架构标识虚拟团队构成，营造成员归属感； 小团队独立运作，灵活敏捷Feature Team介绍（1）1818团队特点Team测试Leader成员1负责人UI测试研发管理团队建设业务驱动SERVER总监PM成员2产品产品

6、leader成员3技术LeaderFeature产品其它 设计测试 开发 建立以产品特性为核心的自 转型团队包括产品、开发、测试等角 色的完整团队角色分工，但不明确的团体性职责团队负责人，承担对外接口、团队建设与考核等驱动工作Feature Team介绍（2）低耦合的模块架构-QQ项目敏捷开发的基石19 全新的架构设计：支持良好的扩容性和可维护性； 组件化IM基础功能模块：代码耦合度低，模块间的依赖性小， 插件化业务模块：降低业务和QQ的耦合度，自升级、自维护，满足业务需求的快速滚动应用层IM层内核层VAS 协议、网络、文件系统 独立的增值业务模块 登录、聊天、群、分组 传文件、表情、通讯录2

7、0多流开发-QQ项目敏捷开发的支柱20当前开发流特性开发流合入主线申请分流测试验证每周Rebase对独立的特性建立单独的开发子流每个DE有1-n条开发流保持一个主流，并规定时间窗发布完成单元测试的开发子流，合入主线随时间窗版本发布多流开发全新的协作模式21多流模式给开发团队带来的好处： 多流支持多版本并行开发，满足产品的多版本规划 产品功能、业务模块可以独立开发，满足业务部门需求的快速滚动 适当规避风险，项目的节奏更可控 开发任务间相互依赖性小、程序设计耦合度低，降低代码占用的冲突， 提高开发资源利用率TAPD-QQ团队敏捷开发的助力2223对外发布形式灰度发布的补充博客版本关键技术或产品体验的小范围尝试试用版本版本发布前的用户试用，收集问题，覆盖式测试小版本开发周期在一个月左右，功能相互独立的（主要是业务支持），一般不动app和底层大版本开发周期在1季度左右，为满足较大功能或重构的版本，涉及app和底层修改回顾24 1. 总结教训和过程，不断完善 2.选取适合的实践，深化实施 3.大团队，小规模 ，化整为零 4. 技术改造，控制整体