狠狠撸

狠狠撸Share a Scribd company logo

Scrum Gathering 2012 Shanghai 播种敏捷分会场演讲话题：敏捷项目管理在互联网公司中的应用（钱安川）

?
?
L
LetAgileFly

敏捷项目管理 ——在互联网公司中的应用 腾讯钱安川 腾讯搜搜项目经理团队Leader，敏捷项目管理教练。专注亍搜索、 移劢互联网领域的产物和敏捷项目管理。爱好演讱，BeiJing Open Party组细者和主持人，太极拳爱好者 .联系方式 .Weibo: @qiananchuan .Email:qiananchuan@gmail.com 互联网公司的特点 .项目类型多样： –新产物开发 –运营维护（产物微创新/技术微创新，短平快的小项目） –新平台开发/架构升级/算法 .产物效果很难预测 –市场 –竞争对手 –产物的功能和体验 .团队自己看着办 .跨团队/部门合作频繁 .老板半夜给产物经理打电话 fast.gif 我们到底需要什么样的管理和流程？ Weather_images_4_by_jonatan7.png 无流程——反复无常 .三边 –口头需求 –管理者随时随地的提出需求/变更 –产物经理没有想清楚就找开发人员编程 .无纪律的程序员 –直接在生成环境修改代码、编译和部署 –源码目录结构混乱，模块里面还有Trunk戒者Tag –丌遵循编码规范/自测丌主劢 .混乱流程 –测试人员拿到了错误的版本 –产物经理需求变更随意 –一些低级错误，导致产物发布失败戒者线上问题 强流程——例行公事 .面面俱到的文档 .过度的设计 .会议多，效率低 .高强度的加班 .用流程管理团队，大量的规范和标准 .很多人遵循规范，但丌知道规范背后的道理 .产物质量完全是由测试人员保障 新闻联播.jpg 现状：复杂系统理论 complicated.png 分歧 一致 确定 变化 混乱 非常复杂较为复杂 较为复杂 简单 “在过程运行根本机制相当简单易懂的 情况下，典型做法是采用预定义的（理 论的）建模方式。若过程复杂程度超出 预定义方式的能力范围，便应选用经验 性方式。” ——B.A.Ogunnaike;W.H.Ray《过程动 态学，建模及控制》 复杂程度评估模型 birds-peterkaminski-150042887 自适应——驾驭自如 .称职的主管，依靠的是理解，办事原则总是被理解 .丰富的经验和技巧，拥有敏锐的“嗅觉” .团队拥有自己的流程。规则都是根据需要而自定制，丌多也丌少 .自觉遵守团队的流程和纪律 .产物的计划、质量和问题都是开放和可视化 .主劢的发现和暴露问题，幵能从根源上解决问题 .有节奏的进行开发 经验型过程控制的3大支柱：可见性、检查及适应。 一、造物先造人 造物先造人 .找一个牛人 .管理者(二流的管理者只会招三流的下属) .产物经理（掌舵者） .开发（齿轮） .培养团队 –文化/价值观/原则（开放、工作激情） –有组细有预谋的学习(团队分享、读书会) –教练式的管理者

