12

在传统的 Waterfall 中，需求是按照深奥的模板收集的——通常是在 MS-Word 文档中。在“严格”的瀑布模型中，该文档在需求阶段之后被冻结，变更控制/变更管理流程负责引入受控变更。(**) [通常情况下，文件会变成“活文件”，最终变成“活生生的噩梦”]

目前，我要领导一个项目，该项目是将现有桌面应用程序重写为 Web（从 VB 6.0 到 ASP.Net）。客户有一个他想要重写的应用程序的基线版本。[所以需求被冻结......没有范围蔓延]。要按原样重用的数据模型。只迁移前端/业务规则。看应用程序，我觉得它最多只有 3/4 个主要屏幕，仅此而已。

一些团队成员想要在开始新开发之前记录（在我看来是老派的思想）整个事情。我和其他一些人认为，将 UI 转换为 Web 应该相对容易，查找旧代码，编写业务逻辑，进行自动化单元测试，进行集成测试并逐屏交付（或逐个业务功能）

我的问题是：在敏捷开发中，如果我不对其进行优化，我该如何保持“敏捷”。我的观点是写详细的文档是反敏捷的。你怎么看？敏捷大师将如何解决上述问题（将现有的 VB 6.0 应用程序重写为 ASP.Net）？

免责声明： 创建 1000 页的功能规范可能是为了履行合同义务、政治上的必要性，系统可能真的很复杂（现在，“复杂性”的定义是通往黑暗之地的旅程）。

4

8 回答 8

12

首先，如果客户或产品负责人要求拥有（阅读准备支付）文档，您可以制作文档并保持敏捷。

增量和迭代地扩展您的文档，就像您对代码所做的那样。测试一点，编码一点，然后……记录一点。

我看到了三种方法：要么包括在任务估计中编写文档的时间，创建文档特定的任务，要么有文档积压项目/故事。

文档故事的风险在于它们可能计划得很晚，在实施之后很长时间，所以我不推荐这样做。

文档任务具有在迭代计划中可见的优势，因此不应忘记或忽视它们。

于 2008-12-26T14:24:58.947 回答
3

I've put a lot of thought on the subject - we work in a Scrum environment, and we've ended up having difficulties to organize the documentation.

What I'm heading to at the moment, though it's quite early so I don't know if it'll pass the long term test, is to use a wiki for the documentation.

Basically, the workflow is the following :

  1. Stories come up in the backlog
  2. Story gets picked up by a programmer
  3. Programmer does the code, and in the DoD (Definition of Done), also has to write some tests against the new functionnality, and has to edit the wiki to add a page for the new functionnality.

The wiki is organized with mediawiki templates, pretty much inspired from mediawiki extensions doc pages, with the name of the functionnality, the version it has been introduced into, anything that can be usefull. The template adds pictos to distinguish between different kinds of features (and of their status).

At the end of the day, the wiki has the great advantage of letting you add the documentation page without being bothered about where or how to put it, but obviously regularly you need someone to come behind and organize the mess.

The important thing to keep in mind, whatever tool you use, is that the developper should write some doc just after the development has taken place (including technical aspects) - and not before, and not months after...

于 2008-10-25T08:40:03.513 回答
3

敏捷并不意味着“没有规范”。这意味着尽早且经常地测试和发布（但不一定要投入生产）。

Scrum 中的待办事项是“规范”。如果您实际上没有写下和管理功能列表，您将失去功能，并且您将永远无法确定产品何时发布（将无法估计剩余的工作量，因为您有不知道你在哪里或者还有多少事情要做）。功能列表必须由某人管理。最简单的方法是写下产品应该做的所有事情（您可以根据需要获得尽可能复杂的措辞和定义）并跟踪已完成的内容和剩下的事情。您还将如何将工作分配给开发人员并将状态报告给“管理层？

于 2008-10-24T22:17:33.957 回答
3

在我看来，功能规范是必要的，具体取决于技术团队对产品的参与程度以及团队的高级程度。如果技术团队参与产品定义，您肯定需要更少的文档，因为假设的空间会更小。如果您有一个由初级工程师组成的团队，您需要更强大的文档，否则事情将不会按照冲刺结束时定义的方式完成。
另请注意，由于不接近利益相关者和产品远见者的天然障碍，远程团队需要更多功能规范形式的文档。拥有预先的功能规范是敏捷的一个特征。我看到很多技术团队的任务仅由用户故事描述，而且我经常看到这些团队未能实现发布并满足利益相关者的期望。

这个主题非常广泛，有很多意见，但在我看来，这可以归结为开发人员不必猜测需求这一事实。

事实上，我相信可交付成果的成功和质量与开发人员需要做出的猜测/假设的数量成反比。我认为敏捷性会随着指定的好坏而增加，因为你会犯更少的错误，并且会花费更少的时间来纠正这些错误。

