logo标签列表

功能规格说明书和敏捷过程

agileagile-processeswaterfall
12
在传统的瀑布模型中，通常使用晦涩难懂的模板收集需求，并将其记录在一个 MS-Word 文档中。在“严格”的瀑布模型中，要求阶段结束后将冻结该文档，并由变更控制/变更管理过程负责引入受控变更。(**) [通常，该文档会变成一个“活性文档”，最终变成一个“活生生的噩梦”]
目前，我需要领导一个项目，对现有的桌面应用程序进行重写，转变为 Web（从 VB 6.0 到 ASP.Net）。客户拥有一个基准版本的应用程序，他希望重写该应用程序。[因此需求已经确定，没有范围蔓延] 数据模型将被重新使用。只需迁移前端/业务规则。看着这个应用程序，我感觉它最多只有3/4个主要屏幕。
一些团队成员想要在开始新开发之前完整地记录下来（我认为这是老派的思想）。我和其他一些人认为，将界面转换为 Web 应该相对容易，查找旧代码，编写业务逻辑，进行自动化单元测试，继续进行集成测试并逐屏幕（或按业务功能）交付。
我的问题是： 在敏捷开发中，如果我不进行优化，我如何保持“敏捷性”。我的观点是编写详细的文档是反敏捷的。你怎么看？敏捷大师会如何处理上述问题（重写现有的 VB 6.0 应用程序到 ASP.Net）？
免责声明： 创建一个1000页的功能规范可能是为了满足合同义务、政治必要性或系统确实复杂（现在，“复杂性”的定义是一次前往泥潭之旅）。
什么是“文档”- 为什么您觉得敏捷是适当的开发方法？ 你已经处于传统的“V”过程的底部。敏捷的价值在哪里？与流行观点相反，敏捷并不总是运行开发计划的最佳方式... - theMayer
1
我投票关闭此问题，因为根据帮助中心的定义，这不是一个编程问题。 - Rob
8个回答
12

首先，如果客户或产品负责人要求提供文档（即准备支付费用），您可以生成文档并保持敏捷性。

像编写代码一样，逐步迭代地增加文档。进行少量测试、少量编码和...少量文档编写。

我认为有三种方法可实现此目标：要么在任务估算中包括编写文档的时间，创建专门的文档编写任务，或者拥有文档编写的待办事项/用户故事。

文档编写的风险在于它们可能计划得非常晚，在实施之后很长时间才会编写，因此我不建议这样做。

文档编写任务的优点是在迭代规划中可见，因此不应被遗忘或忽视。

3
在我看来，功能规格说明书的必要性取决于技术团队对产品的参与程度和团队成员的资历。如果技术团队参与产品定义，你肯定需要较少的文档，因为假设的空间会更小。如果你有一支初级工程师团队，你需要更强的文档支持，否则最终完成的工作可能与最初定义的不同。
同时，请注意由于远程团队与利益相关者和产品愿景之间存在自然障碍，所以需要更多的功能规格说明文档。拥有���先准备好的功能规格说明书是敏捷开发的一个特征。我看到过很多技术团队，其中任务仅由用户故事描述，但往往这些团队无法实现发布并满足利益相关者的期望。

这个主题非常广泛，有很多不同的观点，但在我看来，这可以归结为开发人员不应该猜测需求。

事实上，我认为交付成果的成功和质量与开发人员需要做出的猜测/假设数量成反比。我认为，规范程度越高，敏捷性就越高，因为你会犯更少的错误，并且会花费更少的时间来纠正这些错误。

3
敏捷并不意味着“无规格”。它的意思是早期测试和发布（但不一定要发布到生产环境）。
在 Scrum 中，产品待办事项清单就是“规格”。如果你不实际编写和管理功能列表，你将会失去一些功能，并且永远无法确定产品何时发布（因为你不知道自己在哪里或还有多少工作要做）。必须由某人来管理功能列表。最简单的方法就是写下产品应该做什么（你可以在措辞和定义上变得复杂），并跟踪已完成和未完成的任务。否则，你将无法分配开发人员的工作，并向“管理层”报告状态。
我并不是说“没有规格”，而是它需要多详细呢？同时也要和我正在面对的问题相关联... - Vyas Bharghava
3

我已经认真考虑了这个问题——我们在Scrum环境下工作，但我们遇到了组织文档的困难。

目前我正在思考的是，使用wiki来管理文档，虽然现在还不确定它是否能够通过长期测试。

基本上，工作流程如下：

  1. 在待办事项列表中出现需求故事
  2. 程序员接手需求故事
  3. 程序员编写代码，在DoD（定义完成）中，还必须撰写一些针对新功能的测试，并编辑wiki以添加新功能页面。

