Scrum Development Method
Scrum is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development. Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach.
Scrum is unique because it introduced the idea of “empirical process control.” That is, Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases. In Scrum, projects are divided into succinct work cadences, known as sprints, which are typically one week, two weeks, or three weeks in duration. At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. This allows a project’s direction to be adjusted or reoriented based on completed work, not speculation or predictions.
Philosophically, this emphasis on an ongoing assessment of completed work is largely responsible for its popularity with managers and developers alike. But what allows the Scrum methodology to really work is a set of roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic.
Scrum is a “process skeleton,” which contains sets of practices and predefined roles. The main roles in Scrum are:
During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog,” which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed. The team then determines how much of this they can commit to complete during the next sprint. During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredictable challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
There are several implementations of systems for managing the Scrum process, which range from yellow stickers and whiteboards, to software packages. One of Scrum’s biggest advantages is that it is very easy to learn and requires little effort to start using.
Feature Driven Development Method
Feature Driven Development (FDD) is an agile and adaptive approach for developing systems. The FDD approach does not cover the entire software development process, but rather focuses on the design and building phases. However, it has been designed to work with other activities of a software development project and does not require any specific process model to be used. The FDD approach embodies iterative development with the best practices found to be effective in industry. It emphasizes quality aspects throughout the process and includes frequent intangible deliveries, along with accurate monitoring of the progress of the project.
FDD consists of 5 sequential processes and provides a methods, techniques and guidelines needed by the project stakeholders to deliver the system. Furthermore, FDD includes the roles, artifacts, goals, and timelines needed in a project. Unlike some other agile methodologies, FDD claims to be suitable for the development of critical systems.
Process
As mentioned earlier, FDD consists of 5 sequential processes during which the design and building of the system is carried out. The iterative part of the FDD processes (design and build) supports agile development with quick adaptations to late changes in requirements and business needs. Typically, an iteration of the feature involves a 1 to 3 week period of work for the team.
Develop an Overall Model
When the development of an overall model begins, the domain experts are already aware of the scope, context and requirements of the system to be built. Documented requirements such as use cases were functional specifications are likely to exist at this stage. However, FDD does not explicitly address the issues of gathering and managing the requirements. The domain expert present a so-called “walk-through” in which the team members and the chief architect are informed of the high-level description of the system.
The overall domain is further divided into different domain areas and a more detailed walk-through is held for each of them by the domain members. After each walk-through, the development team works in small groups in order to produce object models for the domain area at hand. The development team then discusses and decides upon the appropriate object models for each of the domain areas. Simultaneously, and overall model shape is constructed for the system.
Build a Features List
The walk-throughs, object models and existing requirement documentation give a good basis for building a comprehensive features list for the system being developed. In the list, the development team presents each of the client valued functions included in the system. The functions are presented for each of the domain areas and these function groups consist of so-called major feature sets. In addition, the major feature set are further divided into feature set. These represent different activities within specific domain areas. The feature list is reviewed by the users and sponsors of the system for their validity and completeness.
Plan by Feature
Planning by feature includes the creation of a high-level plan, in which the feature sets are sequenced according to their priority and dependencies and assigned to chief programmers. Furthermore, the classes identified in the “developing of an overall model” process are assigned to individual developers, i.e. class owners. Also scheduled major milestones may be done for the feature sets.
Design by Feature and Build by Feature
A small group of features is selected from the feature set(s) and feature teams needed for the developing the selected features are formed by the class owners. The design by feature and build by feature processes are iterative procedures, during which the selected features are produced. One iteration should take from a few days to a maximum of 2 weeks. There can be multiple feature teams concurrently designing and building their own set of features. This iterative process includes such tasks as design inspection, coding, unit testing, integration and code inspection. After a successful iteration, the completed features are promoted to the main build while the aeration of designing and building begins with a new group of features taken from the feature set.
Roles and Responsibilities
The FDD classifies its rolls into 3 categories: key roles, supporting roles and additional roles. The 6 key roles in an FDD project are: project manager, chief architect, development manager, chief programmer, class owner and domain experts. The 5 supporting roles comprise release management, language guru, build engineer, toolsmith and system administrator. The 3 further roles that are needed in any project are those of the testers, deployers and technical writers. One team member can play multiple roles, and a single role can be shared by several people.
Project Manager
Project manager is the administrative and financial leader of the project. One of his/her tasks is to protect the project team from outside distractions and to enable the team to work along with providing it with the appropriate working conditions. In FDD, the project manager has the ultimate say on the scope, schedule, and staffing of the project.
Chief Architect
The chief designer is responsible for the overall design of the system and running the workshop design sessions held with the team. The chief architect also makes the final decisions on all design issues. If necessary, this role can be divided into the roles of domain architect and technical architect.
Development Manager
The development manager leads daily development activities and solves any conflicts that may occur within the team. In addition, this role includes the responsibility of solving resourcing problems. The task of this role can be combined with those of the chief architect project manager.
Chief Programmer
The chief programmer is an experienced developer, who participates in the requirements analysis and design of the project. The chief programmer is responsible for leading small teams in the analysis, design and development of new features. Selecting features from the feature set(s) to be developed in the next iteration of the “design by feature and build by feature” processes and identifying the classes and class owners that are needed in the feature team for the iteration also belong to the responsibilities of the chief programmer, along with cooperation with other chief programmers in solving technical and resourcing issues, and reporting the progress of the team weekly.
Class Owner
Class owners work under the guidance of the chief programmer in the tasks of designing, coding, testing and documenting. He/she is responsible for the development of the class he/she has been assigned to be the owner of. Class owners form feature teams. For each iteration those class owners are involved whose class is included in the features selected for the next development iteration.
Domain Expert
The domain expert may be a user, a client, a sponsor, a business analyst or a mixture of these. His/her task is to possess the knowledge of how the different requirements for the system under development should perform. Domain experts pass this knowledge to the developers in order to ensure that the developers delivering competent system.
Domain Manager
Domain manager leads the domain experts and resolve their differences of opinion concerning requirements of the system.
Release Manager
Release manager controls the progress of the process by reviewing the progress reports of chief programmers and holding sure progress meetings with them. He/she reports the progress to the project manager.
Language Guru
A member sponsor pull for possessing a thorough knowledge of, for example, a specific programming language or technology. This role is particularly important when the project team is dealing with some new technology.
Build Engineer
A person responsible for setting up, maintaining and running the build process, including the tasks of managing the version control system and publishing documentation.
Toolsmith
Toolsmith is a role for building small tools for development, test and data conversion teams in the project. Also, a toolsmith may be working with setting up and maintaining databases and websites for project specific purposes.
System Administrator
The task of a system administrator is to configure, to manage and to troubleshoot servers, network of workstations and development and testing environments used by the project team. Also, the system administrator may be involved in the productionizing of the system being developed.
Tester
Testers verify that the system being produced meet the requirements of the customer. May be an independent team or part of the project team.
Deployer
Deployers’ work is concerned with converting existing data to the format required a new system and participating in the deployment of new releases. May be an independent team or a part of the project team.
Technical Writer
The user documentation is prepared by technical writers, who may form an independent team or be a part of the project team.
Practices
• Domain object modeling: exploration and explanation of the domain of the problem. Results in a framework where the features are added.
• Developing by feature: developing and tracking the progress through a list of small functionally decomposed and client valued features.
• Individual class (code) ownership: each class has a single person nominated to be the one responsible for the consistency, performance and conceptual integrity of the class.
• Feature teams: refers to small, dynamically formed teams.
• Inspection: refers to the use of the best known defect detection mechanisms.
• Regular bills: refers to ensuring that there is always a running, demonstrable system available. Regular bills form the baseline to which new features are added.
• Configuration management: enables the identification and historical tracking the latest versions of each completed source code file.
• Progress reporting: progress is reported based on complete work to all necessary organizational levels