Feature-Driven Development Projects

A software process functions within a context, that of a software development project. Jeff De Luca, FDD's inventor, has told me on more than one occasion that he sees his job as a project leader as building and maintaining a system to build and maintain a software system. Jeff saw his role as more than building and reporting on a plan in Microsoft Project, tracking a budget, and logging issues and risks. While our goal as developers was to build the software system required by our customers, his goal was to build a system out of people, processes, and tools that could do just that in a cost-effective and timely manner.

Just like good software designers, good project leaders have collected and become adept at applying an experience-based set of patterns that solve common problems. The difference is that these are project structure and behaviour patterns not software structure and behaviour patterns.

The participants in project patterns are not services, classes, functions, data structures and algorithms. Instead the ingredients of a software project comprise things like:

• Some statement of purpose, vision, problem statement, or list of goals or very high-level requirements describing what the system needs to do. Without this there is no reason for the project to exist.
  
• A list of the roles that people play on the project. When written down, this usually takes the form of an abstract organisation chart. Each different role requires a set of skills and a level of experience. Each role defines responsibilities and accountability.
  
• People with the requisite skills and experience to play the roles in the abstract organisation chart. Assigning people to the roles within the abstract organisation chart produces a concrete organisation chart for the project.
  
• A set of well bounded processes describing how these people playing their roles interact with each other to produce the desired software system.
  
• A set of technologies; programming languages, development tools, ready-built components, modules and products.
  
• An architecture, a framework within which to construct the software system. The project may reuse an existing architecture. Alternatively an appropriate framework may not exist and one of the first activities of the project needs to produce and prove the architecture.

The statement of purpose does need to be sensible. It is nonsense to define a statement of purpose for a project that is not achievable within a reasonable time frame. For very ambitious programs, it is often better to identify several projects that can be run concurrently or as follow-on efforts. As we will see FDD supports this need very nicely indeed. The statement of purpose may also start off somewhat vague. Chapter seven suggests a useful exercise to help refine the statement of purpose.

The list of roles of a project team is like the players' positions in a sports team or the parts in a play or symphony. We need the software development equivalent of players, actors and musicians to cast in those roles.

The processes describe the rules of the game, the acts of the play or the movements in a symphony. They describe the framework through which all work is performed.

The technologies are the players' equipment, the props used in the play or the musicians' instruments.

Likewise the architectural framework is the marked pitch, playing area or the stage and scenery.