该wiki采用mediawiki模板进行组织，与mediawiki扩展文档页面非常相似，包括功能名称、引入版本、任何有用信息等。模板添加图标以区分不同类型的特性（及其状态）。

总之，wiki的一个很大优点是可以让您添加文档页面而不必担心放在哪里或如何放置，但显然需要定期有人来整理混乱。

无论使用什么工具，重要的是开发人员应该在开发完成后立即编写文档（包括技术方面）——而不是在之前或几个月之后...

我有一个团队Wiki[ScrewTurn Wiki]...将Func Spec作为wiki的想法...嘿，我喜欢它（当然，如果客户要求副本，把Wiki页面转换成PDF应该就足够了）。 - Vyas Bharghava
我喜欢你提出的建议，即在开发后立即进行文档记录。臃肿的规格说明最适合律师使用。 - Chad
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元素来完成这个任务，例如菜单项、故事板、键盘快捷键等等（我们可能有多个关于“保存文件”的主题变化）。所有这些相关的文物都可以附加到基本的故事/需求上，从而得到更完整的文档。但是，只有将您实际实现的那些故事添加到您的软件网络版本的文档中。
在这里，事情变得有点颠倒，变得更加“敏捷”。在开发期间和开发后，重新审视记录的要求，并添加团队所做的更改/修改/改进（无需经过仅限于文档的CCB）。能够在不通过所有审核委员会等程序或在开发过程中发现文档某些方面不完整时将文档编辑/更新而不是将其抛回墙上，使我们能够适应未知因素-因此，敏捷。
这份文档应该具有某种形式的版本控制或历史记录，这样我们就可以描述我们所期望的系统，同时还可以描述实际实现的系统-注意到有关文档是定义完成的一部分的另一个答案/建议（我也这样做）。 （Wikis对此很有用；但是，完全集成的概念更加理想-例如，能够将票据与主干中的文件相关联在版本控制系统中会很好。）
总之，事先创建详尽的文档，这些文档不能在开发工作期间或不久之后进行修改，这将使您无法灵活适应未知因素。但是，参考《领先的精益软件开发》一书中提到的，如果政策不允许使用某些实践/流程，那么无论您说自己是精益（或scrum或敏捷），都没有关系。
确保您不过度详尽的一种方法-可能可以在此答案中使用此思维方式-只在需要时编写所需的内容（类似的概念存在于开发中）。另一个方法是让每个人都了解到您无需尝试并在前面找出所有问题（从瀑布到敏捷的最大转变）-我们将记录每个想法，它可能会或可能不会在发布中结束。最后，弃用（和删除）任何不再适用的内容...我曾经看过一份系统文档，当我审查该系统时，该文档的一半实际上不再适用于该系统。
2
如果创建一个功能规格说明书是合同上的必要，那么你应该非常谨慎地考虑其中的内容。如果你未能按照你的功能规格说明书承诺交付结果，你可能会被拒绝付款。
不幸的是，如果你采用这种过程，你将无法保持敏捷性。客户是否真的希望为重新编写的应用程序添加相同的功能？如果是的话，那为什么要重新编写？我相信有一些从未使用过的功能。
我不会费心去记录旧版本。你已经有了参考，即应用程序本身。软件中没有歧义。
撰写文档并不违反敏捷开发原则。违反原则的是在没有优先考虑和获得客户反馈的情况下进行设计。敏捷开发的重要方面之一是获得客户的认可。如果他们不相信它，那么项目将比它应该的更难推进。
Dave，一方面你说如果我写了一个详细的功能规范，我就不会保持敏捷。而你又说[详细的？]文档编写并不是反敏捷的（我实际上是在谈论详尽、冗长的文件）……这两者不是矛盾的吗？ - Vyas Bharghava
1
敏捷开发中有功能规格说明文档，采用敏捷特性列表、产品待办事项，甚至是在冲刺期间的冲刺待办事项中。它们并不叫文档并不代表它们没有价值。与瀑布模型中的功能规格说明书的区别在哪里呢？……敏捷功能规格说明只包含所需内容，因此更加简洁明了，记住“实际交付的软件胜过完整的文档”吗？
1

既然您已经有了描述产品应执行的操作的文档，我会将其用作初始待办事项，并将工作按优先级从高到低拆分成一小块一小块的。然后在每个迭代期间处理每组任务块。简而言之，请使用 Scrum 方法以您的初始文档作为待办事项。

我不会在没有进行这种优先级排序工作的情况下直接进行实现。这并不需要很多写作，但要更多地引用您想要解决的问题块。

我不会事先记录整个过程。

此外，您将有一些与您正在处理的平台直接相关的任务，这些任务需要被捕获并添加到工作周期内的待办事项中。

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接