读书笔记：《Scrum实战 故事 模型与成功秘诀》

Posted 2022-01-03 Rolei_zl

《Scrum实践 故事 模型与成功秘诀 The Scrum Field Guide: Practical Advice for Your First Year》   Mitch Lacey 著   傅勃 译

-- 以实例（故事）讲述Scrum框架，所读有限的几本关于敏捷的书，讲的比较生动清楚的。文化和环境差异，有些方法仍需要在实际的实践中不断揣摩。

-- 个人理解的敏捷：
    > 小步快跑，小车不倒慢慢推；增量式的开发，不断的迭代开发、检查、反馈、修正，尽可能早的发现问题修改问题
    > 与其等到最后被客户逼着做变化，不如主动的让客户提出变化，逼着客户尽可能早的发现真正的需要，从彼此的沟通中快速反馈

• 敏捷核心：拥抱变化；信任、工作优先级；实施敏捷的目的：降低成本、减少风险、让员工高兴、让客户更满意、增强变化响应能力。
• Scrum，管理软件和产品开发的轻量级框架，解决复杂的适应在性，以高效生产力、创造性方式交付价值最大化的产品。
                特征：团队内外的反馈和透明；短周期、协同工作适用于快速变化或紧急需求项目。在尽可能短的周期内从不确定性变为确定性。
• Scrum 3 个角色：产品负责人（Product Owner，为团队掌舵使其基于业务价值朝着最佳方向前进，作为客户代表把愿景转换为团队可以执行的产品列表并且负责正在开发的产品或者服务的投资回报与商业价值）、Scrum Master（服务于团队，以非命令方式保持流程的顺畅，消除障碍、解决问题，报告团队行为表现，帮助团队分析和充分理解碰到的问题和系统）、Development Team（开发团队，核心团队）           
• Scrum 4 种会议：会议用来确定团队是否在正确轨道上前进的方法，注意控制会议的节奏和主题。计划会（Planning Meeting，优先级、速率、sprint长度，最好的和最坏的打算）、每日站会（Standup Meeting，已经完成什么、正在或计划做什么、出现什么问题和障碍）、Sprint审核会（Sprint Review Meeting，停下来看看项目是否在正确的轨道上，展示给客户的实质的、有价值的东西，得到客户反馈）、回顾会（Retrospective Meeting，检视过程、检视问题）
• Scrum 3 种工件：产品列表事项（Product Backlog / User Story）、Sprint列表（Sprint Backlog）、燃尽图（Burn-down Chart)
• Scrum基本价值观：专注、尊重、承诺、勇气、开放
• Scrum过程：速率、透明和真实、承诺、角色尽可量不重叠（角色冲突，平衡）
• Sprint：敏捷开发过程中具有固定节奏的迭代周期（合适的刺激-反应周期，与项目期限有关，最长4周），以计划会议开始，以潜在可交付产品的演示结束
• User Story（用户故事）：用户通常想做的最小动作或者具有商业价值的最小功能。分解用户故事生成有事点，即完成用户故事要完成的工作任务。兼顾大小与优先级。
   模版：作为一个<用户>，我能够<动作>，这样<结果>。
• 核心故事：整个功能，用户帮事，最小适销特性的功能集。
• DoD（Definition of Done，完成的定义）：建立明确的目标、建立密切的团队成员关系、提供清楚的交流方式降低风险、保持正确的方向和专注。针对发布质量的承诺，建立待完成事项目列表。
• TDD，测试驱动开发，以小周期来开发代码的软件设计技术
• Refactor，重构，不改变已有代码意图或者行为的情况下加强或改善其设计的行动。外部行为保持不变，但内部的东西更流畅。
• XP，极限编程：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）
• 每日站会（Standup Meeting）：做了什么、将做什么、用什么问题
• Scrum与传统项目管理的区别
  - 传统项目管理以关键路径（critical path），即最长路径为基础制定计划、进行变更；Scrum以Sprint为基础，通过短期目标不断调整，始终观注当前优先级最高的工作
  - 传统项目管理靠计划驱动；Scrum靠价值驱动
  - 传统项目在项目最后才安排一个阶段来写文档；Scrum在项目执行过程中不断的维护文档，实时更新以反映变化，将文档作为DoD的一部分进行定义。优秀的敏捷团队对文档是纪律严明的，在项目的每个阶段适量文档是很重要的，文档的写作完成取决于必要性、可变性与成本，只做需要的文档、不多做。将文档工作写入DoD。尽量压缩写、维护、返工和修改文档所花的时间，平衡功能的稳定性与变化性，平衡成本、变化性和风险。
