显然我们使用Scrum开发方法.以下是一般情况:
开发人员试图完成他们的任务.通常,任务需要完成大部分sprint.QA讨厌Dev发布他们可以测试的内容,Dev在sprint结束前一两天将一些错误的代码抛给QA,并花费其余的时间来修复QA发现的错误.QA永远无法按时完成任务,冲刺很难按时发布,而Sp和QA在冲刺结束时有几天可怜.
当可释放的Dev任务占用大部分冲刺时,scrum应该如何工作？
感谢大家参与讨论.由于这是一个相当开放的问题,似乎没有一个"答案" - 下面有很多好的建议.我将尝试总结一些"带回家"的观点,并做出一些澄清.
(顺便说一下 - 这是放置这个的最好的地方还是我应该把它放在'答案'？)
要思考/行动的要点:
需要确保开发人员任务尽可能小(粒度).
Sprint长度应根据平均任务长度进行适当调整(例如,1周任务的冲刺应至少为4周)
团队(包括QA)需要努力提高估算的准确性.
如果最适合团队,可以考虑并行进行单独的QA冲刺,但要进行抵消
单元测试!
Sergio Acost.. 40
我的意见是你有一个估计问题.似乎缺少测试每个功能的时间,并且在规划sprint时仅考虑构建部件.
我不是说这是一个容易解决的问题,因为它比任何事情都更常见.但可能有用的事情是:
将QA视为开发团队的成员,并将其包含在sprint计划和更紧密的估算中.
'可释放的开发任务'不应该占用大部分冲刺.完整的工作功能应该.尝试收集有关每种任务的开发时间与质量保证时间的指标,并在估计未来冲刺时使用这些指标.
您可能需要查看您的待办事项,看看您是否具有非常粗糙的功能.尝试将它们分成可以轻松估算和测试的较小任务.
总而言之,您的团队似乎还没有找到真正的速度,因为在进行sprint的估算和规划时,有些任务没有被考虑.
但最终,估计不准确是一个棘手的项目管理问题,您可以在基于敏捷或基于瀑布的项目中找到它.祝好运.
我的意见是你有一个估计问题.似乎缺少测试每个功能的时间,并且在规划sprint时仅考虑构建部件.
我不是说这是一个容易解决的问题,因为它比任何事情都更常见.但可能有用的事情是:
将QA视为开发团队的成员,并将其包含在sprint计划和更紧密的估算中.
'可释放的开发任务'不应该占用大部分冲刺.完整的工作功能应该.尝试收集有关每种任务的开发时间与质量保证时间的指标,并在估计未来冲刺时使用这些指标.
您可能需要查看您的待办事项,看看您是否具有非常粗糙的功能.尝试将它们分成可以轻松估算和测试的较小任务.
总而言之,您的团队似乎还没有找到真正的速度,因为在进行sprint的估算和规划时,有些任务没有被考虑.
但最终,估计不准确是一个棘手的项目管理问题,您可以在基于敏捷或基于瀑布的项目中找到它.祝好运.
这里的派对有点晚了,但这是基于你所写的内容.
现在,Scrum是一种项目管理方法,而不是开发方法.但在我看来,关键是要有适当的发展过程.没有一个,你花费大部分时间来反应而不是建设.
我是测试第一的人.在我的开发过程中,我首先构建测试以强制执行需求和设计决策.你的团队如何执行这些？我试图在这里提出的观点是,你根本无法"把东西扔到篱笆上",并期待任何事情,但不会发生.这种失败要么是由测试团队进行的(通过不是很好地测试,从而让问题漏掉),要么是由开发人员(通过不构建解决问题的产品).我不是说你必须首先编写测试 - 我不是激进分子或测试优先的传播者 - 但是我说你必须有一个流程来制作质量,测试,准备生产的代码当你达到迭代的结束.
在我称之为死亡螺旋方法的这种开发方法中,我一直都是对的.我在这样的模型中为政府(美国)建立了多年的软件.它不能很好地工作,它花费了很多钱,它产生了晚期的代码,糟糕的代码,并没有为士气做任何事情.当你花费所有时间修复你本可以避免的错误时,你无法取得任何进展.我被这件事彻底打败了.
您不希望QA发现您的问题.你想让他们失业,真的.我的目标是让QA大吃一惊,因为一切正常.当然,这是一个目标.在实践中,他们会找到东西.我不是超级人类.我犯错了.
回到安排......
在我目前的工作中,我们做Scrum,我们只是不称它为.我们不是这里的标签,但我们正按时生产高质量的代码.每个人都在船上.我们告诉QA我们准备好测试什么以及什么时候测试.如果他们提前两周来敲门,他们就可以说话了.每个人都知道时间表,每个人都知道发布中会有什么,每个人都知道产品必须像广告中那样在QA之前工作.那是什么意思呢？你告诉QA"不要打扰测试XYZ - 它已经坏了,在发布C之前不会修复",如果他们进行测试,你会将它们指回到那个声明并告诉他们不要浪费你的时间.苛刻,也许,但有时是必要的.我不是要粗鲁,但每个人都需要知道"规则"
您的管理层必须在船上.如果他们不是你会遇到麻烦.QA无法运行该节目,开发组也无法完全运行它.所有组(即使这些组只是每组一个人或戴着几顶帽子的人)都需要在同一页面上:客户,测试团队,开发人员,管理人员和其他任何人.通常,一半以上的战斗是沟通.
也许你在冲刺期间所做的事情远不止于此.情况可能就是这样.你为什么这样做？要满足时间表？如果是这样,那就是管理层需要介入并解决问题的地方.如果您要提供QA错误代码,请期待他们将其丢回.最好给他们3件有用的东西,而不是8件未完成的东西.目标是生成一组在每次迭代时完全实现的功能,而不是将一堆半完成的东西放在一起.
我希望这是收到的,因为它的目的是 - 作为鼓励而不是咆哮.就像我提到的那样,我一直在你身边,这并不好玩.但是有希望.你可以在冲刺中扭转局面,也许两个.也许您不会在下一个sprint中添加任何新功能,只需修复损坏的内容即可.你必须作为一个团队来决定.
另一个用于编写测试代码的小插件:自从采用"首先编写测试"方法以来,我发现自己对我的产品更加放松,更加自信.当我的所有测试都通过时,我有一种自信,如果没有它们我就无法拥有.
祝你好运!
在我看来,在需要QA功能测试的场景中存在资源分配问题,以便在sprint中"完成"给定功能.在我迄今为止发现的任何QA相关的scrum讨论中似乎没有人解决这个问题,这里的原始问题几乎是相同的(至少是相关的),所以我想提供一个部分答案并稍微扩展一下这个问题.
至于关于完整冲刺的开发任务的具体原始问题 - 如果QA的功能测试是您对'完成'的定义的一部分,那么放宽这些任务的一般建议似乎是有意义的.假设让我们说4周冲刺,如果需要大约一周的时间来测试来自多个开发人员的多个功能,那么看起来开发任务需要大约3周,然后是大约1周的测试任务延迟一周就是答案.QA当然会尽快开始我们认识到,从最后一组交付的功能中,将会有大约一周的延迟.我意识到我们希望尽快获得QA的功能,因此你不会在sprint中拥有这种类似瀑布的场景,但实际情况是开发通常无法实现,值得为QA提供功能,直到sprint的1到3周.当然,这里和那里都有点点滴滴,但大部分工作是2-3周的开发,然后大约一周的测试剩余.
所以这里是资源分配问题,我对问题的扩展 - 在上面的场景中QA有时间测试sprint的计划功能(3周的开发任务,最后一周用于测试最后提供的功能).另外,我们假设QA在开发一周后开始获得一些可测试的功能 - 但QA的第一周是什么,以及第四周的开发是什么？
如果QA功能测试是sprint中某个功能的"完成"定义的一部分,那么这种低效率似乎是不可避免的.QA将在第1周期间基本闲置,并且在第4周期间开发将基本闲置.当然,有些事情自然会填补这些时间,例如错误修复和验证,设计/计划等,但我们基本上以75%的容量计划我们的资源.
显而易见的答案似乎是发展和质量保证的重叠冲刺,因为现实是质量保证总是在一定程度上落后于发展.产品所有者和其他人的演示将遵循QA冲刺,因为我们希望在显示之前测试功能.这似乎可以更有效地利用开发和QA,因为我们没有浪费太多时间.假设我们想让开发人员继续开发和测试测试,我看不到更好的实用解决方案.也许我错过了一些东西,我希望有人可以为我揭示这一点 - 否则看起来这种僵硬的scrum方法是有缺陷的.谢谢.
希望您通过在每个sprint中处理更少的开发任务来解决这个问题.这引出了一些问题:谁设定了开发人员的目标？为什么Dev一直没有达到这些目标？
如果开发人员没有设定自己的目标,那就是他们总是迟到的原因.这不是练习Scrum的理想方式.这只是增量开发,具有大的,截止日期驱动的可交付成果,并且开发人员没有实际的利益相关者责任.
如果开发者因为不了解而无法设定自己的目标,那么他们必须更多地参与到前面.
Scrum取决于敏捷宣言中概述的四个基本原则.
交互很重要 - 这意味着开发,QA,项目管理和最终用户需要更多地交谈并相互交谈.软件是用计算机的神秘语言编码知识的过程.要对知识进行编码,开发人员必须具备相关知识.[为什么你认为我们把它称为"代码"？] Scrum不是"写规范 - 抛出横向"方法.这是反"写规范 - 抛出横梁"
工作软件很重要 - 这意味着每件作品都必须导致工作发布.没有一套错误修复QA来解决,但工作软件.
客户协作 - 这意味着开发人员必须与业务分析师,最终用户,业务所有者以及能够帮助他们了解他们正在构建的内容的每个人合作.截止日期与下一件交给客户的事情无关.如果客户需要X,那么每个人都可以做到最优先考虑.如果项目计划说构建Y,那就是malarkey的负载.
响应变化 - 这意味着客户可以重新安排以下冲刺的优先级.他们无法在进程中重新安排冲刺(这很疯狂)但是所有以下冲刺都是改变优先级的候选者.
如果客户开车,则截止日期变得不那么人为"项目里程碑",而且"我们首先需要X,然后是Y,而Z部分中的这个东西,我们不再需要它了.现在我们有W,Z是多余的".
Scrum规则规定,所有Sprint项目都需要在Sprint结束时进行"全面测试,可能实现的功能"才能被认为是完整的.Sprint总是按时结束,并且团队没有得到信任,并且不允许在Sprint评论中提供任何未完成的内容 - 包括QA.
从技术上讲,这就是你应该需要的.一个团队承诺一定数量的工作,最终在Sprint结束前两天进入QA并且QA没有及时完成.因此,Sprint的输出为零,他们必须走在客户面前,并承认他们没有任何东西可以展示一个月的工作.
下一次,你会打赌他们会选择更少的工作,并找出如何让它到QA,以便它可以按时完成.
作为一名从事敏捷项目工作2.5年的QA,这是一个非常棘手的问题,我仍然没有得到所有答案.
我作为"三元组"的一部分工作(两个开发人员配对程序+一个QA),我参与了在两周迭代开始时计划会议的故事和估算.正如上面提到的adrianh一样,QAs必须在最初的sprint计划中听到他们的声音.这可能很难,特别是如果你与具有非常强烈个性的开发人员合作,但QAs必须在真正意义上的主张(即不具有侵略性或有力,但尊重地寻求理解真理/ PO和开发人员/技术专家同时使自己理解).我主张在计划鼓励测试驱动的心态时首先制定质量保证任务 - 质量保证可能必须真正地将自己推进以实现这一目标.与有多少人认为软件开发有效但由于多种原因支付红利相反;
QA被听到并且没有降级为被问到"所以你将如何测试它？" 开发者说过他们的作品(瀑布心态)之后.
它允许QA提出测试的想法,同时检查验收标准的可测试性,同时存在真相/采购订单(我确实说他们必须出现在计划会议中,不是吗？!)填补理解上的空白.
它为测试驱动的方法提供了基础 - 在发布测试方法并负责任务后,Devs可以考虑如何生成代码以通过这些测试.
如果步骤1 - 3是您在迭代的其余部分中唯一的TDD活动,那么您仍然比Steve在第一篇文章中假设的情景好一百万倍; "开发人员试图完成他们的任务.通常这些任务需要大部分sprint完成.QA讨厌Dev发布他们可以测试的东西,Dev终于在sprint结束和花费之前的一两天向QA抛出一些错误的代码其余的时间修复QA发现的错误"
毋庸置疑,这有一些关于质量保证的警告;
他们必须准备好让Devs和Truth/PO挑战他们的测试想法并达成妥协; "QA警察"的态度不会在敏捷团队中流露出来.
质量保证任务必须达到难以平衡,既不太详细也不太通用(任务可以写在卡上以便放在"散热器板"上并在每日站立会议上讨论 - 他们需要从"进行中"转移到在迭代期间"完成").
质量保证需要为规划/评估会议做准备.对于看不见的用户故事,不要期望能够只是出现并为您生成一种测试方法!开发人员似乎能够做到这一点,因为他们的任务往往更加明确 - 例如"将x模块更改为与z组件接口"或"重构方法".作为QA,您需要熟悉计划之前引入/更改的功能,以便了解测试范围以及可能应用的测试设计技术.
几乎必不可知的是,自动化测试并在迭代的前两三天内将这些内容写入并"失败",或者至少与开发人员准备好代码时共同使用.然后,您可以运行test/s并查看它们是否按预期通过(正确的QA TDD).这就是你在迭代结束时避开迷你瀑布的方法.您应该在开始编码之前或开始编码时向Devs演示测试,以便他们知道目标是什么.
我说4"几乎是必不可少的",因为有时可以通过预期行为的手动清单(我敢说脚本!)成功实现 - 关键是提前与Devs分享; 跟他们说话!
关于任务主题的上述第2点,我尝试创建粒度为1/2小时到2小时的任务,每个对应于可证明的工作,例如"添加检查错误密码以进行自动测试 - 2小时".虽然这有助于我组织我的工作,但是其他团队成员一直批评它过于详细,并且对我的立场有影响,要么将多个任务从前一天完成移动,要么根本无法完成任何任务,因为我还没有进入他们.人们真的希望在日常站立时看到稳定的进步感,因此在半天或一天的时间内创建任务会更有帮助(但是你可以保留自己的"微任务"列表来完成您用于在站立时传达整体进度的更大任务)
关于上述第4点和第5点; 您提前准备的自动化测试或手动检查清单应该只涵盖快乐路径或关键验收标准.一旦这些通过,您可以计划在迭代结束时进行最后一轮"探索性测试"的额外任务,以检查边缘情况.Devs在那段时间所做的事情是有问题的,因为就他们而言,他们是"代码完整",除非你找到一个bug.一些敏捷从业者提倡首先考虑边缘案例,尽管这也可能有问题,因为如果你没时间用完,你可能无法保证已经提供了验收标准.这是一个精细平衡的决策之一,取决于用户故事的背景和您作为QA的经验!
正如我在开始时所说的那样,我仍然没有得到所有的答案,但希望上面提供一些经验丰富的指针!
京公网安备 11010802040832号 | 京ICP备19059560号-6 