We are in the process of reviewing some of our project management processes here at Alagad in search (as always) of ways to better manage and track projects. Currently, we use a combination of Trac sites, SVN repositories, and a handful of other tools for our projects, but I have often found this collection of individual tools can be burdensome and I don’t have a great love for Trac as it is not the most flexible system in the world.
So, here is the question – how do you manage projects? Are there any tools that you use for tracking projects … milestones, tasks, bugs, time, etc? Do your clients have access to these tools? What about solutions like BaseCamp? Is a hosted solution better than a tool or set of tools that you have to then download and maintain? Do you have a favorite tool or tool set? If so, I would love to hear about it. If not, what are some things that the currently available tools missing?
Comments on: "How do you manage projects?" (25)
I happen to love Basecamp. But it’s not a solution for managing the entire project. It’s really good for managing communication with your clients. It also tracks milestones and todo’s but not to the extent you might need with Trac.
Also it doesn’t do bugs.
I am working on switch my work systems over to trac and subversion. Then using mylyn within eclipse to manage tickets and code.
We’re looking at rolling our own where I work – mainly to meet some special needs but I’ve been looking around at other systems – two that look intriguing are FogBugz and Atlassian’s suite of products. Very tightly knit, but expensive.
in regards to proccess I highly recommend checking out:
And the Book Rapid Development:
Rapid Development is a fairly old book now but is really required reading for anyone interested in improving their process and gets everyone using the same vocabulary and understanding the core issues.
For me the process is more important then the tools. I’ve used so many tools over the years they all just blur together with various strengths / weaknesses. I know build engineers will have different opinions but from a developers perspective all I need is check in/out, merge, compare, revert and comment. Things like automated builds and smoke test are nice to haves but not needed on all projects.
Tool wise, and this is more a personal preference, I dont like SVN or CVS. The clients just crash way too often and I (again personally) dont like having the UI integrated into the OS like in tortoise.
There are some technical issues with SVN and CVS especially when dealing with binary files and you have to be a bit too disciplined running manual updates to not accidentally conflict with another devs changes.
I do tend to like the Visual Source Safe / Source Gear Vault approach as the UI automatically updates files for you and checking out a file locks it instantly preventing anyone else from trying to edit the file. Rather then SVNs approach of dealing with conflicts when you check in a file (when its already too late) VSS/SGV stops the problem before it can occur (this is more a problem with binary files but annoys me when I have to do a merge on txt files). I do like having a separate application UI / window for the client and this is what VSS/SGB provide.
Because of some issues with VSS (no http access, cost, etc) I prefer source gear vault:
For SCRUM management Ive used Scrumworks:
Its not perfect and has some UI issues but I liked the structure it provided. It be great if it integrated with task / bugs in issue trackers but it doesn’t.
I use to do process consultation on Flash Projects for Universal Mind and other big name clients and the best advice I can give you is to get key stake holders and team members involved. Even if you have the greatest process and the most expensive tools money can buy, its not going to matter if no one uses them. And, in my experience, developers tend to be more accepting of changes if they can help influence the change.
anyhow hope that helps dude! =)
+1 for the Atlassian stuff.
Using JIRA for bug tracking, including road maps (bug/feature targeting).
Has plugins to connect to your SVN repos. When you commit, include the JIRA bug id and the commit shows up in JIRA.
Then, FishEye can be used for repository insight – diffs, change logs, etc
Very powerful suite; very easy to use.
(apologies if this posts twice)
I’ve been using FogBugz very heavily recent and it’s the best tool that I personally have used for bug tracking, project estimates, and project scheduling. The evidence-based scheduling alone is worth the price of admission.
I haven’t had a chance to test it yet, but there is even an Eclipse plugin that ties into FogBugz, and as with Trac, you can hook FogBugz into SVN. Trac’s nice, but FogBugz blows it away. It also costs money though so if budget’s an issue, Trac’s a nice solution.
I’ve had good results for the last couple of years using OnTime from Axosoft
Not free, but reasonably priced.
I particularly like it when I am using sub-contractors as it makes it very easy to assign work, and keep track of who is doing what, and where they stand.
Having worked as a staff and project manager as well as a consultant and lead developer, it sounds to me like you don’t have an established process. The process is more important than the tools used to enforce the process; I would start by reviewing project management best practices (for example PMBOK) as well as agile techniques (such as SCRUM recommended earlier) and come up with a process that works for your situation. Once you have put that together the tools will be easier to choose because you will have defined the parameters within which those tools must operate.
Take a look at the Rails project Redmine. Easy to setup, great feature set (Connects to svn, per project Wiki, Bug tracking, forums, etc). Actively developed.
I’m doing SVN/Trac where I work, but I don’t need to track time. I’ve got separate repos and Trac environments for each project.
We also use the Atlassian stack (JIRA & FishEye & Confluence).
Projects start in the wiki (Confluence) with basic ideas and features being described and discussed. This initial stage also includes a basic layout of timing constraints (milestones, etc.).
Once the project is ready to be started we create a project in the issue tracker (Jira) and an svn repository. Features are transformed into Jira issues, estimated there and assigned to releases and iteratoions.
The wiki page contains a list of issues for the projects current phase and their status so you always get a toplevel view from the wiki without digging into Jira details.
Finally we are using a custom plugin to create worklogs from svn commits. Developers use commit messages like “[PRJ-23] Added feature x (4h30m)”, the change is associated with the corresponding issue and the 4h30m are accounted in Jira (automatically adjusting the remaining estimate).
Works like a charm 🙂
+1 for Atlassian
Easy to manage and assign tasks and keep track of project (from developer view)
-JIRA to track project and tasks
Stack for development used with JIRA:
-Confuence for WIKI (XWiki not bad either)
-Use Mylyn (only if team is mature)
-Bamboo for CI (CruiseControl or TeamCity is also good)
-SVN for source control (nice for greenfield project..prefer StarCity for older projects where maintenace of code is done by multiple teams)
The code review tool (Crucible?)also looks good.
Of late our clients are preferring to use http://unfuddle.com/ Integrated SVN, ticketing and issue tracking
Wow, you get busy working for a day and see what happens.
Just for a general note, we do currently use Trac, SVN and a couple of other little tools to support our project management process, which I personally feel is pretty good. With that said, it is always growing as it should when we see new things and I am always on the lookout for new tools to better support that process.
@Terrence – Yeah, I have looked at BaseCamp several times, but it looked pretty high level and did not do everything I needed.
@Eric – I think you are the first person I have ever heard push VSS over CVS or SVN. I have never seen any issues with the SVN clients like Tortoise, although some of the Eclipse based tools could use a bit of help.
@Matt – I have read a lot of the stuff by Joel from FogCreek Software(?) and have heard of FogBugz, but never really looked into it.
One thought that is coming to mind here, with all of the tools recommended, why are none of them ColdFusion based? Rather than start a new discussion here, I have posted this as a question as a new topic and would like your input.
I posted a site describing my development setup for contracting projects (SVN, SpringLoops, integrated Basecamp) – including a screencast talking about the integration points. Might be helpful for you here…
Best of Luck.
At this point I think we’re looking for something that will automate a lot of the setup process (test URL, dev URL, production URL, build scripts.
I’ll agree that our biggest issue at this point is the lack of a process, but we want to make sure that what we end up with actually saves us time and effort. Since we do consulting, we need to be able to adapt between hosting projects ourselves, working with other hosts, allowing for VPN-based access to private networks, automating the build process between these various systems, etc. It needs to be extremely flexible and yet manageable. I know, we’re looking to build the next killer app.
In any case, at the very least it seems like we’re facing issues that others have to deal with too. The first step to overcoming any set of issues is sharing the problem across as wide a base as possible.
Thanks for the comments! 😀
+1 for redmine. We were using Trac for a while but redmine has much better support for multiple projects. We switched over last year and are now happily managing several dozen projects with it. It’s actively developed too — the lead developer is a machine.
We have started using Subversion, Code Beamer and ant scripts to handle the builds.
We use CFEclipse on the dev side and it ties very will with svn and Code Beamer, including being able to commit code changes directly against a tracker item in Code Beamer.
Code Beamer also has APIs that can be easily accessed from ColdFusion to pull reports or give clients access to the tracking process.
Eric Pfleckl is managing the process for us at NaturalInsight. Drop him a note if you want to chat with him. Doug knows how to get in touch with him or you can drop me a line.
SVN vs VSS/SGV is a huge debate many of flame war have sparked. Over the past 10 years and dealing with different dispositions and background it really comes down to preference.
My preference is SGV and here are my reasons (that some CVS/SVN users will say is an issue with my workflow or can be dealt with running custom scripts. . . no thanks, I got other code to write) which deal mostly with that client :
Tortoise (which is the only stable client ive been able to find):
1) it slows down the OS
2) copy and pasting files into a new directory isnt always reliable. Ive had a number of instances where it would hold onto the svn path and cause all kinds of awesomeness.
3) you cant drag and drop existing svn directories (because SVN data is saved in the folder) to new locations, you have to deal with it manually and resolve the paths yourself, update the directories, update the server paths, commit, do possible merges (if conflicts then you lose all previous commands), then run clean up. Then all other developers have to do the same especially if they where working in that directory.
4) have to manually deal with conflicts on binary files (swf, flas, images, etc) sometimes working on 1 file at a time (fun) and with different developers.
Overall things in SVN just require more effort / interactions / clicks to do the same thing in SGV for example:
To lock a file and see other locks:
1) go to folder
2) run update to check for locks
3) click ok to close window
4) refresh directory (on my machine at least. icons never update in the folder your viewing, you have to manually refresh
5) lock file
6) click ok to close window
7) edit file
8) commit file
9) click ok to close window
10) run update to make sure you have latest copies of all new files
11) click ok to close window
12) THEN, if developer b forgot to run an update before he edited the locked file: deal with merging his changes, getting new binary files, etc and enjoy the process again.
In SGV to lock a file:
1) go to folder inside SGV (auto updates)
2) check out file (locks it, auto updates all files)
3) edit (you cant edit without checking out)
4) check in (unlocks) (auto updates all files)
SVN requires too much developer discipline and developer intervention. I dont want to have to police my version control system and Ive spent far more many hours dealing with SVN then I have SGV and I have equal experience using both .
Because everything is automated in SGV you mitigate the risk of developers forgetting to run updates. Because the ui is separate it doesnt slow down the UI of the OS and because it auto updates constantly and you have to check out a file to edit it, you dont have to deal with conflicts 99% of the time (it stops the problem before it can happen). Finally, just less clicks and that makes me giggle.
I think SVN appeals to a lot of server developers because it is free, open source (I hate to say it but *some* people prefer open source just because its open source) and if your dealing primarily with text files, merges (in theory, ive never seen this work 100% of the time) are automated.
On the other side of the argument, some might find the SGV approach to restricting because you have to checkout/download and/or wait for a file to get released to edit. Which I can understand, but in my experience, Ive had fewer headaches with SGV.
I’ve worked with both SVN and SVG, and to me, it comes down to the size of the development team(s)
SVN is more suited for large development environments, where there are multiple teams working together, and there is a dedicated configuration management team always ready to handle merges and conflicts. Usually multiple people will be working on the same code.
VSS/SVG is better suited for a small development team, where there is no dedicated configuration management and developers can usually lock a file without worrying that someone else will need it.
Another vote for Jira!
>> VSS/SVG is better suited for a small
>> development team, where there is no
>> dedicated configuration management
>> and developers can usually lock a
>> file without worrying that
>> someoneelse will need it.
I totally disagree. VSS is suited for anyone. Only for small (yes) teams, and M$ aficionados wich may want to discover what a versioning system looks like. The exclusive lock concept is stupid in versionning. We are 2 or 3 developers at work, and the project is definitely not well structured. We cannot change this (15 years), so we often have to modify the same files. The files are localy modified (just a read attribute, it’s really useless) and after you have to merge manually (if you remember to) in any case. With these rules, the system is not very useful. The lock concept reduces the scope of versionning, and it masks the problem. The file is shared, VSS tends to reduce the real complexity, it’s a total illusion.
Concerning the subject, I use plain wiki and doc, I plan to use Redmine. I’ve checked out Assembla, it’s very polished, but I think it’s a facade.
“I’ve checked out Assembla, it’s very polished, but I think it’s a facade.”
I’m interested in what you mean, and why you think this? I’ve been using Assembla for a few weeks.. its pretty good, but i’m finding the lack of flexibility in viewing of tickets a little frustrating. Time tracking isn’t the best either.
Gonna check otu some of the other tools mentioned in the comments – thanks everyone
A survey for projects managers aimed to get as many insights as possible into typical or untypical stumbling blocks and setbacks they experience. Respondents are eligible for a project management training addressing the needs based on the survey. By Tony Wong, Digital Onion Inc. http://www.digitalonioninc.com
I’m an experienced Project Manager with PMI certifications. There are many aspect to managing successful projects, but you must first be very familiar with the project life cycle. Each phase of the life cycle requires different tools and techniques. If you have specific questions, please post them on my blog at http://infrastructureprojectmanagement.blogspot.com/
I would be more than happy to work with you by providing you advices based on over 12 years of successful infrastructure and software development project management.