Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

精益产品开发实例

514 vues

Publié le

介绍一个产品设计开发团队如何综合应用 看板方法,精益创业,实例化需求等实践,改善产品的定义及团队的协作,实现交付效率、质量和客户满意度的同步大幅提升。摆脱曾经的被动局面,在激烈的云计算基础实施产品市场竞争中取得突破性的增长和盈利。

你将了解到:
看板方法的实施和演进
实例化需求的有效实施
如何做到自动化功能测试和代码的同步交付
对团队自组织的理解
未来的计划

Publié dans : Logiciels
  • Soyez le premier à commenter

精益产品开发实例

  1. 1. 爱数 AnyShare 精益研 发体系建设 何勉 张震 hemian@agilean.cn zhang.zhen@eisoo.com
  2. 2. 基于云盘体验的企业级⽂文档共享平台AnyShare 私有云存储 群组作 诉Ta 安全管理云盘体验 ⾼高效分享 Plugin 平台可运营 可视化运营管理; 分布式与分层部署; 多组织单元与分层管理; 权责可分离 三员管理(三权分⽴立); ⾮非法内容管控; 系统可整合 统⼀一⾝身份认证; 多层次整合; ⾃自助式OEM; 桌⾯面虚拟化整合; 江北教育局 13000⽤用户 南宁公安局 8000⽤用户 ⻄西安电⼦子科技⼤大学 5000⽤用户
  3. 3. 分享内容 ⼀一.看板⽅方法实施 ⼆二.⾃自动化测试和ATDD 三.⾃自组织团队的建设 层次化的⾃自 动测试 组件化和服务 化架构 以看板⽅方法整合开发过程 并 指导团队持续改进 持续集成 持续交付 快速探索客户需求和商 业模式 并 以业务⺫⽬目标未导向规划 需求 研发团队:29⼈人 开发19,测试10 开发测试融合,两个虚拟⼩小组 精益创业 ATDD开发过程 精益产品开发体系 产品团队:6⼈人
  4. 4. ⼀一. 看板⽅方法实施
  5. 5. 顺畅,⾼高质量地交付价值
  6. 6. 第 3 步 建⽴立反馈和度量体系 指导深层次和系统的改进 第 2 步 限制在制品数量 加速流动、暴露问题、激发协作 第 1 步 端到端地可视产品开发过程 建⽴立团队协作和改进的基线
  7. 7. 第 3 步 建⽴立反馈和度量体系 指导深层次和系统的改进 第 2 步 限制在制品数量 加速流动、暴露问题、激发协作 第 1 步 端到端地可视产品开发过程 建⽴立团队协作和改进的基线
  8. 8. 后端团队看板 前端团队看板
  9. 9. If you can't describe what you are doing as a process, you don't know what you're doing. 如果你不能以⼀一个清晰的过程来展⽰示你所从事 的⼯工作,你就不会真正的了解你在做什么。  —质量管理之⽗父 戴明
  10. 10. 后端模块 前端模块 ⾃自动测试任务 开发任务 bug 故事 ⽤用户需求
  11. 11. 需求从产品设计到交付的过程 需求的分解和合并, 团队成员间的合作 问题和阻碍 需求流转的规则 看板是否如实和全⾯面地反映了需求交付过程? 团队成员是否能根据看板上的信息⾃自主做决定? ⽇日常的问题是否能在看板上得到即时体现? ⾃自我检查列表
  12. 12. 第 3 步 建⽴立反馈和度量体系 指导深层次和系统的改进 第 2 步 限制在制品数量 加速流动、暴露问题、激发协作 第 1 步 端到端地可视产品开发过程 建⽴立团队协作和改进的基线
  13. 13. 平均求交付时间 = 每周需求交付的个数 同时开发测试的需求的数⺫⽬目 平均求交付时间 = 4(个/周) 20(个) = 5周 平均求交付时间 = 4(个/周) 10(个) = 2.5周
  14. 14. 束⽔水攻沙 明朝治理⻩黄河的⽔水利专家 被誉为“千古治⻩黄第⼀一⼈人” 潘季驯
  15. 15. 需求流动速度快,则能即时发现和解决问题 反之:需求积压,问题也会隐藏和累积 急则沙随⽔水流 缓则⽔水漫沙停 —— 潘季驯
  16. 16. 反例:未产⽣生作⽤用的约束 需求过⼤大,⻓长期不 动,隐藏问题 需求在测试阶段累 积
  17. 17. 所设置的约束是否减少了整个系统的在制品? 在制品的约束是否能让问题即时暴露? 在制品的约束是否激发团队协作和解决问题?⾃自我检查列表
  18. 18. 第 3 步 建⽴立反馈和度量体系 指导深层次和系统的改进 第 2 步 限制在制品数量 加速流动、暴露问题、激发协作 第 1 步 端到端地可视产品开发过程 建⽴立团队协作和改进的基线
  19. 19. 顺畅,⾼高质量地交付价值 ? ?
  20. 20. 顺畅? 离群点(特殊原因) 异常点(共同原因分析)
  21. 21. 期望看到控制图 原因分析
  22. 22. 业务⻛风险 关联⻛风险 技术⻛风险 资源⻛风险
  23. 23. ⾼高质量?
  24. 24. 流程操作 基础环境 代码、架构 ⼈人员技能
  25. 25. 数据和反馈能够即时地获取? 数据是不是能够⽅方便、低成本的获取? 是否便于统计分析,以发现系统性原因?
  26. 26. 第 3 步 建⽴立反馈和度量体系 指导深层次和系统的改进 第 2 步 限制在制品数量 加速流动、暴露问题、激发协作 第 1 步 端到端地可视产品开发过程 建⽴立团队协作和改进的基线 ⼤大道不过三两⾏行 说穿不值⼀一⽂文钱
  27. 27. ⼆二.⾃自动化测试和ATDD
  28. 28. 单元测试 组件接⼝口测试 系统 测试 单元测试 组件接⼝口测试 系统 测试 理想的测试⾦金字塔 我们是测试圣诞树
  29. 29. 组件化,服务化的架构 全覆盖的有效接⼝口测试 测试需求同步 测试开发同步 把可测性作为架构和接⼝口 设计的约束 良好的测试设计规范 + + + +
  30. 30. 32 实例化需求 概念填空 例⼦子 需求 测试 澄清 成为 验证
  31. 31. 需求例⼦子 测试 (⾃自动化) 澄清 成 为 验 证
  32. 32. 输出 2:需求表格 实例化需求的输出 输出 1: ⽤用户使⽤用⼯工作流(场景) 需求例⼦子 澄清
  33. 33. 测试即需求 脚本即代码 做好⾃自动化测试的15条原则 原则 11: 把测试当作需求的第⼆二⾯面 原则 12: ⽤用例⾸首先是给⼈人阅读的 原则 13: 象对待代码⼀一样对待脚本 原则 14: 统⼀一管理⼿手⼯工和⾃自动测试 原则 15: 拥抱开源 原则6: 把环境及配置从脚本中分离出来 原则7: 明确的setup和teardown 原则8: 尽可能使⽤用三层模型 原则9: 在⽤用户⼯工作流中使⽤用三阶段模式 原则10: 最⼩小化和稳定化依赖 原则1: 把测试锚定到需求上 原则2: 在测试集上描述需求 原则3: 每个测试⽤用例验证且只验证⼀一个概念 原则4: 测试⽤用例的名称应该清晰的表达其⺫⽬目的 原则5: 测试⽤用例之间的不要相互依赖 Enviroment Libs Test TestSuite +Document +tags -setup() -teardown() TestCase +document +tags +bissiness ruler -setup() -tearDown() 0..* TestRun +tags HighLeveLlib <<keyword>> LowLevelLib <<keywords>> run Env +variables UserFlow <<keyword>> TechActivities <<keyword>> use 关注1 关注2.1 关注2.2 关注2.3 关注3 include include 可执⾏行需求 分离关注点 测试集的组织 测试脚本的编写 测试活动的管理
  34. 34. 三.团队的⾃自组织
  35. 35. empowerment = f ( Authority, Resource, Information, Accountability ) 信任 资源 信息 责任感
  36. 36. 信息 Information 责任感 Accountability 资源 Resource ⽇日常操作 团队协作 系统状况 业务情况 能⼒力 培训 ⼯工具 时间 预算 改进机会 即时看到⾏行动的结果 信任 Authority 促进 建⽴立结果和利益的关联 形成团队的共同⺫⽬目标 环境 指导 有能⼒力采取⾏行动 知道何时采取⾏行动 ⺫⽬目标驱动 的团队⾃自 组织 促进 促进
  37. 37. 1 2 3团队有效协作, 基本顺畅⾼高质量交付价值 ⾯面向⺫⽬目标的⾃自我组织 持续改善 业务和研发⽆无缝协作 共同持续探索和创新
  38. 38. Thanks!

×