Spiral model

The spiral model is a risk-driven process model generator for software projects. Based on the unique risk patterns of a given project, the spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping.

History[edit]

This model was first described by Barry Boehm in his 1986 paper "A Spiral Model of Software Development and Enhancement".^[1] In 1988 Boehm published a similar paper^[2] to a wider audience. These papers introduce a diagram that has been reproduced in many subsequent publications discussing the spiral model.

These early papers use the term "process model" to refer to the spiral model as well as to incremental, waterfall, prototyping, and other approaches. However, the spiral model's characteristic risk-driven blending of other process models' features is already present:

[R]isk-driven subsetting of the spiral model steps allows the model to accommodate any appropriate mixture of a specification-oriented, prototype-oriented, simulation-oriented, automatic transformation-oriented, or other approach to software development.^[2]

In later publications,^[3] Boehm describes the spiral model as a "process model generator", where choices based on a project's risks generate an appropriate process model for the project. Thus, the incremental, waterfall, prototyping, and other process models are special cases of the spiral model that fit the risk patterns of certain projects.

Boehm also identifies a number of misconceptions arising from oversimplifications in the original spiral model diagram. He says the most dangerous of these misconceptions are:

· that the spiral is simply a sequence of waterfall increments;

· that all project activities follow a single spiral sequence; and

· that every activity in the diagram must be performed, and in the order shown.

While these misconceptions may fit the risk patterns of a few projects, they are not true for most projects.

To better distinguish them from "hazardous spiral look-alikes", Boehm lists six characteristics common to all authentic applications of the spiral model.^{[ citation needed ]}

The Six Invariants[edit]

Authentic applications of the spiral model are driven by cycles that always display six characteristics. Boehm illustrates each with an example of a "hazardous spiral look-alike" that violates the invariant.^[3]

Define artifacts concurrently[edit]

Sequentially defining the key artifacts for a project often lowers the possibility of developing a system that meets stakeholder "win conditions" (objectives and constraints).

This invariant excludes “hazardous spiral look-alike” processes that use a sequence of incremental waterfall passes in settings where the underlying assumptions of the waterfall model do not apply. Boehm lists these assumptions as follows:

1. The requirements are known in advance of implementation.

2. The requirements have no unresolved, high-risk implications, such as risks due to cost, schedule, performance, safety, security, user interfaces, organizational impacts, etc.

3. The nature of the requirements will not change very much during development or evolution.

4. The requirements are compatible with all the key system stakeholders’ expectations, including users, customer, developers, maintainers, and investors.

5. The right architecture for implementing the requirements is well understood.

6. There is enough calendar time to proceed sequentially.

In situations where these assumptions do apply, it is a project risk not to specify the requirements and proceed sequentially. The waterfall model thus becomes a risk-driven special case of the spiral model.

Perform four basic activities in every cycle[edit]

This invariant identifies the four basic activities that must occur in each cycle of the spiral model:

1. Consider the win conditions of all success-critical stakeholders.

2. Identify and evaluate alternative approaches for satisfying the win conditions.

3. Identify and resolve risks that stem from the selected approach(es).

4. Obtain approval from all success-critical stakeholders, plus commitment to pursue the next cycle.

Project cycles that omit or shortchange any of these activities risk wasting effort by pursuing options that are unacceptable to key stakeholders, or are too risky.

Some "hazardous spiral look-alike" processes violate this invariant by excluding key stakeholders from certain sequential phases or cycles. For example, system maintainers and administrators might not be invited to participate in definition and development of the system. As a result, the system is at risk of failing to satisfy their win conditions.

Risk determines level of effort[edit]

For any project activity (e.g., requirements analysis, design, prototyping, testing), the project team must decide how much effort is enough. In authentic spiral process cycles, these decisions are made by minimizing overall risk.

For example, investing additional time testing a software product often reduces the risk due to the marketplace rejecting a shoddy product. However, additional testing time might increase the risk due to a competitor's early market entry. From a spiral model perspective, testing should be performed until the total risk is minimized, and no further.

"Hazardous spiral look-alikes" that violate this invariant include evolutionary processes that ignore risk due to scalability issues, and incremental processes that invest heavily in a technical architecture that must be redesigned or replaced to accommodate future increments of the product.

