什么是需要圈定？
需要圈定是指，在迭代研发的根底上，通过一次产研会议，确定本次迭代应该做哪些具体的需要。并非所有的需要都会通过迭代的模式来执行，相似零碎新建等较大的整块改变类需要就不适宜，这种需要因为锁定人力等缘故，虽不参加圈定，但也会间接影响圈定后果
为什么要进行需要圈定？
圈定的意义在于，每次迭代依据产能确定正当的需求量，并确保整体业务价值最大化。
在大多数时候，研发资源都不是相对富余的，即所有需要须要的总开发量往往都是超过现有研发产能的。另外研发产能在每个迭代之间也不是完全一致的，诸如局部人员已被锁定或上次迭代存在延期等，都会导致局部人力被占用。
在需要不能一股脑塞给研发团队的状况下，如何晓得本迭代该做哪些呢？那就须要确定需要的综合优先级和要害工夫节点，以及研发团队本迭代还剩多少产能。在这个根底上进行团队任务分配，是迭代研发能够进行的第一步
圈定的参加人员
- 产品团队（代表人）：须要理解本期冀望能做的所有需要，以及价值排列关系和要害工夫节点，最好对需要改变对应的模块和复杂度有一个简略的意识。参加人数并不固定，一般来说是团队负责人以及需要优先级较高的几个产品来加入，如果本期冀望池中没有本人的需要，那齐全不须要参加
- 各方向研发 / 测试团队（代表人）：研发 / 测试团队在这里须要细分，细分准则是以人力知情和裁定单元为粒度，例如后端组长没法通晓和调配前端团队的人力状况，前端也可能不止一个团队，那就都须要派代表人。最终要达成的成果是，在场代表人一起能够通晓和安顿所有研发 / 测试团队的人力调配
须要提前须要筹备的材料
- 产品团队：需要冀望池，就是本迭代所有想做且能做的需要池，并依照优先级进行排列，得出优先级天然也须要产品团队外部的充沛探讨和老板拍板。池中的需要文档细节能够不太精密，但肯定得说分明大方向改变范畴和性能点，并在会前就提前将冀望池发到群里，不便研发 / 测试团队代表人评估工作量
- 研发 / 测试团队：本迭代可调配人力状况，以及从高到低对本迭代冀望池工作量的预估。并非要把所有需要都看一遍，而是只看到本人团队最大能接受的范畴，例如前端团队本迭代残余 20 人 / 天待调配产能，P0、P1、P2 三个需要粗略预计就曾经占用了 19 人 / 天，再思考须要留一点 Buffer，那 P3 的需要就不须要费时间再看。这也要求了每个团队的代表人能够粗粒度评估需要所需工作量
如何进行圈定
简略来说就是在需要冀望池的根底上，依据各团队人力最大承载能力进行删减。为了节俭会议工夫，本次会议不须要太多形容需要的业务价值，而应该重点阐明改变范畴等影响研发 / 测试工作量的内容，因为冀望池的优先级自身便代表了产品团队对业务价值的认知。上面举例说明如何操作：
- 产品关上冀望池，从 P0 开始，简略介绍本需要波及的改变领域，并解答研发 / 测试团队代表的疑难
- 本需要相干的各研发 / 测试团队依据本身的残余人力状况，确认是否能够圈定
- 各团队都能够圈定的话反复下面流程，对下一个优先级的需要进行圈定确认
- 如果其中某团队已达到人力瓶颈，原则上来说便不倡议圈定，但也能够通过外借人力、删减需要内容等形式进行补救
- 在某团队曾经呈现瓶颈后，也能够持续圈定改变范畴不波及该团队的需要
- 无奈持续圈定时，圈定完结，并更新冀望池中已圈定局部为本期迭代池
圈定的外围产出
达成共识的已圈定需要池，可依照业务优先级进行开发工作。实践上这个池子内的需要都应该是本迭代无风险实现的，因为曾经充分考虑了人力分配情况。如果因为紧急插入需要、或人力忽然开释等起因导致工夫预估不再精确，则能够在冀望池的根底上以同样的圈定准则酌情变动
为什么须要辨别需要圈定和需要评审
为了最大可能缩小会议占用的工夫，一个所有人都参加的长时间大会也能起到应有的作用，但那不是咱们须要的，咱们应该致力让参会的每个人都不浪费时间，同时让每个人都不进行反复过的工作。圈定是为了确认和调配工作量，只有大方向确定谁来做，能不能做即可，这个过程只须要大量团队代表参加，关注点也集中在改变范畴和工时安顿。而需要评审则是针对繁多需要性能和细节的确认，须要对应的产品和研发 / 测试认真斟酌钻研，非本需要的开发人员齐全不须要浪费时间参加旁听。另外业务价值对于研发团队来说属于非必要信息，更重要的是产品团队外部对于业务价值的排序须要达成共识