Skip to main content

Posts

Showing posts from December, 2006

From tracking to planning ... and back

xProcess provides many of the facilities of an issue tracking tool alongside its project planning/execution and process improvement functionality. Particularly with the new web client access, it's quite possible to use xProcess as your issue tracking server as well as your project execution environment. However many projects and organisation already have issue tracking systems in place and would like to integrate the two systems, allowing issues to transform into tasks in project plans - when they have been classified in the tracker system - and the status of issues to change when progress is reported by the project.

The mechanism xProcess provides for implementing such integrations is the Workflow Server. This can monitor the tracker system as well as changes within the xProcess data source and trigger actions when specific changes are detected. How does this work out in practice? Here's a brief summary of a current integration with a leading tracking tool.
The tracker is used …

Comparing big patterns and small ones

When defining your processes in xProcess you need to decide on the level of granularity at which to define task patterns and the degree of complexity to build in. Compare these two examples of feature pattern.

This first one is nice and simple. Two people will work on the feature using and/or modifying the three associated artifacts (Word documents in this case) Specification, Design and Test Spec. It's simplicity is its greatest advantage since this allows a lot of flexibility when such features are planned in a real project.

The next pattern is more complex and goes to a finer level of granularity. It defines 5 subtasks, using 4 specific role types and having different artifacts for each of the tasks. The artifacts are a mix of Word documents Wiki pages and xProcess Forms (user-defined data held in internal XML format). The result is a more complex patterns which breaks down the work into more speciifc packages and provides more guidance in terms of the work to be done.

There are d…

What makes processes agile?

The key thing that makes processes agile is "reduction of work in progress". Traditionally, projects' processes view and partition the whole project: for example software development processes that divide the life-cycle into phases like Requirements, High-level Design, Detailed Design, Code and Build, Integration and Testing, Maintenance. Each phase of the project transforms the whole output from the previous phase into the relevant output products for that phase. You could represent such a lifecycle in this way, where each step, T, takes the artifacts, A, from the previous step and delivers them to the next step.


The major problem with this model is that every step must be completed for every part of the project before any delivery (the so-called "big-bang" delivery). There's a lot of work in progress in this model, and that means a lot of risk and a high level of required investment.

In contrast, an agile lifecycle defines the necessary transformations in …

New diagram in xProcess

A recent development in xProcess is the support for State Transition Diagrams to define the workflow that is triggered by changes to elements of xProcess data. The diagram attached to this entry is a sneak preview.

You can define states of the elements you are interested in (Tasks, Projects, Peoiple, etc.) by defining a rule in OGNL. When these objects change from one of the pre-defined states to another the Workflow Server will inspect the defined triggers and call the actions defined therein.

More later!