A forum for technical support discussion related to Fogbugz.
We have a bunch of different developers working on code in our company. To avoid tripping over one another, each developer generally creates a separate branch in version control for the tasks they're working on. Only once these tasks are complete does the developer merge those back into the main code line.
To help keep things organized, we've been creating a project in FogBugz for each branch that gets created in version control. So for example Bob creates branch proj09.01, Sally creates branch proj09.02 and Dick creates branch proj09.03... they all work away, only Bob and Sally finish their changes before a release and merge these back into the main code line. We thus create a new release branch in version control called ver09.01 (the version 9.01 release) that includes all the new features from the proj09.01 and proj09.02 code lines in the last sprint. The features that Dick was working on get postponed till next release.
We ALSO want to keep track of those features in FogBugz however. As developers, we're interested in a couple of things:
1. What features are currently being worked on and who is responsible for each of them
2. What branches are currently active and what features are included in each branch
3. How progress is tracking on the features in each of the branches
4. Which branches are likely to be completed on time to make it into the next release build
This can be achieved by creating projects in FogBugz coresponding to each of our branches. The features that each developer will be working on in their branch will thus be transfered from the Inbox (task backlog) to the project corresponding to the branch they are working on. This way, each developer can log in to FogBugz and easily see what projects are active (and thus what branches are currently active) and what features are in each project (and thus in each branch), who is responsible for each branch/project/task set and, if the reports are doing what you want we can also track the progress on the project and see how likely it is that a branch of code will be wrapped up and integrated before the next release build.
This all works fine as long as we create "Project Milestones" for each project and associate the tasks in each project with those project milestones.
However, if you instead create "Global Milestones"and associate the tasks in each project with a global milestone then none of the reports work, because ALL of the tasks in a project are associated with that project (of course) and they are also ALL associated with a global milestone. The project report doesn't work (it complains that the project doesn't have any local milestones configured) and the global milestones report doesn't work ("All of Bob's time is allocated to specific projects, so there is no time left for Global Milestones.")
This creates a problem for us. As individual developers we're interested in our individual branches/projects and the tasks in that branch/project, their priority and how we're doing time wise. Our project/program managers are more interested in how things are tracking overall though. For that, we figured we could use milestones. What we wanted was to have tasks assigned to particular projects and devs would typically be looking at a project centric view of the tasks, but also have those tasks assigned with a particular global milestone (e.g. Sprint 9.5) and our project/program managers would typically be looking at a milestone centric view of the tasks.
Presently though, it's not possible to have both - you can either view tasks by project and by project milestones or by global milestones but not both. I can't see any logical reason not to be able to organize and view the data in this way though... The FogBugz reports appear to be calculating things as though you are EITHER working on a project OR working on a milestone - but these two things are not exclusive (the fact that a task can be assigned to both a project and a milestone is testament to this fact) so there is no reason why we shouldn't be able to generate reports for both milestones and for projects and have the tasks that are associated with each appear in both reports.
The only way we can work things at the moment is to have each of our tasks associated with Project Milestones, generate project centric reports and then have our project/program manager aggregate all of the information from those project timelines into Excel or MS Project or something... basically manually creating a "Milestone" report to see how we're all tracking towards the next release. Obviously, this is far from ideal.
So I guess I'd have one of two suggestions:
1. The easiest would be to modify the Global Milestones report. There's no reason to exclude items from this report just because they are associated with a particular project (in addition to being associated with the global milestone)
2. Another possibility would be if we could associate projects themselves with global milestones. That way individual features could be associated with projects and project milestones, and groups of features (in our case branches/projects) would be associated with global milestones (that would correspond to either Sprints or Releases). This would be more flexible, as it would not preclude the use of interim project milestones such as "Coding", "Testing", "Integration" etc. at the same time as having all of the features associated with those Project milestones also, implicitly (by their inclusion in the project) being associated with a broader objective (the current sprint or the next release).
Any possibility of getting either 1 or 2 included in the software? Short term, suggestion number 1 would probably be sufficient.
Since your developers are all working on the same product, I'd suggest having each of your branches represented by different milestones. For example, Fog Creek's projects are "FogBugz", "Copilot", "CityDesk", "Jobs Board", etc. -- each individual branch is represented by a milestone such as "FogBugz 7.0.31" or "FogBugz 6.0.50 Backport" or "FogBugz 7.1 - Mono." Projects are meant to be long-lived, while milestones should be created and deactivated often.
Wednesday, September 9, 2009
Hm, OK well we only have one product - but I certainly don't want all the Cases in one project. At the very least we want to distinguish between Cases that we're currently working on and those that are in the Inbox.
Maybe we can just create a project for each release that we are working on, and add a Codeline custom field (there seem to be two custom fields "Version" and "Computer"... the later of which we're not using - so I'll use that for the Codeline).
As for the milestones, I guess if we have one project that includes all of the different tasks from the different codelines then we can use project milestones, rather than global ones)... which means the reports will work.
This topic is archived. No further replies will be accepted.Other recent topics