Availability - how much and who to?

When you're specifying your availability in xProcess there are 2 parts to the information required: when are you available? and to which projects? If you are wanting to change availability for people in your project from the assumed defaults (usually 8 hours each weekday), then here are a few hints to get you started.

The first part - your overall availability - can be specified for both organisations and for individuals Open an editor for either a person or organisation and you'll find (at the bottom of the editor pane) a tab labelled "Availability". This shows the availability records that have been defined. Each record has a from and to date ("..." means "forever" in this context, either in the past for the "from" date, or in the future for the "to" date). For each day of the week you can either specify a specific number of hours or inherit the hours specified on another person or organisation.

By default organisations at the top level (that is organisations with no parent organisation) are created with availability of 8 hours on Monday to Friday. Sub-organisations or persons within an organisation are created to inherit availability from their parent organisation. So for example public holidays can be defined by adding availability records at the top level and personal holidays defined on the individual person in the same way.

The second part of defining availability is to divide your time between one or more projects. When the Project Manager adds a resource to his team he must specify the percentage availability (default 100%) and the from and to dates for this person (defaults to the start and end of the project). To change the percentage of time available to any one project, hit the "Resources" button in the Project Manager perspective "Tools" panel, or open the project editor and go to the "Available Resources" tab. You can then select the relevant person and use the "Manage Project Availability for..." button. Again availability records can be added for a period specifying a percentage of the overall time the person is available on each day of the week. (The default in this case is 100% each day.)

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.]

Not just project management - not just process improvement

Explaining xProcess's position in the market of agile management products is something I never find straightforward. On the one hand it's important to emphasize the way you can simply define a set of tasks a team will be working on and immediately generate a plan (which you can then monitor in real time as tasks are re-prioritised, started and completed). On the other hand there's all that cool stuff you can do defining the task patterns, artifact templates, gateways and workflows that make up the process definitions behind different project approaches. I guess it all depends who you're talking to. If they're project managers needing something to get them started quickly, emphasize the simplest possible agile approach (prioritizing a list of tasks, defining the resources available and generating the plan). If they're process gurus - it has to be said these guys are thinner on the ground! - try impressing them the process modelling facilities xProcess provides for you. Producing the graphical task patterns and even workflows is a great starting point.

If you're going for the "simplest possible" approach, try these steps:

• Create a new Data Source (or open an existing one) and switch to Project Manager perspective
• Create a new Project (hit the "New" button in the "Tools" panel)
• Define your tasks (hit "New", select "Task" and create multiple tasks in a comma-separated list)
• Define your resources (hit the "Resources" button, then "Add/New Project Resource" and select yourself as the project resource
• Hit the "Tasks" button to see forecast dates for your new tasks
• View Gantt and Burndown charts for your plan
• Add further resources if available and see the forecast dates and charts change
• Hit the "Priorities" button and make one of the later scheduled tasks highest priority (drag-and-drop or type "0" in its priority field and save the change using Ctrl-S)
• View the change to the task order in the Gantt chart.
  

SpringSource Application Platform released

An interesting announcement this week that you may have missed is the release of the SpringSource Application Platform. Effectively this is a lightweight but high-performance platform providing most of the functionality of existing application servers in a much simpler, small-footprint package. SpringSource CEO Rod Johnson has been quoted as saying that it will provide a "leaner and more powerful solution." He continued. "The SpringSource Application Platform, comprised of the dm-Kernel we developed, along with the proven Spring, Eclipse Equinox and Apache Tomcat technologies inside, provides the industry with the leanest, most flexible server for running enterprise Java applications". Paul Kuzan, a leading software architect and part of the team that put together xProcess, has been contributing to the open source code in the SpringSource platform. "It's a really exciting development in the app server world", said Paul, "and one that is likely to make a very big impact in the years ahead. Watch this space!"