假设我们正在创建Acme CMS。此CMS Web应用程序将允许您创建具有子类别（无限深度）的无限数量的类别，并且每个类别可以具有与其关联的0+个内容页面。
所以这个项目在高层次上会有：
前端 索引页面 2.具有内容页面列表的类别页面 3.内容页面
管理控制面板 1.类别（添加/更新/删除） 2.页面（添加/更新/删除/）
架构设计 表 2.存储过程 3.数据访问层
问题： 我正在使用bug跟踪器和Wiki，那么我应该如何打破这个项目呢？
我正在考虑将每个部分（前端/管理面板）分解为单个页面，然后为每个页面（或主题）编写简单的用户故事。
当我完成用户故事后，我将在我的bug跟踪器中创建一个案例列表，代表我必须开发的功能，以及每个功能的估计值。
我是否正确地打破了这个项目？计划中的任何重大差距都会使该项目失败（理论上无论如何！）
请提供详细的答案，也许是我应该做的一般概念，详细的例子解释它以及为什么等。
答案 0 :(得分：2)
“我正在考虑将每个部分（前端/管理面板）分解为单个页面，然后为每个页面（或主题）编写简单的用户故事。”
页面没有故事。用户有故事。页面是您为实现用户故事而构建的内容。
主题 - 如果有一个这么小的东西 - 是“管理内容”。也许有两个主题：关于写作/编辑的故事集和关于浏览/阅读的故事。
有些用户（'编辑'？）想要创建，整理，更新和删除内容，以便他们可以某些东西 [问题没有说明]。你强迫他们使用网页，因为它比5x8卡和标记更好 - 更便宜 - 更快。
有些用户（“读者”？）想要检查内容并导航以便他们可以 - 谁知道？ - 在某事上更快乐，更富有成效。你强迫他们使用网页，因为它比用磁铁固定在白板上的5x8卡更好。
您有关于创建和管理内容主题的故事。
“然后在我的错误跟踪器中创建一个案例列表，代表我必须开发的功能，以及对每个功能的估计”
右。这些功能必须首先从数据模型开始，然后以一些有用的形式进行演示。也许在页面上。实际上，一旦你有一个广泛满足用例的模型，你就可以微调演示文稿，使模型更有用。
“业务层和演示文稿是我需要详细说明的”
模型==业务层。他们是一回事。
页面==演示文稿。注意。这是最后一次。一旦您拥有用例和支持这些用例的模型，您就可以向人们展示您的内容，以便他们可以与模型进行交互。
答案 1 :(得分：1)
据我所知，您的设计中存在一些明显的差距，部分功能是隐含的（类别和页面的链接），有些则完全被忽略（管理员登录，用户管理，预览等） ）。这些将占您的小应用程序的大约一半，并且您最好将它们包含在初始大纲中。也许您可能想采用更系统的方法来设计CMS。你可以采取至少三种一般路线：
首先设计一个域模型，然后设计业务层，然后设计UI和数据模型。
从数据模型开始，并在其上构建业务层和UI。
首先为UI建模，然后对其他所有内容进行建模。
无论您希望采用哪种方式（或组合方式），都有一些一般性指导原则：
首先要了解您想要自动化的工作。这被称为“工作范围”。这里的“大图”可以用字面意思来说，虽然它只是一个描述过程的故事，但最好使用包含动作，人工制品，其他应用程序，用户等的丰富图片进行可视化。至于“大”图片需要包含的部分内容超出了预期的产品，要大于您想要自动化的工作部分。
然后概述您希望产品需要处理的具体工作。这通常被称为“产品范围”。
列出应用程序的用户角色（或配置文件），输入和输出列表，外部接口列表。
现在您可能想要开始编写一些用户故事。每个用户配置文件至少需要一个，因为您需要提供所有用户视角的说明。
此时，您可以随时使用足够的信息，使用域模型或UI模型或数据模型开始更精确的问题建模，无论您喜欢什么或感觉更舒服。< / p>
所有步骤都非常迭代。一旦您对应用程序有了更多的了解，它就会有更广泛的背景，并且有一系列需要实现的功能，以满足您的要求，您可以进行一些非常粗略的估算，然后进行优先级排序。
毋庸置疑，这只是一个简化的框架，许多软件开发人员会采用不同的方法来设计应用程序，具体取决于他们的技能，需求，偏好等。但它可能是一个更系统的评估的良好起点你要解决的问题。
答案 2 :(得分：0)
“无限制”部分被打破......甚至GMail也有上限......
编辑：虽然我的回答得到了落实，但我认为这是正确的。一旦你与非程序员谈话，“无限制”的部分变得非常危险，并可能会刺伤你。此外，您无法真正拥有可扩展的数据模式以实现无限制嵌套......但这应该是显而易见的。