A substantial time amount passed since last post in this blog caused only because I'm recently very busy, although the list of interested subjects to describe in my Tomboy notes are extending monthly. Unfortunately I don't know when the appropriate time comes to make it...
Anyway today I had some more free day and I needed to setup some Trac environments for the team and the customers. Casually I reviewed some Trac plugins, that seemed to me sensible, and should increase productivity with Trac. Bellow is the short list of those I've found useful.
First and foremost I always install this plugin. This is very annoying in Trac for me, that it always sends a notification to the person who updates the ticket. This is completely unnecessary feature, because I believe that if someone is updating the ticket, he knows about that, and doesn't require additional email notification. The installation of this plugin simply disables this feature.
This is new for me, and I've installed this to fully verify the usefulness of the FullBlogPlugin, described below. This plugin basically adds a few great notification capabilities to Trac.
First is the "watch" capability for the tickets and wiki pages. While the "watch" feature for tickets is available by default using CC field, I've found this more friendly using this plugin. For each ticket/wiki page you can just click "Watch/Unwatch" links on the top of the ticket/wiki page view, and you are then notified about all changes in the ticket/wiki page. This is especially great for wiki pages describing some important facilities in our application. By subscribing changes all team can be informed about updates in these mechanisms.
Instead of subscribing all wiki pages by whole team (by clicking "Watch" on important pages), there's an option in Settings, that enables entering the names (also with using wildcards) of all wiki pages that should be by default watched by all team members.
Another function that may be considered useful is the possibility of watching concrete users, and their changes in Trac (new tickets, updates etc...). Currently I see few usages of this - eg. if you need to manage some subset of Trac users, or you have Trac opened to the customers and you'd like to trace their updates.
FullBlogPlugin
This plugin adds a blog feature to the Trac, which involves adding new blog posts, browsing and commenting them. This is the great feature, which I believe that can support scrum meetings, and even introduce scrum-meeting-like functionality for remote teams, working in different time zones.
In recent project, to notify about some important changes in the project, new features, and deployment events we were using one big ticket with all team set on CC. This may be now changed to the blog, when this plugin is installed. If each developer is told to write blog entries about recent work, new mechanisms and important changes in existing ones, the whole team can keep up-to-date information about the project as totality (which is one of responses of the scrum meetings).
The FullBlogPlugin lacks by default if the notification capabilities, but when you install the current trunk version of AnnouncerPlugin (described above), it introduces these lacking features. You can for example "watch" the blog entries, or follow some chosen bloggers. But for applying mentioned function of the blog feature in the team, the best are automatic options for subscribing blogs, which are following:
This is maybe less about productivity, but more about saving the time, of tracking the hours spent on the work. But first a little introduction...
There's a much bigger Trac plugin for time tracking and estimation: TimingAndEstimationPlugin. I was working with this once. This plugin allows you to estimate tickets time, add hours spent on ticket by particular developers, make some estimation and budget calculation using these information, and even connect another plugins making burn down charts, etc. This might be a better choice for someone, depending on what he wants to achieve, although in my personal opinion this plugin was not really good, and we used it just once for one project. AFAIR the information calculated/managed was not clear to us, it introduced some more complexity to Trac (and the power of this system is kept, when it's kept simple). Moreover, for estimation, requirements and user stories management, and generally managing project in scrum with burn down charts etc. I can much more recommend Agilo, which is complete tool for scrum project management based on Trac, than the TimingAndEstimationPlugin.
Now, returning to TracHoursPlugin, this is very simple one. It adds the "Add hours" link on the ticket view page, and the Hours view in menu, to calculate hours added to tickets with some query filters (like default query filters for Trac reports). So you can for example check the hours spent in some time range, spent by some developers, or spent on some ticket types or component.
This plugin is really great when you make some project, and you base on hourly rate, but with no time commitment, so for example one week you can work 10 hrs, while another 30 hrs, etc. This plugin allows you to really easy track the time and to make the financial settlements with the customer.
ChildTicketsPlugin
For a longer time I've been looking for better way to organize Trac tickets. This is the biggest problem in bigger projects managed with Trac, that it quickly becomes a mess with the plain "ticket list" views. only Unfortunately I didn't find anything that 100% satisfies me here, and if I manage project with Trac, I usually support myself with the mind mapping software, like Freemind (on the other hand this is best project management tool I've been using until now ;) ).
The ChildTicketsPlugin is an approach to introduce parent - child relations in the Trac tickets, and I 've currently chosen this plugin for test if it really helps with tickets organization in my new project. Maybe for some time I'll write a little more about this. For now I can just write that it looks simple. It allows you to define parent - child relations between tickets, and you can define what type of parent can have what type of children. Depending on how you like to organize your project, it can be eg. Requirement - User Story - Task, or Feature - Task + Feature - Bug etc. Whatever structure you find useful, you can configure here.
Now, the rest is easy, adding new ticket you can enter the parent ID, and you create the parent - child relation between these tickets. However, this is not very usable workflow: add ticket - enter parent ID, because you'd need to know the parent ID first, but the plugin provides another way of adding tickets - you can first find the appropriate parent ticket, and add any of the allowed child ticket types using a button.
This simple feature can be supported by additional reports, allowing us to view some kind of root ticket types, and "drill down" the project. We can also use empty/not empty parent ID filter, to determine orphaned tickets. Moreover there's a ChildTicketTreeMacro macro available, which can display the tickets tree structure in various places (like wiki pages, or ticket descriptions).
There's an alternative plugin for Trac, which is called MasterTicketsPlugin, what might be useful for some situations, but looking on the description it does far to much than I need, and brings more complexity for Trac. However, I didn't tested it today because of lack of time.
And more...
There are a lot more of Trac plugins that might be considered useful from the productivity point of view, which I didn't test. But currently these mentioned here appeases all my needs and fills the lacking functionality in Trac. However, I hope I'll extend this post in future.
First is the "watch" capability for the tickets and wiki pages. While the "watch" feature for tickets is available by default using CC field, I've found this more friendly using this plugin. For each ticket/wiki page you can just click "Watch/Unwatch" links on the top of the ticket/wiki page view, and you are then notified about all changes in the ticket/wiki page. This is especially great for wiki pages describing some important facilities in our application. By subscribing changes all team can be informed about updates in these mechanisms.
Instead of subscribing all wiki pages by whole team (by clicking "Watch" on important pages), there's an option in Settings, that enables entering the names (also with using wildcards) of all wiki pages that should be by default watched by all team members.
Another function that may be considered useful is the possibility of watching concrete users, and their changes in Trac (new tickets, updates etc...). Currently I see few usages of this - eg. if you need to manage some subset of Trac users, or you have Trac opened to the customers and you'd like to trace their updates.
FullBlogPlugin
This plugin adds a blog feature to the Trac, which involves adding new blog posts, browsing and commenting them. This is the great feature, which I believe that can support scrum meetings, and even introduce scrum-meeting-like functionality for remote teams, working in different time zones.
In recent project, to notify about some important changes in the project, new features, and deployment events we were using one big ticket with all team set on CC. This may be now changed to the blog, when this plugin is installed. If each developer is told to write blog entries about recent work, new mechanisms and important changes in existing ones, the whole team can keep up-to-date information about the project as totality (which is one of responses of the scrum meetings).
The FullBlogPlugin lacks by default if the notification capabilities, but when you install the current trunk version of AnnouncerPlugin (described above), it introduces these lacking features. You can for example "watch" the blog entries, or follow some chosen bloggers. But for applying mentioned function of the blog feature in the team, the best are automatic options for subscribing blogs, which are following:
- always notify me when any blog is modified, changed, deleted or commented on
- always notify me when any blog post is created
- always notify me when any blog that I posted is modified or commented on
- always notify me when a blog that I'm watching changes
- always notify me when any blogger that I follow has a blog update
This is maybe less about productivity, but more about saving the time, of tracking the hours spent on the work. But first a little introduction...
There's a much bigger Trac plugin for time tracking and estimation: TimingAndEstimationPlugin. I was working with this once. This plugin allows you to estimate tickets time, add hours spent on ticket by particular developers, make some estimation and budget calculation using these information, and even connect another plugins making burn down charts, etc. This might be a better choice for someone, depending on what he wants to achieve, although in my personal opinion this plugin was not really good, and we used it just once for one project. AFAIR the information calculated/managed was not clear to us, it introduced some more complexity to Trac (and the power of this system is kept, when it's kept simple). Moreover, for estimation, requirements and user stories management, and generally managing project in scrum with burn down charts etc. I can much more recommend Agilo, which is complete tool for scrum project management based on Trac, than the TimingAndEstimationPlugin.
Now, returning to TracHoursPlugin, this is very simple one. It adds the "Add hours" link on the ticket view page, and the Hours view in menu, to calculate hours added to tickets with some query filters (like default query filters for Trac reports). So you can for example check the hours spent in some time range, spent by some developers, or spent on some ticket types or component.
This plugin is really great when you make some project, and you base on hourly rate, but with no time commitment, so for example one week you can work 10 hrs, while another 30 hrs, etc. This plugin allows you to really easy track the time and to make the financial settlements with the customer.
ChildTicketsPlugin
For a longer time I've been looking for better way to organize Trac tickets. This is the biggest problem in bigger projects managed with Trac, that it quickly becomes a mess with the plain "ticket list" views. only Unfortunately I didn't find anything that 100% satisfies me here, and if I manage project with Trac, I usually support myself with the mind mapping software, like Freemind (on the other hand this is best project management tool I've been using until now ;) ).
The ChildTicketsPlugin is an approach to introduce parent - child relations in the Trac tickets, and I 've currently chosen this plugin for test if it really helps with tickets organization in my new project. Maybe for some time I'll write a little more about this. For now I can just write that it looks simple. It allows you to define parent - child relations between tickets, and you can define what type of parent can have what type of children. Depending on how you like to organize your project, it can be eg. Requirement - User Story - Task, or Feature - Task + Feature - Bug etc. Whatever structure you find useful, you can configure here.
Now, the rest is easy, adding new ticket you can enter the parent ID, and you create the parent - child relation between these tickets. However, this is not very usable workflow: add ticket - enter parent ID, because you'd need to know the parent ID first, but the plugin provides another way of adding tickets - you can first find the appropriate parent ticket, and add any of the allowed child ticket types using a button.
This simple feature can be supported by additional reports, allowing us to view some kind of root ticket types, and "drill down" the project. We can also use empty/not empty parent ID filter, to determine orphaned tickets. Moreover there's a ChildTicketTreeMacro macro available, which can display the tickets tree structure in various places (like wiki pages, or ticket descriptions).
There's an alternative plugin for Trac, which is called MasterTicketsPlugin, what might be useful for some situations, but looking on the description it does far to much than I need, and brings more complexity for Trac. However, I didn't tested it today because of lack of time.
And more...
There are a lot more of Trac plugins that might be considered useful from the productivity point of view, which I didn't test. But currently these mentioned here appeases all my needs and fills the lacking functionality in Trac. However, I hope I'll extend this post in future.
This comment has been removed by the author.
ReplyDelete