华为敏捷实践产品经理如何开好迭代计划会议

　　迭代计划会议是团队级敏捷的三个基础会议形式之一，本篇文章作者以产品经理的身份给大家提供一些开好迭代计划会议的建议。
　　大家好，我是华为云DevCloud项目管理服务的产品经理恒少，作为布道师和产品经理，出差各地接触客户是常态，线下和华为云的客户交流、布道、技术沙龙。
　　但是线下交流，覆盖的用户总还是少数。我希望借助线上的平台，和用户持续交流华为在研发效能提升上的思索和实践。感兴趣的朋友可以去华为云社区和我聊聊。
　　InpreparingforbattleIhavealwaysfoundthatplansareuseless，butplanningisindispensable。
　　德怀特大卫艾森豪威尔
　　艾森豪威尔，在第二次世界大战期间，担任盟军在欧洲的最高指挥官，同时也是美国第34任总统。他有不少经典的名言，这句话的意思翻译过来就是：计划书往往是无用的，但是计划的过程是不可缺少的。
　　艾森豪威尔的这句话，是很多文章里用来引述计划的名言，我也不能免俗。哈哈。
　　我个人对《人月神话》这本书有着很强的执念，早期坚信软件天生就有易变性，不可见性，软件的计划都是没有什么实际意义的。但是时间累积后，我也终于悟出来，其实做计划的过程是关键。
　　迭代计划会议是团队级敏捷的三个基础会议形式的一个，按软件开发的时序，这个是第一个会议，我之所以放到最后讲，是因为这个会议很重要，非常容易陷入误区。（其实也是我懒，先挑简单的写）
　　迭代计划的初心：
　　团队全员对接下来的迭代要做哪些UserStory、每个UserStory的责任人达成一致
　　团队成员对本轮迭代的完成标准，计划的开始结束时间达成一致
　　团队成员更认真的对待自己充分参与过的承诺。
　　一张图看懂迭代计划：
　　本文，我们使用产品经理和开发团队Leader这两个角色名。这两个角色是目前互联网企业和软件产品企业常用的角色名。产品经理负责产品的定义、规划和需求，开发团队Leader负责带领整个团队完成需求的交付和上线。
　　迭代会议的预先准备阶段：
　　产品经理应提前将特性、大颗粒的需求细化为单个迭代可以交付的多个UserStory。这是一个避免产品经理被拍砖的良心建议，你如果拿着我要做一个社交功能的所谓Story去迭代规划，估计场景会有点尴尬。其实迭代Backlog里面装的只能是UserStory（有时候也可以装上个迭代的遗留Bug）。
　　比较强烈的建议2：产品经理和开发团队Leader，提前从产品Backlog中挑选接下来迭代可以交付的UserStory的备选。产品经理对需求的价值、优先级和期望交付的时间比较清楚，而开发团队的Leader通常对于需求交付的技术依赖，团队的能力，团队的人力管道容量比较清楚。产品经理和开发团队Leader互相交互意见，挑选出预期应该放到下个迭代交付的UserStory，也可以叫做备选的迭代Backlog。
　　这个阶段，备选UserStory的工作量也应该做一个初略的估计，这个时候就是资深开发Leader和小白的区别了。同时产品经理也应该将备选的UserStory都标明优先级，比如使用MustCloud的方法，必须做的，可以做的，对应中文也也就是高优先级和中优先级。便于后面根据人力实际容量选择最终的迭代交付内容。
　　一般的迭代会议指导中，并没有特别提到这个预先准备阶段。之所以笔者特别强调，是因为，在华为之前的实践中，直接进入迭代会议，会出现产品经理和团队成员耗费大量的时间，从产品Backlog中，确认哪些UserStory可以放到这个迭代中，迭代计划会议通常是全员参加的，这样会导致耗费全员大量的时间，特别低效。
　　之前在华为内部，有过一种思路，觉得产品经理无需和进行沟通，直接指定优先级和计划时间就可以了，开发团队无条件执行。这是强产品经理导向的，但是正如网上经常看到的段子一样，这样容易导致产品经理和开发人员矛盾激化，动手拍砖。
　　我们还是认为，产品经理和开发团队应该有一个双向的沟通和理解，有些需求可能确实存在技术的难度。
　　比较强烈的建议3：开发团队Leader应该预先了解团队接下来迭代的人力容量，是不是有同学可能要请假，是不是有同学要调动到其他工作等等。上个迭代团队的人力容量是多少，接下来的迭代团队是不是有一些架构、技术优化方面的工作要预留，预计可以有多少人力容量可以投入到业务需求上。我们也非常推荐，每个迭代里面预留一定的人力容量用于技术，架构的改进，业务需求和架构技术优化保持一个比例，保持产品的的健康。这也是持续改进的体现
　　大家要铭记一个事情：团队的人力容量每个迭代一定是变化的，迄今为止，软件的开发活动还是个智力指导下的双手活动，开发人员心情不好也是会影响人力容量的：）
　　迭代会议的输入：
　　备选的迭代Backlog：一个经过产品经理和开发Leader预沟通的备选迭代Backlog，初步的需求优先级排序
　　迭代的目标：目标包括很多类型，是这个迭代的教堂，比如这个迭代要交付的重大特性，重大的市场发布等，让全员能够感知自己在这个迭代完成的UseStory的价值，迭代目标通常由产品经理向全员传递。团队自身架构、技术的重大优化，也可以是迭代的目标。团队在质量、效率上的改进目标，比如缺陷下降多少都可以是这个迭代的目标。
　　迭代会议的过程：
　　颁布会议规则，比如限定会议时间，别人发言的时候，其他人禁止讲话，每人发言限时多长时间，
　　产品经理首先给大家介绍备选的Backlong中，有哪些UserStory，这个迭代的重大特性及其价值，或者要交付的重大市场发布，或重点客户，介绍Must的UserStory有哪些。
　　开发团队Leader给大家介绍一下技术、架构，研发环境，获取其他的团队自我改进的目标，
　　团队成员全员参加，从MustUserStory开始进行Story的工作量估计，对于有些UserStory，还可以进一步拆分为Task，给出每个Task的估计
　　团队成员全员参加，看看当前计划的UserStory重估计和人力容量是否相配，不能超出人力容量的100。或者团队根据情况，定一个范围，90，80都可以，因为毕竟工作量至少预估计。随着团队越来越默契，估计值越来越准，可以提升到100。
　　如果有超出，产品经理和团队成员一起，重新调整，首先去掉Could的UserStory。这时，基本上这个迭代要交付的UserStory范围就确定了。
　　开发团队Leader带领团队成员，开始分配认领UserStory，我们建议鼓励团队成员主动的Pull（认领），而不是被动的接收Leader的Push（被动接收）。当然有些UserStory可能需要某些成员开发更好，团队Leader可以再调整，我们也可以叫做Pullamp；amp；Push。
　　开发团队Leader统一审视每个成员的实际工作量，避免对有些成员的工作量不均衡，并进行相应的调整。
　　进行简单快速的头脑风暴，团队成员发表自己对于接下来迭代的风险，对于是一般性的风险问题，快速记录，团队Leader会后解决，避免耽误大家时间
　　全员对这个迭代的目标进行信心投票，5分信心最高，1分信心最低，如果平均分低于3分，应该让投比较低的成员再讲讲他们的考虑，看看要不要再调整需求的优先级。
　　会议结束，开始为这个迭代的目标而冲刺。
　　迭代会中的一些雷和坑：
　　1。迭代会议预先准备是非常关键的。团队成员那么多，如果预先不进行备选UserStory的识别和排序，拿一堆颗粒度很大的需求直接去迭代会议，大概率要失败，会议也会及其冗长，那么多团队成员，时间哗哗的就流失了，研发不是请客吃饭，这是要让你们老板倾家荡产啊。
　　2。工作量的估计方法。有绝对估值法（人时人天），或者相对估值法（斐波那契数列的故事点，T恤Size）。关于为什么比较流行使用斐波那契数列我写了一个短文：https：bbs。huaweicloud。comforumthread1315311。html。
　　3。业界在各种敏捷，DevOps培训中，用的比较多的是相对估值法，而且通常有个故事点估计的卡片。但是从我们的实践来看，早期的迭代，团队刚刚成立，团队成员的能力和容量没有基线，团队成员对于产品，架构、技术还在掌握中，研发环境和工具链刚刚搭建，还有些工作需要投入，这种状况下用相对估值法更适合。当团队磨砺一段时间后，团队成员比较稳定，团队成员的能力和对技术架构的掌握越来越好，团队成员的估计越来越准，使用绝对值更接地气，理解起来比较直接。
　　华为云DevCloud同时提供绝对估值法的人时人天，用户只需要选一个计量单位，系统会自动计算另一个计量单位的值，目前按不加班的1天8小时的工作时间，是的，没有算加班时间：），如下图：
　　当然，我们也提供了相对估值法的故事点，如下图：
　　4。关于Task的使用误区。
　　a）把什么都当Task。Task是为这个迭代服务的，是必须有产出。学习了什么这个不可以算作这个迭代的Task。
　　b）把有些不当做Task。搭建环境，准备代码库或代码分支，验收，刷新自动化测试用例，这些都是要算Task的，不是只有写代码才算Task。
　　5。准备会议时，Must的UserStory的总量不能超过备选Backlog总工作量的80，如果备选Backlog都是Must的UserStory，失去了优先级排序的意义了。
　　6。准备会议时，Must的UserStory的总量不能超过团队容量。
　　7。整个迭代会议，建议使用专业的敏捷协同管理工具，大家看到内容一致，大家刷新调整后的内容也一致并即刻生成，会议结束的同事，一份本迭代的UserStoryTask列表就生成了，也不用会后再去整理。
　　下面是我们所在的团队最近的一个迭代计划列表例子：
　　写在最后的要点总结：
　　迭代会议事先准备很重要
　　过程中鼓励团队成员自主Pull，而不是一味着的Push
　　相信团队，相信团队对工作量的估算，给团队以尊重，工作量不要压得那么慢，超出人力容量的迭代，质量很难得到必要的保证。
　　如上的三个原则其实不仅仅适用于迭代计划会议，其实也适用于软件开发过程中的很多活动和会议。
　　希望能帮助大家开一个开心，高效，信心满满的迭代会议。
　　至此，软件迭代开发中三个最基本的活动：迭代计划会议，每日站立会议，迭代回顾会议，都介绍完了。感兴趣的朋友可以到华为云社区看相关的文章。
　　相关阅读：
　　《华为敏捷DevOps实践：产品经理如何开好敏捷回顾会议》
　　《华为敏捷DevOps实践：如何开好站立会议》