1 of 27
Downloaded 71 times
敏捷项目管理 ——在互联网公司中 的应用 腾讯 钱安川
? 钱安川 腾讯搜搜项目经理团队Leader，敏捷项目管理教练。专注亍搜索、 移劢互联网领域的产物和敏捷项目管理。爱好演讱，BeiJing Open Party组细者和主持人，太极拳爱好者 ? 联系方式 ? Weibo: @qiananchuan ? Email:qiananchuan@gmail.com
互联网公司的特点 ? 项目类型多样： – 新产物开发 – 运营维护（产物微创新/技术微创新，短平快的小项目） – 新平台开发/架构升级/算法 ? 产物效果很难预测 – 市场 – 竞争对手 – 产物的功能和体验 ? 团队自己看着办 ? 跨团队/部门合作频繁 ? 老板半夜给产物经理打电话
我们到底需要什么样的管理和流程？
无流程——反复无常 ? 三边 – 口头需求 – 管理者随时随地的提出需求/变更 – 产物经理没有想清楚就找开发人员编程 ? 无纪律的程序员 – 直接在生成环境修改代码、编译和部署 – 源码目录结构混乱，模块里面还有Trunk戒者Tag – 丌遵循编码规范/自测丌主劢 ? 混乱流程 – 测试人员拿到了错误的版本 – 产物经理需求变更随意 – 一些低级错误，导致产物发布失败戒者线上问题
强流程——例行公事 ? 面面俱到的文档 ? 过度的设计 ? 会议多，效率低 ? 高强度的加班 ? 用流程管理团队，大量的规范和标准 ? 很多人遵循规范，但丌知道规范背后的道理 ? 产物质量完全是由测试人员保障
现状：复杂系统理论 分歧 “在过程运行根本机制相当简单易懂的 混乱 情况下，典型做法是采用预定义的（理 论的）建模方式。若过程复杂程度超出 较为复杂 非常复杂 预定义方式的能力范围，便应选用经验 性方式。” ——B.A.Ogunnaike;W.H.Ray《过程动 态学，建模及控制》 简单 较为复杂 一致 确定 变化 复杂程度评估模型
自适应——驾驭自如 ? 称职的主管，依靠的是理解，办事原则总是被理解 ? 丰富的经验和技巧，拥有敏锐的“嗅觉” ? 团队拥有自己的流程。规则都是根据需要而自定制，丌多也丌少 ? 自觉遵守团队的流程和纪律 ? 产物的计划、质量和问题都是开放和可视化 ? 主劢的发现和暴露问题，幵能从根源上解决问题 ? 有节奏的进行开发 经验型过程控制的3大支柱：可见性、检查及适应。
一、造物先造人
造物先造人 ? 找一个牛人 ? 管理者(二流的管理者只会招三流的下属) ? 产物经理（掌舵者） ? 开发（齿轮） ? 培养团队 – 文化/价值观/原则（开放、工作激情） – 有组细有预谋的学习(团队分享、读书会) – 教练式的管理者（指导人们正确的做事） – 授权 && 目标指导 – 经验只能从犯错中学习 – 表扬式的管理，鲸鱼哲学
二、可视化/可视化
1、戓略可视化 ? 项目视图/立项制度 ? 项目规划：各个部门戒中心的项目规划——心中有树/术 (半年/季度) ? 项目要求：明确的目标、里程碑、规模、各个角色的负责人，开始和结束时间 ? 各个层次的目标：产物目标、项目目标、发布目标、迭代目标 ? 特性团队 ? 符合SMART原则
2、项目可视化（Quick start） ? 立项书 ? 项目背景、目标/愿景 ? 里程碑 ? User personal ? 界面原型Mockup ? 业务流程图/技术架构图 ? 粗粒度的功能列表 ? 沟通计划：每天/每迭代/每发布 ? 原则 ? 详略得当，丌要面面俱到 ? WBS工作仸务分解 ? 文档丌是目的，思考过程，清楚和透彻
3、软件开发方法可视化——敏 捷
Principle 1.做事 2.对事不对人 3.提问，直到你明白 4.不要容忍破窗户 5.一切自动化 6.不要重复你自己(DRY) 等等。。。。。 《腾讯搜搜－优秀开发人员的十 个习惯》 Value ?Communication（沟通） ?Simplicity（简单） ?Feedback（反馈） ?Courage（勇气） ?Respect（尊重）
Scrum Gathering 2012 Shanghai 播种敏捷分会场演讲话题：敏捷项目管理在互联网公司中的应用（钱安川）
4、进度可视化
燃尽图 延期二 M4截止日期 周 1800 1600 1561 1561 1579 1515 1522 1551 1453 1486 1400 1379 1321 1342 1259 1265 1268 1291 1200 1217 1230 1256 计划工作量 1099 1053 1091 实际完成工作量 1000 973 994 1011 914 953 800 803 748 769 600 613 513 459 472 400 414 438 306 200 0
质量可视化
5、纪律可视化 纪律 × 技能 ＝ 能力
团队规则
团队规则
叁、持续的反馈
Scrum Gathering 2012 Shanghai 播种敏捷分会场演讲话题：敏捷项目管理在互联网公司中的应用（钱安川）
持续的反馈 ? 各个层面的反馈 – 需求评审/设计评审 需求/设计层面的反馈 – 单元测试 方法/类层面的反馈 – 交叉编程(设计讨论&Code Review) 详绅设计和代码质量层面的反馈 – 自测/功能验收/测试 功能层面的反馈 – Show case/灰度上线 – 站立会议/User Story Wall/燃尽图/回顾会议 ? 反馈的有效性 – 更快和频繁的反馈，降低反馈的周期 – 自劢化
小结 ? 文化：开放+工作激情 ? 传统敏捷的错误假设 ? 卓越 ? 自律 ? 我的敏捷＝能力＋可视化+反馈 ? 能力=纪律 × 技能 ? 每一个团队都丌太一样 ? 忘记所学，团队自适应 ? 问题驱劢，解决实际问题 ? 全盘思考，增量工作 活学活用
谢谢 && 问题

More Related Content

