保存到桌面加入收藏设为首页
汇凯科技
当前位置:首页 > 汇凯科技

华为云敏捷DevOps实践,教你开好迭代计划会议 - 每日科技网-打开科技之门-深圳汇凯科技有限公司

时间:2018-12-25 18:36:38   作者:   来源:   阅读:58   评论:0
内容摘要: 【每日科技网】  迭代计划会议是团队级敏捷的三个基础会议形式的一个按软件开发的时序这个是第一个会议这个会议很重要非常容易陷入误区。  迭代计划的初心:  1.团队全员对接下来的迭代要做哪些UserStory、每个UserStory的责任人达成一致  2.团队成员对本轮迭......
        【每日科技网】

  迭代计划会议是团队级敏捷的三个基础会议形式的一个按软件开发的时序这个是第一个会议这个会议很重要非常容易陷入误区。

  迭代计划的初心:

  1.团队全员对接下来的迭代要做哪些UserStory、每个UserStory的责任人达成一致

  2.团队成员对本轮迭代的完成标准计划的开始结束时间达成一致

  3.团队成员更认真的对待自己充分参与过的承诺。

  一张图看懂迭代计划:

  本文我们使用产品经理和开发团队Leader这两个角色名。这两个角色是目前互联网企业和软件产品企业常用的角色名。产品经理负责产品的定义、规划和需求开发团队Leader负责带领整个团队完成需求的交付和上线。

  迭代会议的预先准备阶段:

  1:产品经理应提前将特性、大颗粒的需求细化为单个迭代可以交付的多个UserStory。这是一个避免产品经理被拍砖的良心建议你如果拿着“我要做一个社交功能”的所谓Story去迭代规划估计场景会有点尴尬。其实迭代Backlog里面装的只能是UserStory(有时候也可以装上个迭代的遗留Bug)。

  2:产品经理和开发团队Leader提前从产品Backlog中挑选接下来迭代可以交付的UserStory的备选。产品经理对需求的价值、优先级和期望交付的时间比较清楚而开发团队的Leader通常对于需求交付的技术依赖团队的能力团队的人力管道容量比较清楚。产品经理和开发团队Leader互相交互意见挑选出预期应该放到下个迭代交付的UserStory也可以叫做备选的迭代Backlog。

  这个阶段备选UserStory的工作量也应该做一个初略的估计这个时候就是开发Leader和小白的区别了。同时产品经理也应该将备选的UserStory都标明优先级比如使用Must-Cloud的方法必须做的可以做的对应中文也也就是高优先级和中优先级。便于后面根据人力实际容量选择最终的迭代交付内容。

  一般的迭代会议指导中并没有特别提到这个预先准备阶段。笔者之所以特别强调是因为在华为之前的实践中直接进入迭代会议会出现产品经理和团队成员耗费大量时间的问题。从产品Backlog中确认哪些UserStory可以放到这个迭代中迭代计划会议通常是全员参加的这样会导致耗费全员大量的时间特别低效。

  之前在华为内部有过一种思路觉得产品经理无需进行沟通直接指定优先级和计划时间就可以了开发团队无条件执行。这是强产品经理导向的但是正如网上经常看到的段子一样这样容易导致产品经理和开发人员矛盾激化“动手拍砖”。

  我们还是认为产品经理和开发团队应该有一个双向的沟通和理解有些需求可能确实存在技术的难度。

  3:开发团队Leader应该预先了解团队接下来迭代的人力容量是不是有同学可能要请假是不是有同学要调动到其他工作等等。上个迭代团队的人力容量是多少接下来的迭代团队是不是有一些架构、技术优化方面的工作要预留预计可以有多少人力容量可以投入到业务需求上。我们也非常推荐每个迭代里面预留一定的人力容量用于技术架构的改进业务需求和架构技术优化保持一个比例保持产品的的健康。这也是持续改进的体现。

  大家要铭记一个事情:团队的人力容量每个迭代一定是变化的迄今为止软件的开发活动还是个智力指导下的双手活动团队开发人员的心情也是会影响人力容量的。

  迭代会议的输入:

  1.备选的迭代Backlog:一个经过产品经理和开发Leader预沟通的备选迭代Backlog初步的需求优先级排序。

  2.迭代的目标:目标包括很多类型是这个迭代的“教堂”比如这个迭代要交付的重大特性重大的市场发布等让全员能够感知自己在这个迭代完成的UseStory的价值迭代目标通常由产品经理向全员传递。团队自身架构、技术的重大优化也可以是迭代的目标。团队在质量、效率上的改进目标比如缺陷下降多少都可以是这个迭代的目标。

  迭代会议的过程:

  1.颁布会议规则比如限定会议时间别人发言的时候其他人禁止讲话每人发言限时多长时间

  2.产品经理首先给大家介绍备选的Backlong中有哪些UserStory这个迭代的重大特性及其价值或者要交付的重大市场发布或重点客户介绍Must的UserStory有哪些。

  3.开发团队Leader给大家介绍一下技术、架构研发环境获取其他的团队自我改进的目标。

  4.团队成员全员参加从Must UserStory开始进行Story的工作量估计对于有些UserStory还可以进一步拆分为Task给出每个Task的估计。

  5.团队成员全员参加看看当前计划的UserStory重估计和人力容量是否相配不能超出人力容量的。或者团队根据情况定一个范围90%80%都可以因为毕竟工作量至少预估计。随着团队越来越默契估计值越来越准可以提升到。

  6.如果有超出产品经理和团队成员一起重新调整首先去掉Could的UserStory。这时基本上这个迭代要交付的UserStory范围就确定了。

  7.开发团队Leader带领团队成员开始分配认领UserStory我们建议鼓励团队成员主动的Pull(认领) 而不是被动的接收Leader的Push(被动接收)。当然有些UserStory可能需要某些成员开发更好团队Leader可以再调整我们也可以叫做Pull&Push。

  8.开发团队Leader统一审视每个成员的实际工作量避免对有些成员的工作量不均衡并进行相应的调整。

  9.进行简单快速的头脑风暴团队成员发表自己对于接下来迭代的风险对于是一般性的风险问题快速记录团队Leader会后解决避免耽误大家时间

  10.全员对这个迭代的目标进行信心投票5分信心1分信心如果平均分低于3分应该让投比较低的成员再讲讲他们的考虑看看要不要再调整需求的优先级。

  11.会议结束开始为这个迭代的目标而冲刺。

  迭代会中的一些雷和坑。

  1.迭代会议预先准备是非常关键的。团队成员那么多如果预先不进行备选UserStory的识别和排序拿一堆颗粒度很大的需求直接去迭代会议大概率要失败会议也会及其冗长。

  2.工作量的估计方法。有估值法(人时/人天)或者相对估值法(斐波那契数列的故事点T恤 Size)。关于为什么比较流行使用斐波那契数列我写了一个短文详情请登录华为云官网在论坛中搜索“恒少”。

  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. 整个迭代会议建议使用专业的敏捷协同管理工具大家看到内容一致大家刷新调整后的内容也一致并即刻生成会议结束的同事一份本迭代的UserStory/Task列表就生成了也不用会后再去整理。下面是我们所在的团队最近的一个迭代计划列表例子:

  写在最后的要点总结:

  1.迭代会议事先准备很重要。

  2.过程中鼓励团队成员自主Pull而不是一味着的Push。

  3.相信团队相信团队对工作量的估算给团队以尊重工作量不要压得那么慢超出人力容量的迭代质量很难得到必要的保证。

  4.如上的三个原则其实不仅仅适用于迭代计划会议其实也适用于软件开发过程中的很多活动和会议。


相关评论

最近更新

精彩推荐

阅读排行

本站所有站内信息仅供娱乐参考,不作任何商业用途,不以营利为目的,专注分享快乐,欢迎收藏本站!
所有信息均来自:百度一下 (威尼斯人官网)