04.与敏捷相关.md
敏捷是 一系列 价值观、方法、手段、实践、技术、框架的归类的总称。
敏捷是一类具有相似价值观和原则的软件开发方法的统称
初次诞生于2001-02-11～13
以人为本、目标导向、合作共赢、拥抱变化
敏捷12原则
# 精益思想
50～80年代丰田的准时生产制度
90年代的精益管理
现代的精益思想：精益生产、设计、服务。
# 五大原则
价值：由客户决定，满足客户需求才有存在的意义。
价值流：按照最终客户立场寻找整体最佳的活动。原材料到成品的价值赋予过程，就是做什么样的东西。
流动：生产强调的是创造出来的价值能够流动起来。
拉动：按用户需求拉动生产，而不是强推产品给客户去适应和使用。
尽善尽美：用同等的价值创造过程为用户提供同等的价值。
这是一种意识上的改革：流水线生产，细流而快、粗流而慢。木桶的短板效应。决定生产效率的不是最快的员工，而是最慢的员工。
# 看板
可视化卡片，明确工作事项、工作量、执行人、审查人。
至少三列，要完成的工作、进行中的工作、已完成的工作。
看板适用于：
灵活性：排列优先级
专注于持续交付
提高工作效率和质量
提高效率：方便检查每个任务
团队成员专注力
工作负载的可变性：有卡片就清楚的知道哪些当前可做。
减少浪费：卡片提供了透明化。
# 框架
Scrum
# Scrum 3355
3种角色：PO、SM、开发团队
3种工件：产品待办事项列表、迭代待办事项列表、产品增量与集成
5种仪式：迭代、迭代计划、每日站会、评审会议、迭代回顾
5种价值观：承诺、专注、开放、尊重、勇气
流程：
- 客户、市场、高层等 提供创意、缺陷、功能等给PO，由PO创建产品待办事项列表。
- 然后再迭代计划会议上通过讨论来创建 迭代待办事项列表，有了迭代任务列表后，开始2到6周的迭代任务，之后会每天开展站立会，在迭代过程中SM会将产品的功能细化。
- 最后迭代结束的时候，向用户提供可工作的软件，同时根据该功能软件和迭代过程遇到的事情来开展评审会和反思会。
Scrumban
敏捷看板，将工作，分为很多小的冲刺，通过看板的可视化来监督工作。
# 极限编程 XP
特定最佳实践提炼到最纯粹和最简单的形式, 周期内持续运用该实践。 基于频繁交付周期的软件开发方法 5种价值观：沟通、简洁、反馈、勇气、尊重。 主要原则：人性化、经济、互惠互利、自相似、改进、多样性、反思、流程、机会、冗余、失败、质量、循序渐进、承担责任
组织：集中办公
技术：结对编程、测试驱动编程、增量。
规划：用户故事、周周期、季周期
整合：快速构建、持续集成、测试优先。
提倡 测试驱动开发、多次集成反复回归测试、多做代码评审以及结对编程。
XP 1～2周 且非常严格，Scrum 2～4周 相对宽松的自主意识。
敏捷前期可以XP，后面在Scrum。这样的按需融合很不错。
12个实践
完整团队：整个团队参与，墙壁会有图表显示进度。
计划游戏：可持续的，循序渐进。每两周就评估一下下两周的候选任务成本，有客户来确认功能优先级。
客户测试：客户通过脚本语言来自动验收。
简单设计：良好的设计，少些冗余的代码。
结对编程：两个程序员一台机器。
测试驱动开发：先错再对，根据反馈来循环。
改进设计：重构，代码干净，更有表达力。
持续集成：保持系统的完整性，不断的集成。
集体代码所有权：每个人都可以参与任何模块的开发。
编码标准：所有人的代码看起来像是同一个人写的。
系统隐喻：系统中的模块与其它模块外观一致，无论是代码层面还是UI层面。
可持续的速度：不是非常拼命的工作，而是像马拉松一样的可持续性的工作。
# 水晶方法 Crystal
方法论家族：红、橙、黄、透明的不同家族。
根据错误引发的后果来确定项目中的重要性：C D E L
原则：
频繁交付、反思改进、个人安全、渗透式沟通、焦点、与专家用户建立方便的联系、配有自动测试。
和前两种框架一样，但水晶和XP很像，XP的纪律性很高，但水晶是尽可能用最少的纪律来让项目成功。
# 其它方法
FDD 功能驱动开发：6个角色，每个人可以担任一个或者多个。
项目经理 首席架构师 开发经理
首席编程人员 类负责人 领域专家
目的是满足大型项目的特定需求。它有重视小型商业价值功能的能力，也就是小的功能用它就很便捷，几个人或者一个人就干完了。
DSDM 动态系统开发方法：制约因素驱动交付。一开始就设置成本、质量、实践，利用范围优先级来满足这些制约因素的要求。动态的地方是 成本和功能是可以相互调整的。在有限的条件下调整，并做出可交付的功能。
8个原则：专注于业务需求、准时加皮肤、写作、在质量上不妥协、增量式构建、迭代开发、持续明晰的沟通、演示控制。
AgileUp 敏捷统一过程：加速周期、轻量。在交付之前能够纳入相关反馈。
SoS：Scrum of Scrums，多敏捷团队。多团队会定期召开会议，目标是清楚团队协调工作中潜在的未来障碍，优化团队效率。
适用于 大规律敏捷框架 SAFe、大规模敏捷开发 LeSS、企业 SCRUM、规范敏捷 DA。
# 方法和技术
# 仆人式领导
为团队赋权，注重理解和关注成员的需要和发展，从而实现最高绩效。
与团队定义 为什么，在项目层面进行优化。确立目标后，鼓励团队，要求他们在工作中做出贡献。注重结果而不是完美的去遵循敏捷过程，常常能交付且反思产品和过程。
管理协调 转向 促进合作
消除组织障碍，文档、过程。
为他人贡献铺路
教育相关方，使其了解为什么要敏捷以及如何敏捷。
通过指导、鼓励和帮助 来为团队提供支持。
通过技术项目管理活动 来帮助团队。
庆祝团队的成功。
与业务代表（PO）开展合作
# 其它
敏捷团队
敏捷团队角色
MVP最小可行产品
消除任何非增值工作
尊重人
使用信息发射源来确保工作的透明化，比如直接发聊天记录的链接。
文档够用即可，多提供有价值的产品，而不是详尽的文档。
社会契约：团队章程和工作协议
# 通才型专家
I 型人才：领域内非常专业，领域外少有贡献。有深度无广度。
T 型人才：能力强且专业会沟通。
许多成功的敏捷团队都由通才型专家组成。
# 敏捷宣言
客户协作高于合同协商
动态特性的合同签署技术：
多层结构
强调价值交付
总价增量
固定时间和材料
累进的时间和材料
提前取消方案
动态范围方案
团队扩充
支持全方位供应商
# 章程
项目上和团队上的章程。
敏捷项目上：
项目愿景：为什么要做，谁受益，如何受益。
发布标准：满足哪些条件才意味着项目完成。
预期的工作流：怎样合作。
敏捷团队上：
团队价值观：可持续的开发速度和核心工作时间。
工作协议：准备就绪、完成的如何定义，通过定义这些协议，团队成员才能一直的判断完整性。从而能够考虑时间周期和工作过程中的限制。
基本规则：会议上发言的各种规定
团队规范：会议时间等
敏捷团队中形成的默契就是敏捷团队章程。
目标创建一个敏捷的环境，在这个环境中，团队成员发挥他们最大的能力。
回顾：用于团队学习、改进和调整其过程。哪些做的好，哪些需要改进，哪些需要研究。
待办事项列表：根据发布的主要内容，先以故事形式来创建，后根据故事来创建足够下一个迭代完成的项目任务。PO会制作产品路线图，用于显示可交付成果的序列。
每日站会：在站会中汇报并做出小的承诺，发现问题，并确保工作能够顺利进行下去。就是大致过一下任务，昨天做了啥，今天准备做啥，有遇到啥阻塞。而且任何人都可以主持站会。站会不要太久，一般15分钟即可，不忽视其他人。
展示和评审：以用户故事的方式完成特定功能后，会定期展示工作产品。让PO来确定是否接受，有了展示和频繁发布，团队的学习速度会比那的快起来。
敏捷回顾会议参与人：可以是 PO、SM、团队成员、客户、利益相关人、专家、领导层、任何感兴趣的人。
规划基于迭代的敏捷：多次规划、注意意外情况、PO拆分故事使其变小、根据团队来考虑故事的大小。
迭代会议：会议目的、参会者、时间、持续时间、会议准备、产物(迭代待办事项)。
用户故事：角色、功能、价值。作为 某某，我想要 什么样的功能，以便于 能够带来什么样的价值。
用户故事地图：由众多用户故事连起来的业务流程及时间线。
层级：史诗 > 主题 > 用户故事 > 任务。
层次与时间的对应：大于一个版本，以月来算 > 大于一个冲刺，以周来算 > 一个冲刺，以天来算 > 一个任务，以小时来算。
故事优先级 MoSCoW
莫斯科法则
M：必须
S：应该有
C：可以有
W：不会有
卡诺KANO模型
对用户需求进行分类和优先级排序
分析用户需求对用户满意度的影响
该模型反应产品各个属性和用户满意度之间的非线性关系。
估算 故事点 Story Point：测量单元。
取决于复杂性、投入量、风险大小。
相对估算：通过比较来估算。
【@NOTE】 扑克估算：斐波那契额数列，有点玄学。
燃尽图：剩余的故事点的二维坐标趋势图，下降趋势。
燃起图：已完成的故事点的二维坐标趋势图，上升趋势。
燃尽图如果不是下降趋势，那么说明需求梳理的不是很清楚。
先确定真正可用的研发时间，再请团队根据这个时间来倒推范围。
可以使用燃尽图来跟进并发现风险。发现较大偏差，即使分析根本原因。比如通过 TAPD（腾讯敏捷协作平台）的“历史记录” 或者 Lark 飞书文档上任务表格的 历史记录 发现协作问题。形成解决问题的行动项，并且跟进行动项执行。
突发事件的应对：如有风险，先告知所有干系人，比如发风险报告。评估影响，并应对。
Mike Cohn的 Risk-value矩阵
先处理高价值和高风险的，低价值高风险的事情不建议做。
非得失败，应该在早期失败，而不是花费更多的资源后再失败。
# 总结
因地制宜，多丰富自己的知识库。对于高风险项目，识别主要挑战，针对性管理。时间紧迫的项目，用简单、轻量、团队好理解的框架和流程，降低实践导入过程和管理过程中的成本。