如何分解fogbugz区域中的部分?

发布于 2024-07-16 11:25:46 字数 256 浏览 7 评论 0原文

我有一个想要构建的 Web 应用程序,我应该如何使用fogbugz 管理我的所有任务。

如果我想逐页列出我的所有任务,我应该使用区域吗? 我也想将其分解为模块,我再次使用区域吗?

示例:

  • 用户
    • 添加用户
    • 删除用户
    • 为用户分配权限/角色

,或者如果它在页面上进行,则列表看起来会有所不同。

I have a web application I want to build, how should I manage all my tasks with fogbugz.

If I want to list all the tasks I have on a page by page basis, should I use areas for that?
I also want to break it down to modules, again I use areas?

example:

  • Users
    • add user
    • delete user
    • assign permissions/roles to a user

or if it do in on a page basis the list would look different.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

江挽川 2024-07-23 11:25:46

随着时间的推移,我发现尝试通过项目和责任(领域)以外的任何内容来严格构建案例都是浪费精力。

只需将案例放入 FogBugz 中正确的项目和区域下,并使用一个好的标题即可。

因此,项目就是您正在从事的产品或业务项目。

这些区域应该是 UI、代码、文档、数据迁移等人们具有不同职责和/或能力的区域。

然后为您的案例命名以便于管理和搜索,将案例范围控制在几个小时内如果可能的话,当然不会超过几天。

因此,从您的示例来看,它可能很简单...

  • 添加角色
  • 查看角色
  • 更新角色
  • 删除角色?
  • 列出角色
  • 添加用户
  • 查看用户
  • 更新用户
  • 删除用户
  • 列出用户
  • 添加依赖性检查以删除角色。

老实说,即使上面的内容可能有点过分,您可能会逃脱:

  • User Role add/view/update/delete/list
  • User add/view/update/delete/list

你做得越简单,您对开发人员的信任越多,开发人员感受到的阻碍就越少,并且更有可能继续工作。

Over time I've found that it's a waste of effort trying to rigidly structure your cases by anything other than Project and responsibility (Area).

Just get the cases into FogBugz under the right project and area with a good title.

So, the Project is whatever the product or business project is that you're working on.

The areas should be things like UI, Code, Docs, Data Migration, the kinds of things that people have different responsibilities and/or abilities in.

Then title your cases for easy management and searching, keeping the scope of the case to a few hours if possible, certainly no more than a couple of days.

So, from your example it could be as simple as...

  • Add Role
  • View Role
  • Update Role
  • Delete Role?
  • List Roles
  • Add User
  • View User
  • Update User
  • Delete User
  • List Users
  • Add dependency checks to delete role.

To be honest, even the above is probably a little over-board, you'd probably get away with:

  • User Role add/view/update/delete/list
  • User add/view/update/delete/list

The simpler you make it, and more trust you put in your devs, the less hampered your devs will feel and more likely to just get on with it.

轻拂→两袖风尘 2024-07-23 11:25:46

用户可以按分配给他们的案例进行过滤,以便他们始终可以查看自己的队列。

许多不同的领域只会造成不必要的复杂性——你只是不需要那种程度的细分。

请记住,您永远不应该拥有大量活动案例,并且不需要对简短列表进行大量分类。

我发现区域标志的最佳用途是将多个开发人员的工作分组到一个队列中。 然后你会得到一个任何人都可以快速查看的队列。

例如,您可能有一个“产品规划”区域,其中包含您尚未决定执行的功能创意。 在大型团队中,您可以为每个子团队分配一个区域,以便每个直线经理都可以单独查看自己的队列。

我们有一个大型且复杂的项目,该项目已经使用 Fogbugz 4 年了,而且我们从未需要超过 5 个区域。 如果我们按照您在这里建议的方式分割区域,我们现在将拥有数百个区域。

Users can filter by cases assigned to them, so they can always view their own queue.

Lots of different areas will just create unneeded complexity - you just don't need that level of breakdown.

Bear in mind that you should never have large numbers of active cases, and you don't need lots of categorisation for short lists.

I find that the best use of the area flag is to group work into a queue across more than one developer. Then you get a queue anyone can quickly view.

For instance you might have a "Product planning" area for feature ideas that you haven't decided to do yet. In a large team you might assign an area for each sub-team, so each line manager could view their queue on its own.

We have one large and complex project that's been using Fogbugz for 4 years and we've never needed more than 5 areas. If we'd split areas the way that you suggest here we would now have hundreds of them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文