Risk determines degree of detail[edit]

For any project artifact (e.g., requirements specification, design document, test plan), the project team must decide how much detail is enough. In authentic spiral process cycles, these decisions are made by minimizing overall risk.

Considering requirements specification as an example, the project should precisely specify those features where risk is reduced through precise specification (e.g., interfaces between hardware and software, interfaces between prime and sub contractors). Conversely, the project should not precisely specify those features where precise specification increases risk (e.g., graphical screen layouts, behavior of off-the-shelf components).

Use anchor point milestones[edit]

Boehm's original description of the spiral model did not include any process milestones. In later refinements, he introduces three anchor point milestones that serve as progress indicators and points of commitment. These anchor point milestones can be characterized by key questions.

1. Life Cycle Objectives. Is there a sufficient definition of a technical and management approach to satisfying everyone's win conditions? If the stakeholders agree that the answer is "Yes", then the project has cleared this LCO milestone. Otherwise, the project can be abandoned, or the stakeholders can commit to another cycle to try to get to "Yes."

2. Life Cycle Architecture. Is there a sufficient definition of the preferred approach to satisfying everyone's win conditions, and are all significant risks eliminated or mitigated? If the stakeholders agree that the answer is "Yes", then the project has cleared this LCA milestone. Otherwise, the project can be abandoned, or the stakeholders can commit to another cycle to try to get to "Yes."

3. Initial Operational Capability. Is there sufficient preparation of the software, site, users, operators, and maintainers to satisfy everyone's win conditions by launching the system? If the stakeholders agree that the answer is "Yes", then the project has cleared the IOC milestone and is launched. Otherwise, the project can be abandoned, or the stakeholders can commit to another cycle to try to get to "Yes."

"Hazardous spiral look-alikes" that violate this invariant include evolutionary and incremental processes that commit significant resources to implementing a solution with a poorly defined architecture.^{[ clarification needed ]}

The three anchor point milestones fit easily into the Rational Unified Process (RUP), with LCO marking the boundary between RUP's Inception and Elaboration phases, LCA marking the boundary between Elaboration and Construction phases, and IOC marking the boundary between Construction and Transition phases.

Focus on the system and its life cycle[edit]

This invariant highlights the importance of the overall system and the long-term concerns spanning its entire life cycle. It excludes "hazardous spiral look-alikes" that focus too much on initial development of software code. These processes can result from following published approaches to object-oriented or structured software analysis and design, while neglecting other aspects of the project's process needs.

Scrum (software development)

Scrum is an iterative and incremental agile software development framework for managing product development. It defines "a flexible, holisticproduct development strategy where a development team works as a unit to reach a common goal", challenges assumptions of the "traditional, sequential approach" to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines 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 unpredicted 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.

History[edit]

Scrum was first defined as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach" in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the "New New Product Development Game".^[1] Takeuchi and Nonaka later argued in "The Knowledge Creating Company"^[2] that it is a form of "organizational knowledge creation, [...] especially good at bringing about innovation continuously, incrementally and spirally".

The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier and printer industries.^[3] They called this the holistic or rugby approach (in rugby football, a scrum refers to the manner of restarting the game after a minor infraction), as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team "tries to go the distance as a unit, passing the ball back and forth".^[3]

In the early 1990s, Ken Schwaber used what would become Scrum at his company, Advanced Development Methods, and Jeff Sutherland, with John Scumniotales and Jeff McKenna, developed a similar approach at Easel Corporation, and were the first to refer to it using the single word Scrum. ^[4] In 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum methodology at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) in Austin, Texas, its first public presentation.^[5] Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum.

In 2001, Schwaber worked with Mike Beedle to describe the method in the book Agile Software Development with Scrum. ^[6] Its approach to planning and managing projects is to bring decision-making authority to the level of operation properties and certainties.^[7] Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber's early papers, which capitalized SCRUM in the title.^[7]

Later, Schwaber with others founded the Scrum Alliance and created the Certified Scrum Master programs and its derivatives. Ken left the Scrum Alliance in the fall of 2009, and founded Scrum.org to further improve the quality and effectiveness of Scrum.

