"I am thinking of breaking each section (front end/ admin panel) down into individual pages, then writing simple user stories for each page (or theme)."
Pages don't have stories. Users have stories. Pages are a thing you build to implement the user story.
The Theme -- if there is one for something this small -- is "managing content". Perhaps there are two themes: the collection of stories about writing/editing and the story(s) around browsing/reading.
Some users ('editors'?) want to create, organize, update and remove content so they can something [the question doesn't say]. You force them to use web pages because it's better - cheaper - faster than 5x8 cards and markers.
Some users ('readers'?) want to examine content and navigate so they can -- who knows? -- be happier and more productive at something. You force them to use web pages because it's somehow better than 5x8 cards held to a whiteboard with magnets.
You have stories about the theme of creating and managing content.
"then create a list of cases in my bug tracker representing features that I have to develop, along with an estimate for each one"
Right. And the features have to begin with data model first, then presentation in some useful form. Perhaps on pages. Indeed, once you have a model that satisfies the use cases in a broad way, you can fine-tune the presentation to make the model more usable.
"business layer & presentation is what I need to detail"
Model == business layer. They're the same thing.
Pages == presentation. Note. This is last. Once you have use cases and a model that supports those use cases, you can present your stuff to people so they can interact with the model.
As far as I can see you've got a few glaring gaps in your design, part of the features is implied (linking of categories and pages) and some are left out altogether (login for administrators, user management, preview etc). These are going to make up about half of your small application, and you better include them into the initial outline. Perhaps you may want to take a more systematic approach to designing the CMS. And there are at least three general routes you could take:
Design a domain model first, and then design business layer, then UI and data model.
Start with data model and build business layer and UI on top of it.
Model the UI first, then everything else.
Regardless of which path you would prefer to take (or combination of) there are some general guidelines:
Start with a big picture of work you want to automate. This is called “work scope”. “Big picture” here can be meant quite literally and although it can be a just a story describing the process, it is best to visualise using a rich picture that includes actions, artefacts, other applications, users etc. As for the “big” part of the equation the picture needs to encompass more than the intended product, be bigger than the segment of work you want to automate.
Then outline what specific work you want your product to take care of. This is usually referred to as “product scope”.
Make a list of user roles (or profiles) for your application, list of inputs and outputs, list of external interfaces.
Now you may want to start writing some user stories. You’ll need at least one per user profile, since you need to provide an illustration of all user perspectives.
At this point there going to be just enough information at your disposal to start a more precise modelling of the problem using either domain model, or UI model or data model, whichever you fancy or feel more comfortable with.
All of the steps are very much iterative. Once you understand a bit more about the application, its wider context and have a list of features that need to be implemented to meet the requirements you’d be in the position to give some very rough estimates and then go through a prioritisation process.
Needless to say that this is just a simplified framework and many software developers would take a different approach to designing an app, depending on their skills, needs, preferences etc. But it could be a good starting point to a more systematic evaluation of the problem you want to solve.
The "unlimited" part is broken... even GMail has an upper limit...
Edit: Although my answer got downvoted I think it is right. As soon as you talk with non-programmers the "unlimite" parts become very dangerous, and will likely stab you in the back. Also you can't really have a scalable data schema for unlimited nesting... but that should be obvious.
发布评论
评论（3）
“我正在考虑将每个部分（前端/管理面板）分解为单独的页面，然后为每个页面（或主题）编写简单的用户故事。”
页面没有故事。 用户有故事。 页面是您为实现用户故事而构建的东西。
如果这么小的事情有一个主题的话，那么主题就是“管理内容”。 也许有两个主题：关于写作/编辑的故事集和关于浏览/阅读的故事。
一些用户（“编辑者”？）想要创建、组织、更新和删除内容，以便他们可以做一些事情[问题没有说]。 你强迫他们使用网页，因为它比 5x8 卡片和记号笔更好、更便宜、更快。
一些用户（“读者”？）想要检查内容并进行导航——谁知道呢？ ——在某件事上变得更快乐、更有成效。 你强迫他们使用网页，因为它比用磁铁固定在白板上的 5x8 卡片要好。
您有关于创建和管理内容主题的故事。
“然后在我的错误跟踪器中创建一个案例列表，代表我必须开发的功能，以及每个案例的估计”
对。 这些功能必须首先从数据模型开始，然后以某种有用的形式呈现。 也许在页面上。 事实上，一旦您拥有了广泛满足用例的模型，您就可以微调演示文稿以使模型更可用。
“业务层和表示是我需要详细说明的”
模型==业务层。 它们是同一件事。
页数==演示。 笔记。 这是最后一次。 一旦您拥有用例和支持这些用例的模型，您就可以向人们展示您的内容，以便他们可以与模型进行交互。
"I am thinking of breaking each section (front end/ admin panel) down into individual pages, then writing simple user stories for each page (or theme)."
Pages don't have stories. Users have stories. Pages are a thing you build to implement the user story.
The Theme -- if there is one for something this small -- is "managing content". Perhaps there are two themes: the collection of stories about writing/editing and the story(s) around browsing/reading.
Some users ('editors'?) want to create, organize, update and remove content so they can something [the question doesn't say]. You force them to use web pages because it's better - cheaper - faster than 5x8 cards and markers.
Some users ('readers'?) want to examine content and navigate so they can -- who knows? -- be happier and more productive at something. You force them to use web pages because it's somehow better than 5x8 cards held to a whiteboard with magnets.
You have stories about the theme of creating and managing content.
"then create a list of cases in my bug tracker representing features that I have to develop, along with an estimate for each one"
Right. And the features have to begin with data model first, then presentation in some useful form. Perhaps on pages. Indeed, once you have a model that satisfies the use cases in a broad way, you can fine-tune the presentation to make the model more usable.
"business layer & presentation is what I need to detail"
Model == business layer. They're the same thing.
Pages == presentation. Note. This is last. Once you have use cases and a model that supports those use cases, you can present your stuff to people so they can interact with the model.
据我所知，您的设计中有一些明显的缺陷，部分功能是隐含的（类别和页面的链接），而有些功能则完全被省略（管理员登录、用户管理、预览等）。 这些将占您的小型应用程序的大约一半，您最好将它们包含在初始大纲中。 也许您可能希望采用更系统的方法来设计 CMS。 您至少可以采取三种一般路线：
首先设计领域模型，然后设计业务层，然后设计 UI 和数据模型。
从数据模型开始，并在其之上构建业务层和 UI。
首先对 UI 进行建模，然后再对其他所有内容进行建模。
无论您愿意采取哪条路径（或组合），都有一些通用准则：
从您想要自动化的工作的总体情况开始。 这称为“工作范围”。 这里的“大局”可以按照字面意思来理解，虽然它可能只是一个描述过程的故事，但最好使用包括动作、人工制品、其他应用程序、用户等在内的丰富图片来可视化。作为等式的一部分，图片需要包含的内容不仅仅是预期的产品，大于您想要自动化的工作部分。
然后概述您希望您的产品负责哪些具体工作。 这通常称为“产品范围”。
为您的应用程序创建用户角色（或配置文件）列表、输入和输出列表、外部接口列表。
现在您可能想开始编写一些用户故事。 每个用户至少需要一份个人资料，因为您需要提供所有用户观点的说明。
此时，您将拥有足够的信息，可以使用域模型、UI 模型或数据模型（无论您喜欢或感觉更舒服）开始对问题进行更精确的建模。
所有步骤都是非常迭代的。 一旦您对应用程序及其更广泛的背景有了更多的了解，并拥有了满足要求所需实现的功能列表，您就可以给出一些非常粗略的估计，然后进行优先级排序过程。
不用说，这只是一个简化的框架，许多软件开发人员会根据他们的技能、需求、偏好等采取不同的方法来设计应用程序。但这可能是对问题进行更系统评估的一个很好的起点你想解决。
As far as I can see you've got a few glaring gaps in your design, part of the features is implied (linking of categories and pages) and some are left out altogether (login for administrators, user management, preview etc). These are going to make up about half of your small application, and you better include them into the initial outline. Perhaps you may want to take a more systematic approach to designing the CMS. And there are at least three general routes you could take:
Design a domain model first, and then design business layer, then UI and data model.
Start with data model and build business layer and UI on top of it.
Model the UI first, then everything else.
Regardless of which path you would prefer to take (or combination of) there are some general guidelines:
Start with a big picture of work you want to automate. This is called “work scope”. “Big picture” here can be meant quite literally and although it can be a just a story describing the process, it is best to visualise using a rich picture that includes actions, artefacts, other applications, users etc. As for the “big” part of the equation the picture needs to encompass more than the intended product, be bigger than the segment of work you want to automate.
Then outline what specific work you want your product to take care of. This is usually referred to as “product scope”.
Make a list of user roles (or profiles) for your application, list of inputs and outputs, list of external interfaces.
Now you may want to start writing some user stories. You’ll need at least one per user profile, since you need to provide an illustration of all user perspectives.
At this point there going to be just enough information at your disposal to start a more precise modelling of the problem using either domain model, or UI model or data model, whichever you fancy or feel more comfortable with.
All of the steps are very much iterative. Once you understand a bit more about the application, its wider context and have a list of features that need to be implemented to meet the requirements you’d be in the position to give some very rough estimates and then go through a prioritisation process.
Needless to say that this is just a simplified framework and many software developers would take a different approach to designing an app, depending on their skills, needs, preferences etc. But it could be a good starting point to a more systematic evaluation of the problem you want to solve.
“无限”部分被破坏了......即使GMail也有上限......
编辑：虽然我的答案被否决了，但我认为这是正确的。 一旦你与非程序员交谈，“无限”部分就变得非常危险，并且可能会在背后捅你一刀。 此外，您实际上无法拥有可无限嵌套的可扩展数据模式......但这应该是显而易见的。
The "unlimited" part is broken... even GMail has an upper limit...
Edit: Although my answer got downvoted I think it is right. As soon as you talk with non-programmers the "unlimite" parts become very dangerous, and will likely stab you in the back. Also you can't really have a scalable data schema for unlimited nesting... but that should be obvious.