Skip to main content

Process patterns: what are "composites"?

The key to defining the task structure in a process definition is the task pattern. Task patterns consist of prototype tasks, optionally contained in a prototype project. Here's an example:

This is the task pattern for a "Feature" in the FDD process and it results in the creation of a set of subtasks and artifacts when the Feature pattern is "instantiated". This is quite a simple pattern and it doesn't include any composite tasks, which are structures to allow multiple tasks, optional tasks and iterations of tasks (repeated tasks that follow on one after the other). It is composites that allow arbitary process diagrams, drawn say using UML's activity diagram format, to be translated into xProcess processes. Here's an example of a task pattern, this time shown in the Hierarchy Diagram view, which does contain a composite. It's the "Feature Set" pattern from the same process.

The composite task in this example is called "Features: $Name$" (this is a pattern so the $Name$ will be substituted by the user supplied name when the pattern is instantiated). It contains a choice of 3 patterns: "Defect", "Feature" and "Task". Any of these patterns may be instantiated multiple times within the composite task.

Composite tasks are parent tasks, in other words they do (or will) contain child tasks, and they also define constraints on what type of child tasks can be created through the patterns they contain. In the latest version of xProcess composites can be instances (only one pattern can be instantiated in the composite), collections (an arbitrary number of patterns can be instantiated in them) or iterations (similar to collections but each pattern will be constrained to start after previously instantiated tasks have completed). Composites contain one or more patterns which define the options available when creating new tasks in the composite. In the example above, Defects, Features or Tasks can all be instantiated within the composite.

So the composite mechanism gives the Process Engineer the ability to define task patterns with loops, sequences and optional paths. More or less any pattern that can be represented in a flow chart or activity diagram can be created in an xProcess pattern by using composites. Composites go further though. Because of xProcess' support for top-down estimation, composites have their own estimates and resource requirements so that they can be scheduled even before the detailed decisions about how many tasks, iterations or options have been made.

To understand how these top-down estimates work in practice, see this blog article: Latest Patterns for Scrum which shows how the top-down estimate for a Sprint is used for scheduling resources, up to the point that all the backlog items have been created within it.

Footnote Question (for the techies among you!):
Are all parent tasks also composites as well as vice versa?
Well firstly all composites are parent tasks. Even if they as yet contain no child tasks they are classified as parent tasks because they allow task patterns to be instantiated in them. On the other hand parent tasks are only composites if they contain a set of patterns. This set defines the patterns that can be instantiated in the composite /parent task. So a parent task without such a set of patterns is not a composite and (in version 2.x) any non-hidden task pattern maybe instantiated in it.
[Note in version 3 this behaviour is likely to be changed, effectively removing any distinction between parents and composites. If the parent task does not contain any patterns, no patterns will be able to be instantiated in it. This will allow Process Engineers to create project patterns where, for example, certain tasks have a fixed set of children which cannot be added to.]
Post a Comment

Popular posts from this blog

Does your Definition of Done allow known defects?

Is it just me or do you also find it odd that some teams have clauses like this in their definition of done (DoD)?
... the Story will contain defects of level 3 severity or less only ... Of course they don't mean you have to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "Done"if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.

Let's look at the consequences of this policy. 

Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in…

"Plan of Intent" and "Plan of Record"

Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many successful ventures and in a number of SIGs and conferences in which he is active. In spite of knowing Ron by correspondence over a long period of time it was only at JavaOne this year that we finally got together and I'm very glad we did.

Ron wrote to me after our meeting:

I told a number of people later at JavaOne, and even later that evening at the Software Engineering Management SIG, about xProcess. It really looks good. A question came up: It's a common technique in large organizations to keep a "Plan of Intent" and a "Plan of Record" - to have two project plans, one for the business partners and boss, one you actually execute to. Any support for that in xProcess?

Good question! Here's my reply...

There is support in xProcess for an arbitrary number of target levels through what we call (in the process definitions) P…

Understanding Cost of Delay and its Use in Kanban

Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - as is often the case - estimating it quantitatively may be difficult or even impossible. Analysing Cost of Delay (even if done qualitatively) is important because it focuses on the business value of work items and how that value changes over time. An understanding of Cost of Delay is essential if you want to maximise the flow of value to your customers.

Don Reinertsen in his book Flow [1] has shown that, if you want to deliver the maximum business value with a given size team, you give the highest priority, not to the most valuable work items in your "pool of ideas," not even to the most urgent items (those whose business value decays at the fastest rate), nor to your smallest items. Rather you should prioritise those items with the highest value of urgency (or CoD) divided by the time taken to implement them. Reinertsen called this appro…