7

We attempt to do agile development at my current job and we succeed for the most part. The main problem seems to be that the developers on the project are always waiting for requirements at the beginning of the sprint and rushing to get get things down by the end. The business analysts who are delivering the requirements are always working non-stop to get the requirements done.

EDIT: Additional Information: We are customizing a COTS application for our internal use. Our 'user stories' just consist of what part of the application we will be customizing in the specific sprint and also what systems we will integrate with internally. The integration with different systems normally works pretty well because we can start working on that right away. The 'customize x screen' are the main problems areas because the developers can't do anything from that. We have to wait until we get the requirements from the BAs before we can really do anything.

EDIT: More insight/confusion perhaps: I wonder if part of the problem is that the screen that are being customized are already there as this is a COTS product that is being heavily customized. People suggest that the user stories should be along the lines of 'make a screen that does X'. That's already done. Maybe there isn't a good way to do user stories for these requirements... maybe this need to be a whole new question.

4

10 回答 10

9

Don't wait. Build a prototype based on whatever minimal requirements you do have and get feedback ASAP from the product owner. More often than not they don't know what they want anyway - if you can show them something tangible as a starting point you're more likely to get useful feedback. Also, once you have a better idea of the real requirements you will probably have already gained a lot of insight from developing your prototype.

于 2008-09-23T19:12:43.753 回答
4

如果我正确理解您的情况，那么 BA 就是落后的人。您可以尝试两件事。

  1. 尝试小冲刺或更小的需求块。无论哪种方式，BA 的工作都应该更加简洁和易于管理。

  2. 进行交互以返工或消除错误。这应该让 BA 有时间走在曲线的前面。

但是，如果问题在于 BA 在提出更多要求之前需要在“狂野”中看到先前的要求，那么您将面临更大的问题。:)

于 2008-09-23T19:14:29.430 回答
3

At a previous position we managed this by asking our business customers to be a week ahead or so. Sure this breaks from some of the strict interpretations of agile but it made things so much easier. We would have both testing and the business working a week or 2 off from development so when developers were working on iteration 2 testing is working on what came out of IT1 and the business is on IT3. Priority was always given to active development so sometimes it broke down if a story was particularly flexible (i.e. the business had to spend lots of time revising things mid iteration) but overall it worked well.

Update to respond to the questioneers Update

It seems to me those don't really stand on their own as stories then and maybe the BA team needs to reevaluate how they are writing stories. I mean you can't reall "tell a tale" with customize X screen. In theory a story should be something like "When the user goes to screen X they should be able to modify (and save) the floozit"

于 2008-09-23T19:13:46.607 回答
2

Sounds like the BAs may not be handing you your user stories for the sprint in a timely manner.

I take it that there is no sprint planning sessions from what you say.

Given that one of the big tenets of Scrum is that the development team takes responsibility for what they will work on per sprint, it sounds like this ain't too agile to me! (-:

Apart from having short sprints that is.

于 2008-09-23T19:14:28.743 回答
1

好吧，有几件事可能会有所帮助 - 在 SCRUM 过程中，有产品负责人的概念，它是猪角色，它代表客户。因此，您可以邀请 PLM 或客户的主要联系人参加您的 SCRUM 会议。这将使您的客户对您的流程有一定的认可，并使他们与您“一起”实现您的目标 - 每周为客户构建可能会有所帮助。因此，每周投放的基本思想是向客户展示“进步”。因此，如果几个星期没有进展，这应该提出“为什么？”的问题。然后您应该能够解释这是因为缺乏需求最终确定。

希望这可以帮助

于 2008-09-23T19:16:47.910 回答
1

“用户故事”是未来对话的占位符，因此请到客户面前询问他们；如果那是 BA 的工作，那就生火吧；-)

于 2008-09-23T19:40:26.013 回答
1

您的用户故事不完整。“自定义 X 屏幕”是一项任务，它不描述任何要求或完成标准。用户故事应该类似于“允许 Nancy 查看库存中物品的相关采购订单”。然后将其分解为您可以在 sprint 期间处理的任务。

一旦 BA 开发了一个可行的用户故事，然后将其添加到您的产品 backlog 中，对其进行优先排序，并为最重要的 backlog 项目计划您的 sprint。BA 应该独立于您的 sprint 开发用户故事并添加到您的待办事项中，因此不会阻碍您。在冲刺期间，任务完成并且用户故事没有改变。发布后，客户提供反馈，这些反馈作为更多用户故事进入产品积压。

于 2008-09-23T19:48:52.497 回答
0

我看到了几种处理方法：

选项 1，在 SCRUM 下，您应该有一个产品负责人来管理您的产品待办事项，该待办事项应该包含对软件功能的请求。如果该功能包含诸如“自定义屏幕 X”之类的模糊内容，并且您决定将其添加到您的 sprint 中，那么 sprint 任务应该是具体的分解任务，我想说其中一项任务必须是“定义屏幕要求X'。

在每日 SCRUM 中，当您向每个团队成员询问三个问题时，拥有该屏幕模块任务的开发人员会说“我被阻止等待 BA 的要求。”，您的 Scrum 主管会尽其所能让它继续前进。

在我看来，选项 2 是项目不会进入您的产品 backlog，直到它们被定义得足够好，至少可以进行一些生产性工作。我们都知道需求会发生变化，但关键是您应该有足够的资源开始。

于 2008-09-23T21:34:51.947 回答
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

相信我，一旦你让这股潮流继续下去，你就永远不会回头。

于 2008-09-24T09:56:44.737 回答
0

如上所述，通常在每个 sprint 开始时，您应该优先考虑现有的 backlog，并为当前的 sprint 挑选一些故事。如果没有足够的用户故事供开发人员使用，您应该将开发人员转移到另一个项目，并让产品负责人有时间为该项目创建一个体面的（=足以养活一些团队）积压工作。

于 2012-04-17T18:45:05.983 回答