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矩阵
先处理高价值和高风险的,低价值高风险的事情不建议做。
非得失败,应该在早期失败,而不是花费更多的资源后再失败。
# 总结
因地制宜,多丰富自己的知识库。对于高风险项目,识别主要挑战,针对性管理。时间紧迫的项目,用简单、轻量、团队好理解的框架和流程,降低实践导入过程和管理过程中的成本。