1 、敏捷管理的目的
传统项目验收模式和客户需求的矛盾， 以适应需求的变化
2、敏捷适合哪些项目？
哪些项目用传统方式：确定型工作 （前期收集好大量的需求,范围比较明确，不容易变更，产品一次性交付 --- eg.发射火箭）
哪些项目用敏捷方式：不确定型工作（eg. 巡航导弹）
技术 && 需求不确定性：技术上有一定难度，需求上也会有一定变化，适合敏捷模式
技术和需求都简单的，适合线性开发模式
都复杂的就风险较大了
3、敏捷方法与传统方法的本质区别
敏捷核心价值观
1）个体和互动 高于 流程和工具
2）工作的产品 高于 详尽的文档
3）客户合作 高于 合同谈判
4）响应变化 高于 遵循计划
初期计划问题不足的，与其坚持原订计划，不如把精力用于项目中“不可避免的变化”
短期迭代的计划比中长期计划更有效
总结：传统模型（预测型管理）---- 需求、设计、开发、测试、验收 每个验收点都是文档，没有产品，在大量的时间里客户看不到产品
敏捷型管理 ---- 小功能小火车类型；
软件产品功能的使用频度： 45% 从未使用 13%经常用 16%有时 19%偶尔用 7%总是用 （精力需聚焦于此，解决用户痛点）
4、敏捷开发模型
1） 整合迭代和增量两种方法
2）早期没有做过多过于仔细的计划，然后在实施过程中一起去探索，然后有个开放的心态，那么接下来有些什么调整，总体来说是个动态的拥抱的过程。
3） 基本思路：试错、快速试错、低成本快速试错；
5、精益思想解读
迭代 VS 增量
1）试错、快速试错、低成本试错；
2）最常用的敏捷方法： Scrum + XP（Code Review 、结队编程等） + 看板，以精益作为基础
6、看板方法概览
1）找痛点---刚需：真实、高频、不可替代 （理解需求的不同象限）
越真实，越高频，就越刚需 ==〉 需抢占市场，烧钱也要做，比如滴滴打车
7、Scrum计划方法
1）敏捷计划：按功能（用户故事）进行计划，替换传统的按层级进行开发的模式。 （纵向切蛋糕模式，不要做完一整块蛋糕，而是先从上到下做出一小块蛋糕给客户尝尝，然后再做更多的蛋糕）
优点：避免等待、可低成本快速试错 ，提升效率
接受客户的需求变更，不意识着任意无序的允许变更，要有节奏、有序的接受变更---对于变更要有管理、评估
8、敏捷需求的构成
需求文档 --〉 用户故事的方式呈现 （作为XX，我想XXX，以便于XXXXXX）
对于需求整理，需要具备三要素：排优先级、估算、划定特定版本
针对研发过程中的变化，需要对需求进行定期梳理：插入新条目、重新估算、调整优先级、删除条目、细化条目等，总的原则是：最重要的产品待办事项，能够呈现在看板上。
9、Scrum的角色和职责
1）角色职能：
产品负责人（PO）：内外圈承接，代表客户的利益（与需求联系更紧密）、工作重点是协助客户整理产品功能，排列优先级，生成产品Backlog，并向团队详细介绍将要实现的功能 〈做什么〉
敏捷教练（SM）：实施敏捷方法、作为流程专家，将敏捷方法部署于日常的项目管理，同时向干系人比如客户、高层介绍敏捷，获得支持，移除实施敏捷的障碍。 〈怎么做〉
开发团队（开发&测试人员）： 我们是一个团队Team ，我们是一群跨职能的伙伴们组成，拥有实现产品功能需要的全部角色，我们采取彼此信赖，自组织的工作方式。
内部利益干系人（业务负责人、经理、项目集管理人员）
外部利益干系人（客户、用户、合作伙伴、监管部门）
2）主要职能映射表：
估算： 开发团队
待办事项排序：PO
速率预估：开发团队
完成定义：SM、开发团队、PO
遵循流程：SM
技术决策：开发团队
迭代规划：SM、开发团队、PO
网友评论