如何实施 SCRUM

Posted 2023-04-09

步骤1）明确定义.

[Agile Development]

    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法.

[Scrum]

     Scrum是一种实现敏捷开发的一个方法论, 它包含了一系列实践和预定角色的过程框架.

[Sprint]

    迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，每一次任务周期(迭代)都可以生产或开发出一个可以交付的软件产品版本.

步骤2)明确职责.

A)ProductOwner的职责

1.创建产品愿景，对产品的ROI负责。
2.定义产品特性，梳理产品列表，确定产品功能。
3.参与规划活动
4.确定特性优先级，定义接收标准并验证工作成果
5.与开发团队合作
6.与利益干系人合作

B)ScrumMaster的主要职责.

1.敏捷团队教练，帮助团队完成目标

2.帮助团队最大化生产力

3.提高团队工作效率，利用技术手段

4.帮助团队协作
5.保证Scrum推行

C)Team的主要职责.

主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

步骤3)实施Scrum.

sprint迭代周期示意图

Scrum的预定角色和标准过程

需要了解更多scrum的具体信息，可以看下这里:快速了解什么是敏捷开发，什么是Scrum? 怎么实施Scru

参考技术A 一、敏捷管理理论
1、敏捷管理的定义
敏捷即灵活性，是动态的、适应于具体情况、迎合变化和自我完善的。敏捷项目管理是应对经常变化的、具有不确定性的软件项目的管理方法。敏捷是一种态度而不是一个流程，是一种氛围而不是方法。敏捷项目管理中最重要的一个术语就是创新。实施敏捷项目管理过程中项目管理者要注意：调整团队自身来适应变化，致力于产品，和客户进行协调，注重沟通。
2、敏捷管理的开发方法
常见的敏捷软件方法包括：Crystal、ASD（AdaptiveSoftwareDevelopment）、Scrum、FDD（FeatureDrivenDevelopment）、XP（ExtremeProgramming）、RUP（RationalunifiedProcess）等，它们都具有强调灵活、阶段迭代、反馈和逐步逼近目标的特性，本文中将重点介绍Scrum方法。
二、Scrum开发方法
Scrum（英式橄榄球争球队），软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。正如Schwaber所言，Scrumisanagile，lightweightprocessthatcanbeusedtomanageandcontrolsoftwareandproductdevelopmentusingiterative，incrementalpractices。Scrum将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝目标有明确的推进。
1、Scrum方法的原理
（1）Scrumteam。指整个项目小组，不仅仅包括全职开发人员，也包括了发行软件会影响到的外部人员，比如市场营销人员和顾客。
（2）Backlog。Backlog是一种任务列表，包括ProductBacklog和SprintBacklog两种，是指导Scrum开发方向的指针。SprintBacklog是一个Scrum团队计划将要在当前Sprint中完成的所有功能列表。SprintBacklog实际上是ProductBacklog的一个子集，在ProductBacklog的纲要性指导下，SprintBacklog不断发展并且充实整个项目的ProductBacklog，使之趋于完善。比如：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。
（3）Sprint（冲刺）。Scrum开发过程由一系列迭代的Sprint过程组成，一个Sprint过程就是一个冲刺过程，多个Sprint过程顺序进行，直至风险评估认为产品可交付为止。一个sprint是在限定时间段内的一系列开发活动，包括分析、设计、编码、测试等。通常为30天的迭代时间，把Backlog中的每一项安排在Sprint中，由团队估算出所需要的时间（按小时记）。每一次Sprint之后，一定要有可以交付使用的功能。每一次Sprint之后要回顾，团队按照既定的SprintBacklog目标来演示完成的内容。
（4）Scrummeeting。Scrummeeting是Scrum中项目管理的有效手段，分为两种：Sprintmeeting和Dailymeeting。Sprintmeeting是在下一个Sprint开始之前，即在当前sprint即将结束之时举行的，Sprintmeeting讨论并决定下一个sprint的sprintBacklog，会议举行的时间周期随Sprint的周期而定。本回答被提问者采纳

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

《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，从财务、客户、内部运营、学习与成长四个角度，将组织的战略落实为可操作的衡量指标和目标值的一种新型绩效管理体系。 -- 感觉很老了，以后再了解