读书笔记：《Scrum 敏捷软件开发》

Posted 2022-05-31 Rolei_zl

《Scrum 敏捷软件开发》 美 科恩 著

Scrum是一种项目管理框架，大量的实现细节需要团队自行完成
测量（减少不确定性）、回顾（持续改进）、前瞻（确认最有价值的功能）；评估、承诺
这是一本关于 如何实施敏捷，以及敏捷实施过程中问题建议的书。
实施敏捷：生产力提升，成本降低，很高的客户满意度，更透明的开发过程，更高的预测能力。 -- 是不是有点吹牛，传统的项目同样可以做到
敏捷心态：如果它不完美，就精益求精 -- 持续改进同样在每个项目中存在
敏捷转型的能力：学习新技术、技能，以团队方式思考和工作，短时间实现最有价值的功能、交付潜在可以工作的软件，共享信息
敏捷：答案并非非此即彼 -- 敏捷并没有告诉你必须怎么做，而是给你提醒要注意什么、做什么，怎么做、如何做在动态动改变和接受。
Scrum Master：团队领导者（服务型，servant-leader），对流程有控制权，帮助团队学会使用Scrum，保证团队一起顺利工作，有效向目标前进，提供指导而非答案 -- 正确做事
自组织团队：学会忍住不说，让团队自己处理问题并做出决定。Scrum没有具体的实践工程，相信团队可以解决问题，交付高质量、潜在可工作的软件，团队为产品所有方面负责
Product Owner：确认正确的目标，确认做什么，确认优先级，确认愿景，确认边界 -- 做正确的事
-- 敏捷将传统的PM职责分解到Scrum Master、Product Owner等多个角色中，完成项目实施过程中的过程管理、监控、需求确认的工作
重构：改变代码结构而非行为 -- 不是实现新的功能 或 原有功能的重新实现？
迭代、增量，不做大型设计，有意、有计划的设计 -- 小步快跑
特性团队：公共功能；组件团队：特殊用途或个例功能；按职能或功能组建、切分团队
团队正确的人：专业技能、平衡技术水平等级、平衡领域知识、多样性、持久性
推动团队朝着更敏捷的方向前进
不需要除去所有文档，不需要一份完美的需求描述，尽量消除不需要的文档；保留文档尽可能简短，考虑自动生成文档；采用不同的精度、粒度，不断细化 -- 没有完美的文档，但有不同形式详尽的记录；产生恰到好处的文档，最终目标是改进构建软件
创造需求，让涌现的需求更早发现，持续提练需求：对项目有帮助的事，创造有价值的事；保持节奏，总在做最重要的事情
可工作的软件：既定功能完成，潜在的可发布软件（可以选择是否发布）
做计划：非一步到位，而是逐步完善，做最有价值的功能 -- 做计划，书中说的有意思
敏捷中的估算：估算不等于承诺 -- 承诺 = 估算 + 冗余/问题/风险，给出范围而非绝对值，保留置信区间
测试不是验证的步骤，而是提高质量的一种方式；在流程中、产品制造过程中构建质量，质量会对成本和生产率产生影响
敏捷中的自动化测试是针对验收测试进行的 -- 自动化不只是测试用例执行的工具，还包括过程管理工具，性能、安全测试工具，单元测试工具等
会议：会议将所有干系人的目标、行动统一在一起；每日站会是一个沟通、同步工作状态的会议；Scrum of Scrums是解决问题的会议

---