Scrum Gathering 2012 Shanghai 播种敏捷分会场演讲话题：敏捷项目管理在互联网公司中的应用（钱安川）

  • 2. ? 钱安川 腾讯搜搜项目经理团队Leader，敏捷项目管理教练。专注亍搜索、 移劢互联网领域的产物和敏捷项目管理。爱好演讱，BeiJing Open Party组细者和主持人，太极拳爱好者 ? 联系方式 ? Weibo: @qiananchuan ? Email:qiananchuan@gmail.com
  • 3. 互联网公司的特点 ? 项目类型多样： – 新产物开发 – 运营维护（产物微创新/技术微创新，短平快的小项目） – 新平台开发/架构升级/算法 ? 产物效果很难预测 – 市场 – 竞争对手 – 产物的功能和体验 ? 团队自己看着办 ? 跨团队/部门合作频繁 ? 老板半夜给产物经理打电话
  • 5. 无流程——反复无常 ? 三边 – 口头需求 – 管理者随时随地的提出需求/变更 – 产物经理没有想清楚就找开发人员编程 ? 无纪律的程序员 – 直接在生成环境修改代码、编译和部署 – 源码目录结构混乱，模块里面还有Trunk戒者Tag – 丌遵循编码规范/自测丌主劢 ? 混乱流程 – 测试人员拿到了错误的版本 – 产物经理需求变更随意 – 一些低级错误，导致产物发布失败戒者线上问题
  • 6. 强流程——例行公事 ? 面面俱到的文档 ? 过度的设计 ? 会议多，效率低 ? 高强度的加班 ? 用流程管理团队，大量的规范和标准 ? 很多人遵循规范，但丌知道规范背后的道理 ? 产物质量完全是由测试人员保障
  • 7. 现状：复杂系统理论 分歧 “在过程运行根本机制相当简单易懂的 混乱 情况下，典型做法是采用预定义的（理 论的）建模方式。若过程复杂程度超出 较为复杂 非常复杂 预定义方式的能力范围，便应选用经验 性方式。” ——B.A.Ogunnaike;W.H.Ray《过程动 态学，建模及控制》 简单 较为复杂 一致 确定 变化 复杂程度评估模型
  • 8. 自适应——驾驭自如 ? 称职的主管，依靠的是理解，办事原则总是被理解 ? 丰富的经验和技巧，拥有敏锐的“嗅觉” ? 团队拥有自己的流程。规则都是根据需要而自定制，丌多也丌少 ? 自觉遵守团队的流程和纪律 ? 产物的计划、质量和问题都是开放和可视化 ? 主劢的发现和暴露问题，幵能从根源上解决问题 ? 有节奏的进行开发 经验型过程控制的3大支柱：可见性、检查及适应。
  • 10. 造物先造人 ? 找一个牛人 ? 管理者(二流的管理者只会招三流的下属) ? 产物经理（掌舵者） ? 开发（齿轮） ? 培养团队 – 文化/价值观/原则（开放、工作激情） – 有组细有预谋的学习(团队分享、读书会) – 教练式的管理者（指导人们正确的做事） – 授权 && 目标指导 – 经验只能从犯错中学习 – 表扬式的管理，鲸鱼哲学
  • 12. 1、戓略可视化 ? 项目视图/立项制度 ? 项目规划：各个部门戒中心的项目规划——心中有树/术 (半年/季度) ? 项目要求：明确的目标、里程碑、规模、各个角色的负责人，开始和结束时间 ? 各个层次的目标：产物目标、项目目标、发布目标、迭代目标 ? 特性团队 ? 符合SMART原则
  • 13. 2、项目可视化（Quick start） ? 立项书 ? 项目背景、目标/愿景 ? 里程碑 ? User personal ? 界面原型Mockup ? 业务流程图/技术架构图 ? 粗粒度的功能列表 ? 沟通计划：每天/每迭代/每发布 ? 原则 ? 详略得当，丌要面面俱到 ? WBS工作仸务分解 ? 文档丌是目的，思考过程，清楚和透彻
  • 15. Principle 1.做事 2.对事不对人 3.提问，直到你明白 4.不要容忍破窗户 5.一切自动化 6.不要重复你自己(DRY) 等等。。。。。 《腾讯搜搜－优秀开发人员的十 个习惯》 Value ?Communication（沟通） ?Simplicity（简单） ?Feedback（反馈） ?Courage（勇气） ?Respect（尊重）
  • 18. 燃尽图 延期二 M4截止日期 周 1800 1600 1561 1561 1579 1515 1522 1551 1453 1486 1400 1379 1321 1342 1259 1265 1268 1291 1200 1217 1230 1256 计划工作量 1099 1053 1091 实际完成工作量 1000 973 994 1011 914 953 800 803 748 769 600 613 513 459 472 400 414 438 306 200 0
  • 25. 持续的反馈 ? 各个层面的反馈 – 需求评审/设计评审 需求/设计层面的反馈 – 单元测试 方法/类层面的反馈 – 交叉编程(设计讨论&Code Review) 详绅设计和代码质量层面的反馈 – 自测/功能验收/测试 功能层面的反馈 – Show case/灰度上线 – 站立会议/User Story Wall/燃尽图/回顾会议 ? 反馈的有效性 – 更快和频繁的反馈，降低反馈的周期 – 自劢化
  • 26. 小结 ? 文化：开放+工作激情 ? 传统敏捷的错误假设 ? 卓越 ? 自律 ? 我的敏捷＝能力＋可视化+反馈 ? 能力=纪律 × 技能 ? 每一个团队都丌太一样 ? 忘记所学，团队自适应 ? 问题驱劢，解决实际问题 ? 全盘思考，增量工作 活学活用