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.

Scrum敏捷开发模型

468 vues

Publié le

Scrum敏捷开发模型

Publié dans : Ingénierie
  • Soyez le premier à commenter

Scrum敏捷开发模型

  1. 1. SCRUM敏捷开发模型 Tony Deng https://twitter.com/wolfdeng https://delicious.com/wolf.deng https://friendfeed.com/tonydeng https://tonydeng.github.io
  2. 2. 互联⺴⽹网公司项⺫⽬目的特点 • 项⺫⽬目类型多样: • 新产品开发 • 运营维护(产品微创新/技术微创新,短平快的⼩小项⺫⽬目) • 新平台开发/架构升级/算法 • 产品效果很难预测 • 市场 • 竞争对⼿手 • 产品的功能和体验 • 团队⾃自⼰己看着办 • 跨团队/部⻔门合作频繁 • ⽼老板半夜给产品经理打电话
  3. 3. 项⺫⽬目是神⻢马? • 做项⺫⽬目就是组织⼀一些⼈人,为实现既定的⺫⽬目 标,在指定时间内、在有限的⼈人⼒力资源和⾮非 ⼈人⼒力资源约束条件下进⾏行的⼀一项独特的⼀一次 性⼯工作。
  4. 4. 项⺫⽬目中的质量和成本的关系 如果关注质量,那⻓长期来看质 量会提升,成本会降低 如果关注成本,那⻓长期来看成 本会提升,质量会降低
  5. 5. 我们到底需要什么的管理和流程?
  6. 6. ⽆无流程—反复⽆无常 • 三边 • ⼝口头需求 • 管理者随时随地的提出需求/变更 • 产品经理没有想清楚就找开发⼈人员编程 • ⽆无纪律的程序员 • 直接在⽣生产环境修改代码、编译和部署 • 源码⺫⽬目录结构混乱 • 不遵循规范/⾃自测不主动 • 混乱流程 • 测试拿到了错误的版本 • 产品经理需求变更随意
  7. 7. 强流程—例⾏行公事 • ⾯面⾯面俱到的⽂文档 • 过度的设计 • 会议多,效率低 • ⾼高强度的加班 • ⽤用流程管理团队,⼤大量的规范和标准 • 很多⼈人遵循规范,但不知道规范后⾯面的道理 • 产品质量完全是由测试来保障
  8. 8. 现状:复杂系统理论 分歧 ⼀一致 确定 变化 复杂程度评估模型 “当⼀一个流程运作的底层机制⽐比较容易 理解时,采⽤用定义好的(理论的)模型 ⽅方法是⽐比较典型的。当流程对定义好的 ⽅方法来说过于复杂的时候,基于经验主 义的⽅方法会是⼀一个明智的选择。” — B.A.Ogunnaike;W.H.Ray《过程动态学,建模和 控制》 互联⺴⽹网的项⺫⽬目变化是常态
  9. 9. 常⻅见基于经验的项⺫⽬目评估场景 By 《神秘的程序员》 这个场景中⼤大家都 只是基于⾃自⼰己的经 验,来对当前项⺫⽬目 进⾏行评估。 差异太大
  10. 10. 只基于⾃自⼰己经验的评估会带来 什么后果? • 员⼯工疯狂加班,⽼老板觉得没有产出 • 团队成员互相埋怨 • 各个部⻔门之间⽆无法正常配合 • 错过市场,错过时间 • …… • 总⽽而⾔言之,不可控
  11. 11. 真正的“经验主义” • “经验主义”这⼀一词指通过观察,经验和实验来 获得信息。 • 经验主义流程控制应该是基于持续不断的循 环,来检查流程是否准确的运转,并按照需 要调整适应。 • 经验主义流程控制的三⼤大⽀支柱:透明性、检 查、适应。
  12. 12. SCRUM基本流程 http://blogs.msdn.com/b/nickmalik/archive/2013/06/11/placing- architecture-properly-into-scrum-processes.aspx
  13. 13. SCRUM的本意
  14. 14. SCRUM⾓角⾊色与职责 • Scrum Master • 负责确保⼤大家遵守Scrum的价值、实践和规则;帮助团队实施Scrum。Scrum Master并不对团 队进⾏行管理。 • Product Owner • 管理Product Backlog、确保团队⼯工作价值的唯⼀一责任⼈人。他负责维护Product Backlog,确保每 个成员明晰列表内容、明确哪些条⺫⽬目具有最⾼高优先级,从⽽而了解下个需要开发的条⺫⽬目。 • PO是⼀一个⼈人,⽽而不是⼀一个产品委员会。可能会有⼀一些⼈人向PO提出建议或影响他的决策,但 要改变某条⺫⽬目的优先级必须先说服PO。 • Team Members • 由开发⼈人员组成的Scrumt团队负责在每⼀一个迭代周期将⼀一定量的开发任务完成。团队同时也 是跨职能的;团队成员必须具备完成开发任务所需要的技能,5到9个⼈人被公认为是“最佳的” 团队构成⼈人数。
  15. 15. PRODUCT BACKLOG • Product Backlog是Scrum的核⼼心,也是⼀一切的起 源。 • 从根本来说,Product Backlog就是⼀一个需求、 或故事、或特性等组成的列表,按照重要性 的基本进⾏行了排序。
  16. 16. PRODUCT BACKLOG⽰示例 ID Name Imp(重要性) Est(初始估算) How to demo(如何做演 ⽰示或验收) Notes 1 存款 30 5 登录,打开存款 界⾯面,存⼊入10元 钱,转到我的账 户余额界⾯面,检 查我的余额,增 加了10元钱 需要UML时序 图。⺫⽬目前不考虑 加密的问题。 2 查看⾃自⼰己的交易 明细 10 8 登录,点击“交 易”,存⼊入⼀一笔 款项。返回交易 ⻚页⾯面,看到新的 存款显⽰示再⻚页⾯面 上 使⽤用分⻚页技术避 免⼤大规模的数据 库查询。和查看 ⽤用户列表的规则 相似。
  17. 17. PRODUCT BACKLOG中的关键 字段 • ID—统⼀一的标识符,也就是个⾃自增⻓长的数字⽽而已,以防重命名故事以后找不到它们。 • Name(名称)—简短的、描述性的故事名。⽐比如“查看你⾃自⼰己的交易明细”。它必须含义明确,这 样整个团队才能⼤大致明⽩白我们说的是什么东⻄西,跟其他故事区分开。⼀一般由2到10个字组成。 • Importance(重要性)— 产品负责⼈人评出⼀一个数值,指⽰示这个故事有多重要。例如10或150。 分数越⾼高越重要 • Initial estimate(初始估算)—团队的初步估算,表⽰示与其他故事相⽐比,完成该故事所需要的⼯工作 量。最⼩小的单位是故事点(story point),⼀一般⼤大致相当于⼀一个“理想的⼈人/天”。不需要保证绝对 的准确⽆无误,⽽而是要保证相对的正确性(即,两个点的故事说花费的时间应该是四个点的故事 说需要的⼀一半) • How To demo(如何做演⽰示)—它⼤大概描述了这个故事应该如何在sprint review会议中如何进 ⾏行演⽰示,本质就是⼀一个简单的测试规范。“先这样做,然后那样做,就应该得到……的结果” • Notes(注解)—相关信息、解释说明和对其它资料的引⽤用等等。⼀一般都很简短。
  18. 18. PRODUCT BACKLOG三元素 Scope(范围) Estimate(估算) Importance(重要性) 范围和重要性由产品负责⼈人(PO)设置,估算由团队设置。
  19. 19. SPRINT计划会议 • Sprint计划会议应该算是Scrum中最重要的活 动。要是它执⾏行的不好,整个Sprint甚⾄至都会 被毁掉。 • Sprint计划会议的⺫⽬目的,是为了让团队获得⾜足 够的信息,能够在这次Sprint期间不受干扰的 ⼯工作,也是让PO负责⼈人能对此有充分的信⼼心
  20. 20. SPRINT计划会议 • Sprint计划会议详细的讨论了如何能够按照需求完成这些⼩小功 能模块,与会的成员有:Scrum Master、Product Owner、 Team • 在会议中⼤大家要确定Sprint的周期,即⼀一次迭代开发时间所执 ⾏行的任务(建议第⼀一次接触Scrum的团队采⽤用两周为⼀一个迭代 周期⽐比较合适);该会议还要为发布和演⽰示估算时间并排列 Sprint任务列表。 • “完成发布”的定义是:功能⾄至少拥有整洁的代码,经过重 构,进⾏行了单元测试,通过构建,完成验收测试。
  21. 21. SPRINT计划会议注意事项 • Produc Owner • 会议前确保Product Backlog准备好 • 所有重要的backlog都已经根据重要性做过评分 • 给team讲解各个backlog,保证⼤大家都能明⽩白backlog想要做的事情 • Scrum Master • 组织⼤大家正常的按照Scrum的⽅方式来参加会议 • Team • 对每⼀一个backlog进⾏行故事点(story point)的估算 • 确定团队成员名单及投⼊入度(如果不能100%投⼊入的话) • 确定本次sprint backlog(即本次sprint包含的product backlog) • 确定sprint的⺫⽬目标 • 确定好本次sprint演⽰示⽇日期
  22. 22. 每⽇日⽴立会 • 每⽇日⽴立会是Scrum的⼀一个⾮非常重要的实践⽅方法。Scrum的所有成员都需要参 与。 • 每个团队成员只可以向其他⼈人汇报三件事情,并且只能是这三件事情。 • 从上次会议之后完成了哪些⼯工作 • 在下次会议之前准备完成哪些⼯工作 • 在⼯工作中存在哪些的障碍 • Scrum Master将障碍记下来,会后协助团队成员铲除障碍;如需要讨论, 会后进⾏行 • 团队在⽴立会的时候更新backlog的状态,并更新燃尽图。
  23. 23. SPRINT评审 • 评审时团队在此期间展⽰示他们所构造的产品。 Product Owner、Scrum Master、ScrumTeam都要 出席,当然任何对此感兴趣的⼈人都可以参加。 • 会议的⺫⽬目的只是对这个Sprint⼯工作结果的展⽰示和 听取反馈。
  24. 24. SPRINT REVIEW • Sprint Review是Scrum中第⼆二重要的事件(最重要的是sprint计划 会议),因为这是做改进的最佳时机 • 在Review会上,每个⼈人都可以贡献和讨论想法 • 讨论的内容主要三项: • 爽:如果我们可以重做同⼀一个sprint,哪些做法是可以保持。 • 不爽:如果我们可以重做同⼀一个sprint,哪些做法需要改变。 • 改进:有关将来如何改进的具体想法。
  25. 25. Q & A

×