于 2016-04-11T08:58:29.883 回答
2

如果创建功能规范是合同的必要条件，那么您应该仔细考虑其中的内容。如果您未能兑现您在功能规格中的承诺，您可能会被拒绝付款。

不幸的是，如果你采用这个过程，你将不会保持非常敏捷。客户真的希望重新编写的应用程序具有相同的功能吗？如果是，那为什么要重写？我确信有一个从未使用过的功能。

我不会费心记录旧版本。您已经有一个参考，即应用程序本身。软件中没有歧义。

文档编写不是反敏捷的。在没有优先考虑并从客户那里获得反馈的情况下设计一些东西是。敏捷的一个重要方面是获得客户的认可。如果他们不相信，那么该项目将比应有的更艰难。

于 2008-10-25T08:31:53.453 回答
2

正如已经指出的那样，敏捷并不意味着很少或没有文档——“工作软件优于综合文档”。

我处理文档的方式几乎是颠倒过来，只考虑文档的所有部分（包括作为技术规范的代码和单元测试）。因此，描述业务/用户需求的故事（或您用来分配工作的任何其他机制）应该足够详细，以供从事工作的团队估计；否则，它是不完整和模糊的。此外，我在自己的实践中做的事情，如果故事（或其他）估计需要超过一个工作日才能符合团队对“完成”的定义，它很可能应该被分解（这种原子化然后编译最终导致相当广泛的文档，但不会像不这样做那样假设很多未知数 - 并且可以导致非常有趣的重用和模式启示）。

使用 BDD 样式要求的示例：

Given I am working on a document
When I select "Save As..."
Then a menu should appear allowing me to choose a name, 
and a file type, 
and a location in the file system,
and a file should be created in the file system

我们可能需要/想要添加 UI 元素来完成此操作，菜单项、情节提要、键盘快捷键等。等等。

所有这些相关的工件都可以附加到基础故事/需求上；产生更完整的文档。但是，仅将您实际实施的那些故事添加到您的软件 Web 版本的文档中。

这就是事情变得有点颠倒并变得更加“敏捷”的地方。在开发期间和开发之后，重新访问文档化的需求并添加团队编辑所做的更改/修改/改进（无需通过仅文档化的 CCB）。编辑/更新文档和相关资产的能力无需通过所有审查委员会和诸如此类的 - 或者当我们在开发过程中发现文档在某种程度上不完整时将文档“扔回墙上”使我们能够适应未知数 - 因此，敏捷。

该文档应该具有某种形式的版本控制或历史记录，它允许我们描述我们想要的系统，但也描述实际实现的系统 - 注意另一个关于文档是完成定义的一部分的答案/建议（我也做）。（Wiki 对此有好处；然而，一个完全集成的概念更可取 - 例如，能够将票证与版本控制系统中的主干中的文件相关联会很好。）

总结一下。预先创建详尽的文档，在开发工作期间和/或之后不久就无法更改，这将使您无法敏捷 - 能够快速适应未知情况。然而，参考领先的精益软件开发，他们提到如果政策不允许正确使用某些实践/流程，那么你是否说你是精益（或 scrum 或敏捷）都没关系。

确保您不会过于详尽的一种方法-可能已经在此答案中使用了这种心态-仅在需要时才编写所需的内容（通常在开发中存在类似的概念）。另一种方法是让每个人都明白，您不需要预先尝试并弄清楚所有事情（从瀑布到敏捷的最大转变） - 我们将记录每个想法，它可能会或可能不会最终发布。最后，弃用（并删除）任何不再适用的东西……我记得曾经看过一个系统的文档，当我查看系统时，有一半的文档实际上不再适用于系统了。

于 2013-03-17T16:32:48.940 回答
1

由于您有一份描述产品应该做什么的文档，我会将其用作初始积压工作，并开始将工作拆分为从最高优先级到最低优先级排序的小块。然后将在迭代期间处理每组片段。简而言之，将 Scrum 与您的初始文档一起用作 backlog。

如果不进行优先级排序工作，我不会直接进行实施。它不需要大量的写作，但更多地参考您想要处理的部分。

我不会预先记录整个事情。

此外，您将有一些与您要处理的平台直接相关的任务，这些任务需要被捕获并添加到 sprint backlog 中。

此外，您可能会意识到您不想在几次迭代后实现所有需求。

于 2008-10-24T22:30:59.860 回答
1

敏捷有一个以敏捷特性列表、产品待办列表形式存在的功能规范文档，甚至在冲刺待办列表中的任务也是如此。它们不被称为文件的事实并没有减少它们。与瀑布中的功能规范的区别？...敏捷功能规范仅包含所需的内容（哈哈），因此内容较少，还记得您的“工作软件优于综合文档”吗？

于 2014-07-03T13:29:58.863 回答