Have you tried working with your customer to define / formulate acceptance tests? Using something like Fit to come up with these tests - would result in better specs as well as force the customer to think about what is really required. The icing on the cake is instant-doc-executable specs at the end of this process.
That is of course, if your customers are available and open to this approach. Give it a try!
If not (and that seems to be the majority - because it is less work) - calendar flash 'em - schedule meetings/telecons every week until they sing like canaries :) +1 to Dana
I'm a big believer in Use Cases, detailing the system behaviour in response to user actions. Collectively these can form a loose set of requirements, and in a SCRUM environment can help you prioritise the Use Cases which will form that particular sprint's implemented features.
For example, after talking to your functional team you identify 15 separate Use Cases. You prioritise the Use Cases, and decided to plan for 5 sprints. And the end of each sprint you go through and demo the product fulfilling the Use Cases implemented during the sprint, noting the feedback and amending the Use Cases.
Sometimes the easiest way to get input from people is to force it out of them. My company used SCRUM on a project, and found very quickly that people tend to keep to themselves when they already know what they're doing. We ended up organizing weekly meetings where team members were required to display something that was learned during the week. It was forced, but it worked pretty well.
请记住，随着产品的发展，PO 在看到工作产品时应该有想法。 这并不是一件坏事，实际上这是你可以通过敏捷获得的最好的东西之一。 需要注意的是，这个想法必须包含在产品待办事项列表中，并且需要由 PO 确定优先级。 而且，如果有必要并且会为客户增加价值，则应该计划在下一个冲刺中构建该想法。
I understand that the people you call functional people are acting as Product Owners, right?
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?
Actually, without having any specs you probably have no acceptance test for the backlog itens as well. You should ask the PO to write the user stories, I like the "As a - type of user -, I want -some goal- so that -some reason-." form. Keep in mind that the User Stories shall be INVEST - Independent, Negotiable, Valuable to users or customers, Estimable, Small and Testable. What is a must is to have the Acceptance tests written together with the story so that the team should know what the story must be able to do in order do be set as done.
Remember that as the product evolves, it's expected to the PO have ideas as he sees the working product. It's not a bad thing, actually it is one of the best thing you can get through Agile. What you have to pay attention is that this ideas mus be included in the product backlog and it needs to be prioritized by th PO. And, if it's necessary and will add value to the customer, the idea should be planned to be built in the next sprint.
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.
I agree that you need some sort of requirements (user stories or else).
One piece of advice I can give is to use some sort of visual aids with the functional teams. When customers have plenty of ideas (as you've said) they usually also have a visual idea of what a feature looks like, when the developed product doesn't fit this visual idea it creates a lot of doubts, even if it does the job functionally.
When discussing functionality with customers, I try to be very visual. Drawing sketches on a board, or even verbally describing what something would look like. Trying to find a common visual image. You can then take a photo of the sketches and use them as part of the documentation.
Another advice is to keep your sprints as short as possible, so that you do more frequent demos. But you may already be doing this, since you didn't mention your current sprint duration.
I recommend the book "Practices of an agile developer" it is full of suggestions how to make a scrum team successful. It also gives good tips how to get the product owner/customer more involved and how to get the whole process rolling. It's worth the money IMHO.
发布评论
评论（9）
您是否尝试过与客户合作定义/制定验收测试？
使用像 Fit 这样的东西来进行这些测试 - 将产生更好的规格，并迫使客户考虑真正需要什么。 在此过程结束时，锦上添花的是即时文档可执行规范。
当然，前提是您的客户愿意并且愿意接受这种方法。 试一试！
如果没有（这似乎是大多数 - 因为工作量较少） - 日历闪现 - 每周安排会议/电话会议，直到他们像金丝雀一样唱歌:) +1给Dana
Have you tried working with your customer to define / formulate acceptance tests?
Using something like Fit to come up with these tests - would result in better specs as well as force the customer to think about what is really required. The icing on the cake is instant-doc-executable specs at the end of this process.
That is of course, if your customers are available and open to this approach. Give it a try!
If not (and that seems to be the majority - because it is less work) - calendar flash 'em - schedule meetings/telecons every week until they sing like canaries :) +1 to Dana
我非常相信用例，它详细说明了响应用户操作的系统行为。 总的来说，这些可以形成一组松散的需求，并且在 SCRUM 环境中可以帮助您确定用例的优先级，这些用例将形成特定冲刺的已实现功能。
例如，在与您的职能团队交谈后，您确定了 15 个单独的用例。 您确定了用例的优先级，并决定规划 5 个冲刺。 在每个冲刺结束时，您都会经历并演示满足冲刺期间实施的用例的产品，记录反馈并修改用例。
I'm a big believer in Use Cases, detailing the system behaviour in response to user actions. Collectively these can form a loose set of requirements, and in a SCRUM environment can help you prioritise the Use Cases which will form that particular sprint's implemented features.
For example, after talking to your functional team you identify 15 separate Use Cases. You prioritise the Use Cases, and decided to plan for 5 sprints. And the end of each sprint you go through and demo the product fulfilling the Use Cases implemented during the sprint, noting the feedback and amending the Use Cases.
有时，从人们那里获取意见的最简单方法就是强迫他们发表意见。 我的公司在一个项目中使用了 SCRUM，很快就发现，当人们已经知道自己在做什么时，他们往往会保持沉默。 我们最终组织了每周一次的会议，要求团队成员展示本周学到的东西。 这是被迫的，但效果很好。
Sometimes the easiest way to get input from people is to force it out of them. My company used SCRUM on a project, and found very quickly that people tend to keep to themselves when they already know what they're doing. We ended up organizing weekly meetings where team members were required to display something that was learned during the week. It was forced, but it worked pretty well.
我知道你所说的职能人员是产品负责人，对吗？
实际上，如果没有任何规范，您可能也无法对积压的项目进行验收测试。 你应该要求 PO 编写用户故事，我喜欢“作为一种 - 类型的用户 -，我想要 - 一些目标 - 以便 - 一些原因 -”。 形式。 请记住，用户故事应具有投资性 - 独立、N可协商、V对用户或客户有价值、E< /strong>stimable、Small 和Testable。 必须将验收测试与故事一起编写，以便团队应该知道故事必须能够做什么才能完成。
请记住，随着产品的发展，PO 在看到工作产品时应该有想法。 这并不是一件坏事，实际上这是你可以通过敏捷获得的最好的东西之一。 需要注意的是，这个想法必须包含在产品待办事项列表中，并且需要由 PO 确定优先级。 而且，如果有必要并且会为客户增加价值，则应该计划在下一个冲刺中构建该想法。
I understand that the people you call functional people are acting as Product Owners, right?
Actually, without having any specs you probably have no acceptance test for the backlog itens as well. You should ask the PO to write the user stories, I like the "As a - type of user -, I want -some goal- so that -some reason-." form. Keep in mind that the User Stories shall be INVEST - Independent, Negotiable, Valuable to users or customers, Estimable, Small and Testable. What is a must is to have the Acceptance tests written together with the story so that the team should know what the story must be able to do in order do be set as done.
Remember that as the product evolves, it's expected to the PO have ideas as he sees the working product. It's not a bad thing, actually it is one of the best thing you can get through Agile. What you have to pay attention is that this ideas mus be included in the product backlog and it needs to be prioritized by th PO. And, if it's necessary and will add value to the customer, the idea should be planned to be built in the next sprint.
职能团队中的某个人应该是团队的一部分，并且可以回答您有关所添加功能的问题。
如果 Backlog 项目不够详细，您如何估计它们？
您可以建立一个规则，即无法计划没有明确验收标准的积压项目。
如果让职能团队中的某个人担任产品负责人来确定、选择待办事项并确定其优先级，和/或担任领域专家会更好。
另外，确保职能团队和开发团队中的每个人都使用相同的语言，以避免误解； 请参阅无处不在的语言。
跟踪等待职能团队答复的最长时间，以及浪费在开发不必要的功能或重新设计现有功能以使其符合要求的时间。
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.
我同意您需要某种要求（用户故事或其他）。
我可以给出的一条建议是对职能团队使用某种视觉辅助工具。 当客户有很多想法时（正如你所说的），他们通常也会对某个功能的外观有一个直观的想法，当开发的产品不符合这个视觉想法时，就会产生很多疑问，即使它确实符合这个视觉想法。功能上的工作。
当与客户讨论功能时，我尝试非常直观。 在板上画草图，甚至口头描述某物的外观。 试图找到一个共同的视觉形象。 然后，您可以拍摄草图照片并将其用作文档的一部分。
另一个建议是让你的冲刺尽可能短，这样你就可以进行更频繁的演示。 但您可能已经在这样做了，因为您没有提及当前的冲刺持续时间。
I agree that you need some sort of requirements (user stories or else).
One piece of advice I can give is to use some sort of visual aids with the functional teams. When customers have plenty of ideas (as you've said) they usually also have a visual idea of what a feature looks like, when the developed product doesn't fit this visual idea it creates a lot of doubts, even if it does the job functionally.
When discussing functionality with customers, I try to be very visual. Drawing sketches on a board, or even verbally describing what something would look like. Trying to find a common visual image. You can then take a photo of the sketches and use them as part of the documentation.
Another advice is to keep your sprints as short as possible, so that you do more frequent demos. But you may already be doing this, since you didn't mention your current sprint duration.
您正在举行站立会议吗？您有燃尽图吗？ 我认为这两个领域会让你受益匪浅。
Are you doing stand-up meetings and do you have burn down chart? I think those two areas would benefit you greatly.
他们参加站立会议吗？
您可以建议在每个（或某些）他们中派出一名代表，在冲刺结束之前要求他们提供意见
Are they participating in the stand-up meetings?
You could propose to have a representative at each (or some) of them, to ask them for input before the end of the sprint
我推荐这本书“敏捷开发人员的实践”充满了如何使 Scrum 团队取得成功的建议。 它还提供了如何让产品负责人/客户更多地参与以及如何让整个过程顺利进行的好建议。 恕我直言，这是值得的。
I recommend the book "Practices of an agile developer" it is full of suggestions how to make a scrum team successful. It also gives good tips how to get the product owner/customer more involved and how to get the whole process rolling. It's worth the money IMHO.