Valacich J., George J., Hoffer J.A. Essentials of Systems Analysis and Design
Подождите немного. Документ загружается.
Appendix B Agile Methodologies 383
than predictive methodologies, (2) a focus on people rather than roles, and (3) a
self-adaptive process.
The Agile Methodologies group argues that software development method-
ologies adapted from engineering generally do not fit well with the reality of
developing software. In the engineering disciplines, such as civil engineering,
requirements tend to be well understood. Once the creative and difficult work of
design is completed, construction becomes more predictable. In addition, con-
struction may account for as much as 90 percent of the total project effort. For
software, on the other hand, requirements are rarely understood well, and they
change continually during the lifetime of the project. Construction may account
for as little as 15 percent of the total project effort, leaving design to constitute
as much as 50 percent of the project effort. Applying techniques that work well
for predictable, stable projects, such as building a bridge, tend not to work well
for fluid design-heavy projects, such as writing software, say the Agile Method-
ology proponents. What are needed are methodologies that embrace change and
that are able to deal with a lack of predictability. One mechanism for dealing with
a lack of predictability, which all Agile Methodologies share, is iterative devel-
opment. Iterative development focuses on the frequent production of working
versions of a system that have a subset of the total number of required features.
Iterative development provides feedback to customers and developers alike.
Second, the focus on people in Agile Methodologies is a focus on individuals
rather than on the roles that people perform. The roles that people fill, of systems
analyst or tester or manager, are not as important as the individuals who fill those
roles. Fowler argues that the focus on engineering principles applied to systems
development has resulted in a view of people as interchangeable units instead of
a view of people as talented individuals, each of whom has something unique to
bring to the development team.
Third, the Agile Methodologies also promote a self-adaptive software develop-
ment process. As software is developed, the process used to develop it should be
refined and improved. Development teams can discover these improvements
through a review process, often associated with the completion of iterations. The
implication is that, as processes are adapted, you would not expect to find a
single monolithic methodology within a given corporation or enterprise. Instead,
you would find many variations of the methodology, each of which reflects the
particular talents and experience of the team using it.
Agile Methodologies are not for every project. An Agile or adaptive process is
recommended if your project involves:
쐍 Unpredictable or dynamic requirements
쐍 Responsible and motivated developers
쐍 Customers who understand and will get involved
On the other hand, a more engineering-oriented predictable process may be
necessary if the development team exceeds 100 people and the project is
operating under a fixed-price or fixed-scope contract. Thus, organizations need
various approaches for developing information systems, depending upon the
characteristics of the system and the development team.
Although not universally agreed on, the key differences in development
approaches are listed in Table B-1, based on work by Boehm and Turner (2004).
These five key factors can be used to help determine which development
approach would work best for a particular project.
As you can see from Table B-1, the size of the systems development project
is a key indicator of whether Agile Methodologies are appropriate. Agile methods
fit much better with smaller projects than with larger ones. Traditional methods
are preferred for large projects and for those dealing with safety-critical
systems, such as the control systems for nuclear power plants and missile
384 Appendix B Agile Methodologies
launch pads. The reason for using engineering-based methods for safety-critical
systems is that they have been proven to work well with such systems. Another
variable that differentiates between Agile and traditional approaches is
dynamism. Agile methods work well when the target system is to operate in a
volatile and fluid environment, where business conditions are turbulent and
frequently changing. Because of the large amount of planning that is part of
them, traditional approaches work best where the system being developed
operates in a stable environment. You read about how Agile Methodologies
stress the importance of individuals rather than roles. The implication is that an
Agile approach may not work so well unless there is a critical mass of agility
experts. Finally, Agile methods will work best in an organization culture that
thrives on uncertainty, rapid change, and chaos. Traditional methods work
where organizational roles are clearly defined and change little.
One of the best-known and most written-about Agile Methodologies is called
eXtreme Programming. Developed by Kent Beck in the late 1990s, eXtreme
Programming illustrates many of the central philosophies of this new approach
to systems development. We use eXtreme Programming as an example of the
central ideas common to many Agile methods and present it next in more detail.
eXtreme Programming
eXtreme Programming is distinguished by its short development cycles, its
incremental planning approach, its focus on automated tests written by
programmers and customers to monitor the process of development, and its
reliance on an evolutionary approach to development that lasts throughout the
lifetime of the system. One of the key emphases of eXtreme Programming is its
use of two-person programming teams, described here, and having a customer
on-site during the development process. The relevant parts of eXtreme
Programming that relate to design specifications are: (1) how planning, analy-
sis, design, and construction are all fused together into a single phase of activ-
ity, and (2) its unique way of capturing and presenting system requirements and
design specifications. All phases of the life cycle converge together into a
TABLE B-1: Five Critical Factors That Distinguish Agile and Traditional Approaches
to Systems Development
Factor Agile Methods Engineering-Based Methods
Size Well-matched to small products and teams.
Reliance on tacit knowledge limits scalability.
Methods evolved to handle large products and
teams. Hard to tailor down to small projects.
Criticality Untested on safety-critical products. Potential difficulties
with simple design and lack of documentation.
Methods evolved to handle highly critical products.
Hard to tailor down to low-criticality products.
Dynamism Simple design and continuous refactoring are excellent for
highly dynamic environments but are a source of potentially
expensive rework for highly stable environments.
Detailed plans and Big Design Up Front are excellent
for highly stable environments but are a source of
expensive rework for highly dynamic environments.
Personnel Requires continuous presence of a critical mass
of scarce experts. Risky to use non-Agile people.
Needs a critical mass of scarce experts during
project definition but can work with fewer later in the
project, unless the environment is highly dynamic.
Culture Thrives in a culture where people feel comfortable
and empowered by having many degrees of freedom
(thriving on chaos).
Thrives in a culture where people feel comfortable
and empowered by having their roles defined by
clear practices and procedures (thriving on order).
Source:
Boehm & Turner, 2004. Used by permission.
Appendix B Agile Methodologies 385
series of activities based on the basic processes of coding, testing, listening,
and designing.
Under this approach, coding and testing are intimately related parts of the same
process. The programmers who write the code also write the tests. The emphasis
is on testing those things that can break or go wrong, not on testing everything.
Code is tested soon after it is written. The overall philosophy behind eXtreme
Programming is that code will be integrated into the system it is being developed
for and tested within a few hours after it has been written. Code is written, inte-
grated into the system, and then tested. If all the tests run successfully, then
development proceeds. If not, the code is reworked until the tests are successful.
Another part of eXtreme Programming that makes the code-and-test process
work more smoothly is the practice of pair programming. All coding and testing
is done by two people working together, writing code and writing tests. Pair
programming is not one person typing while the other one watches. Rather, the
two programmers work together on the problem they are trying to solve,
exchanging information and insight and sharing skills. Compared to traditional
coding practices, the advantages of pair programming include: (1) more (and
better) communication among developers, (2) higher levels of productivity,
(3) higher-quality code, and (4) reinforcement of the other practices in eXtreme
Programming, such as the code-and-test discipline. Although the eXtreme Pro-
gramming process has its advantages, just as with any other approach to systems
development, it is not for everyone and is not applicable to every project.
The Heart of the Systems Development Process
The systems development life cycle used in this book provides a convenient
way to see the systems development process and helps to organize this book.
The different phases are clearly defined, their relationships to each other are
well specified, and the sequencing of phases from one to the next, from begin-
ning to end, has a compelling logic. In the Agile Methodologies, current practice
combines the activities traditionally thought of as belonging to analysis, design,
and implementation into a single process. Instead of systems requirements
being produced in analysis, system specifications being created in design, and
coding and testing being done at the beginning of implementation, current prac-
tice combines all of these activities into a single analysis-design-code-test
process (Figure B-2). These activities are the heart of systems development, as
we suggest in Figure B-3. This combination of activities started with rapid
application development (RAD), which you read about in Chapter 1, and is seen
in many of the Agile Methodologies.
In the rest of this appendix, we will focus on the heart of systems development—
analysis, design, and implementation—from the perspective of the Agile Method-
ologies. Note that Figure B-3 shows two arrows between analysis and design.
Test Design
Code
Analyze
FIGURE B-2
The analysis-design-code-test loop.
386 Appendix B Agile Methodologies
These arrows denote the iteration between these two activities, which is at the
core of developmental agility. In the next sections you will read about the iteration
between analysis and design and where certain aspects of implementation fit it.
The first section is about requirements determination. The second section is about
design specifications, and the last section is about the combination of coding and
testing in implementation. As you read before, many flavors of the Agile Method-
ologies are available. We will illustrate how these methodologies work primarily
with the eXtreme Programming approach, but we will also reference Agile Usage-
Centered Design, originally developed by Larry Constantine and adapted for Agile
Methodologies by Jeff Patton.
Requirements Determination
Three requirements determination techniques are presented in this section.
The first is continual user involvement in the development process, a tech-
nique that works especially well with small and dedicated development teams.
The second approach is a JAD-like process called Agile Usage-Centered
Design. The third approach is the Planning Game, which was developed as
part of eXtreme Programming.
Continual User Involvement One of the criticisms of the traditional
engineering-based approach to systems development is that users were involved
only in the early stages of analysis. Once requirements had been gathered from
them, the users were not involved again in the process until the system was being
installed and they were asked to sign off on it. Typically, by the time users saw the
system again, it was nothing like what they had imagined. Also, given how their
business processes had changed since analysis had ended, the system most likely
did not adequately address user needs. To some extent, this view of limited user
participation is a stereotype of the traditional approach to development.
Nonetheless, limited user involvement has been common enough to be perceived
as a real and serious problem in systems development.
One approach to the problem of limited user involvement is to involve the
users continually throughout the entire analysis and design process. Such an
approach works best when development can follow the analysis-design-code-
test cycle favored by the Agile development methodologies (Figure B-1), as the
user can provide information on requirements and then watch and evaluate as
those requirements are designed, coded, and tested. This iterative process can
continue through several cycles until most of the major functionality of the
system has been developed. Extensive involvement of users in the analysis and
design process is a key part of many Agile approaches, but it was also a key part
of rapid application development (see Chapter 1).
Planning &
Selection
Implementation
& Operation
Design
Analysis
FIGURE B-3
The heart of systems development.
Appendix B Agile Methodologies 387
Continual user involvement was a key aspect of the success of Boeing’s Wire
Design and Wire Install system for the 757 aircraft (Bedoll, 2003). The system
was intended to support engineers who customize plane configurations for
customers, allowing them to analyze whether all 50,000 wires can possibly be
installed on a 757. A previous attempt at building a similar system took more
than three years, and the resulting system was never used. The second attempt,
relying on Agile methods, resulted in a system that was in production after only
six weeks. One of the keys to success was a user liaison who spent half of his
time with the small development team and half with the other end users. In
addition to following the analysis-design-code-test cycle, the team also had
weekly production releases. The user liaison was involved every step of the way.
Obviously, for such a requirements determination to succeed, the user who
works with the development team must be especially knowledgeable, but he or
she must also be in a position to give up his or her normal business responsi-
bilities in order to become so heavily involved in a system’s development.
Agile Usage-Centered Design Continual user involvement in systems
development is an excellent way to ensure that requirements are captured
accurately and are immediately implemented in system design. However, such
constant interaction works best when the development team is small, as was
the case in the previous Boeing example. Also, it is not always possible to
have continual access to users for the duration of a development project. So
Agile developers have come up with other means for effectively involving users
in the requirements determination process. One such method is called Agile
Usage-Centered Design, a process with nine steps, which we have adapted and
presented as eight steps in Table B-2.
Notice how similar the overall process is to a JAD meeting (see Chapter 5). All
of the experts are gathered together and work with the help of the facilitator.
What’s unique about the Agile Usage-Centered Design is the process that
TABLE B-2: Steps in the Agile Usage-Centered Design Method
for Requirements Determination
1. Gather a group of people, including analysts, users, programmers, and testing staff, and sequester them in a room
to collaborate on this design. Include a facilitator who knows this process.
2. Give everyone a chance to vent about the current system and to talk about the features everyone wants in the new system.
Record all of the complaints and suggestions for change on whiteboards or flip charts for everyone to see.
3. Determine what the most important user roles would be. Determine who will be using the system and what their goals are
for using the system. Write the roles on 3 5 cards. Sort the cards so that similar roles are close to each other. Patton
(2002) calls this a
role model.
4. Determine what tasks user roles will have to complete in order to achieve their goals. Write these down on 3 5 cards.
Order tasks by importance and then by frequency. Place the cards together based on how similar the tasks are to each
other. Patton calls this a
task model.
5. Task cards will be clumped together on the table based on their similarity. Each clump of cards is called an
interaction
context.
6. For each task card in the interaction context, write a description of the task directly on the task card. List the steps that are
necessary to complete the task. Keep the descriptions conversational to make them easy to read. Simplify.
7. Treat each clump as a tentative set of tasks to be supported by a single aspect of the user interface, such as a screen, page,
or dialog, and create a paper-and-pencil prototype for that part of the interface. Show the basic size and placement of the
screen components.
8. Take on a user role and step through each task in the interaction context as modeled in the paper-and-pencil prototype.
Make sure the user role can achieve its goals by using the prototype. Refine the prototype accordingly.
388 Appendix B Agile Methodologies
supports it, with a focus on user roles, user goals, and the tasks necessary to
achieve those goals. Then tasks are grouped and turned into paper-and-pencil
prototypes before the meeting is over. Requirements captured from users and
developers are captured as prototyped system screens. The two most effective
aspects of this approach are the venting session, which lets everyone get their
complaints out in the open, and the use of 3 5 cards, which serve as very
effective communication tools. As with any analysis and design process or
technique, however, Agile Usage-Centered Design will not work for every
project or for every company.
The Planning Game The techniques used for requirements determination
in eXtreme Programming are captured in the Planning Game. The Planning
Game is really just a stylized approach to development that seeks to maximize
fruitful interaction between those who need a new system and those who build
it. The players in the Planning Game, then, are Business and Development.
Business is the customer and is ideally represented by someone who knows the
processes to be supported by the system being developed. Development is
represented by those actually designing and constructing the system. The game
pieces are what Beck calls “Story Cards.” These cards are created by Business
and contain a description of a procedure or feature to be included in the system.
Each card is dated and numbered and has space on it for tracking its status
throughout the development effort.
The Planning Game has three phases: exploration, commitment, and steering
(Figure B-4). In exploration, Business creates a Story Card for something it
wants the new system to do. Development responds with an estimation of how
long it would take to implement the procedure. At this point, it may make sense
to split a Story Card into multiple Story Cards, as the scope of features and
procedures becomes clearer during discussion. In the commitment phase,
Business sorts Story Cards into three stacks, one for essential features, one for
features that are not essential but would still add value, and one for features that
would be nice to have. Development then sorts Story Cards according to risk,
based on how well they can estimate the time needed to develop each feature.
EXPLORATION
Business writes a Story Card.
Development provides an estimate.
COMMITMENT
Business sorts Stories by necessity.
Development sorts Stories by risk.
Business chooses Stories for next release.
STEERING
Business reviews progress.
Business and Development adjust plan.
FIGURE B-4
eXtreme Programming’s
Planning Game.
Appendix B Agile Methodologies 389
Business then selects the cards that will be included in the next release of
the product. In the final phase, steering, Business has a chance to see how the
development process is progressing and to work with Development to adjust
the plan accordingly. Steering can take place as often as once every three weeks.
The Planning Game between Business and Development is followed by the
Iteration Planning Game, played only by programmers. Instead of Story Cards,
programmers write Task Cards, which are based on Story Cards. Typically,
several Task Cards are generated for each Story Card. The Iteration Planning
Game has the same three phases as the Planning Game: exploration, commit-
ment, and steering. During exploration, programmers convert Story Cards into
Task Cards. During commitment, they accept responsibility for tasks and
balance their workloads. During steering, the programmers write the code for
the feature, test it, and if it works, they integrate the feature into the product
being developed. The Iteration Planning Game takes place during the time
intervals between steering phase meetings in the Planning Game.
You can see how the Planning Game is similar in some ways to Agile Usage-
Centered Design. Both rely on participation by users, rely on cards as commu-
nication devices, and focus on tasks the system being designed is supposed to
perform. Although these approaches differ from some of the more traditional
ways of determining requirements, such as interviews and prototyping, many of
the core principles are the same. Customers, or users, remain the source for
what the system is supposed to do. Requirements are still captured and negoti-
ated. The overall process is still documented, although the extent and formality
of the documentation may differ. Given the way requirements are identified and
recorded and broken down from stories to tasks, design specifications can
easily incorporate the characteristics of quality requirements: completeness,
consistency, modifiability, and traceability.
Design Specifications
With their focus on working software over documentation, the Agile Method-
ologies promote rapid iterative movement between design and coding. Design
specifications are captured as part of the design process itself, evolving with
each iteration through the cycle of analysis-design-code-test (see Figure B-2),
leaving little room in the process for documenting the design with paper or
diagrams or in any other way than the code itself.
At one extreme, then, a project using only Agile Methodologies would not
produce design specifications of any kind other than the code. At the other
extreme, where more traditional or engineering-based methodologies are
used, detailed and complete design specifications would be generated. These
specifications would then be handed over to programming and testing teams
once they were complete. Many choices are also available between these
extremes. Whether a systems development project is organized in terms of
Agile or more traditional methodologies depends on many different consider-
ations. If a project is considered to be high risk, highly complex, and has a
development team made up of hundreds of people, then more traditional
methods will apply. Less risky, smaller, and simpler development efforts lend
themselves more to Agile methods. Other determining factors include organi-
zational practice and standards and the extent to which different parts of the
system will be contracted out to others to develop. Obviously, the larger
the proportion of the system that will be farmed out, the more detailed the
design specifications will need to be so subcontractors can understand what
is needed.
Agile Methodologies go from requirements to functional design directly to
code, where the design specifications are immediately captured and then
tested. Lengthy text specifications, computer-based specification tools, and
390 Appendix B Agile Methodologies
Refactoring
Making a program simpler after
adding a new feature.
Simple design
Creating uncomplicated software
and software components that
work to solve the current problem
rather than creating complicated
software designed for a future that
may not come.
intermediate diagrams, such as structure charts, tend to be ignored in favor of
capturing design specifications directly in the code itself. You just read that in
eXtreme Programming, users generate stories that serve as the basis for system
functions and features. These user requirements are not consolidated into a
single, detailed, and complete design specification, as would be expected in an
engineering-based development effort. Instead, requirements serve as the basis
for a design that is captured in code and then tested (Figure B-2). As the founder
of eXtreme Programming says, “Code is the one artifact that development
absolutely cannot live without. . . . It turns out that code can be used to
communicate—expressing tactical intent, describing algorithms, pointing to
spots for possible future expansion and contraction” (Beck, 2000, pp. 44–45).
After testing, all of the code that works may be integrated at the end of each
working day, and working versions of the system will be released frequently, as
often as once per week in some cases. eXtreme Programming developers design
and build working systems in short amounts of time (relative to traditionally
organized methods), and they do it without written or diagrammatic design
specifications. eXtreme Programming employs two particular techniques that
are used to continually improve the quality of the design as developers continue
to iterate through the analysis-design-code-test cycle. These techniques are
simple design and refactoring.
Simple design is exactly what it sounds like: keeping the design simple. For
many developers and programmers, it is too easy to look ahead and try to
anticipate changes in how the system will work and to design accordingly for
these changes. Many times, those anticipated future conditions never material-
ize, and the time and effort that went into designing for the uncertain future is
wasted. According to Beck (2000), design should focus on solving the immedi-
ate problem, not on solving future problems that may or may not occur. eXtreme
Programming has four constraints that pertain to what Beck means by the
simplest design:
쐍 The system must communicate everything you want it to
communicate.
쐍 The system must contain no duplicate code.
쐍 The system should have the fewest possible classes.
쐍 The system should have the fewest possible methods.
Classes and methods refer to object-oriented programming and design (see
Appendix A), and in the nonobject world, these last two constraints could
correspond to tables in a relational database and in lines of code that model
processes in a system, respectively.
Refactoring is related to the overall goal of simple design in eXtreme
Programming. Refactoring is nothing more than simplifying a system, typically
after a new feature or set of features have been added. As more features are
added to a system, it becomes more complex, and this complexity will be
reflected in the code. After a time of increasing complexity, eXtreme Program-
ming developers stop and redesign the system. The system must still pass the
test cases written for it after it has been simplified, so rework continues until
the tests can be passed. Different forms of refactoring include simplifying
complex statements, abstracting solutions from reusable code, and removing
duplicate code. Refactoring and the continuing simplification it implies
reflects the iterative nature of eXtreme Programming and the other Agile
Methodologies. As development progresses and the system gets closer to being
ready for production, the iterations and the evolution of the system slow, a
process Beck calls productionizing. A system ready to go into production is
ready to be released to users, either customers ready to buy the software or
internal users.
Appendix B Agile Methodologies 391
Implementation
Although coding and testing are in many ways part of the same process, it is not
uncommon in large and complicated systems development environments to find
the two practices separated from each other. You have seen examples of this
case in Chapter 10. Big companies and big projects often have dedicated testing
staff who develop test plans and then use the plans to test software after it has
been written. You have already seen how many different types of testing there
are, and you can deduce from that how elaborate and extensive testing can be.
With eXtreme Programming and other Agile Methodologies, coding and testing
are intimately related parts of the same process, and the programmers who write
the code also write the tests. The general idea is that code is tested soon after it
is written. If the code passes the tests, then it is integrated into the system. If it
does not pass, the code is reworked until it does pass.
What We’ve Learned about Agile Methodologies
Agile methods have been in use since “The Agile Manifesto” was issued in 2001,
and some were in use even before that. We saw one example, at Boeing, where
Agile methods were successful. In the years that Agile methods have been used,
what have we learned about their use in organizations? What can managers do
to try to ensure that Agile methods really do work? Several studies have inves-
tigated Agile methods in practice.
One study, a survey of over 100 Agile projects, found three primary critical
success factors for Agile development. The first is delivery strategy, which
refers to the continuous delivery of working software in short time scales. The
second is following Agile software engineering practices. That means managers
and programmers must continually focus on technical excellence and simple
design. The third critical success factor is team capability, which refers to the
Agile principle of building projects around motivated individuals.
Another study found that, once implemented, Agile methods can lead to
improved job satisfaction and productivity on the part of programmers. They can
also lead to increased customer satisfaction, even though the role of on-site cus-
tomer representative can be tiring and so not sustainable for very long. Agile
methods tend to work best in small projects. In some instances, it may make
sense to combine them with traditional development methods.
The best programmers for Agile methods have faith in their own abilities and
good interpersonal skills and trust. To succeed, Agile teams need to balance a
high level of individual autonomy with a high level of team responsibility and
corporate responsibility. However, high levels of team autonomy are a two-
edged sword. On the one hand, highly autonomous teams tend to be more effi-
cient. They are able to take actions that reduce the time, cost, and resources
needed to develop a system. In fact, Agile projects undertaken by efficient
teams tended to come in on time, on budget, and with the needed software func-
tionality. On the other hand, highly autonomous teams also have more ability to
say no to new user demands. Users may not be entirely happy with the result-
ing system if too many of their demands are declined.
A detailed study of one Agile development effort showed that some of the key
principles of Agile development had to be modified to help ensure success. For
example, in the Agile project studied, pair programming was not always used,
especially when resources were needed elsewhere. Second, the process of writ-
ing the test case first and then the code was followed until the system became
too complex. Third, the customer was not located in the same place as the pro-
grammers. Instead, the customer stayed in contact through regular meetings and
continual e-mail and phone communication. Even with these modifications, the
resulting system was considered a success—fewer than ten updates were issued
392 Appendix B Agile Methodologies
because of errors and none were issued because of implementing the wrong
functionalities. Working together, the users and developers were able to clarify
system requirements and create a user interface that was easy to learn and use.
In conclusion, Agile development offers managers and programmers more
choice in their efforts to produce good systems that come in on time and at or
under budget. Agile methods are here to stay, and over time, we will come to
understand them better, as well as how best to use them for the benefit of
developers and users.
Key Points Review
1. Define Agile Methodologies.
The Agile Methodologies, a collection of related
methodologies for systems development, rely on
object-orientation and the need for speed. This
approach sacrifices the milestones and multiple
phases of the engineering approach currently com-
mon in systems development, favoring instead
close cooperation between developers and clients,
combining many life cycle phases into few phases,
and having multiple rapid releases of software.
Although many individual methods reflect the new
approach, collectively they are called the Agile
Methodologies. These individual methods have in
common a focus on adaptive methodologies,
people instead of roles, and an overall self-adaptive
development process.
2. Explain when to use Agile Methodologies and
when to use engineering-based approaches to
systems development.
First, Agile methods fit much better with
smaller projects than with larger ones. Tradi-
tional methods are preferred for large projects
and for those dealing with safety-critical systems.
Second, Agile methods work well when the target
system is to operate in a volatile and fluid envi-
ronment, where business conditions are turbu-
lent and frequently changing. Because of the large
amount of planning that is part of them, tradi-
tional approaches work best where the system
being developed operates in a stable environ-
ment. Third, because Agile Methodologies stress
the importance of individuals rather than roles,
an Agile approach may not work as well unless a
critical mass of people is trained to use Agile
methods. Finally, Agile methods will work best in
an organization culture that thrives on uncer-
tainty, rapid change, and chaos. Traditional meth-
ods work where organizational roles are clearly
defined and change little.
3. Define eXtreme Programming.
eXtreme Programming was developed by Kent
Beck in the late 1990s. eXtreme Programming is
distinguished by its short development cycles, its
incremental planning approach, its focus on auto-
mated tests written by programmers and customers
to monitor the process of development, and its
reliance on an evolutionary approach to develop-
ment that lasts throughout the lifetime of the system.
One of the key emphases of eXtreme Programming is
its use of two-person programming teams. A second
emphasis is having a customer on-site during the
development process. The techniques used for re-
quirements determination in eXtreme Programming
are captured in the Planning Game, a stylized ap-
proach to development that seeks to maximize
fruitful interaction between those who need a new
system and those who build it. Other important as-
pects of eXtreme Programming are simple design
and refactoring.
4. Discuss the Agile Methodologies approach to
systems requirements determination, design
specifications, and the combination of coding
and testing.
Three methods for requirements determination
from an Agile Methodologies perspective were
presented in this appendix: (1) continual user
involvement in the development process, a tech-
nique that works especially well with small and
dedicated development teams; (2) Agile Usage-
Centered Design, a JAD-like approach; and
(3) the Planning Game, developed as part of
eXtreme Programming. Agile Methodologies pro-
mote rapid iterative movement between design
and coding, so design specifications are captured
as part of the design process itself. Specifications
evolve with each iteration, through the cycle of
analysis-design-code-test, leaving little room in
the process for documenting the design with
paper or diagrams or in any way other than the
code itself. For Agile Methodologies, coding and
testing are intimately related parts of the same
process, and the programmers who write the
code also write the tests. The general idea is that
code is tested soon after it is written.