|
|
4 回复 | 直到 11 年前
|
1
7
一般来说,测试人员和文档编制人员(以及其他非开发人员)都是Scrum团队的平等成员。其背后的想法是将风险降到最低。 要求定义“完成”,其中包括一个经过充分测试和记录的潜在可交付产品,这将迫使项目在每个sprint结束时聚集在一起。 如果测试直到开发人员完成之后才开始,那么会发生的事情是在开发人员完成一项任务之后发现大量的错误。所以现在你必须修复这些bug,这是非常缓慢和昂贵的,因为bug相互作用,而且一般规则是:“修复bug的费用随时间呈指数增长。”你早期捕获的bug既便宜又容易修复,后期bug是一个噩梦。 这就是为什么您希望测试(和文档)与开发同步进行的原因。现在你应该问,怎么做!测试很慢,它怎么能和dev同步? 答案是自动化,也就是说,Scrum总是位于XP或敏捷之上,这两者都要求出色的单元测试覆盖率和TDD。这是另一个需要注意的问题。特性开发人员应该同时编写单元测试和系统测试。所有测试自动化都应该由特性开发团队完成。有些地方把特性开发从自动化开发中分离出来,这很糟糕。 好的,现在您有了很好的自动化测试,并且每天至少运行一次。很明显你在练习持续集成,对吗?这大大减少了测试人员的工作量。这就是测试如何与开发保持同步的方法。还有一件事,测试人员现在致力于真正困难和创造性的东西,这些东西不可能或很难自动化,每当他们以这种方式发现一个bug时,暴露这个bug所花费的时间都是自动化的,并且成为日常回归测试的一部分。哎呀,回答得太长了! 现在到问题的第二部分。Scrum是关于纪律的。冲刺很短,不应该在冲刺期间发生积压更改。非技术性工作应该被分支到客户支持团队中,并且他们可以围绕这一点进行Scrum。你说得对,听起来你的文化和实践与Scrum不兼容。 在我的经验中,转换到Scrum/Agile是一个非常痛苦、压力很大的过程,大多数转换尝试都失败了。成功的关键之一是在执行团队中支持Scrum/Agile。从你的描述来看,似乎你没有。 Scrum有成本和收益,但是你做得不好,你可能会花费很少或没有收益。如果你做了错误和糟糕的Scrum,你最好不要做Scrum。 |
|
2
5
如果设计人员和测试人员由于开发依赖性而无法计划冲刺,那么这意味着您的开发计划不正确。这是一个需要解决的问题。 您的团队应该能够说“任务B需要先完成任务A”。任务A将花费8小时,然后任务B将花费4小时”。如果您的任务估计是准确的,那么依赖性根本就不是问题。
如果发生这种情况,那么问题是你没有做Scrum。Scrum工作的唯一方法是管理层完全接受这个过程。这意味着在开发人员进行计划的Sprint工作时,要让他们单独工作30天,并通过Scrum已有的方法添加新的工作。您将愿望列表项添加到产品积压工作中,然后在Sprint计划期间,开发人员和利益相关者就下一个Sprint中要处理的内容达成一致。 如果您一直有客户支持问题干扰了正常的开发,那么您应该认真考虑划分团队,让一个团队致力于在Scrum中开发,并让另一个团队负责处理客户支持问题。然后,你可以在每次冲刺结束时前后旋转人。 |
|
|
3
3
您真的不应该根据Sprint中期提出的更改向Sprint积压工作中添加更改,它们应该只进入产品积压工作中并被忽略,直到Sprint结束。 你应该把你的最后期限和冲刺相一致。我认为在冲刺的中途退出一个任务是可以接受的,但不能引入一个新的任务。 如果你发现你在冲刺中添加了很多任务,那么你的冲刺可能太长了。记住,你的目标是在每个冲刺中完成大约20天的工作,任何时候,你都会开始遇到你描述的问题! 测试人员对任何敏捷过程都很重要,但并不真正适合Scrum,因为理论上没有活动任务的任何人都会选择下一个任务。尝试在任务和人之间选择关联开始进入到日程安排中,这是整个事情都在试图避免的! 测试人员,如果在开发人员附近工作,可以帮助确定一项工作是否真正完成! |
|
|
4
0
首先,您根本没有使用Scrum,您可能使用了一些Scrum实践,但并不是整个过程。
设计人员和测试人员通常在开发完成后处理一项任务,因此他们不能充分计划冲刺,因为这种依赖性。 任务依赖性没有关系,巫婆很少发生,并且有能力进行适当的计划。在sprint计划中,团队应该估计关于done定义的故事。如果它包括并且确实应该包括设计和测试故事,那么完成故事验收标准所需的工作的估计必须包括设计和测试任务。
看来你的冲刺长度比你需要的要长。你为什么不试着把它改短呢?一个好的冲刺长度是您可以提交的长度,以避免冲刺中的更改。我想1周就行了。 这个行为表明你的ScrumMaster没有正确地完成他的工作,因为他没有消除障碍。 |
推荐文章