敏捷开发之Kanban

1、敏捷项目管理钱魏 2013年4月23日Kanban所有任务都适合迭代？ 紧急的技术支持 临时增加的优先级非常高的需求 需求的批量小，导致无法24 周一个迭代稳定发布 估算非常难，导致不容易承诺，例如不清楚原因的bug 修改，需要技术预研的任务 一些专家只对自己的技能擅长，导致计划扑克等团队估算形同虚设，同时他们在迭代中的任务很可能不饱满或者超值 由于大量增加和变化的需求，导致燃尽图对PO 和团队已经没有意义 市场的需要，2 周的周期，太长了看板是什么？一种最轻量的管理流程的方法3个规则1个工具1.可视化的工作流2.限制WIP3.关注平均完成时间可以包含整个全局流程和抓住最重要的流程关键原则局部

2、最佳化的总和效益不等于整体最佳化效益，系统的产出等于系统中最弱一环的产出。Kanban vs Scrum团队Kanban vs Scrum迭代Kanban vs Scrum产品管理Kanban vs Scrum持续改进Kanban vs Scrum白板Kanban vs Scrum比较类别KanbanScrum交付频率没有时间盒的概念，可以是固定时间段，也可以是事件驱动固定时间盒的迭代流程管理对需求的大小没有特别限制，不同大小的需求同样适用需求必须分解为一个迭代可以完成的更小的部分过程管理没有特别推荐的工具燃尽图是特别推荐的团队能力许可的任何时候都可以增加新的需求迭代过程中不可以增加新的需求对

3、估算没有强制要求估算是要求的，计划是以估算为基础的计划和过程改进的主要度量依据是：生产周期（从订货到交货的时间间隔，Lead Time）计划和过程改进的主要度量依据是：速度（Velocity）看板可以被更多的团队同时使用一个迭代团队使用自己的白板，一般无法共享在流程的节点限制WIP以迭代为单位限制WIP看板可以在整个发布过程中一直持续反映项目的整体状态迭代白板只可以反映本次迭代的状况，整个发布过程的状态需要通过发布白板、工具或者每一个迭代白板的快照来分析团队组织跨职能是可选的，允许专业技能的员工在自己专项的流程节点中更独立的发挥作用 跨职能团队没有要求任何固定角色团队的角色分为三个：PO、SM

4、（Scrum Master）、开发团队承诺是可选的，即不需要，很多时候也不容易要求团队做出承诺。重点是提高流程的效率团队每一个迭代的交付是有承诺的成功实施看板的关键使工作流可视化(Visualization)限制在制品(WIP, Work-In-Progress)管理流动，对流动进行度量(Measure)和优化(Optimize) 前置时间和产出量 (Lead Time / Throughput) 累积流图(CFD)明确定义清晰的规则和策略 定义服务类别 定义问题解决和上升策略识别改进机会，持续改善，不断提升协作性怎样开展看板怎样开展看板所有任务需要经历三个阶段（预备处理、开发、部署）开发团队制定 每个期间最多可接受的工作项目上限（WIP）每个阶段运行的WIP（比如为3、3、1）所有待办工作预备处理（3）开发（3）部署中（1）已上线处理中完成