假设我们正在创建 Acme CMS。此 CMS Web 应用程序将允许您创建无限数量的带有子类别(无限深度)的类别，并且每个类别可以有 0+ 个与其关联的内容页面。
所以这个项目在高层次上将具有:
前端 1.索引页 2. 类别页面与内容列表页面 3.内容页
管理控制面板 1.类别(添加/更新/删除) 2.页面(添加/更新/删除/)
架构设计 1. 表格 2.存储过程 3.数据访问层
问题: 我正在使用错误跟踪器和 Wiki，那么我应该如何分解这个项目？
我正在考虑将每个部分(前端/管理面板)分解为单独的页面，然后为每个页面(或主题)编写简单的用户故事。
当我完成用户故事后，我将在错误跟踪器中创建一个案例列表，代表我必须开发的功能，以及对每个案例的估计。
我是否正确分解了这个项目？计划中的任何重大缺陷都会导致该项目失败(无论如何都是理论上的!)
请提供详细的答案，也许是我应该做什么的一般想法，并提供详细的示例解释它以及原因等。
最佳答案
“我正在考虑将每个部分(前端/管理面板)分解为单独的页面，然后为每个页面(或主题)编写简单的用户故事。”
页面没有故事。用户有故事。页面是您为实现用户故事而构建的东西。
主题——如果这么小的事情有一个主题的话——就是“管理内容”。也许有两个主题:关于写作/编辑的故事集和关于浏览/阅读的故事。
一些用户(“编辑者”？)想要创建、组织、更新和删除内容，以便他们可以做一些事情[问题没有说]。你强制他们使用网页，因为它比 5x8 卡片和标记更好、更便宜、更快。
一些用户(“读者”？)想要检查内容并进行导航——谁知道呢？ ——在某件事上变得更快乐、更有成效。你强制他们使用网页，因为这比用磁铁固定在白板上的 5x8 卡片要好。
您有关于创建和管理内容主题的故事。
“然后在我的错误跟踪器中创建一个案例列表，代表我必须开发的功能，以及每个案例的估计”
对。这些功能必须首先从数据模型开始，然后以某种有用的形式呈现。也许在页面上。事实上，一旦您拥有了广泛满足用例的模型，您就可以微调演示文稿以使模型更可用。
“业务层和表示是我需要详细说明的”
模型==业务层。它们是同一件事。
页面==演示。笔记。这是最后一次。一旦您拥有用例和支持这些用例的模型，您就可以向人们展示您的内容，以便他们可以与模型进行交互。
关于project-management - 项目设计/规范批评，这是正确的想法吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/304145/