0

We are a small team of 3 developers (2 experienced but new to this particular business sector) developing a functionally complex product. We're using Scrum and have a demo at the end of each sprint. Its clear that the functional team have plenty of ideas but these are not well communicated to the development team and the demo poses more questions than answers.

Have you any recommendations for improving the the quality of input from the functional people?

Further info: I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?

4

9 回答 9

2

您是否尝试过与客户合作定义/制定验收测试
使用 Fit 之类的东西来进行这些测试 - 会产生更好的规格,并迫使客户考虑真正需要什么。锦上添花的是此过程结束时的即时文档可执行规范。

当然,前提是您的客户有空并对这种方法持开放态度。试试看!

如果不是(这似乎是大多数 - 因为它的工作量较少) - 日历闪现 - 每周安排会议/电话,直到他们像金丝雀一样唱歌:) +1 给 Dana

于 2008-08-26T18:59:07.133 回答
1

有时,从人们那里获得意见的最简单方法是强迫他们发表意见。我的公司在一个项目中使用了 SCRUM,并且很快发现当人们已经知道自己在做什么时,他们往往会保持沉默。我们最终组织了每周例会,要求团队成员展示一周中学到的东西。这是被迫的,但效果很好。

于 2008-08-26T18:58:52.923 回答
1

我非常相信用例,详细说明系统行为以响应用户操作。总的来说,这些可以形成一组松散的需求,并且在 SCRUM 环境中可以帮助您优先考虑将形成特定 sprint 实现的功能的用例。

例如,在与您的职能团队交谈后,您确定了 15 个单独的用例。您优先考虑用例,并决定计划 5 个 sprint。并且在每个 sprint 结束时,您要演示满足在 sprint 期间实施的用例的产品,注意反馈并修改用例。

于 2008-08-27T14:05:21.530 回答
1

Someone from the functional team should be part of the team and available to answer your questions about the features you're adding.

How can you estimate the Backlog item if they are not detailled enough ?

You could establissh a rule that Backlog item that do not have clear acceptance criteria cannot be planned.

If would be better to have someone from the functional team acting as Product Owner, to determine, choose and priotitize the Backlog items, and/or as Domain Expert.

Also, make sure everyone in both the functional team and the development team speaks the same language, so as to avoid misunderstandings ; See ubiquitous language.

Track the time most waiting for answers from the functional team as well as he time wasted developping unnecessary features or reworking existing features so that they fits the bill.

于 2008-10-04T13:05:07.587 回答
1

我知道你称之为职能人员的人是产品负责人,对吗?

我认为部分问题在于没有这样的规范或用户故事。就我个人而言,我认为他们需要写下某种要求——他们应该写下什么样的东西,以及考虑到敏捷过程的复杂性是什么?

实际上,如果没有任何规范,您可能也没有对积压工作的验收测试。你应该让 PO 来写用户故事,我喜欢“作为一种用户类型,我想要一些目标,这样一些理由”。形式。请记住,用户故事应该是 INVEST -独立的、可协商的、对用户或客户有价值的、E stimable S mall测试。必须将验收测试与故事一起编写,以便团队应该知道故事必须能够做什么才能将其设置为已完成。

请记住,随着产品的发展,PO 在看到工作产品时会产生想法。这不是一件坏事,实际上它是你可以通过敏捷获得的最好的东西之一。您需要注意的是,这个想法必须包含在产品积压中,并且需要由 PO 优先考虑。而且,如果有必要并且会为客户增加价值,则应该计划在下一个 sprint 中构建这个想法。

于 2008-09-16T05:56:14.657 回答
0

你在做站立会议吗?你有燃尽图吗?我认为这两个领域会让你受益匪浅。

于 2008-09-14T20:03:35.887 回答
0

他们是否参加站立会议?

您可以提议在每个(或部分)中派一个代表,在 sprint 结束前征求他们的意见

于 2008-08-26T18:57:22.897 回答
0

我推荐《敏捷开发者的实践》这本书,里面充满了如何让 Scrum 团队成功的建议。它还提供了如何让产品所有者/客户更多地参与以及如何让整个过程滚动的很好的提示。恕我直言,这是物有所值的。

于 2008-09-23T18:03:20.677 回答
0

我同意您需要某种要求(用户故事或其他)。

我可以给出的一条建议是在职能团队中使用某种视觉辅助工具。当客户有很多想法(如你所说)时,他们通常也会对某个功能的外观有一个视觉想法,当开发的产品不符合这个视觉想法时,它会产生很多疑问,即使它符合在功能上工作。

在与客户讨论功能时,我尽量表现得非常直观。在板上画草图,甚至口头描述某物的外观。试图找到一个共同的视觉形象。然后,您可以为草图拍照并将其用作文档的一部分。

另一个建议是尽可能缩短 sprint,以便进行更频繁的演示。但是您可能已经这样做了,因为您没有提及您当前的 sprint 持续时间。

于 2015-04-16T18:25:56.297 回答