功能规范和敏捷过程

在传统的瀑布中,需求被收集 - 通常在MS-Word文档中 - 遵循一个深奥的模板.在"严格"瀑布模型中,此文档在需求阶段后冻结,并且变更控制/变更管理流程负责引入受控变更.(**)[通常,文件变成"活文件",最终成为"生活噩梦"]

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

一些团队成员希望在他们开始新开发之前记录(在我看来,旧的思想流派).我和其他一些人认为,将UI转换为Web,查找旧代码,编写业务逻辑,进行自动化单元测试,继续进行集成测试以及按屏幕(或按功能划分的业务功能)进行屏幕显示相对容易

我的问题是:在敏捷开发中,如果我不优化它,我将如何保持"敏捷".我的意见是编写详细的文档是反敏捷的.你怎么看？敏捷大师将如何解决上述问题(将现有的VB 6.0应用程序重写为ASP.Net)？

免责声明: 创建1000页的功能规格可能是为了履行合同义务,这是一种政治需要,系统可能真的很复杂(现在,"复杂性"的定义是一片黑暗的旅程).

首先,如果客户或产品负责人要求(已准备好支付)文档,您可以生成文档并保持敏捷.

正如您将使用代码一样,逐步和迭代地扩展文档.测试一点,编码一点......文档稍微.

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

文档故事的风险在于它们可能计划很晚,很长一段时间后才实施,因此我不建议这样做.

文档任务具有在迭代计划中可见的优点,因此不应忘记或忽略它们.