摘要:企业在作敏捷转型中,需求没法按时交付的困扰你是否也遇到过呢?
在以前组织的一次敏捷线下活动中,有家企业问道:“咱们公司刚作敏捷转型不久,遇到一个比较头疼的问题——团队天天都很忙,从转型到如今已经两个多月了,基本没有一个迭代能作彻底部任务,问题出在哪?”该问题一提出后,引起了激烈讨论:html
“咱们公司也是,总有那么几我的完不成手头任务,每次拖后腿让客户不满意”;segmentfault
“最近咱们项目用了个新框架,不少人他没用过啊,不知道从哪下手,项目评审的时候一片惨淡”。框架
其实上述几种状况归根到底都属于需求没法按时交付,相似这样的困扰你是否也遇到过呢?工具
在交流中,笔者了解到每家公司的状况:spa
笔者结合交流结果及以往经验,对需求延期交付的缘由进行了以下分析:htm
需求延期交付一般有两方面缘由——团队主观缘由以及客观缘由。客观缘由一般是由过程方面的阻塞形成的,好比团队须要购买一批云资源,公司规定资源采购须要老板最终审批签字方可实施,正巧遇上老板出差没法签字,致使工做卡在最终审批环节没法交付。blog
没有客观因素干扰,需求没法按时交付一般就是指团队手头工做在迭代结束前没法所有完成,这是主观缘由。形成团队手头工做完不成的缘由有不少,背景中提到的缘由可归纳为如下三种:ip
冲刺待办列表是计划会议的输出之一,计划会议上团队根据团队速率认领故事,造成冲刺待办列表;若是团队速率被高估或者个别故事估值偏小,则冲刺待办列表中的故事点数相对团队真实速率就会偏多,最终致使工做过多,迭代结束时部分需求没法按时交付。项目管理
冲刺待办列表中故事过多还有一种可能:计划会议输出的冲刺待办列表是合理的,但是因为一些突发因素,产品负责人向迭代插入了新的任务,致使冲刺待办列表故事太多。资源
项目使用了新的框架、语言、工具等,团队以前没接触过,须要必定时间去磨合,因此前期不免出现延迟交付。工做技术难度较高是相对于团队平均水平来讲的,若是团队总体技能水平偏薄弱,好比都是团队成员都是刚入行的新人,普通研发工做相对这个团队来讲都很困难,这种状况也很容易出现延迟交付。
团队某位成员请假了,本来计划完成的工做由于请假只作到一半,因此最后没法按时交付;另外若是团队成员没作到自组织,在项目中出工不出力,也容易致使迭代结束手头工做没有完成;最后若是团队成员工做遇到障碍被卡住,该成员不向团队暴露障碍,而是一直本身孤军奋战,也会致使需求延期交付。
除请假外,其余两种状况均可以经过敏捷的风险管控方法(如每日站会)避免发生,因此这种状况也能够总结为团队风险管控没有作好。
针对分析中客观缘由部分,团队能够经过创建Backup的形式进行避免。以采购为例,项目经理或老板秘书作老板的Backup,当老板因为自身缘由没法亲自审批时,Backup可向老板汇报,征得老板赞成后代替老板审批,避免流程方面的因素影响团队交付,也体现了敏捷宣言中的“个体与交互赛过流程与工具”。
针对团队主观缘由部分,本文基于合理开展敏捷活动给出以下措施。
冲刺待办列表故事过多的主要缘由是高估团队速率,故事大小估算错误以及迭代中有新需求插入。针对这三种状况,给出以下解决方案:
团队速率是团队在迭代中认领多少故事的依据。
在敏捷转型初期,因为团队没有历史数据作参考,很容易估算错团队速率,致使冲刺待办列表中故事过多或过少——故事过多则可能致使延期交付;故事过少,则会浪费开发资源。如何估算团队速率呢?
肯定开发团队天天在开发工做上投入的时间(刨除会议,接打电话,收发邮件等时间),将时间乘以迭代天数,便可得出迭代中团队用于开发冲刺任务的生产力。而后团队从产品待办列表中选择一系列故事,预估这些故事的完成时间和用于开发冲刺任务的生产力相近,而后统计这些故事的点数,便可估算出团队速率。起初估算结果可能不许确,可是一般团队对速率的估算会随着迭代进行而越发准确。
举个例子:团队5个开发人员,其中三我的天天有6.5小时用来工做,其他二人天天有6小时能够工做,迭代两周(10 工做日),那么团队可工做的时间总和就是(6.5×3+6×2)×10=315。咱们从产品待办列表中选择315小时左右的故事放入冲刺待办列表。冲刺待办列表详细信息以下(本文故事由华为云DevCloud进行管理):
由图可看出团队速率大概是33左右。也就是说,计划会议中团队从产品待办列表中选择30个故事点的故事放到冲刺待办列表,进行开发,团队有可能所有交付,而选择50个,则所有交付是有困难的。
根据团队速率认领故事,可让团队量力而行,有效地减小延期交付。
除了对团队速率估算错误,对故事大小估算错误也容易致使延迟交付,关于故事大小的估算方法能够参考【DevCloud · 敏捷智库】如何估算第二篇:利用核心概念解决估算常见问题
敏捷迭代中因为时间盒和工做量都固定,若是有新需求加入迭代——好比生产环境忽然发现一个以前没测出的Bug,须要修复,迭代工做量可能会超出团队生产力,致使延迟交付。
Tips:团队在计划会议领取任务时,不要领取的太满,最好预留一些缓冲时间,以便于应对突发状况。
若是产品负责人迫于领导或客户压力,不容许需求置换,只能向冲刺待办列表中硬塞故事,这时候应该怎么办呢?在敏捷中,Scrum Master做用之一是扮演团队的“保护伞”,让团队集中精力去完成迭代目标。若是产品负责人强制的向迭代中添加故事,Scrum Master可与对方沟通,弄清楚对方为何向迭代中插入故事——以前整理故事有遗漏或者发现了之前未测出的Bug,仍是对方不知道Scrum不建议向进行中的迭代插故事。若是是需求遗漏,应该在回顾会议上总结经验,往后避免;若是对方不了解Scrum,能够经过讲解Scrum相关知识,让对方理解为何Scrum不建议向进行中的迭代加入新故事,之后避免这种状况发生。
加班也是一个应对突发问题的选择,可是研究代表短时间加班会提升效率,长期加班团队成员会因休息不足,注意力不集中等缘由下降效率。长期加班除了不利于团队建设以外,不定时的加班对团队速率也有很大影响,而敏捷提倡可持续发展,因此加班解决突发问题属下策。
对于项目技术难度要求超出团队能力,成员没法估算工做量或无从下手致使项目交付延期的状况,能够利用“探针(Spike)”技术评估项目。
探针是一种敏捷实践。当遇到没法估算,或无从下手的故事时,团队能够从这个大故事中分割出一个小故事,而后对小故事进行开发,这个小故事就是探针。探针的开发完成时间可做为估算整个故事完成时间的依据,后续估算有了依据,就会准确不少,延迟交付的风险也会随之减小。
固然除了探针技术,团队成员的技术培训也是必不可少的——团队内技术分享或培训,能够提升团队总体技术水平,从而提升研发效率、减小特性延迟交付的风险。
每日站会是一个很好的风险管控工具。迭代中的每一天均可以当作是一个小迭代,每日站会经过保证小迭代正常运行,进而保证整个迭代的稳定进行。每日站会若是只汇报工做,一般会变得浮于形式,各类风险可能也没法被确认,最后致使每日站会发挥不了自身做用。认真开好每日站会能够预防延迟交付。
团队成员在每日站会“前一天作了什么”,“今天要作什么”的基础上,陈述工做详细状况以及具体进度,这样可让团队的工做状态更加透明。从团队风险管控角度来看“我昨天用了5小时开发A功能,目前A功能开发了50%,今天预计再投入5小时,开发至80%”比“我昨天开发了A功能,今天要继续开发A功能”要好得多。
另外借用一些项目管理工具,能够更直观的看出员工的工做状态。以华为云DevCloud项目管理功能为例,在故事中,能够清楚地看到员工的实际工时和故事的完成度,便于了解和把控故事延迟交付的风险。
没作好风险管控会影响故事的按时交付,每日站会经过“我遇到什么风险”识别团队遇到的风险。遇到风险时,首先团队成员能够指定团队中某一成员,让其帮忙清楚风险;固然团队成员也能够主动帮忙清除风险。若是团队内没有人可以清除风险,这时候Scrum Master就应该发挥“清道夫”的做用,经过协调内部或外部资源来解决风险,帮助团队扫清障碍,以确保项目能够按时交付。
想了解更多关于每日站会的内容能够参考:【DevCloud · 敏捷智库】如何玩转每日站会?
【DevCloud · 敏捷智库】如何估算第二篇:利用核心概念解决估算常见问题
Mike Cohn 敏捷软件开发实践——估算与计划 北京:清华大学出版社