Jeff De Luca and Peter Coad introduced a groundbreaking approach to software development in 1997. This innovative method, Feature Driven Development, was born from Jeff’s experience managing a complex software project in Singapore. Traditional strategies proved inadequate for the intricate problem domain, leading to the discovery of feature-driven development and modelling in colour with the help of Peter Coad and others.
Coding standards, measurement audits, and metrics are crucial to F.D.D.’s quality concept. Feature-driven development prioritises meetings compared to other methodologies (such as Scrum and XP). A Scrum team typically meets daily, while a Feature-Driven Development team primarily communicates information via documentation. In Feature Driven Development, the end user is the actual user, whereas in Scrum, the product owner is. Feature-driven Development identifies the target audience and the content and context of the project. As part of this process, teams must determine what, why, and for whom their project is (the next few steps will clarify how). Data collection is not considered stage 0, but it must be done at this stage.
Having people on board for a project is most important, but processes and technology are also critical. In addition to the six roles defined by Feature-Driven Development, there are implied roles. Throughout design workshops, the Chief Architect leads the team in developing the system’s overall design. The Project Manager (PM) manages the budget, staffing, equipment, space, and resources. One needs sound technical, modelling, and facilitation skills to succeed in this work. As the project progresses, the Chief Architect must guide it through technical difficulties.
A Development Manager (DM) leads the development process daily. Development Managers resolve resource conflicts when Chief Programmers cannot. Chief Programmers are pivotal in the development lifecycle, contributing to software development at every phase. Their responsibilities range from high-level requirement analysis and design to leading small teams of three to six developers in low-level analysis, design, and development.
On the other hand, a Class Owner is a developer who takes charge of designing, developing, testing, and documenting the new software system. Domain Experts may be users, sponsors, or business analysts. A knowledge base enables developers to develop the right system based on the correct information. Communicating, writing, and presenting well are essential skills for domain experts. Participation and knowledge are necessary for a system to be successful.
Supporting roles include the following. Release Managers are responsible for ensuring that Chief Programmers report progress every week. Because of this, he reports directly to the Project Manager. Programmers specialising in a particular language or technology are called Language Gurus, and they play a vital role in developing new programming languages or technologies. The Build Engineer is responsible for setting up, maintaining, and running the regular build process. Toolsmiths develop tools for data conversion, testing, and development teams.
System administrators configure, manage, and troubleshoot servers, workstations, and network solutions. An independent tester ensures that a system’s functions meet users’ requirements and are correctly implemented. After data is converted to the new system’s new formats, new versions are physically deployed. The technical writer prepares user guides both online and in print. Classes (pieces of code) belong to a specific person or role during development. A developer in Feature Driven Development owns an object model class. For features affecting multiple classes, more than one class owner may be involved in the implementation. To accomplish this, the Feature Owner should act as the team leader and coordinate the efforts of many developers.
As a result of the limited number of features, the size of a feature team is limited. As the feature team owns all the code for that feature, you do not have to wait for other teams to update the code. There is a sense of collective ownership as well as code ownership. Feature team members work under the guidance of a skilled, experienced developer to design and implement features. In this way, relying on specific classes or developers is less risky. A class owner may be a member of multiple feature teams.
Feature teams led by other Chief Programmers include Chief Programmers as Class Owners. In feature-driven development, the mix of feature teams and inspections adds dimension. A feature team comprises more than one member, so there is no concern about humiliation. We propagate exemplary development practices, conventions, and culture by using the best-known defect detection techniques and leveraging their opportunities. Whenever a feature is completed, the source code, libraries, and components are taken, and the system is assembled as a whole. Demonstrable systems are, therefore, always available. Based on the work that has been completed, we regularly, correctly, and accurately report progress at all levels of the project.
The journey of feature-driven development begins with Domain Experts collaborating with developers to create a domain object model. This model, representing the key concepts and relationships in the domain, is the foundation for the development process. As a result of the modelling activity and any required activities that have been conducted, the developers create a feature list. The next step is to draw up a rough plan and assign duties. We typically take on small groups of features that last no longer than two weeks.
Domain and development team members work together under the guiding hand of an experienced object modeller (Chief Architect). Domain members perform a high-level walkthrough of the system scope and its context. Then, domain members perform more detailed walkthroughs of each problem domain area. Each time a walkthrough is completed, the domain and development members work together in small groups to develop object models for the domain area. Peer review and discussion are conducted for each small group’s model supporting the domain walkthrough. In each domain area, one model or a merger of models is selected by consensus. To adjust the model shape as needed, the domain area model is merged into the overall model.
As part of their planning process, the project manager, development manager, and chief programmers determine the order of implementing features based on feature dependencies, load across the entire development team, and complexity. There is no strict order to the main tasks in this process. It is a frequent pattern in planning activities to consider all tasks together, refine one or more, and then consider the others again. A typical situation involves assigning feature sets to Chief Programmers based on the development sequence. When doing so, consider which key classes each developer is assigned. It is only when this balance is achieved, and all business activities have been assigned to Chief Programmers that class ownership is complete.
Chief Programmers are responsible for developing several features. The Chief Programmer selects features from a list of assigned features for development. They typically schedule small groups of features for development at a time and may choose multiple features that can be implemented by the same class (hence developers). A Chief Programmer is generally responsible for such a group of features. To develop the selected feature(s), the Chief Programmer identifies the class owners (developers) likely to be involved. They then refine the object model based on the sequence diagram(s). Class owners implement the items needed for their class to support the design package in order to implement the design for the feature(s) in the work package. The Chief Programmer determines when to perform unit testing and code inspections on the developed code. If a code inspection is successful, the code can be pushed forward.
Team members are not asked for completeness percentages when working on feature-driven development. As part of Feature Driven Development, teams are informed of the percentage of their work that has been completed! Up to 500 developers can be involved in feature-driven development. Using feature-driven development, teams can achieve frequent, measurable results more quickly. Feature blocks are tiny blocks of client-valued functionality. Organising these little blocks leads to a set of business-related features.
In feature-driven development, working results are produced every two weeks. An approach based on features is well-suited for teams where developers have varying levels of experience. It also offers reporting capabilities and tracking progress. Therefore, big companies and managers find it more appealing. Feature-driven development can benefit long-term, complex projects. It is an effective method for development teams seeking scalability, predictability, and simplicity.
