大型项目的敏捷项目管理探索详解.ppt

大型项目的敏捷项目管理探索 — 即通研发管理组 Eagleluo * 敏捷大会感受 * * 1. 业界在敏捷方面已经在前面跑了 2.路已经有人走了 ，我们可以借鉴 3.敏捷管理不可复制，需要自己找寻 4.增强我们继续探索的信心 Agile is nothing special 不是发明，而是发现 聪明的人做正确的事 程序员修炼之道，不变的规则 破窗理论：Fix problems as soon as they occur DRY原则：Don’t Repeat Yourself 如何变得敏捷 工具：故事墙、度量 管理：经理融入团队、充分授权 人：技能提升、更多地学习 如何推行敏捷 从一个团队开始 搞定高层和底层 敏捷大会内容——大师的话 * Do One Thing Well…（Dave Thomas） 从试点到推广 容易产生的障碍 过度承诺：导致不可持续的速度、忽视学习 人的惰性：导致精细管理、过多控制 专业化：导致单一职能，效率重于价值 部分完成：迭代结束时牺牲质量或功能不全 缺少自动化测试：导致独立的测试团队，非跨职能 跨越障碍 合理承诺：增强可视性合理估计，减少遗留问题 人员培养：培养scrum master、引入持续集成等实践 改变组织：分解项目管理职能、转变团队结构 敏捷大会内容——诺基亚-西门子 QQ团队怎样做敏捷尝试呢？ * 1. 总结教训和过程，不断完善 2.选取适合的实践，深化实施 3.大团队，小规模 ，化整为零 4. 技术改造，控制整体流程，保证执行 我们曾经的设想与尝试 * * * 建立以PM为主导，包含产品、设计、前后台开发和测试的feature team，快速进行产品迭代开发 通讯录 Feature team GUI Feature team Email Feature team 无线 Feature team 日历 feature team server Client 产品 UI 交互 测试 QA Feature Team VoIP feature team 评审组 体验设计 评审组 技术架构 评审组 App feature Team …… Basic IM 最早的Feature Team设想 我们现在的方案 * * 组织结构和项目结构 * 研发模型图示 1、产品规划 2、业务发展 2、用户反馈 3、领导意见 产品需求池 需求评审 需求 需求开发 功能测试 QQ版本规划 合入当前开发版本 每周需求 Review 需求 短线版本1 短线版本2 长线版本 * 以需求为中心，整合产品、开发、测试等资源 版本节奏： 一个季度一个大版本，两个小版本，基本保证一个月一个版本，每个季度初PM确定各个版本的发布时间。 每个版本初始阶段都可以看作一个空箱子，随着需求的不断开发、合入，逐渐形成各个版本的Featurelist。 需求管理： 需求的收集放入日常工作中 由产品统一管理和规划，并输出到TAPD需求池 需求的合入：需求合入前需要通过合入申请，进入系统测试前都可以申请，如果没有评估通过，那么放入下一个版本中。 研发流程——需求为中心 研发模式——流程示意图 * 高层、团队、 市场、运营 需求评审会 待开发的需求List （创意、业务、运营反馈….） 最高优先级需求 产品负责人 按小组划分 各小组迭代 特性List 各开发团队进行需求开发 最大的问题是什么？ * 整合、分解、再整合 * * * （人员上）化整为零， （版本需求上）聚沙成塔”。 hummer架构的特点，实现了每个FT可以独立负责一个大功能模块 每个FT都有自己的开发、产品、测试，形成小的项目团队 组织架构标识虚拟团队构成，营造成员归属感； 小团队独立运作，灵活敏捷 Feature Team介绍（1） * * 团队特点 Team 测试Leader 成员1 负责人 UI 测试 研发管理 团队建设 业务驱动 SERVER 总监 PM 成员2 产品 产品leader 成员3 技术Leader Feature 产品 其它 设计 测试 开发 建立以产品特性为核心的自 转型团队 包括产品、开发、测试等角 色的完整团队 角色分工，但不明确的团体性职责 团队负责人，承担对外接口、团队建设与考核等驱动工作 Feature Team介绍（2） 低耦合的模块架构-QQ项目敏捷开发的基石 * 全新的架构设计：支持良好的扩容性和可维护性； 组件化IM基础功能模块：代码耦合度低，模块间的依赖性小， 插件化业务模块：降低业务和QQ的耦合度，自升级、自维护，满足业务需求的快速滚动 应用层 IM层 内核层 VAS 协议、网络、文件系统