A bug tracker contains much of the data necessary to make a decent piece of project management software. The key requirements are:
o Issue dependencies
o Time estimates
o Progress estimates
o Developer Availability
o Gantt charts and other useful PM reporting
It may not be the case that Nitpick is the right software to put this project management feature set into. It should certainly be optional and ignorable, perhaps even disabled by default.
The theory would be that there would be a single developer friendly place to view what should be done next and when it should be done. It would also provide an easier place for the PM to view the most up to date completion estimates (even if only quite coarse via issue completion) and to have a permanent and easy to find location of discussion/descriptions of features and requirements.
This would need to tie in with the feature described in 4ebf2a29 to be useful in all cases. First in the fact that issues over multiple repositories would have to be queried to produce the reports. More interestingly is handling feature completion within branches. It isn't reasonable to ask the PM to reconcile completion estimates from all the branches by themselves, but they would also likely desire to have their information updated more frequently than when a feature is complete.
One critical feature is some way to produce a project Gantt chart for a project overview.
The use of this is to give a PM or interested developer a view of the critical path as currently assigned and some idea of how feasible the current schedule is. It would also be useful in determining what work is getting done.
To produce a Gantt chart any particular issue needs:
- An owner
- An estimated time of work
- An estimated current completion
- A started timestamp
- A finished timestamp
Every user also must have a number of hours per day (likely for any day of the week) they will be working on this project.
Every Fix_By also requires a deadline so a critical path can be computed, though the system should attempt to find the minimum time option. Assuming that any single person will only ever work on a single issue at a time is reasonable.
From the discussion here (http://curtis.lassam.net/pierc/#id-790719) is seems that it could be useful to support non hour based time measurements. Specifically complexity based estimates.
If we allow integer values for time estimation of a project (nominally hours) and further allow float values for the time a dev has available on any particular average day of the week then we can either have that scaleless number represent hours or complexity units.
This would enable the Agile style Planning Poker.
Every Fix_By also requires a deadline so a critical path can be computed, though the system should attempt to find the minimum time option. Assuming that any single person will only ever work on a single issue at a time is reasonable.
Let's evaluate why we need each item:
o Owner - Needed so we can schedule in parallel
o Estimated time - Needed so we know how long any particular issue will take
o Current completion - Needed to straddle an issue on the current date line for scheduling. If we don't have this then we must assume when we schedule that any issue is either not yet started or done. This causes problems with lengthy items and causes the schedule to jitter. Of course, if developers don't keep their estimated completion up to date the same happens, but that could happen at a fixed time for the team.
o Started Timestamp - Needed to record when work was started in order to pin the work in realtime in the past. Probably only necessary if you want to show a Gantt chart in the past.
o Completion Timestamp - Needed to record when work actually stopped. Probably only necessary if you want to show the Gantt in the past.
o Units of work per dev per day of week - Necessary to convert the time estimate of an issue into a number of days of work. Must be in the same unit as the work estimate for the issue, but otherwise requires no fixed unit.
o Fix_By requires a name and date. Milestones require a deadline in order so know scheduling priorities. Issues themselves could have deadlines instead, but that would lose the effect of automated scheduling.
From the above it seems that start timestamp and end timestamp aren't actually necessary since I don't know of any particular use for Gantt charts of the past. Of course there will still be a record of who did which issue, but pass-offs would be a bit funny. If that level of accuracy is necessary then new issues should be created for sub-issues instead of changing the ownership of a task.
Summary of necessary new information:
- Estimated units of work for task
- Estimated percent completion for task
- Estimated units of work per dev per day of week
- Fix_By date
If we don't have anything indicating a start time, then we won't be able to handle external dependencies based on date without some ugly hacks. In fact I can't think of a workaround that will work at all.
Unfortunately adding that information makes the entire setup NP-Complete.
If I can work out an efficient algorithm for the simple case of only inside the dependency tree, then two modes could be provided. A most where none of the tasks have non-zero earliest possible start times (meaning they can't start immediately assuming all the dependencies where magically complete) and then a mode where there are these external earliest possible start times for some tasks.
Resource balancing should be done by a human, it's simply too much work to automatically enter skill equivalences. The UI for this would be to click on the issue in the Gantt chart and it would open the bug. The user could then change the owner of the issue and recompute the Gantt chart.
Of course the critical path should be specially coloured.
I don't think we should necessarily do a traditional Gantt chart. A traditional Gantt chart has the vertical axis be tasks and the horizontal axis be time. This is reasonable if any particular task requires multiple people or other resources to accomplish, but it makes it difficult to see where juggling people or equipment would shorten the schedule.
Since Nitpick won't support automatic resource balancing manual balancing must be made easy. On most software projects there is only one scarce resource, developer time, so it should be possible to do a different chart.
My current thought is to have developers as the primary vertical axis and time as the horizontal axis. Then you show issues as blocks within that graph. Since it is assumed that only one task may be performed at a time (as that's more efficient of developer time) this should work well. Dependencies between tasks will be shown with links. It may be necessary to have a secondary vertical axis (by having a developer take multiple lines) to help differentiate between issues the same developer does which have a dependency.
An alternative is to have the secondary grouping on the vertical axis be each individual issue. So every developer would have a row for every future task they have to handle. This may make it difficult to see who has too much work and needs to be juggled.
After drawing some samples I don't think having a secondary grouping per person is valuable. Better to have one column per person with one task after another. Tasks should be colour coded for the Fix_By they are due for. On mouseover of one item it'd be very useful to highlight every task in the subtree, that is, every task the selected task depends upon and every task which depends upon the selected task.
I suppose that this isn't a Gantt chart at all, but seems that it would be more useful. It'd be similar to a complex project Gantt chart if it were filtered to a single milestone.
One situation where multiple columns would be useful is when a developer has some tasks partially complete, but they've come upon a new dependency and had to stop. In that case the partially complete issue could have the work remaining start whenever the dependency is expected to be resolved with the completed portion above it, showing completion status. Since there would be two tasks listed for the same time period (some amount of work-to-be-done on its own in the developer row and the work-to-be-done of some other task overlapping the already completed work of the first issue.
One feature that would be useful is to have items which aren't completed coloured based upon their completion status. So the first x% would be green, the last 100-x% blue to signify that approximately x% has been completed.
If the issues in the past are only those which haven't been completed completely yet then doing this should give a decent idea of which tasks are on schedule and which are behind.
Furthermore, if the scheduling worked backwards from the deadline and showed the current date in some special way, then it would be easy to see how far various things are behind without complicating the scheduling algorithm with having to iterate juggling until the start fits where the current date is. Doing this jiggling has issues when it comes to weekend and the like, since some people may not be on a particular project seven days a week for an even number of work units a day.
Another critical feature is a list of "What should I work on Next?". This would be a list of suggested issues for a developer to work on in the order that they should be done.
This should take into account schedule needs, including scheduling between other developers, dependencies (ie. don't suggest an item with an unmet dependency) and arbitrary due dates (which could be Fix_by milestones).
This feature should also automatically produce reasonable schedule dates for any particular item. This would be useful when using Nitpick as a personal scheduler, perhaps as part of a larger project.
The idea is that you fill in the scheduling information and then any particular issue would have a reasonable finish date computed.
Here is the current list of things left to do on this feature:
1. Take the difference in fix_by dates when computing the schedule
2. Show overlapping items when one is to be continued
3. Colour code the issues by their fix_by
After trying it, I don't believe that statically colouring the critical path is the right thing to do. It's non-trivial to mark the tasks on the critical path in such a way that a minimal set is marked and every time span is covered.
abd97310fcb2 seems to cover the need of marking the critical path and does it in a more general and accurate way.
Overlapping tasks to show the partial completion status is perhaps not worth it.
- It's quite a bit of work to do this because HTML tables don't work in a useful manner for this.
- It will greatly increase the horizontal space needed to show the schedule. This will make things less useful.
I'm going to make this a new issue to consider later, a7fcc48d
Similar to the situation in 73f8e6dd adding the scheduling feature required new metadata. New issues will have it, but old issues won't. To add it create a helper script
#!/bin/bash
awk '/--/ {print "Units_of_Work: 1000\nPercent_Complete: 0";} {print}' $1 > $1.tmp
mv $1.tmp $1
And then run it with:
find .nitpick -name issue -exec /path/to/add_fields.sh \{\} \;
This will modify all the existing issues to have the default values of the new metadata items.
A bug tracker contains much of the data necessary to make a decent piece of project management software. The key requirements are: o Issue dependencies o Time estimates o Progress estimates o Developer Availability o Gantt charts and other useful PM reporting It may not be the case that Nitpick is the right software to put this project management feature set into. It should certainly be optional and ignorable, perhaps even disabled by default. The theory would be that there would be a single developer friendly place to view what should be done next and when it should be done. It would also provide an easier place for the PM to view the most up to date completion estimates (even if only quite coarse via issue completion) and to have a permanent and easy to find location of discussion/descriptions of features and requirements. This would need to tie in with the feature described in
4ebf2a29to be useful in all cases. First in the fact that issues over multiple repositories would have to be queried to produce the reports. More interestingly is handling feature completion within branches. It isn't reasonable to ask the PM to reconcile completion estimates from all the branches by themselves, but they would also likely desire to have their information updated more frequently than when a feature is complete.Date: 2012-07-19 18:02:40
User: travisb
This also needs the functionality from
73f8e6ddDate: 2012-11-02 04:39:57
User: travisb
One critical feature is some way to produce a project Gantt chart for a project overview. The use of this is to give a PM or interested developer a view of the critical path as currently assigned and some idea of how feasible the current schedule is. It would also be useful in determining what work is getting done.
Date: 2012-11-02 05:19:40
User: travisb
To produce a Gantt chart any particular issue needs: - An owner - An estimated time of work - An estimated current completion - A started timestamp - A finished timestamp Every user also must have a number of hours per day (likely for any day of the week) they will be working on this project. Every Fix_By also requires a deadline so a critical path can be computed, though the system should attempt to find the minimum time option. Assuming that any single person will only ever work on a single issue at a time is reasonable.
Date: 2012-11-03 17:32:00
User: travisb
From the discussion here (http://curtis.lassam.net/pierc/#id-790719) is seems that it could be useful to support non hour based time measurements. Specifically complexity based estimates. If we allow integer values for time estimation of a project (nominally hours) and further allow float values for the time a dev has available on any particular average day of the week then we can either have that scaleless number represent hours or complexity units. This would enable the Agile style Planning Poker.
Date: 2012-11-03 17:46:47
User: travisb
Every Fix_By also requires a deadline so a critical path can be computed, though the system should attempt to find the minimum time option. Assuming that any single person will only ever work on a single issue at a time is reasonable. Let's evaluate why we need each item: o Owner - Needed so we can schedule in parallel o Estimated time - Needed so we know how long any particular issue will take o Current completion - Needed to straddle an issue on the current date line for scheduling. If we don't have this then we must assume when we schedule that any issue is either not yet started or done. This causes problems with lengthy items and causes the schedule to jitter. Of course, if developers don't keep their estimated completion up to date the same happens, but that could happen at a fixed time for the team. o Started Timestamp - Needed to record when work was started in order to pin the work in realtime in the past. Probably only necessary if you want to show a Gantt chart in the past. o Completion Timestamp - Needed to record when work actually stopped. Probably only necessary if you want to show the Gantt in the past. o Units of work per dev per day of week - Necessary to convert the time estimate of an issue into a number of days of work. Must be in the same unit as the work estimate for the issue, but otherwise requires no fixed unit. o Fix_By requires a name and date. Milestones require a deadline in order so know scheduling priorities. Issues themselves could have deadlines instead, but that would lose the effect of automated scheduling. From the above it seems that start timestamp and end timestamp aren't actually necessary since I don't know of any particular use for Gantt charts of the past. Of course there will still be a record of who did which issue, but pass-offs would be a bit funny. If that level of accuracy is necessary then new issues should be created for sub-issues instead of changing the ownership of a task. Summary of necessary new information: - Estimated units of work for task - Estimated percent completion for task - Estimated units of work per dev per day of week - Fix_By date
Date: 2012-11-04 23:57:33
User: travisb
If we don't have anything indicating a start time, then we won't be able to handle external dependencies based on date without some ugly hacks. In fact I can't think of a workaround that will work at all.
Date: 2012-11-05 00:33:09
User: travisb
Unfortunately adding that information makes the entire setup NP-Complete. If I can work out an efficient algorithm for the simple case of only inside the dependency tree, then two modes could be provided. A most where none of the tasks have non-zero earliest possible start times (meaning they can't start immediately assuming all the dependencies where magically complete) and then a mode where there are these external earliest possible start times for some tasks.
Date: 2012-11-02 05:22:54
User: travisb
Resource balancing should be done by a human, it's simply too much work to automatically enter skill equivalences. The UI for this would be to click on the issue in the Gantt chart and it would open the bug. The user could then change the owner of the issue and recompute the Gantt chart. Of course the critical path should be specially coloured.
Date: 2012-11-03 18:09:44
User: travisb
I don't think we should necessarily do a traditional Gantt chart. A traditional Gantt chart has the vertical axis be tasks and the horizontal axis be time. This is reasonable if any particular task requires multiple people or other resources to accomplish, but it makes it difficult to see where juggling people or equipment would shorten the schedule. Since Nitpick won't support automatic resource balancing manual balancing must be made easy. On most software projects there is only one scarce resource, developer time, so it should be possible to do a different chart. My current thought is to have developers as the primary vertical axis and time as the horizontal axis. Then you show issues as blocks within that graph. Since it is assumed that only one task may be performed at a time (as that's more efficient of developer time) this should work well. Dependencies between tasks will be shown with links. It may be necessary to have a secondary vertical axis (by having a developer take multiple lines) to help differentiate between issues the same developer does which have a dependency.
Date: 2012-11-04 02:39:08
User: travisb
An alternative is to have the secondary grouping on the vertical axis be each individual issue. So every developer would have a row for every future task they have to handle. This may make it difficult to see who has too much work and needs to be juggled.
Date: 2012-11-04 03:40:14
User: travisb
After drawing some samples I don't think having a secondary grouping per person is valuable. Better to have one column per person with one task after another. Tasks should be colour coded for the Fix_By they are due for. On mouseover of one item it'd be very useful to highlight every task in the subtree, that is, every task the selected task depends upon and every task which depends upon the selected task. I suppose that this isn't a Gantt chart at all, but seems that it would be more useful. It'd be similar to a complex project Gantt chart if it were filtered to a single milestone.
Date: 2012-11-04 03:51:32
User: travisb
One situation where multiple columns would be useful is when a developer has some tasks partially complete, but they've come upon a new dependency and had to stop. In that case the partially complete issue could have the work remaining start whenever the dependency is expected to be resolved with the completed portion above it, showing completion status. Since there would be two tasks listed for the same time period (some amount of work-to-be-done on its own in the developer row and the work-to-be-done of some other task overlapping the already completed work of the first issue.
Date: 2012-11-04 03:32:35
User: travisb
One feature that would be useful is to have items which aren't completed coloured based upon their completion status. So the first x% would be green, the last 100-x% blue to signify that approximately x% has been completed. If the issues in the past are only those which haven't been completed completely yet then doing this should give a decent idea of which tasks are on schedule and which are behind.
Date: 2012-11-05 02:16:57
User: travisb
Furthermore, if the scheduling worked backwards from the deadline and showed the current date in some special way, then it would be easy to see how far various things are behind without complicating the scheduling algorithm with having to iterate juggling until the start fits where the current date is. Doing this jiggling has issues when it comes to weekend and the like, since some people may not be on a particular project seven days a week for an even number of work units a day.
Date: 2012-11-02 04:44:53
User: travisb
Another critical feature is a list of "What should I work on Next?". This would be a list of suggested issues for a developer to work on in the order that they should be done. This should take into account schedule needs, including scheduling between other developers, dependencies (ie. don't suggest an item with an unmet dependency) and arbitrary due dates (which could be Fix_by milestones).
Date: 2012-11-02 05:17:44
User: travisb
This feature should also automatically produce reasonable schedule dates for any particular item. This would be useful when using Nitpick as a personal scheduler, perhaps as part of a larger project. The idea is that you fill in the scheduling information and then any particular issue would have a reasonable finish date computed.
Date: 2012-11-12 17:44:10
User: travisb
Here is the current list of things left to do on this feature: 1. Take the difference in fix_by dates when computing the schedule 2. Show overlapping items when one is to be continued 3. Colour code the issues by their fix_by
Date: 2012-11-12 17:51:33
User: travisb
I forgot all about: 4. Document this all 5. Colour code the critical path a different colour by default.
Date: 2012-11-12 18:33:58
User: travisb
After trying it, I don't believe that statically colouring the critical path is the right thing to do. It's non-trivial to mark the tasks on the critical path in such a way that a minimal set is marked and every time span is covered. abd97310fcb2 seems to cover the need of marking the critical path and does it in a more general and accurate way.
Date: 2012-11-12 20:22:58
User: travisb
Overlapping tasks to show the partial completion status is perhaps not worth it. - It's quite a bit of work to do this because HTML tables don't work in a useful manner for this. - It will greatly increase the horizontal space needed to show the schedule. This will make things less useful. I'm going to make this a new issue to consider later,
a7fcc48dDate: 2012-11-20 03:08:11
User: travisb
Similar to the situation in
73f8e6ddadding the scheduling feature required new metadata. New issues will have it, but old issues won't. To add it create a helper script #!/bin/bash awk '/--/ {print "Units_of_Work: 1000\nPercent_Complete: 0";} {print}' $1 > $1.tmp mv $1.tmp $1 And then run it with: find .nitpick -name issue -exec /path/to/add_fields.sh \{\} \; This will modify all the existing issues to have the default values of the new metadata items.Tracked by Nitpick