Monday, May 31, 2004

Using CFDs

The first of a new series of Coad Letter’s has been published at the Borland Developer Network - Using Cumulative Flow Diagrams. This is one of several which make up the content of two papers I’ll be giving at the Borland Developer Conference in September.

Introduction

Agile software development methods such as Scrum and Feature Driven Development manage and report project progress in a very different manner than traditional critical path project management. Scrum started with the use of a “burn down” chart which plotted the estimated number of hours remaining to complete the Sprint backlog. More recently “burn up” charts have become popular. These plot the number of completed Stories, Tasks or Features on the project with a projected completion target. It is possible to extrapolate the plot with a trend line to estimate the completion date of a project.

The concept of a “burn up” chart had been used in Feature Driven Development since its inception in the late 1990’s. It’s called a Feature Complete Graph as shown here.

Download in PDF Format [395K]

Sunday, May 30, 2004

Academic Comparison of FDD and XP

It seems to be the season for the academic community to publish papers about FDD. Here is another recent one by Serguei Khramtchenko of Harvard University, Comparing eXtreme Programming and Feature Driven Development in Academic and Regulated Environments.

What encourages me most about these academic papers is that the authors seem to have captured a better understanding of FDD from reading the literature and without exposure to the originators than some authors in the agile field. One key element these authors have understood which is often misquoted is that modeling comes before the feature list in FDD. Yes! Modeling is used as a discovery process. Something else Serguei really latches on to is the power of color modeling and its vital role in making FDD extremely lean, ”While they are not expected to become UML gurus I witnessed amazingly quick learning of color UML.”

Saturday, May 29, 2004

Aspects and FDD

Jianxiong Pang and Lynne Blair show in this new academic paper, Refining Feature Driven Development - a methodology for early aspects, how to adapt FDD for use with Aspect Oriented Software Development (AOSD). It shows clearly that Features readily represent an aspect-oriented requirements engineering approach but that the design-by-feature and build-by-feature steps can be refined for use with aspects to develop more easily reusable features - separated as individual aspects.

By and large I wholeheartedly agree with this paper. It’s a pity that so much FDD related material hasn’t been very explicitly documented. For example, the authors suggest the idea of a persistency (sic) feature set which would contain features to describe persistent storage. Actually Peter Coad wrote about this concept in 1997 when he described 4 types of features PD (problem domain), HI (human interface), SI (system interface) and DM (data management) where the DM features are equivalent of the persistency features suggested here. Equally, the compatibility features described could be argued are covered under the heading of SI.

However, I have argued previously and documented in my writing that there are some non-functional requirements not covered in the original FDD literature that do deserve to be documented as features. Although these do not represent “client-valued functionality”, they are “client valued non-functionality”. They represent some differentiating ability for which the customer will pay (i.e. associates a tangible value to them) such as a performance or speed improvement.

What I like most about adapting FDD for aspect-oriented programming is the clear alignment and ease of traceability. Every line item on the Feature List, now has a specific aspect in the code. Talk about properly aligning a value chain - every developer can speak concisely and articulately about what they are doing and why it is valuable to the client, business or end consumer - whilst management can (automatically) track progress towards the goal by monitoring the delivery of aspects. Now that really is the basis for agile management!

Friday, May 28, 2004

FeatureComplexityPointDays

If we mix the topics from yesterday and the day before to get FeatureComplexityPointDays, we have created a control metric or “smell test” for our development team. If a Feature with Complexity Points of 2 is supposed to take 1 man day and we desire that Lead Time should never exceed 2 weeks (10 man days) then an under control FDD process should have a FeatureComplexityPointDays per Developer score of 20 or less.

For example if a Feature Team consisting of 1 Chief Programmer and 2 Developers has a Chief Programmer Work Package with 15 Features with average complexity of 2 then they have a CPWP with an estimated FeatureComplexityPointDays total of 30. This CPWP should typically complete in 5 working days. If it takes longer or shorter then it might just show that the estimate was wrong. This is normal common cause variation. However, if the actual FeatureComplexityPointDays number exceeds some control limit, say 60 [a precise calculation of a control limit needs a set of real data sampled daily over a short period to get an average moving range], then it’s a strong indication that something is wrong - an identifiable, assignable cause. Identifiable, assignable causes can and should be addressed by management intervention.

Metrics cannot tell you the root cuase of the problem. The manager needs to act as a facilitator to help find the cause, then use his or her judgement to implement action to remove the assignable cause which took the process out of control.

Thursday, May 27, 2004

Feature Complexity Points

Over the last few years, I’ve written several times about my 5 point scale for Feature Complexity in FDD. As my colleague Daniel Vacanti tells me,

“All features are not born equal”

and neither they are!

In fact the size or complexity of a Feature is a particularly important thing to know in two situations. The first is when you are working on a short iteration cycle anything from 2 to 8 weeks. The second is where you are close to complete - only a few Features to go, but equally only a few days on the schedule remaining and you don’t want to be even one day late. Feature complexity is not important on larger projects such as the original FDD project in Singapore - about 15 months, 2000 business logic features and as many more again for UI and interfaces to legacy systems. We have shown over the years that a statistical sample of Features tends to show a very normal distribution of complexity and there is indeed the concept of an “average Feature”. Hence, when trying to estimate an FDD project it is often easier to do it for a 500 or 1000 Feature project than it is for a 80 Feature project.

So Feature Complexity Points provides a way of managing FDD projects accurately in smaller iterations. I use a 5 point scale because psychologically it is easy to categorize things into 5 buckets. However, what are those five buckets. Well that hasn’t ever been adequately written down. It’s heuristic. I once wrote a suggestion that it is roughly based on the number of classes touched by the Feature and this is still a good rule of thumb. The more classes required, the more complex. Features which touch only a single class such as enquiry on a boolean variable - is it set of not? - are so simple that they are definitely complexity 1 out of 5. A Feature with a great deal of algorithmic complexity or involving complex business rules may be a 5 on the scale.

As a default, I then use a power law to translate the Feature Complexity Points into effort. 1 = 0.5 days, 2 = 1 day, through to 5 which is 8 days or more. Remember in FDD a Feature should never take more than 10 days. If it’s so big that you can’t envisage completing it in 10 man days then analyze it more and change it to more, smaller Features.

I’m beginning to build a list of heuristics for Feature Complexity and I will publish it later this year. Meanwhile, inventory measured as Feature Complexity Points that are tracked on a CFD chart will tend to give more accurate measures than simple Feature tracking.