敏捷
敏捷
敏捷宣言及思维模式
敏捷宣言（4条）：
个体以及互动 而不是 过程和工具
可用的软件 而不是 完整的文档
客户合作 而不是 合同谈判
应对变更 而不是 遵循计划
重点：重探索、重实践；轻文档、轻计划
敏捷的12大价值观（重点）：
尽早持续交付有价值的软件
欢迎提出变更
要交付可用的软件，周期越短越好
信息传达最有效的方法是面对面交谈
** 可用的软件是衡量进度的首要衡量标准 **
提倡可持续开发
简洁，减少浪费，精益
定期反省
重点关键字：** 关注价值、小批量、消除浪费 **
精益与看板方法
如何看待精益、敏捷、看板方法三者之间的关系：
敏捷和看板方法是精益思想的衍生物。精益思想是一个超集，与敏捷和看板方法拥有共性。
共性在于：** 交付价值、尊重人、减少浪费、透明化、适应变更、持续改善。 **
不确定性、风险和生命周期选择
迭代和增量方法，应用了：
非常短的反馈循环
频繁调整过程
重新进行优先级排序
定期更新计划
频繁交付
敏捷生命周期
预测型
迭代型（变更频繁、复杂度高）
增量型（频繁少量交付）
敏捷型
基于迭代的敏捷（考试默认）：timebox固定
基于流程的敏捷
混合敏捷方法
Scrum框架
看板方法（流程可视化）：工作流可视化，障碍易被察觉，通过在制品限制WIP来实现流程管理
极限编程XP（注重效率和质量）
故事卡：什么角色，需要什么功能，实现什么目的
持续集成
重构：之前的临时解决方案，存在隐患，需要被重新解决（技术债务）
自动化测试：开发好的功能快速发布
测试驱动开发：明确验收标准后再进行开发工作
Scrum框架
Scrum团队的三个角色
敏捷教练 Scrum Master（帮助产品开发团队学习、应用Scrum来达成商业价值，服务大家，解决工作中的障碍，对团队效能负责）
产品负责人 Product Owner （对产品相关的内容what，拥有决策权，例如：做什么，按照业务价值大小排优先级）
开发团队 Developers（决定开发方法how，负责DoD，对交付结果负责）
Scrum团队是自组织的，没有子团队或层次结构
Scrum团队是跨职能的，干活不求人，破梳子型通才
Scrum团队通常是10人以下，如果团队过大，可以考虑Scrum of Scrum
Scrum的三个工件
产品待办事项 Product Backlog（大需求池）
迭代待办事项 Sprint Backlog（小需求池）
增量 Increment
满足DoD的才可以被视为增量，增量必须是可用的
尽早完成增量，尽早展示，尽早获得反馈
如果有多个Scrum团队在同一产品上一起工作，必须一起遵守统一的DoD
Scrum的5个关键事件
迭代 Sprint（容器型事件，包含了以下4个事件）
迭代规划会 Sprint Planning （核心议题时下一次冲刺要实现的目标和范围）
为什么这次迭代有价值（why）
这次迭代能完成什么（what）
如何完成所选的工作（how）
每日站会 Daily Scrum
促进信息在团队内共享和透明（领导可参与，只倾听不干预）
①完成了什么工作；
②计划做什么；
③遇到什么问题；（记录问题到停车场区，会上不解决，额外安排解决）
迭代评审会 Sprint Review
向利益相关方展示工作结果，但是要避免会议仅限于展示
展示不要单向展示，** 要互动沟通，要获得反馈 **
产品负责人PO负责接受或拒绝用户故事
迭代回顾会 Sprint Retro
产品待办事项以外的变化要记录 （但是不确定优先级）
团队共同讨论和识别出最有用的改变
隐藏款： 产品细化会/产品精化会/产品研讨会/产品梳理会（通常在精化会后可以列出符合DoR的产品待办事项条目）
如果迭代目标Sprint Goal 已经过时，迭代可以取消，只有PO有取消迭代的权力。
用户故事从大到小：史诗＞特征＞用户故事＞任务
在团队需要学习一些关键技术或者功能要素时，可以考虑刺探Spike，来用于方法探索（可以多种方案齐头并进测试）
敏捷发布计划
定愿景 → 形成产品路线图（分几步走） → 发布计划（路线图+多长时间完成）
Scrum价值观
承诺、专注、开放、尊重、勇气
仆人式领导
仆人式领导是一种为团队赋权的方法。
鼓励团队创造一个人人都能成功的环境
仆人式领导通过管理关系，在团队内和组织中建立沟通与协作，有助于消除障碍，促进团队理顺过程。
仆人式领导的工作重点，从“管理协调”转向“促进合作”，帮助每个人各尽所能地思考和工作。
仆人式领导通过成为公正的搭桥者和教练来促进大家协作，不是替代他人做出决策。
仆人式领导还应该关注冗长的过程
仆人式领导的职责示例：
教育相关方了解敏捷、如何敏捷
通过知道、鼓励和帮助为团队提供支持（培养和发展团队成员，帮助他们超越自身角色，即使失去他们也在所不惜）
通过技术项目管理活动来帮助团队（量化风险分析、提供培训、开展活动……）
庆祝团队的成功，创造相互欣赏的积极氛围，建立加强合作的良好意愿。
敏捷团队
最有效的敏捷团队，往往在3~9个人。 团队成员100%是专职成员 。（任务切换会损失效率）
敏捷角色：
跨职能 团队成员
产品负责人
团队促进者（敏捷教练、项目经理、Scrum主管……）
团队工作场所：开放式办公区（渗透沟通）、洞穴
分散式团队的管理沟通的技术：鱼缸窗口、远程结对
敏捷团队需要 团队章程， 包含了团队价值观、工作协议、基本规则、团队规范
敏捷项目的衡量指标
团队预测完成或使用【 交通灯状态 （红黄绿）】来描述项目的能力
预测型衡量指标的问题在于：他们往往不反映真实的情况。（注意内红外绿的 西瓜项目 ）
敏捷团队倾向于使用基于经验和价值的衡量指标，而不是预测型指标
敏捷是基于对客户有可见价值的工作产品（可用性）
敏捷工具和技术
燃尽图/燃起图
速度：本次迭代中实际完成功能的故事点大小总和
不同团队速度不具有可比性
** 团队衡量速度时，一定要确认故事已完成可用，要衡量已完成的工作 **
燃起图可以看得出变更，燃尽图看不出变更
看板（流程可视化）
基于流程的敏捷团队使用的衡量指标：交付周期、周期时间、响应时间
交付周期 ：交付一个工作项目花费的总时间
周期时间 ：处理一个工作项目所需的时间（通过衡量周期时间，发现瓶颈和延迟问题）
响应时间 ：一个工作项目等待工作开始的时间
在制品限制WIP：达到在制品限制WIP后，团队不能将工作从左边提取到下一列
蜂拥模式：工作存在瓶颈时，团队成员一起解决问题
功能图
挣值分析
累积流图（把看板变成图）
