敏捷概述
背景
敏捷开发最早被提出应用于软件开发管理流程中。随着时代发展，软件规模和复杂度激增，需求变化加快，软件开发过程日益“重型化”，因此轻量级的，更能适应变化的敏捷软件开发方法被普遍认可并迅速发展流行。
敏捷宣言（原则）
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
认识敏捷
统一认识：敏捷=理念（敏捷核心思想）优秀实践（敏捷的经验积累）具体应用（结合自身，灵活应用）
理念
-
聚焦客户（视觉）价值（Value），消除浪费
- 部分完成但没最终落地的工作。
- 开发完成但没有被客户应用的特性。
- 人员流动导致经验不能累计，重复学习。
- 移交导致信息丢失。
- 任务切换（研究表明多任务工作会导致效率下降20%-40%）。
- 因任务或资源互相依赖而导致工作停滞。
- 缺陷，解决缺陷本身就是浪费，而且缺陷越遗留到后面浪费越大。
-
激发团队（Team）潜能，加强协作
-
激发团队
- 通过目标牵引团队自主工作
- 当团队自管理时效率最高
- 当团队成员不被打扰时，工作效率最高
- 当团队解决自我问题时，提升最快
- 团队成员共同参与计划制定、任务安排，关注团队目标、共担责任
- 人们对自己做出的承诺比别人要求的更认真
- 人们会尽力做到最好
- 在强大的压力下努力工作，会自然降低对质量的要求
-
沟通协作
- 广泛的面对面的交流是团队工作高效的方式
- 白板沟通 优于 电话沟通 优于 邮件沟通 优于 文档、录制的音视频
-
激发团队
-
不断调整以适应（Adapting）变化
-
适应变化
- 认清“客户是逐步发现真正的需求”。
- 小批量快速交付是关键。
- 通过迭代计划不断调整以适应需求变化
-
应持续保持良好的架构
- 良好的架构是适应变化的基石
- 软件开发特点是内容庞大、内容持续增长、持续周期长，因此需要良好的架构来保证长期的演进
- 优秀的架构通过可扩展性来很好的适应需求的变化，对敏捷起到支持作用，相反拙劣的架构会阻碍敏捷
- 良好架构有助于定制合适的增量开发/集成计划，使分层分级的可持续集成更加容易
- 架构需要尽早验证和持续维护
- 通过迭代来实现和验证架构，有利于架构的尽早稳定
- 特殊效果表现需识别影响架构的需求，优先实现，规避架构风险
- 通过重构及时维护和优化架构，使架构保持生命力
- 利用多层次的反馈不断调整以逼近目标
- 良好的架构是适应变化的基石
-
适应变化
实践
-
因地制宜选择合适的敏捷实践
-
敏捷团队(SCRUM)
-
产品负责人ProductOwner（PO）-产品经理/游戏策划/导演
-
负责产品，代表相关的利益
-
提供愿景
-
代表利益相关人（如观众、Marketing、管理者等），对产品投资回报负责
-
确定产品发布计划
-
定义产品并确定优先级
-
验收迭代结果.并根据验收结果和需求变化刷新需求清单和优先级
-
-
SCRUM主管Scrum Master（SM）：
-
确保Scurm正确使用和收益最大化，但是不做决定（不命令和控制Team）
-
辅导团队正确应用敏捷实践
-
引导团队建立并遵守規则
-
保护团队不受打扰
-
推动解决团队遇到的障碍
-
激励团队
-
-
开发团队（Team）：
-
负责自我管理开发产品的人组成的跨职能团队
-
负责估计工作量并根据自身能力找出最佳方案完成任务且保证交付质重
-
向OP和利益相关人演示工作成果
-
团队自我管理、持续改进
-
-
-
工作件
-
产品Backlog（需求清单）
- 什么是产品Backlog
- 经过优先级排序的动态刷新的产品需求清单，用来制定发布计划和迭代计划。
- 产品Blocklog的好处
- 通过需求的动态管理应对变化，避免浪费;
- 易于优先交付对用户价值高的需求。
- 产品Blocklog关键要点
- 清楚表述列表中每个需求任务对用户带来的价值，做为优先级排序的重要参考；
- 动态的需求管理而非"冻结"方式，PO持续地管理和及时刷新需求清单，在每轮迭代前，都要重新筛选出高优先级需求进入本轮迭代；
- 迭代的需求分析过程，而非一次性分析清楚所有需求（只对近期迭代要做的需求进行详细分析，其它需求停留在粗粒度）
- [图片上传失败...(image-e6b495-1543726686826)]
- 什么是产品Backlog
-
迭代Backlog
- 什么是迭代
- 迭代Backlog是团队在一轮迭代中的"任务"（Task）清单，是团队的详细迭代开发计划；
- 当团队接收从产品Blocklog挑选出要在本轮迭代实现的需求时，召开团队迭代计划会议，将需求转化为具体的"任务"；
- 每项任务信息包括当前剩余工作量和贲任人。
- 好处
- 将需求分解成更细小的任务，利于对迭代内进度进行精确控制；
- 剩余工作量可用来实时跟踪团队当前进展。
- 关键要点
- '任务"由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工作都可以列为任务；
- 任务要落实到具体的贲任人；
- 任务粒度要小，工作量大于两天的任务要进一步分解；
- 用小时做为任务剩余工作量的估计单位，并每日重估计和刷新。
- 什么是迭代
-
完成标准
- 什么的完成标准
- 基于"随时可向用户发布"的目标制定衡量团队工作是否已完成的标准，由团队和PO形成共识；
- 好处
- 共同协商的完成标准是团队的自我承诺，团队会更认真；
- 用于准确评估团队工作进展；
- 清晰和明确的完成标准保证了每次迭代是高质量的。
- 关键要点
- 团队自协商：团队根掮项目实际情况来定义完成标准，并严格遵守；
- 有层次：一般分为三个层次：Story级别，迭代级和发布级，每个级别都有各自的完成标准。
- 什么的完成标准
-
产品Backlog（需求清单）
-
管理实践
-
Sprint计划会议
- 什么是计划会议
- 每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品Backlog，输出是团队迭代Backlog
- 多团队迭代计划会议要分层召开
- 版本迭代计划会议：将产品Backlog (需求）分配给团队；
- 团队迭代计划会议：将选取的产品Backlog需求转换成迭代Backlog〔任务），分配给团队成员；
- 迭代计划会议内容：
- 澄清需求、对"完成标准"达成一致
- 工作量估计、根据团队能力确定本轮迭代交付内容；
- 细化、分配迭代任务和初始工作计划。
- [图片上传失败...(image-445853-1543726686826)]
- 好处
- 通过充分讨论，使团队成员对任务和完成标准理解一致；
- 团队共同参与，促进团队成员更认真对待自己的承偌。
- 要点
- 充分参与：SM确保PO和Team充分参与讨论，达成理解一致；
- 相互承诺：Team承诺完成迭代Backlog中的需求并这到"完成标准”，PO承诺在短迭代周期不增加需求〔2-4周）；
- 确定内部任务：Team和PO办商把一些内部任务放入迭代中（例如重构、持续集成环境搭建4等），由PO考虑并与其他外部需求一起排序。
- 什么是计划会议
-
每日站会
- 什么是站会
- 每日工作前，团队成员的例行沟通机制，由SM组织，Team成员全体站立参加
- 聚焦在下面的三个主题：
- 我昨天为本项目做了什么？
- 我计划今天为本项目做什么？
- 我需要什么帮助以更高效的工作？
- 好处
- 增加团队凝聚力，产生积极的工作氛围
- 及时黍露风险和问题；
- 促进团队内成员的沟通和协调。
- 要点
- 准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯；
- 高效会议：会议限时15分钟，每个人都保持站立，依次发言，不讨论与会议三个主题无关的事情〔如技术解决方案等）；
- 问题跟踪：SM应该记录下所有的问题并跟踪解决；
- 什么是站会
-
迭代验收（评审会议）
- 由SM组织，PO和用户代表（外部或内部利益相关人）负责验收、Team负责演示
-
回顾会议
- 什么是回顾会议
- 在每轮迭代结束后举行的会议，目的是分享好的经验和发现改逬点，促进团队不断进步；
- 围绕如下三个问题：
- 本次迭代有哪些做得好
- 本次迭代我们在哪些方面还能做得更好
- 我们在下次迭代准备在哪些方面改进？
- 好处
- 激励团队成员；
- 帮助团队挖掘优秀经验并继承;
- 避免团队犯重复的错误；
- 营造团队自主改进的氛围。
- 要点
- 会议气氛：Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；
- 关注重点：Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；
- 会议结论要跟踪闭环：可以放入迭代Backlog中。
- 什么是回顾会议
-
可视化管理
- 项目跟踪
- To Do
- Doing
- Done
- Finished
- 故事看板[图片上传失败...(image-dd8ce4-1543726686826)]
- 项目跟踪
-
Sprint计划会议
-
技术实践
敏捷特点：简单、高效
- 所有人对项目的成功负责
- 所有人由需求驱动工作，需求一旦确定，就不应该修改了
- 所有人都需要跨领域的工作
- 持续交付、迭代前进
- 小步前进、持续改进
首次实施敏捷的步骤
- 思想动员
- 差距分析
- 环境和工具准备
- 敏捷实践技能准备，技术能力准备
- 确定开发模型和拟应用实践
- 敏捷实施
- 回顾评估与调整改进
- 激励表彰
- 项目结束总结
网友评论