Scrum 敏捷项目管理

Scrum    敏捷项目管理 ScrumMaster    保证Scrum流程顺利执行 Product Manager 负责产品质量，保证项目预期价值 Group    Scrum项目实现团队，具有完全自主性 Product Backlog 产品完成log Sprint    30天计划 Sprint 评审 审查上一sprint中完成的可交付产品 Sprint Backlog Sprint周期需完成log Daily Scrum （全天工作的第一件事）   1.自上次的Daily Scrum后我做了什么？ 2.现在到下次Daily Scrum我准备做什么？ 3.在工作中遇到了什么困难？ 戴明循环  一种全面质量管理方法，P、D、C、A分别是英语Plan（计划）、Do（实施）、Check（检查）、 Action（处置）的缩写。经过计划、实施、检查、处置四阶段构成一个循环。每经一次循环，解决一批质量问题，使产品质量和工作质量达到一个新的水平，然后再进入下一循环。戴明循环既是一个循序渐进的流程，也是一个反复的过程和可量化的过程。 生鱼片规则 Sprint审核时演示的潜在可交付产品功能的每一个增量都必须是完整的，包括分析、设计、编程、文档编制及任何合乎应用软件要求的步骤。即每个增量由经过完整测试和文档描述的潜在可交付功能组成。   如果30天内无法将Idea转换成具备商业模式及可操作性的项目， 如果2个月内无法找到团队核心并组成初创团队， 如果3个月内你的Idea还没被团队充分理解并预期付诸实践， 如果6个月内你还在筹划半年前的那个Idea， 这个Idea已经过时勒，请下一个，这里是互联网！ 更迅捷的项目管理， 更快速的项目决断， 更舒适的用户体验， 更早地实现Idea， 好与不好交由公众来评断， 不要闭门造车以为一切尽在掌握。 — Reinhardt 项目的开始至完成绝不可能是一帆风顺的过程，即使完美主义者也会不可避免地遭遇挑战，”自上而下”或”自下而上”的过程都有其无可掩盖的缺点，只有不断在实践中迭代前进，才能一步步接近真相。 — Reinhardt 项目自始至终周期过长，会造成心理放松，对于项目危机感缺失，以至于造成前期浪费时间，后期加班赶时间的窘相。所以我们需要通过不断地迭代，在一次次循环中完成可交付的增量，基于事实的决策远比前端预测型决策更为有效。 — Reinhardt    Scrum有3种职能者：ScrumMaster，Product Manager，Team，相互之间不渗透，各司其职。ScurmMaster负责Scrum流程顺利完成，即迭代地不断进行，Product Manager根据产品需求及市场预期制定产品Backlog，Team在自发性驱使下完成Sprint。通常过程中，30天为一个迭代周期，称之为Sprint，流程如下： Scrum Start -> Sprint 计划会议（第一部分分析Product Backlog，第二部分解答产品Backlog，并制定Sprint Backlog） –> Sprint 迭代开始 –> Daily Scrum（Sprint 迭代）–> Sprint 评审会议（展示，提问，调整）–> Sprint 评审会议（团队总结，调整）–> Sprint 迭代结束 –> Scrum End 图：Product Backlog 图：Task Board Product Backlog: 是否代表所有利益相关者的最近需求，提醒大家关注最近的将来（利益相关者：投资方，团队，目标用户） Sprint Backlog: Sprint迭代周期内，团队需要完成的项目细则，并确保Sprint周期结束后，项目的潜在可交付性 Scrum计划过程涉及3个问题的解答： 1 项目投资人希望项目结束时能取得哪些成果？ 2 每个Sprint应作出哪些进展？ 3 如何使项目投资人相信该项目是有价值的投资，以及项目申报者有能力交付预期收益？ 4 计划的目的之一是说服投资者为项目注资 Daily Scrum（全天工作的第一件事）： 5 自上次的Daily Scrum后我做了什么？ 6 现在到下次Daily Scrum我准备做什么？ 7 在工作中遇到了什么困难？ Scrum基本原理： 8 Scrum是经验型方法，是”可能性的艺术“ 9 Scrum使得所有事项充分可见，使“秘密交易”最小化 10 Scrum的运作基础是个人和团队的承诺，而非严密的规划及控制。相对于强行控制计划，其忠诚度、自组织和员工责任感是更为有效的机制 11 团队成员只有事先集体负责，承诺在固定时间内交付实际产品后，才算真正掌握Scrum ScrumMaster ScrumManager主要职责: 12 ScrumMaster与传统项目经理区别：从传统的控制者到引导者的转变 13 ScrumMaster需要对团队作出承诺，让团队感受到有人全心全意关注其工作，在任何情况下提供保护和援助。 14 ScrumMaster使团队在Sprint过程中免受干预 15 产品负责人谈论业务需求和目标，团队则讲技术。由于产品负责人很难掌握技术，ScrumMaster的主要职责之一就是教会团队谈论商业需求和目标。团队与产品负责人之间的公分母是产品Backlog ScrumMaster职责： 16 排除产品开发和负责人之间的障碍，确保产品负责人直接推动开发工作 17 教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标 18 激发创造力和放权，从而改善开发团队的环境 19 千方百计提高开发团队的生产力 20 改善工程实践和工具，确保每个功能增量都具备潜在可交付性 21 向各方确保团队工作进展实时更新并高度可视 Scrum高效率探究 限期30天Sprint的固有压力，团队成员表示“需有所付出”的相互承诺，自组织原则及跨职能责任，有助于团队成功履行职责承诺机制条理化，增加相互责任心，团队凝聚效应 “限定时间”可向团队灌输“可能”的艺术，避免过分追求完美 “增量交货”的举措改进工程实践 “放权”和“自组织”能够激发创造力，提升员工满意度 (*****) 当人们不能聚在一起面对面交流时，往往会将自己的问题抛给他人 (****) 预估的目的是为了解每个需求自身及相对于其他需求的规模。该信息有助于划分产品Backlog的优先等级，并将之分入各个Sprint Scrum运行无需过于宽泛的计划，但需足以引导Scrum的经验性过程的检查与适应循环，若成本/收益及假设性数据引导适应环境更有意义地展开，项目必可收益 团队 团队从被管理到自我管理的转变十分困难，但在生产力和工作愉悦度方面的回报显著 在我们的生活和工作经历中，受他人管理的习惯根深蒂固。 Scrum真理：成功的开发需要不断检查和调整 本质：内心深处，认为自己应在一开始便完美安排各事项，确保计划得以严格实施。需要适应调整时，责备自己为实现妥善安排全部事项。从开始就预知结果的人不会存在。 (**) 总体度量，即在最合适的日期交付最佳、最优质的系统。实施其余度量法时应保持谨慎，确保其支持总量度量，避免削弱其效果。我们在设计度量系统时应考虑人类固有的、为取悦他人不计后果的欲望。（e.g. 代码量不应作为绩效考核标准） (***) 团队通常难以用产品负责人能理解的语言与之交流，若产品负责人只谈商业，团队只谈技术，双方无法交流，也就没有协作 Scrum报告 每个Sprint结束时还需产生正式报告 Scrum报告： 22 第一份列出上一次Sprint开始时的产品Backlog 23 第二份为新Sprint开始时的产品Backlog 24 第三份是“变更报告”，详细列出前两份报告的差别 25 第四份为产品Backlog的“剩余时间报告”（Burndown Report） 变更报告总结以下内容： 26 Sprint中发生及Sprint审核的情况 27 项目针对Sprint审核结果所做的适应调整 28 未来Sprint重构的原因 29 发布日期或内容重新制定的原因 30 为何团队在Sprint中完成的需求量比预期少 31 在产品Backlog中，未完成工作的优先等级重排情况如何 32 团队为何比预期生产率高（低） 不使用术语，却教会管理层使用Scrum，属于只是一种表现形式。（e.g. Ajax = 无页面刷新） Scrum扩展项目 Scrum of Scrums Scrum实践扩展成功的关键： 33 在扩展前构建必须的基础设施（构建扩展基础设施的非功能性需求必须在扩展开始前完成） 34 建构基础设施的同时确保交付商业价值 35 优化原始团队的能力，向其余团队分派至少一名初始团队成员 项目扩展为多个团队的产品Backlog中应加入以下非功能性需求： 36 分解业务结构以支持整洁界面的多团队开发 37 分解系统结构以支持整洁界面的多团队开发 38 必要时，定义并实施特定开发环境，支持多团队并置或分布的环境 e.g. 曳光弹：射击者摸黑开冲锋枪时难以瞄准，若每50发子弹中有一颗曳光弹，便可看清方向，调整瞄准。（指明团队方向，冲破迷雾）  e.g. 马克吐温曾说：“没有东西比绞索更易让人集中精神。”（增加紧迫感，提高效率） e.g. “癫狂愚顽”：反复做同样的事情，却期待不同的结果。在预定义方法在项目管理中失败时，人们通常将原因归结于未能严格执行预定义方法。断定项目成功的关键在于加强控制和项目定义。（不断重复地用失败的方法华丽地完成另一次更大的失败