Liquid Planner : Project Management Tool

I have been looking for a project management tool for ages, one that doesn't make me curl up inside and want to die and one that helps my team get stuff done rather than waste their time.

Finally stumbled across Liquid Planner which turns out to be an amazing little tool.

The features that I really like are

* Range estimation for tasks.
* Category vs Project views.

LP takes a novel approach to planning. Instead of giving a single point estimate. ie this task will take 10d to complete I estimate that the task will take between 8d and 12d to complete. This uncertainty is percolated up into the estimates for the rollup tasks and eventually to the estimate for the entire project. Range estimates fit my brain better than single point estimates and I think they make me more honest.

The second feature I like is that there are two views of the system.


The category view allows you to do a functional decomposition of the project. Containers can be nested and are navigable via a tree view. So this view is great for design and requirements capture.

The "project view" is again a tree view but items higher up on the screen and containers represent milestones. Containers are nested so you can model intermediate deliverables or sprints within you greater plan.

The project view is orthogonal to the category view and this is important because when designing a view you want to see the functional layout. When planning you want to see the order in which things need to be delivered.

This has solved my one gripe about other tools I see. They are either good for requirements capture or good for scheduling but never for both.

Scheduling works quite well. It performs resource leveling and supports precedes and depends on dependencies. Scheduling is done in the background and you are notified by an icon when the scheduling is finished and you should refresh the screen.

On the downside, here in Europe the site is a bit sluggish but to be fair they are still in beta and the devs seems quite responsive on the forums. As it is in beta it is currently free to sign up to but will eventually cost about $25 USD per user per month. Fair enough if it saves me an hour a month in time.

As a final note the site is a Ruby On Rails application which may excite or turn some people off depending on their religion :)

Using doxygen and Eclipse for requirements capture

I have been looking around for a good tool for requirements capture but it has been right under my nose. A combination of C++ namespaces and doxygen comments is a superb solution. I am currently using the Eclipse CDT with vxWorks 6.5 which adds the extra benefit or refactoring requirement ids.

Here is a simple requirements file as a C++ header file

/** @addtogroup requirements
 * @{
 */

/** @file requirements.hpp
 *
 */

/** requirements type */
typedef int rq;

/** com */
namespace Com {
    /** xtargets */
    namespace Xtargets {
        /** client */
        namespace Client {

            /** Make sure the product works */
            rq r1;

            /** Ensure customers are happy */
            rq r2;

            /** Get rich from selling many copies */
            rq r3;
        }
        namespace Kernel {

            /** Hide bugs from customers */
            rq r1;

            /** All actions must occur simultaneously
             * and in zero time. */
            rq r2;

            /** Use quantum features of the compiler when
             * environment variables MAGIC is set. */
            rq r3;

        }
    }
}
/** @} */

You don't really use this file as a header file but just take advantage of Doxygen and C++ notation to do the heavy work for you. If using an IDE then you get for free a nice requirements browser using the symbol browser.

When using requirements traceability is important so you may want to refer to certain requirements from comments in your source code. You can do this by using Doxygen notation to create auto links.

/** Some other comment in the code.
 *
 * See Com::Xtargets::Client::r1
 */

Now if you need to change the identifier for requirement r1 then you can use the refactoring capabilities of your IDE if available. In Eclipse you can change the name of the variable and ask it change all references to it in source code and source comments. You thus have a fully traceable requirements management solution without any fancy new tools to setup sans Doxygen and your IDE.

If using Eclipse I recommend setting up a sub project of your main project to house your requirements psuedo header files. When it comes to refactoring this allows Eclipse to find all the sources that might refer to the specific requirements.

I use the nice Doxygen plugin for Eclipse call Eclox to make life a little easier.