一、敏捷迭代开发原理跟现在开发管理有哪些主要不同
小团队，人数少
短的固定的时间箱
跨职能团队
每个迭代结束时要有交付物
与客户沟通协作取得客户满意
迭代内各种工作同时开展
二、敏捷实践——迭代计划会
敏捷实践主要包括：每日站会、迭代计划会、迭代回顾会、迭代评审会（show case）、短周期迭代，这里我们主要分享第二个——迭代计划会
迭代计划会要解决的三个问题：
1） What? 做什么?
2）How? 怎么做?
3）How much? 做多少?
迭代计划会成功的标准：结束后可以立刻开始Coding
1.What? 做什么?
（1）以终为始，跟业务沟通，确定验收标准（UAT）-业务可行性
（2）识别关联系统，方案设计和技术评审，评估开发工作量（包括各个关联系统）-技术可行性
（3）确定需求优先级和业务价值
看板中需求优先级由需求分析岗设置，需求就绪里优先级必须要设置好
每月部落长、需求分析岗要跟业务方对齐需求优先级，降低变更风险；若有插队需求，需上升至部落长或走变更管理流程；建议每两周组织复盘会，与部落长优化流程、沟通、提高质量
（4）确定主要干系人，可做Show case/review
2.How? 怎么做?
（1）方案设计和技术评审
主办小队有责任牵头所有关联系统方，做需求澄清，方案评审
（2）需求拆分系统任务，评估系统任务开发工作量（小于或等于10人天）
小队长负责开发估算，不能做甩手掌柜；个人任务估算每个成员自己设置
看板中个人估算总和和开发估算出现较大差异时（差20%以内算正常），团队内要充分沟通，是否存在对复杂度、可重用的判定不一致
3.How much? 做多少?
（1）为保证小队弹性，应按80%团队容量排入工作（算团队容量时要注意，迭代前跟成员沟通好休假计划，除去会议、培训、沟通、社区时间等）；
其中Must（必须完成）排60%、Could排40%；例如10个需求排入本迭代，6个为Must，当出现空降任务，4个Could可移出本迭代，而变化不太多的团队可排80%的Must
莫斯科原则： 60%must-必须完成 、40%could-最好完成，空降任务可以用40%最好完成的任务做替换，为迭代增加弹性
计划的时候不要排加班时间，达到100%就足够了，因为加班时间本来就是弹性时间
人员不需要考虑级别，可直接从人员预估个人任务工作量中体现
（2）留出当前迭代10%的容量，为下个需求就绪做准备，例如每人做一个需求，给每人1天做准备，澄清、评审、任务拆分等工作
三、目标
交付更大的业务价值
迭代产出物最好是业务可感知的
网友评论