搜索
敏捷项目管理钱魏2013年4月23日Kanban所有任务都适合迭代？紧急的技术支持临时增加的优先级非常高的需求需求的批量小，导致无法2~4周一个迭代稳定发布估算非常难，导致不容易承诺，例如不清楚原因的bug修改，需要技术预研的任务一些专家只对自己的技能擅长，导致计划扑克等团队估算形同虚设，同时他们在迭代中的任务很可能不饱满或者超值由于大量增加和变化的需求，导致燃尽图对PO和团队已经没有意义市场的需要，2周的周期，太长了看板是什么？一种最轻量的管理流程的方法3个规则1个工具1.可视化的工作流2.限制WIP3.关注平均完成时间可以包含整个全局流程和抓住最重要的流程关键原则局部最佳化的总和效益不等于整体最佳化效益，系统的产出等于系统中最弱一环的产出。KanbanvsScrum团队KanbanvsScrum迭代KanbanvsScrum产品管理KanbanvsScrum持续改进KanbanvsScrum白板KanbanvsScrum比较类别KanbanScrum交付频率没有时间盒的概念，可以是固定时间段，也可以是事件驱动固定时间盒的迭代流程管理对需求的大小没有特别限制，不同大小的需求同样适用需求必须分解为一个迭代可以完成的更小的部分过程管理没有特别推荐的工具燃尽图是特别推荐的团队能力许可的任何时候都可以增加新的需求迭代过程中不可以增加新的需求对估算没有强制要求估算是要求的，计划是以估算为基础的计划和过程改进的主要度量依据是：生产周期（从订货到交货的时间间隔，LeadTime）计划和过程改进的主要度量依据是：速度（Velocity）看板可以被更多的团队同时使用一个迭代团队使用自己的白板，一般无法共享在流程的节点限制WIP以迭代为单位限制WIP看板可以在整个发布过程中一直持续反映项目的整体状态迭代白板只可以反映本次迭代的状况，整个发布过程的状态需要通过发布白板、工具或者每一个迭代白板的快照来分析团队组织跨职能是可选的，允许专业技能的员工在自己专项的流程节点中更独立的发挥作用跨职能团队没有要求任何固定角色团队的角色分为三个：PO、SM（ScrumMaster）、开发团队承诺是可选的，即不需要，很多时候也不容易要求团队做出承诺。重点是提高流程的效率团队每一个迭代的交付是有承诺的成功实施看板的关键使工作流可视化(Visualization)限制在制品(WIP,Work-In-Progress)管理流动，对流动进行度量(Measure)和优化(Optimize)–前置时间和产出量(LeadTime/Throughput)–累积流图(CFD)明确定义清晰的规则和策略–定义服务类别–定义问题解决和上升策略识别改进机会，持续改善，不断提升协作性怎样开展看板怎样开展看板所有任务需要经历三个阶段（预备处理、开发、部署）开发团队制定每个期间最多可接受的工作项目上限（WIP）每个阶段运行的WIP（比如为3、3、1）所有待办工作预备处理（3）开发（3）部署中（1）已上线处理中完成工作G工作H工作I工作J工作K工作E工作F工作D工作B工作C工作A工作W工作X工作Y预处理永远留一个给紧急Bug之用Q&AThanks