Two important development strategies are introduced in this chapter: the team model and the process model. Together, these two strategies constitute a systematic approach to meeting the requirements of the development model introduced in “Enterprise Application Model,” in Chapter 1, “What is an Enterprise Application?”
The team model is built around the concept of a small team of peers working in interdependent, cooperating roles. There are six specific team roles defined in the model: Product Management, Program Management, Development, Test and Quality Assurance (QA), User Education, and Logistics Planning.
For very large projects, group managers can fill the team roles, and in turn coordinate small "subteams." Subteams can be either functional teams or feature teams, and can in turn be broken down into yet smaller subteams. Each team, from the highest to the lowest level, consists of no more than five to seven team members with well-defined roles.
The team members "own" the process they are working on, and work closely with other teams in an iterative, cooperative format to achieve a common goal. This facilitates parallel component development and supports the iterative, milestone-based process model.
The process model is an iterative, milestone-based approach to the development process itself. The four characteristics of this milestone-driven model are: milestone-based approach, clear ownership and accountability, risk-driven scheduling, and versioned releases.
In this process model, milestones are not freeze-points, but rather points at which baseline deliverables are placed under change control. Change is tracked through a database system through which all team members are able to participate and agree to changes. Program Management coordinates changes.
Interim milestones are established within each phase of development. This allows an iterative development process in which multiple components are developed in parallel, integrated for testing at interim milestones and test releases, and then successively developed in parallel. Individual team members "own" a clearly-defined part of the project, for which they are responsible to the rest of the team.
Risk-driven scheduling and versioned releases help establish a "product" mindset in which release dates are met by mutual coordination, with risky features or desirable new features postponed for later release.