愿意改变是一种优势，即使这意味着某段时间会使公司的某个部分陷入混乱。
团队成员是工作的主体；团队成员：怀疑者，破坏者，追随者，顽固份子
清楚的知道在哪里结束，知道到达终点的具体步骤
ADAPT：意识Awaeness，渴望Desire，能力Ability，推广Promotion，传递Transfer
Scrum实施模式：start-small小团队试点；all in全面转型
Scrum Master品质：负责，谦逊，投入，有影 响力，知识渊博
Product Owner品质：始终都在Available，懂业务Business-survy，善于沟通Communication，果断Dcisive，得到授权Empowered
关注当前开发内容，避免关注其它sprint细节
每个Sprint中花时间准备下个Sprint；Epic（史诗级用户故事）与Theme（用户故事主题），层层分解；当完成当前Sprint的同时思考接下来的Sprint
需求：处理文档描述出来的需求 与 客户要求的需求的一致性；充分理解而非完全理解
确保系统所有代码被测试
开发人员共同负责开发过程中的所有产出，维护和修改自己和其他人的代码，不断学习和交叉培训
实时的状态反馈，可以分拆主流程和全流程，以便更有针对性的执行代码检查（主流程，全流程） -- 充分利用可以利用的时间复盖必要的产品测试
用更低的成本适应客户需要，发布时包含更多的商业价值 -- 价值不仅对客户，同时也对开发团队本身
如何将个体组织为团队：规模、领域、沟通渠道、技术、经验、环境、市场、期望；保持小团队，交付端到端用户可见的功能，让既定工作快整完成，减少沟通成本 -- 5-9人
变革3步：破冰、转变、固化，创建一个合理分工的环境（容器），并根据变化做出调整，有效的交流、传递能量
增量：以功能为单位，逐一开发形成最终系统（分段调用）；迭代：每次交付一个可用的系统，不断补充细节（重做调度）-- 迭代、增量是为了得到反馈，调整构建和方法
全局观，彼此了解和补位，减少交接成本，最大减少顺序工作的怠工 -- 是否存在瞎忙的状态？
计划：早期，抓住将要交付内容的要素，将细节放到以后考虑，不断增加必要的细节（有足够的知识支撑细节时），为变更及不确定性预留空间，保持可持续的步伐、固定的节奏
技术债：代码不成熟 或 不太正确导致的成本增加
实践社区：专项技能团队，促进组织间技术交流和沟通
分布式团队：沟通、协调；共同愿景、产品愿景、共识、信任、团队文化、规则、工作关系、习惯、做事方式；将关系建立在基于具体协作任务之上，发现彼此优势、技能、态度
分布式团队需要更多的书面记录：代替面对面沟通，同时解决语言、习惯、理解上的差异

---

• Brooks定律
  Brooks法则是指一种实践，应用全面、严密的方法来描述组织之流程、信息系统、人员和组织子单元的当前或未来结构，以便其与组织的核心目标和战略方向保持一致。
  向进度落后的项目中增加人手，只会使项目更加落后。为推迟的软件增加人力将使得软件时间发布更晚。 这是因为后来者需要加快速度，同时还要与前任进行沟通，从而使得开发团队增加了更多的开发时间，这个时间超过了新增程序员所做的贡献。从理论上说，软件发展陷入僵局是可能的，此时开发团队极其庞大，以致所有时间都来互相沟通和重新决定，这样项目永远也不会完成。 -- 百度百科
  新加入成员，沟通时间 与 项目贡献之间的关系 
• 柯维定律
  授权并信任才是有效的授权之道。权力要下放才行。一把抓的控制方式是一种错误，最好的控制来自人们的自治。 -- 百度百科
• 亚节律
  节律：指季节时令或某些物体运动的节奏和规律。
  亚节律？
• 计算机亚文化
  亚文化：集体文化或副文化，与方文化相对应的那些非主流的、局部的文化现象，指在主文化或综合文化的背景下，属于某一区域或某个集体所特有的观念和生活方式，一种亚文化不仅包含着与主文化相通的价值与观念，也有属于自己的独特的价值与观念。
  计算机亚文化？
• 沉默效应
  1. 在人际交往中，没有恰当的沉默，就没有良好的沟通；学会适时沉默，可以调节交流的节奏，从而更好地实现沟通的目的。
  2. 沉默代表冷暴力，习惯性的逃避消极的信息，封闭
• 平衡记分卡
  Balanced Score Card，从财务、客户、内部运营、学习与成长四个角度，将组织的战略落实为可操作的衡量指标和目标值的一种新型绩效管理体系。 -- 感觉很老了，以后再了解