• 团队发展的4个阶段：组建期、激荡期、规范期、执行期
• 团队4种基本工作类型：功能工作（任务时间）、额外工作（完成任务必要的辅助时间，如会议、审核）、试验工作（研究时间）、必要性工作（完成任务必须做的，如构建环境时间） -- 开发时间、非开发时间、研究时间、辅助开发时间 -- 让项目干系人清楚的看到时间是如何支配的、钱是如何花的
• 计划：先估算（经验或历史数据），然后在项目执行过程中用实际数据更新计划，不断调整

我们不能用产生问题时使用的思维方式来解决问题。-- 转换思维方式，解决现有的问题
事情在变好之前先变得更差。
从熟悉的状态以不熟悉的状记是一个艰难的过程，需要耐心和实践。
真相就是，当我们感到深深的不安、不快或者缺乏成就感的时候，我们最出彩的时刻最有可能到来。因为只有在这样的时候，受不安的驱使，我们才有可能走出困境，开始去寻找不同的道路或者真正的答案。--《少有人走的路》
团队是由人组成的而不是使用资源的集合组成的。 -- 人也是一种资源
我们常常会听从陌生人意见而相信他们说的话，却忽视我们认识的人所说的同样的话。
在投资还比较小的时候，失败得越早，总是胜于已经有巨大投资时晚到的失败。
具有巨大价值的事情总是需要花大量的时间。
保持专注、保持积极、保持顽强，这是一个充满挑战的过程。
团队的最佳大小由5到9个人组成。
Brooks定律：在已经延迟的项目中增加人手会使项目进一步延迟。
责任：在Scrum中，谁做工作谁就负责估算，谁做工作谁就做出承诺。
问题解决方案：历史数据、拍脑袋、走着瞧
培养客户，频繁反馈的重要性以及客户参与开发过程的必要性。更快发现潜在的风险。
分解任务是一种艺术，需要批判性思维、清醒的头脑以及透过现象看见本质的能力。
头脑风暴，问题的答案没有对错，没有批评，只有想法。
技术债、文化冲突
良好的工程实践把事情细分为一些更小的步骤，把问题出现到问题修改的时间间隔最小化。
核心时间就是大家对各自喜欢的工作时间和工作习惯所取得的共识。最大化这个核心时间。
速率，团队能够在一定时间之内完成多少工作的衡量。
所有敏捷实践都专注于尽早向客户交付价值。
只要有意义，就要做到质量高于一切。团队自始至终专注于质量。
会议，暴露问题，突出问题并处理问题。
团队成员应该专注于如何合力完成每个Sprint中选定的用户故事，而不是专注于某项专长工作。
选人：尽量避免被迫选入闲着没事干的人只因他们有空。强迫团队接受一个不能融入团队的人会带来灾难性的后果。
文化目标是所有人终其一生的需要与期望；制度化手段则是实现文化目标的种种手段。
团队应该能够控制自己的命运。
拒绝徘徊在过去，坚定地用正面积极的态度迎接未来。
以最小的浪费来做事，是有效率的；做正确的事，也是有效果的。
关注相对大小的估算而不是固定的小时数或者天数。
尽量压缩写、维护、返工和修改文档所花的时间。
为什么要写文档：文档是每个软件项目的一部分。人们总是忘记做过什么、什么时候做了什么决定以及为什么，及时记录；尽可能留住所有知识，为未来团队和项目提供软件发展史实。
外包业务：设置更强的纪律，频繁的检查点，更高的透明性，更多的敏捷实践，特定的工程实践与标准。
工作包：特定的功能或者一套功能集
找到项目干系人相关的用户故事并确保用户故事被完成。
客户期望：以最低成本、在最短时间 获得最多的功能与最好的质量
产品列表、交付时间、交付成本
信任是软件开发公司可以树立的最重要的东西。

• 调研合同：探索范围
• 鉴别用户类型
• 写用户故事
• 估用户故事
• 调研阶段：确定成本与时间表
• 确定团队的速率
• 计算每个Sprint的成本
• 制定发布计划
• 确定支付条款
• 项目合同：交付产品
• 变更