常有朋友会对传统瀑布式项目管理跟敏捷开发管理做比较，对于什么时候用瀑布式，什么时候用敏捷式，你对方法论跟实际落地了解有多深？
由于敏捷开发短频快，基于小步快走，可以不断试错，Scrum是一种基于经验的过程控制理论，主张从当前已知情况作出决定，采用迭代+增量式的方法来优化对未来的预测和管理风险，利用CICD集成式持续改进的方式，找出对业务最重要的功能，然后通过迭代，调整软件方向。相比传统方式，大大增加了产品成功的可能性。如果市场需求不确定，或者你对该领域不熟悉，那么敏捷开发几乎是唯一可行的应对方式。
Scrum有三种角色： Product Owner， Scrum Master，Team，其他。
Scrum的日常工件： 由产品待办事项product backlog，迭代待办事项sprint backlog和产品增量product increment组成。团队在迭代内完成交付成果，集成到以往的迭代成果中，形成【增量式的交付】，每次交付的用户故事必须【符合验收条件】；每次交付的增量成果必须处于可用状态，而不管PO是否决定发布这个用户故事。
价值观：勇气，开放，专注，承诺，尊重
活动
1.迭代计划
1)准备阶段
2)第1阶段：此次sprint交付增量要包括什么内容
3)第2阶段：如何完成交付增量所需的工作
2.迭代Sprint
1)【时间】2-4周，时间长度保持一致
2)【构建】一个完成的可用的潜在可发布的产品增量
3) Spring期间
4）关于取消
3.每日立会
1)【时间】每天，站着，15分钟，做24小时计划
2)【参会人】所有相关人参加，只有PO, SM,Team可以发言
3) 只讨论有价值的内容
4) 事务
4. 评审会议（针对成果）
1)非正式会议，不需要正式演示，在sprint快结束时进行，为了获取反馈促进合作
2)【时长】一个月的sprint建议4小时
3) 事务
4) 参与人
5) 输出
5. 迭代回顾（针对过程）
1)评审会议结束之后，下一个迭代计划会议之前。15-30分钟，总结过程经验教训。
2)【时长】一个月的sprint建议3小时
3) 参会人
4) 事务
评审会议和迭代回顾一般会做如下的事情：
哪些好的要继续保持
哪些不好的应该停止
哪些可以改进（按优先级排序并达成共识）（改进项作为一个任务来改进）
文中PPT转载自【CIO之家】，从概念，发展历程，角色，工具，价值观，活动，实施场景，工程应用等深入对敏捷Scrum的解读。