The important question to ask yourself when writing these specs, is why do we do them? What is the value in the spec?
The value in the spec usually comes in communicating the ideas of the business with the development team. Scrum is designed to bring the business (in the form of the Product Owner) to the development team. By interacting with the team frequently (remember, individuals and interactions over processes and tools), and by seeing working software frequently, the business can work hand in hand with developers to produce software that solves business problems better than by trying to spec out the whole thing before you get to try it out.
This is how Agile projects do a better job of delivering the product the business wants instead of the product they requested.
That said, there are certain base criteria that need to be met. We can test for this, and as with any good tests, we can automate it.
Have a look at BDD and Cucumber. In addition to your User Story, it's good to have a basic set of conditions of satisfaction, preferably in the "Give/When/Then" format. These conditions are the minimum set of criteria for the story to be accepted as complete.
For example, "Given I am logged in, when I log out, then I am taken back to the home page".
If you're going to have acceptance criteria, you're going to want to automate it. The worst part of most specifications is they often end up out of date and collecting dust when the project is complete.
Also, you shouldn't be assigning tasks to the team. Scrum teams are self organizing and anyone should be able to grab any task they feel they can work on while respecting the priority of the stories. Swarming is a big part of the performance benefits of Scrum.
You may want to consider bringing in an outside coach to assist with your transition.
I think that the easiest way is to make the specifications a part of the user stories within the tasks, themselves. Clearly list the acceptance criteria in each one (or if your issue tracking software allows you, create them as first class work item types). Let the issue in whatever you use for work item tracking become the living document.
There are drawbacks, such as finding related issues as specs change over time, but this can usually be managed in the work item tracking tooling, assuming your can relate issues to each other.
The way that we do it is that we (actually a BA, not the developers) creates a sign-off deck for the product owner to review and we collaboratively create tasks off of that. If we cannot create a task, or there are open questions, we will go back to the product owner with those questions and update the deck. All of our decks are organized (in SharePoint) so that we can easily find them in the future.
For me the specs is in the user stories. We define the specs and the tasks duing out initial scrum meeting along with the product owner. The specs and tasks are just for the life time of the scrum iteration as everything might change in the next iteration(in the worst case but there will definitively be changes).
We usually keep track of the specifications and task on a spreadsheet just so that everybody know what they are working on. I have also tried a few software to do this and one of the most interesting ones I have come across is from [VersionOne][1] and also from [Rally][2].
But I still find that using a simple spreadsheet is the fastest and simplest solution.
As I understand SCRUM, it does not take care about specs management. You have to broke/map your specs or specs changes to stories and tasks separately. But you can have a task for this :).
我发现最有帮助的是对故事的大小进行反击。许多组织都疯了，说故事只需几个小时。我认为，最初的 Scrum 书上说是 16 个小时，这通常足以容纳 Web 应用程序的整个屏幕。因此，“实施管理我的帐户”可能是一个故事（而不是“实施用户名”、“实施密码”等数百个小故事的方法），然后参考“管理我的帐户”的设计文档并制作确保有完美的屏幕截图/原型/模型，以便开发人员可以查看它们并将文本直接复制/粘贴到他们正在编写的代码中，并且他们确定需要存在哪些字段（或哪些链接，或哪些图片，或其他什么）。
There is a real tension between Scrum and other agile dev methodologies and spec writing. I think there are two big points of tension:
Because agile says everything should be on an index card, that means you have to have stuff planned out enough to fit on an index card. (E.g. you have to know how it's all going to work.)
Some things don't make sense in isolation (what's the use of an upload file page without a manage uploaded files page, for instance.)
You don't have to design the whole app all at once, but you have to have a vision of the whole app. Then, especially if you have a separation of designers and programmers, you do functional design for a sprint-sized chunk at a time. Those designs then have to be broken down to story-sized chunks.
This is a lot of up front functional design, and I think that's overlooked in a lot of the talk about agile methodologies. Perhaps some shops have the devs do more of the design. Also, I think it's a lot easier to use scrum/agile for making changes/bug fixes to existing apps rather than building new ones.
The thing I've found most helpful is to fight back on story size. A lot of organizations have gone crazy, saying stories need to be only a few hours. The original scrum book says 16 hours, I think, which is often large enough to fit an entire screen of a web app. So "implement manage my account" could be a story (as opposed to the hundreds-of-tiny-stories approach of "implement username", "implement password" etc.) Then reference your design doc for "Manage My Account" and make sure to have word-perfect screenshots/prototype/mockup so the dev can look at them and copy/paste the text directly into the code they're writing, and they know for sure which fields need to be there (or which links, or which pictures, or whatever).
发布评论
评论（5）
简短的回答是，你不知道。
在编写这些规范时要问自己的重要问题是我们为什么要这样做？规格中的值是多少？
规范的价值通常在于与开发团队沟通业务想法。 Scrum 旨在将业务（以产品负责人的形式）引入开发团队。通过经常与团队互动（记住，个人以及流程和工具上的互动），并通过经常查看工作软件，企业可以与开发人员携手合作，开发出能够比试图规范整个业务问题更好地解决业务问题的软件。在你尝试之前的事情。
这就是敏捷项目如何更好地交付企业想要的产品而不是他们要求的产品。
也就是说，需要满足某些基本标准。我们可以对此进行测试，并且与任何好的测试一样，我们可以将其自动化。
查看 BDD 和 Cucumber。除了用户故事之外，最好有一套基本的满足条件，最好采用“给予/何时/然后”的格式。这些条件是故事被认为完整的最低标准。
例如，“假设我已登录，当我注销时，我将返回主页”。
如果您要制定验收标准，您就会希望使其自动化。大多数规范最糟糕的部分是，当项目完成时，它们往往会过时并积满灰尘。
此外，您不应该向团队分配任务。 Scrum 团队是自组织的，任何人都应该能够抓住他们认为可以完成的任何任务，同时尊重故事的优先级。 Swarming 是 Scrum 性能优势的重要组成部分。
您可能需要考虑聘请外部教练来协助您的过渡。
The short answer is, you don't.
The important question to ask yourself when writing these specs, is why do we do them? What is the value in the spec?
The value in the spec usually comes in communicating the ideas of the business with the development team. Scrum is designed to bring the business (in the form of the Product Owner) to the development team. By interacting with the team frequently (remember, individuals and interactions over processes and tools), and by seeing working software frequently, the business can work hand in hand with developers to produce software that solves business problems better than by trying to spec out the whole thing before you get to try it out.
This is how Agile projects do a better job of delivering the product the business wants instead of the product they requested.
That said, there are certain base criteria that need to be met. We can test for this, and as with any good tests, we can automate it.
Have a look at BDD and Cucumber. In addition to your User Story, it's good to have a basic set of conditions of satisfaction, preferably in the "Give/When/Then" format. These conditions are the minimum set of criteria for the story to be accepted as complete.
For example, "Given I am logged in, when I log out, then I am taken back to the home page".
If you're going to have acceptance criteria, you're going to want to automate it. The worst part of most specifications is they often end up out of date and collecting dust when the project is complete.
Also, you shouldn't be assigning tasks to the team. Scrum teams are self organizing and anyone should be able to grab any task they feel they can work on while respecting the priority of the stories. Swarming is a big part of the performance benefits of Scrum.
You may want to consider bringing in an outside coach to assist with your transition.
我认为最简单的方法是使规范成为任务本身的用户故事的一部分。清楚地列出每个项中的验收标准（或者如果您的问题跟踪软件允许您，将它们创建为一流的工作项类型）。让您用于工作项跟踪的任何内容中的问题成为动态文档。
存在一些缺点，例如随着规范随时间的变化而查找相关问题，但这通常可以在工作项跟踪工具中进行管理，假设您可以将问题相互关联。
我们这样做的方式是，我们（实际上是 BA，而不是开发人员）创建一个签核平台供产品负责人审查，然后我们根据该平台协作创建任务。如果我们无法创建任务，或者存在悬而未决的问题，我们将向产品所有者反馈这些问题并更新卡片组。我们所有的套牌都经过组织（在 SharePoint 中），以便我们将来可以轻松找到它们。
I think that the easiest way is to make the specifications a part of the user stories within the tasks, themselves. Clearly list the acceptance criteria in each one (or if your issue tracking software allows you, create them as first class work item types). Let the issue in whatever you use for work item tracking become the living document.
There are drawbacks, such as finding related issues as specs change over time, but this can usually be managed in the work item tracking tooling, assuming your can relate issues to each other.
The way that we do it is that we (actually a BA, not the developers) creates a sign-off deck for the product owner to review and we collaboratively create tasks off of that. If we cannot create a task, or there are open questions, we will go back to the product owner with those questions and update the deck. All of our decks are organized (in SharePoint) so that we can easily find them in the future.
对我来说，规格就在用户故事中。我们在初始 scrum 会议上与产品负责人一起定义规范和任务。规范和任务仅针对 Scrum 迭代的生命周期，因为下一次迭代中的所有内容都可能会发生变化（在最坏的情况下，但肯定会发生变化）。
我们通常会在电子表格上跟踪规格和任务，以便每个人都知道他们正在做什么。我还尝试了一些软件来执行此操作，我遇到的最有趣的软件之一来自 [VersionOne][1] 和 [Rally][2]。
但我仍然发现使用简单的电子表格是最快、最简单的解决方案。
For me the specs is in the user stories. We define the specs and the tasks duing out initial scrum meeting along with the product owner. The specs and tasks are just for the life time of the scrum iteration as everything might change in the next iteration(in the worst case but there will definitively be changes).
We usually keep track of the specifications and task on a spreadsheet just so that everybody know what they are working on. I have also tried a few software to do this and one of the most interesting ones I have come across is from [VersionOne][1] and also from [Rally][2].
But I still find that using a simple spreadsheet is the fastest and simplest solution.
据我了解 SCRUM，它不关心规范管理。您必须分别将规格或规格更改分解/映射到故事和任务。但你可以为此分配一个任务:)。
As I understand SCRUM, it does not take care about specs management. You have to broke/map your specs or specs changes to stories and tasks separately. But you can have a task for this :).
Scrum 与其他敏捷开发方法和规范编写之间存在着真正的紧张关系。我认为有两大紧张点：
因为敏捷说一切都应该
在索引卡上，这意味着您
必须计划好事情
足够适合索引卡。
（例如，你必须知道这一切是怎么回事
去工作。）
有些事情在
隔离（有什么用
上传文件页面无需管理
例如，上传文件页面。）
您不必一次设计整个应用程序，但您必须对整个应用程序有一个愿景。然后，特别是如果你的设计师和程序员是分离的，你一次可以针对冲刺大小的块进行功能设计。然后，这些设计必须分解为故事大小的块。
这是很多预先的功能设计，我认为在很多关于敏捷方法论的讨论中都忽略了这一点。也许有些商店让开发人员做更多的设计。另外，我认为使用 scrum/agile 对现有应用程序进行更改/错误修复比构建新应用程序要容易得多。
我发现最有帮助的是对故事的大小进行反击。许多组织都疯了，说故事只需几个小时。我认为，最初的 Scrum 书上说是 16 个小时，这通常足以容纳 Web 应用程序的整个屏幕。因此，“实施管理我的帐户”可能是一个故事（而不是“实施用户名”、“实施密码”等数百个小故事的方法），然后参考“管理我的帐户”的设计文档并制作确保有完美的屏幕截图/原型/模型，以便开发人员可以查看它们并将文本直接复制/粘贴到他们正在编写的代码中，并且他们确定需要存在哪些字段（或哪些链接，或哪些图片，或其他什么）。
There is a real tension between Scrum and other agile dev methodologies and spec writing. I think there are two big points of tension:
Because agile says everything should
be on an index card, that means you
have to have stuff planned out
enough to fit on an index card.
(E.g. you have to know how it's all
going to work.)
Some things don't make sense in
isolation (what's the use of an
upload file page without a manage
uploaded files page, for instance.)
You don't have to design the whole app all at once, but you have to have a vision of the whole app. Then, especially if you have a separation of designers and programmers, you do functional design for a sprint-sized chunk at a time. Those designs then have to be broken down to story-sized chunks.
This is a lot of up front functional design, and I think that's overlooked in a lot of the talk about agile methodologies. Perhaps some shops have the devs do more of the design. Also, I think it's a lot easier to use scrum/agile for making changes/bug fixes to existing apps rather than building new ones.
The thing I've found most helpful is to fight back on story size. A lot of organizations have gone crazy, saying stories need to be only a few hours. The original scrum book says 16 hours, I think, which is often large enough to fit an entire screen of a web app. So "implement manage my account" could be a story (as opposed to the hundreds-of-tiny-stories approach of "implement username", "implement password" etc.) Then reference your design doc for "Manage My Account" and make sure to have word-perfect screenshots/prototype/mockup so the dev can look at them and copy/paste the text directly into the code they're writing, and they know for sure which fields need to be there (or which links, or which pictures, or whatever).