What tips and "standards" do you use in your Redmine project management process?
Do you have a standard wiki insert template you could share or a standard way to work a project using bugs features tasks and support issues?
Do you let issues and updates get emailed into Redmine? Do you use the forums? Do you use SVN repository? Do you use Mylyn in eclipse to work the task lists?
I'm trying to drag our dept. into some web based PM instead of emailed Word docs of vague requirements followed by Word docs explaining how to QA and Deploy that all get lost in a pile of competing updates and projects so that by the time I have to fix something, no one can find any documentation on how it works.
Answer
I develop and maintain internal applications for a family of manufacturing companies. As of the time of this comment, I'm the only developer/analyst on the IT team. During the worst of the recession my project demands exploded. As such my project AND issue backlog is quite unwieldy. We are currently in the process of restructuring to expand the team.
Here's how I use Redmine to keep my head straight (to the extent that is possible), my users at bay, and hopefully prevent too much hand-holding of new staff in the future.
- I use Subversion for source control, with TortoiseSVN and the aptly named Tortoise-Redmine plugin. Refreshing the Repository on the Redmine project after a commit links the issue, which shows the revision on the issue, and updates my stakeholders via email notification.
- I treat the project description as a means of communicating the project's purpose, scope, and lifecycle stage to those who are not involved. That way my users know what I've got on my plate, and what's still on the buffet that I'm eyeballing from a distance.
- I use specific role names for my permission sets that indicate more than a set of permissions -- again, as a means of documentation. My roles include the following: Project Manager, Project Team Member, Owner, Primary User, Secondary User, Observer, Overlord (for my bosses...both fun and undeniably correct).
- I use the Wiki and Documents for documentation, depending on which I feel is appropriate.
- Versions are pretty much useless to me, so instead of using that for planned releases, I use it to group related issues into sprints.
- I use Eric Davis's fabulous Stuff-To-Do plugin to organize/re-organize the aforementioned sprints before mass-editing the Target Versions on my issues. This also lets my stakeholders know what I'm working on and how I've prioritized their interests (for better or worse).
- To encourage user interaction, I added links to the Redmine project into my applications' Help menus. The "About" box also contains a link to the Redmine project.
Future Plans
- I hope at some point to finish my Visual Studio extension for Redmine integration.
- Build a code library to loosely couple my application with its Redmine project: automate bug submission, alert subscribing stakeholders from system tray, reusable interactive Help menu driven by Redmine's REST API, etc. (Maybe automate portions of documentation with the Wiki?)