agile - 功能规范和敏捷流程

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

4年前关闭。




Improve this question




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

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

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

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

免责声明:
创建一个 1000 页的功能规范可能是为了履行契约(Contract)义务、政治上的必要性，系统可能真的很复杂(现在，“复杂性”的定义是通往黑暗之地的旅程)。

Answer 1

一、可以制作文档并保持敏捷 ，如果客户或产品负责人要求拥有(已准备好支付)文档。

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

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

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

文档任务的优势是 可见 在迭代计划中，它们不应该被遗忘或忽视。