Roles[edit]

There are three core roles^[8] and a range of ancillary roles. Core roles were previously referred to as pigs and ancillary roles as chickens (after the story The Chicken and the Pig).^[9]

The core roles are those committed to the project in the Scrum process—they are the ones producing the product (objective of the project). They represent the scrum team. Although other roles may be encountered in real projects, Scrum does not define any team roles other than those described below.^[10]

Product Owner[edit]

The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and while they may also be a member of the development team, this role should not be combined with that of the Scrum Master.

Role of Product Owner in Defining and Communicating Product Requirements[edit]

Communication is a main function of the product owner. The ability to convey priorities and empathize with team members and stakeholders are vital to steer the project in the right direction. Product owners bridge the communication gap between the team and their stakeholders. As Figure 1 shows, they serve as a proxy stakeholder to the development team and as a project team representative to the overall stakeholder community.^[11]

As the face of the team to the stakeholders, the following are some of the communication tasks of the product owner to the team:

· demonstrates the solution to key stakeholders who were not present in a normal iteration demo

· announces releases

· communicates team status

· organizes milestone reviews

· educates stakeholders in the development process

· negotiates priorities, scope, funding, and schedule

Empathy is a key attribute for a product owner to have – the ability to put one’s self in another’s shoes. A product owner will be conversing with different stakeholders in the project – different people, with a variety of backgrounds, job roles, and objectives. A product owner needs to be able to see from these different points of view. To be effective, it would also be wise for a product owner to know the level of detail his audience needs from him. The development team would need thorough feedback and specifications so they build a product up to expectation, while an executive sponsor may just need summaries of progress. Providing more information than necessary may lose their interest and waste time. There is also significant evidence that face-to-face communication around a shared sketching environment is the most effective way to communicate information instead of documentation. A direct means of communication is then most preferred by seasoned agile product owners.^[12]

A product owner’s ability to communicate effectively is also enhanced by being skilled in techniques that identify stakeholder needs, negotiate priorities between stakeholder interests, and collaborate with developers to ensure effective implementation of requirements.

Development Team[edit]

The Development Team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each Sprint (the Sprint Goal). A Team is made up of 3–9 individuals with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.). The Development Team in Scrum is self-organizing, even though there may be some level of interface with project management offices (PMOs).

Scrum Master[edit]

Scrum is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The Scrum Master is not a traditionalteam lead or project manager, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of the rules of Scrum, often chairs key meetings, and challenges the team to improve. The role has also been referred to as a servant-leader to reinforce these dual perspectives.

The Scrum Master differs from a project manager in that the latter may have people management responsibilities unrelated to the role of Scrum Master. The Scrum Master role excludes any such additional people responsibilities. In fact, there is no role of project manager in Scrum at all, because none is needed. The traditional responsibilities of a project manager have been divided up and reassigned among the three Scrum roles, and mostly to the Development Team and the Product Owner, rather than to the Scrum Master. Practicing Scrum with the addition of a project manager indicates a fundamental misunderstanding of Scrum, and typically results in conflicting responsibilities, unclear authority, and sub-optimal results.^[13]

Events[edit]

Sprint

A sprint (or iteration) is the basic unit of development in Scrum. The sprint is a "timeboxed" effort; that is, it is restricted to a specific duration.^[14] The duration is fixed in advance for each sprint and is normally between one week and one month, although two weeks is typical.^[7]

Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting,^[4] where the progress is reviewed and lessons for the next sprint are identified.

Scrum emphasizes working product at the end of the Sprint that is really "done"; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.^[13]

Meetings[edit]

Sprint planning meeting[edit]

At the beginning of the sprint cycle (every 7–30 days), a "Sprint planning meeting" is held:^[14]

· Select what work is to be done

· Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team

· Identify and communicate how much of the work is likely to be done during the current sprint

· Eight-hour time limit ^[10]

· (1st four hours) Entire team: dialog for prioritizing the Product Backlog

· (2nd four hours) Development Team: hashing out a plan for the Sprint, resulting in the Sprint Backlog

Дата добавления: 2015-08-27