|
|
10 回复 | 直到 14 年前
|
1
9
别等了。根据你的最低要求建立一个原型,并尽快从产品负责人那里得到反馈。通常情况下,他们不知道自己想要什么——如果你能让他们看到一些切实的东西作为起点,你就更有可能得到有用的反馈。另外,一旦你对实际需求有了更好的了解,你可能已经从开发原型中获得了很多洞察力。 |
|
|
2
4
如果我正确地理解你的情况,BAS是落后的。有两件事你可以试试。
然而,如果问题是,在提出更多的需求之前,bas需要在“野生”中看到以前的需求,那么您将面临更大的问题。:) |
|
|
3
3
在之前的一个职位上,我们要求我们的商业客户提前一周左右完成这项工作。当然,这打破了对敏捷的一些严格解释,但它让事情变得简单多了。我们会让测试和业务在开发后一周或两周内工作,所以当开发人员在进行迭代2测试时,测试是在研究it1的结果,而业务是在it3上。总是优先考虑主动开发,因此如果一个故事特别灵活(即,业务在迭代过程中必须花费大量时间修改东西),它有时会崩溃,但总体来说它工作得很好。 更新以响应提问者的更新 在我看来,这些人并不是真的把自己当作故事来看待,也许英航团队需要重新评估他们是如何写故事的。我是说你不能用定制的X屏幕来“讲故事”。理论上讲,故事应该类似于“当用户进入屏幕x时,他们应该能够修改(并保存)floozit” |
|
|
4
2
听起来,bas可能没有及时向您提供sprint的用户故事。 我认为从你所说的来看,没有冲刺计划会议。 考虑到scrum的一个重要原则是开发团队负责每个sprint的工作,这听起来对我来说并不太灵活!(-) 除了短跑。 |
|
|
5
1
好吧,有几件事可能会有帮助 -在scrum过程中,有一个概念,产品所有者wch是一个pig角色,它代表客户。所以你可以邀请PLM或者客户的主要联系人参加你的Scrum会议。这会让你的客户对你的流程有一些认同感,并让他们与你一起实现你的目标。 -每周向客户端生成可能会有所帮助。所以,每周下降的基本思想是显示客户的“进展”。因此,如果几周内没有进展,这应该会引发一个问题:“为什么?”然后您应该能够解释,这是因为缺少需求定稿。 希望这有帮助 |
|
|
6
1
“用户故事”是 未来对话的占位符 ,所以当着客户的面问他们;如果这是BA的工作,那就点火;-) |
|
|
7
1
你的用户故事不完整。“自定义X屏幕”是一项任务,它不描述任何要求或完成条件。用户故事应该类似于“允许Nancy查看库存中项目的相关采购订单”。然后在你的冲刺中把它分解成你可以处理的任务。 一旦BAS开发出一个可行的用户故事 然后 将它添加到您的产品待办事项中,对其进行优先级排序,并为顶级待办事项计划冲刺。bas应该独立于sprint开发用户故事并添加到您的backlog中,因此不会阻塞您。在sprint过程中,任务完成,用户故事不会改变。发布后,客户提供反馈,反馈作为更多的用户故事进入产品待办事项列表。 |
|
|
8
0
我看到了几种处理方法: 选项1,在scrum下,您应该有一个负责管理您的产品backlog的产品所有者,它应该包含对软件特性的请求。如果这个特性包含一些模糊的东西,比如“定制screen x”,并且您决定将其添加到sprint中,那么sprint任务应该是具体的、分解的任务,我认为其中一个任务必须是“定义screenx的需求”。 在每天的scrum中,当你向每个团队成员提出三个问题时,拥有screen mod任务的开发人员会说“我被阻止等待ba的需求”,而你的scrum管理员会尽他们所能让他们继续前进。 选项2,在我看来,是项目不进入你的产品积压,直到他们被定义得足够好,至少做一些生产性的工作。我们都知道需求会改变,但关键是你应该有足够的开始。 |
|
|
9
0
容易的。 让你自己在scrum的严格规则之外思考,回到你的精益之根: http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/ http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/ http://www.infoq.com/articles/hiranabe-lean-agile-kanban 相信我,一旦你得到了流动,你将永远不会回头。 |
|
|
10
0
如上所述,通常在每个sprint开始时,您应该优先处理现有的backlog,并为当前sprint选择一些故事。如果没有足够的用户故事供开发人员使用,那么您应该将开发人员转移到另一个项目,让产品所有者有时间为项目创建一个像样的(足够大,可以满足某些团队的)backlog。 |
推荐文章