New project Pattern for FDD

The project pattern for the Basic FDD process, which is delivered with xProcess is changing in version 2.7.2. Here's a preview.


This puts the emphasis back on the familiar 5 stages of FDD at the top level (Develop an Overall Model, Build a Features List, Plan by Feature, Design by Feature and Design by Feature). The first 3 stages are included in Timebox 00 which covers the start up period of the project and Features and Feature Sets are created as subtasks of combined final stages: Design by Feature - Design by Feature. Major Feature Sets are modeled as Folders with membership defined by Category.

3 Types of Requirement

Priority-driven processes only work if you can model the process around task patterns for a single requirement. There is little point in prioritizing say, coding over testing, or design over specification, since all these activities must take place at some stage, even if they happen inside an activity that is called something else. But are all requirements the same (in the sense of using the same processes) or are some requirements more the same than others?!

Recently I was asked to advise on the requirements capture process for an organization wanting to apply agile techniques in a controlled environment. I came up with some slightly different names for types of requirement, though I think the concepts will be familiar to you if you've analyzed other software development methods. The requirements types (shortened to PCF) are as follows:

• Business problem statements (Problems)
• Solution contraint statements (Constraints)
• Solution feature statements (Features)

I've written elsewhere about FDD, which provides a very good process for managing and prioritizing features. However often projects applying processes like FDD do not pay enough attention to the other types of requirement that precede features.

Problems, for example, should identify issues in terms of a measurable aspect of the current solution and the degree to which a performance improvement would overcome it. Constraints express aspects of the solution that the current designers are not expected to change (though they should also state the rationale behind the constraint, and how and by whom it may be changed if justification exists). Only by considering all of these three types of requirement can the essential requirements of a system be captured.

Action stations

One of the most powerful aspects of xProcess is its flexibility and configurability. Processes are defined in terms of patterns: for example project patterns, task patterns and artifact patterns. Configurable enough. However you can do much more to enhance these and make them easier to use, by using xProcess Actions. These are bits of "OGNL" code that do things when xProcess is working. They can be triggered by user actions, by instantiating a pattern, by workflow or a number of other events.

For example Sam DerKazaryan of Isobar Global asked me recently for an Instantiation Action to increment the issue number on newly created issues. For those of you who like a spot of programming with their process engineering, here's the code snippet that does it...

#root = getPersistenceHelper().getRootExchangeElementContainer(),
#counter = #root.getIntProperty("currentCounterValue"),
#counter = #counter + 1,
setName("Issue " + #counter),
#root.setIntProperty("currentCounterValue", #counter)

Note: you need version 2.7.2 of xProcess or later to run this code.

Finalist for Eclipse Community Awards 2007

Just received great news - xProcess has been shortlisted (1 of 2) for the prestigious Eclipse Technology Awards in the category Best Commercial RCP Application. The two Technology Awards aim to recognize the best Eclipse-based commercial and open source products in the world.

"Finalists were selected from a pool of 63 nominations by a panel of judges from the Eclipse community". Way to go!

New white paper on priority-driven processes

Are your teams working on the most important issues to your business? If not you are losing potential earned value every day that goes by!

I've just finished a paper on this topic called Priority-Driven Processes, which you can download from the Ivis website. Such processes use the priority of deliverables as a key management control, enabling teams to focus on what provides greatest payback soonest. The paper is designed to help people to model and implement processes with priority, and draws on examples from FDD, XP and other agile methods.

If you do download, be sure to send us your feedback!

Do What You Do, But Better...

A recent discussion with Dave Garrett of Gantthead on the essentials of process improvement provoked some very interesting questions and answers. Please check it out on his blog under this title: Do What You Do, But Better...

Sugar-coating BigDecimal syntax

An aside for Java programmers... BigDecimal...
Don't you just love it! Love it and hate it that is.

Benoit Xhenseval recently emailed me about a proposal from within IBM to address the nastiness of BigDecimal syntax by supporting operator overloading in Java. It seems to me a very good way to make the elegance of BigDecimal's fully controlled rounding, with a reasonably readable way of using it. xProcess increasingly uses BigDecimals and I know readers and writers of its code would find this very helpful. If you're interested in supporting the proposal, see Glyn Normington's blog for more details.

Project Patterns

Creating project patterns in xProcess requires you to think about what are the framework parts of youroverall process. The diagram above shows a project pattern for a variant of Feature-Driven Development (FDD) and it's interesting to see how much of the process has been modeled here and how much elsewhere.

If you read the books on FDD - for example the one by Steve Palmer and Mac Felsing is a good one - you'll see that FDD is classicly drawn as 5 stages: Build a Domain Model; Build a Features List; Plan by Feature; Design By Feature; Buld by Feature. You can see from our pattern diagram that 2 of these stages did not make it into the project pattern. Why is that? There's a simple explanation: the last 2 stages in this description are repeated for each and every feature. These 2 stages are modeled within the Feature pattern so that their activities occur each time a feature is instantiated.

You can also see the project pattern contains the first 2 Timeboxes of the project (subsequent ones will be instantiated from the Timebox pattern). This is also a useful idea: put the parts of the process that you know should happen at the start of every project within the project pattern.