This is a methodology.  It should be used like a design pattern.

“We think most process initiatives are silly.  Well intentioned managers and teams get so wrapped up in executing process that they forget that they are being paid for results, not process execution” – Coad, Lefebvre, De Luca 19999

Process makes you think “The process is not as creative as it used to be” and then you quit.

History

First appeared in 1999.  Was a result of many failed attempts at the same project and a demoralized team.

Definition

A process designed and proven to deliver frequent, tangible, working results repeatedly.

It’s not:

• YAP (yet another process) that exists for the sake of process
• not a set of process volumes that will sit on your shelf
• doesn’t demoralize your team to bureaucrats and process-centric fanatics happy

Characteristics

• Minimum overhead and disruption
• Delivers frequent, tangible, working results
• Emphasizes quality at each step
• Highly Iterative

FDD is liked by a lot of people.

Devs because:

• use the word finished often
• they’re involved in many parts of the process
• easy to supply managers with info

Clients because:

• see real results early
• progress reports are written in terms they understand

Managers because:

• gives them a good complete and accurate picture of the project’s state

Processes need to be balanced between Heavy Processes (all or nothing) and Light Processes (pure textbook Agile?). 

Heavy Processes: Most companies spend too much money on process for too little value.  When problems come up the add more to the process.  Processes tend to be too inflexible.  Because of this, processes will just get ignored in silence.  Makes traditional PM’s comfortable so it becomes a blame of the process not the person.

Light Weight:  A form of rebellion against heavy process and high ceremony.  Easy to swing from very heavy and going to very light.  You can lose “thinking before coding”, sight of the big picture and you end up back in chaos.

Focuses of FDD

1. Communication and the language of communication
2. Way to manage complexity.  Standardizing the decomposition model.
3. Quality is introduced right at requirements and all the way through to delivery.
4. Just enough process to make sure the team is working together.  Not so much as to cause pain.

FDD roles

• Project Manager
• Chief Architect
• Development Manager
• Chief Programmer
• Class Owner
• Domain Experts

The list of roles is not fixed.  You can create large teams with a larger number of roles like Testers, Deployers, Technical Writers, Release Managers, etc.

Features

Functional requirements restricted to those of value to a user or client phrased in a language the user or client can understand.  They’re small and able to be implemented within a single iteration.  Some features are small enough to be implemented in a few hours.  If you find that your features are too big to complete in an iteration then you should decompose.

Features have a naming convention like

<action> the <result> <by|for|of|to> a(n) <object>

i.e. Calculate the total amount of a Sale.

     or

       Determine the most recent Cash Register Assignment for a Cashier

Law of Consumption of Artifacts  If you produce it and won’t use it, the artifact is useless.

Feature Sets

Grouping of features that are combined in a business sense.

Subject Areas

Major Feature Sets.

Feature Tree

Example

• SLA Mgmt

  *   Viewing an SLA
      *   View Tree hierarchy of SLA's  <li>View list of SLAs <li>Viewing Reports of SLA 
  

FDD Practices

• Domain Object modeling
• Developing by feature
• Individual Class (code) ownership
• Feature teams
• Inspections
• Regular Builds
• Configuration Mgmt
• Reporting/Visibility of Results
• Feature -> Work decomposition model

Assessment phases can be used to get a better idea of the specs and better estimate cost and time for the over all project.

Make sure you know how to get started on the project, how to verify you’re completed correctly and how you know when you can get out of the project at the end.  Do the same for a feature list.  Plan by feature to come up with feature priorities.  Design by Features next, followed by Build by Feature.

God I love Joel!  Finally a presenter who uses cattle (ICattle, Cow, Cows, SalesManager etc.)  Joel Semeniuk is my new coding HERO!!!

Milestones, Visibility and Reporting

No status reports.  Milestones must be concrete, specific, measurable events defined with knife-edge sharpness.  Each phase is given a %age of overall work and then multiplied by the hours estimate.  This makes more sense at the Feature Set level.

Reporting is more detailed than just a burndown chart.  The data is less and less granular as it gets pushed higher up the management team.

FDD in VSTS

Add a couple of fields (feature, planned, actual).  Everything is a task in VSTS including things like Code Reviews, Decomposition, Coding, Code Inspections, etc.

Imaginet’s GrandView tool.  Has single feature task dependency diagram.  Estimate views also exist for features.  This tool does all estimation, VSTS is only used for the construction phase.

Joel’s cattle based class diagram makes the close to Day 1 of DevTeach 2007 a great thing.