Crystal methodologies
Crystal methodologies are part of a family of methodologies called the Crystal family [39]. All of these methodologies provide guidelines of policy standards, work products, ”local matters”, tools, standards and roles to be followed in the development process [1]. With regard to the development process, only two commonalities exist among the entire crystal family: Incremental cycles may not exceed four months and reflection workshops must be held after every delivery so that the methodology is self-adapting [141].
The word ”crystal” in the name of this methodology-family refers to the various facets of a gemstone, each one being a different viewpoint towards one and the same underlying core [80]. The underlying core represents values and principles, while each facet represents a specific set of elements such as techniques, roles, tools, and standards. An example of a value that is common among the entire crystal family is the importance of proper com- munication and collaboration among the team members [39]. The different methods are assigned colors arranged in ascending opacity, where a less opaque color represents a more agile methodology. The most Agile version is Crystal Clear, followed by Crystal Yellow,
6. AGILE METHODOLOGIES
Crystal Orange and Crystal Red. The version of crystal you use depends on the number of people involved, which translates into a different degree of emphasis on communication [41]. At the moment only crystal clear and crystal orange have been developed [1].
Adaptive software development
Adaptive Software Development (ASD) [77] is a process methodology focused on iterations and constant prototyping and is particularly suited for the development of large and complex software systems. The aim of ASD is to provide a framework with just enough guidance so the project does not fall into chaos, but not so much that it would suppress emergence and creativity [1].
According to HighSmith An iteration in the ASD process: ”needs to be short, so teams
can learn from small rather than large mistakes” [77]. Such a iteration is, as depicted in
figure 6.6, is divided into three phases [77, 79]:
Figure 6.6: The ASD cycle [79]
• speculate phase
In this phase the objectives, vision, goals, and requirements of the system to be de- veloped in the current iteration are specified. The name speculate is chosen instead of planning because planning seems to imply that uncertainty must be avoided.
• Collaborate phase
In this phase the system to be built for the current iteration is constructed.
Other agile methods
In this phase the products constructed during the collaboration phase are exposed to a variety of stakeholders to ascertain value. ”Customer focus groups, technical reviews,
beta testing, and postmortems are all practices that expose results to scrutiny” [77].
Feedback from this phase as well as the system constructed during this iteration are inputs for the next iteration, so it is possible to learn from mistakes made during this iteration.
Feature driven development
Feature Driven Development (FDD) [37, 110] is an agile and adaptive approach to develop systems, which does not cover the entire software development process, but just the design and building phases. The approach prescribes emphasis on quality aspects throughout the process, short iterations with frequent and tangible deliveries and accurate monitoring of other progress of the project [37, 110, 1]. The process, which is depicted in figure 6.7, consists of five sequential phases, of which the first three are done at the beginning of the project and the last two form the iterative part of the process:
Figure 6.7: The five phases of FDD [37]
• Develop an overall model
When this phase begins, the domain experts already are aware of the scope, context and requirements of the system to be built. So, requirement gathering and optionally, the creation of the documentation of these requirements, has been done at this stage. In this stage all team members and the chief architect are informed of the high-level description of the system with so-called ”walkthroughs” of the system, at various levels of detail.
• Build a features list
In this phase a categorized list of the features to support the requirements is produced. The size of these features is so that they can be implemented in ten days. Features requiring more time than ten days are broken down into sub-features. Finally the list of features produced, is reviewed by the users and sponsors of the system to test if the list is both valid and complete.
6. AGILE METHODOLOGIES
• Plan by feature
In this phase, the categories of features are sequenced with respect to their priority and dependencies among another. Then the categories are assigned to developers who will be responsible for the development of that category, and a schedule of milestones is created.
• Design by feature and build by feature
In these phases all the features are produced in an iterative manner. Each iteration, a set of features is selected and the developers responsible for the development of the feature categories selected in this iteration, form teams to perform the implementa- tion. An iteration usually takes anywhere between a few days and two weeks. When an iteration if finished the completed features are integrated into the main build and a new set of features is selected for the next iteration.