一、敏捷项目管理案例分享

业务条线&产品&研发面对面协作：业务与开发办公场地分别为上海和深圳，该公司要求每周至少三天，业务到开发现场集中办公，通过每日站会、物理看板、日报风险、视频演示、上下对齐。

面对面沟通、需求不断澄清的重要性

二、迭代计划会前准备

1.what？做啥？

需求达到就绪标准：需求澄清完成

确认验收标准（UAT）-业务可行性

2.how？怎么做？

识别关联系统，方案设计和技术评审、评估工作量-技术可行性

需求分析岗设置优先级-需求价值

确认主要干系人-review/showcase

3.how much？做多少？

保证小队弹性，按80%容量排入工作

怎么算容量：减去会议时间、培训时间、沟通时间、社区建设还有休假等等（10天 就成员85%左右  8.5天左右，乘以小队人数 ）

MUST（必须完成）只排60%，例如10个需求排入本迭代，6个为必须完成，若有空降，则could（可以完成）的4个可往外拿；变化不太多的团队就排80%的MUST

回答好以上三个问题，可以立即开始Coding

三、心得总结：

1.定期与业务对齐优先级（需求分析岗、部落长、业务、小队长每2周/每月对齐），降低中间插队比例

2.紧急需求：多问为什么紧急，新增与遗留的需求排优先级，若还有冲突则上升到部落长或走变更管理流程，保证价值最高的优先交付

3.建议每两周组织复盘会，与部落长优化流程、沟通、提高质量

4.系统任务<=10天，开发估算是小队长负责（不能做甩手掌柜），个人估算汇总是由小组成员估算汇总得出，两个数据对比能看出差异，差异很大时，大家要充分沟通（复杂度、可重用的），20%以内差异认为可接受

5.迭代结束可以showcase，迭代产出物最好是业务可以感知的

四、Q&A

Q1：迭代计划内是否排入加班时间

A：不要排加班时间，饱和度按正常工作时间达到100%就足够了，因为加班时间本来就是弹性时间

Q2：人员是否按高中初级排列

A：不用，通过个人任务的估算就可以看出来，同一张个人任务卡片，高级的个人任务估算为1，中级为2，初级为3

Q3：需求就绪个数很少，达不到小队容量

A：持续做就绪工作，当前迭代10%容量为下个迭代需求就绪做准备，例如每人做一个需求，给每人1天留作准备，澄清、评审、任务拆分