IT Spiral 先端ソフトウェア工学シリーズ
Agile Programming
Hajimu Iida
Software Design Laboratory,
Nara Institute of Science and Technology
Mike Barker
Nara Institute of Science and Technology
IT Specialist Program Initiative for Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/
2
What is agile programming?
 13 principles
 XP Prinicples:
Examples
 XP (extreme programming): Beck
 Scrum
 Agile Unified Process: Larman
 EVO
 Crystal: Cockburn
 Adaptive Software Development
(ASD)
Feature Driven Development
(FDD)
Dynamic Systems Development
Method (DSDM)
Rapid feedback
 Simplicty
 Incremental changes
 Embrace change
 Quality work
 XP Practices
 Pair programming
 refactoring, unit and
acceptance tests, collective
code ownership, continous
integration
2007/4/1

IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
3
The Agile Manifesto (www.agilealliance.com)
We value
Individuals
and interactions over processes and
tools
Working software over comprehensive
documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
4
The Agile Principles
1.
2.
3.
4.
5.
6.
7.
2007/4/1
Our highest priority is to satisfy the
customer through early and
continuous delivery of valuable
software.
Welcome changing requirements,
even late in development
Deliver working software frequently
Businesspeople and developers must
work together daily throughout the
project
Build projects around motivated
individuals. Given the environment
and support they need, and trust
them to get the job done.
The most efficient and effective
method of conveying information to
and within a development team is
face-to-face conversation
Working software is the primary
measure of progress
8. Agile processes promote sustainable
9.
10.
11.
12.
13.
development
The sponsors, developers, and users
should be able to maintain a
constant pace indefinitely (Not in all
lists)
Continuous attention to technical
excellence and good design enhances
agility
Simplicity – the art of maximizing
the amount of work not done – is
essential
The best architectures, requirements,
and designs emerge from self
organizing teams
At regular intervals, the team reflects
on how to become more effective,
then tunes and adjust its behavior
accordingly.
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
5
Agile Assumptions
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Visibility: project visibility can be achieved solely through delivery of working code.
Iteration: a project can always be structured to be short fixed-time iterations
Customer-interaction: customer teams are available for frequent interaction when needed by developers.
Team-communication: developers are co-located so they can have frequent, intensive communication
Face-To-Face: face-to-face interaction is the most productive method of communication with customers
and among developers
Documentation: developing extensive and consistent documentation and software models is
counterproductive.
Changing requirements: requirements always involved because of changes in technology, customer needs,
and business domains, or acquisition of new customers
Cost-of-change: the cost of change does not dramatically increase over time
Team-experience: developers have the experience needed to define and adapt their processes
appropriately.
Self-evaluation: teams are able and willing to evaluate themselves
Self-organization: the best architectures, requirements, and designs emerge from self-organizing teams
Quality-assurance: the evaluation of software artifacts (products and processes) can be restricted to
frequent informal interviews, reviews, and code testing.
Continuous-redesign: systems can be continuously redesigned (re-factored) and still maintain their
structural and conceptual integrity
Application-specific-development: reusability and generality should not be goals of application-specific
software development
Turk, France, and Rumpe (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
6
Agile Limitations
Personnel limitations
Limited
support for distributed development environments
Limited support for subcontracting
Limited support for development involving large teams
Product limitations
limited support for building reusable artifacts
Limited support for developing safety critical software
Limited support for developing large, complex software
Turk, France, and Rumpe (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
7
How does it differ from disciplined development?
 Disciplined development: Waterfall and spiral
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
heavyweight and lightweight software development
methodologies
8
based on factors such as
1.
Planning and documentation
2. Well-defined phases in the development process
3.
Composition of the development team
4. Use of well elaborated modeling and coding techniques
to generate software development artifacts
 Agile methodologies often characterized as
 Incremental
 Cooperative
 Straightforward
 Adaptive
Meso and Jain (2006)

2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
9
When should you use agile development?
 Barry Boehm’s five dimensions
Complex Adaptive Systems
Agile Distributed Development
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
1
0
Complex adaptive systems (CAS)
Principle of open systems
Principle of interactions and relationships
Principle of transformative feedback loops
Principle of emergent behavior
Principle of distributed control
Principle of shallow structure
Principle of growth and evolution us
Meso and Jain (2006)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
11
Mapping Agile and CAS
Agile practice
CAS principle
Frequent releases
Frequent feedback
Growth and evolution
Transformative feedback loops
Positive value of change
Loose environment
Minimal planning
Emergent order
Distributed control
Growth and evolution
Emergent order
Continuous learning and
improvement
Growth and evolution
Interactions and relationships
Working software product
Path of least effort
Meso and Jain (2006)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
12
Challenges of Agile Distributed Development
Ramash, Cao, Mohan, and Xu (2006)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
13
Practices to achieve distribution and agility
1.
2.
3.
4.
5.
Continuously adjust the process

Planning iterations to finalize requirements and develop designs

Documenting requirements at different levels of formality
Facilitate knowledge sharing

Maintain product/process repository

Focus on well-understood functionality rather than critical new functionality

Short cycle but not time-boxed development
Improve communication

Synchronized work hours

Informal communication but through formal channels

Balanced coordination

Constant communication
Build trust

Frequent visits by distributed partners

Sponsor visits

Build cohesive team culture
Trust but verify

Distributed QA

Supplement informal communication with documentation
Ramash, Cao, Mohan, and Xu (2006)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
14
Why should you use agile development?
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
15
Test Driven Development Drives Software Quality
 Write unit tests BEFORE you write code
 Not just unit tests, also functional, system, end-to-
end, performance, security, and usability tests
 TDD code practices mean more tests passed and
fewer defects
Why does it help?
Tests provide a common language for users and
developers
Tests define a feature or story’s scope
Test-first helps good design
Crispin (2006)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
16
Agile Methodology Adoption Decisions
Critical adoption factors
Project
Duration of the project
 Acceptance of change
 Criticality of project

Team


Team size
Skill level of team
Customer


Location of customer
Customer involvement
Organization




Organizational and reporting structure
Process
Documentation requirements
Layout of the workspace
McAvoy and Sammon (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
17
Practice and projects
 See McAvoy and Sammon (2005). They used a list
of critical adoption factors, then had the students
assign weights and rankings for two case studies.
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
Ａｄｏｐｔｉｏｎ Ａｓｓｅｓｓｍｅｎｔ Ｍａｔｒｉｘ
Ｗｅｉｇｈｔ
Ｒａｎｋ
18
Ｒｅｓｕｌｔ
Duration of the project
Acceptance of change
Criticality of project
Team size
Skill level of team
Location of customer
Customer involvement
Organizational and reporting structure
Process
Documentation requirements
Layout of workplace
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
19
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
A Class Project: Putting the Agile principles and
practices in context
2
0
Consider the Agile Manifesto, principles and practices.
What are the Disciplined principles and practices?
How do you personally weight these items?
How do you think companies weight them?
Consider three groups: developers, companies, and
users. Why would these principles or practices be
important to them? What do they want?
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
21
Why do projects fail?
Requirements are not clearly communicated
Requirements do not solve the business problem
Requirements change prior to the completion of the project
Software (code) has not been tested
Software has not been tested as the user will use it
Software developed so that it is difficult to modify
Software used for functions for which it was not intended
Projects not staffed with resources required
Schedule and scope commitments made before
understanding requirements or technical risks
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
2
2
Extreme Programming (XP)
Instead of “what are all of the practices I might ever
need on a software project?” ask “what is the simplest
set of practices I could possibly need and what do I
need to do to limit my needs to those practices?”
XP Values:
Communication
Simplicity
Feedback
Courage
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
Extreme Programming (XP) Practices
2
3
Practices:
Whole
Team: every contributor to the project is a member, including
the customer
 Planning Game: simple planning and tracking
Small releases: small, fully integrated releases that pass all
Acceptance Tests: defined by the customer
Pair programming
Simple design
Test-driven development
Design improvement
Continuous integration
Team code ownership
Coding standard: consistent style
Metaphor: common and simple picture of what the system looks like
Sustainable pace
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
Extreme Programming (XP) Practices
2
4
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
2
5
Whole Team
All contributors sit together as members of one team
Must include a business representative, the customer, who provides
requirements, sets priorities, and steers the project.
Must include programmers.
May include testers, who help the customer define the customer
acceptance tests
May include analysts, who help the customer define the requirements
Often includes a coach who helps the team stay on track and facilitates
the process
May include a manager, who provides resources, handles external
communication, and coordinates activities
Roles are not necessarily the exclusive property of just one individual.
Everyone on an XP team contributes in any way that they can.
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
2
6
Planning Game
Two key questions: predict what will be accomplished by the
due date, and determine what to do next.
Focus on steering the project instead of trying to predict what
will be needed and how long it will take.
Release planning: customer presents desired features,
programmers estimate their difficulty, customer lays out plan
for project.
Iteration planning: two week iterations, with running useful
software. Customer presents features desired for two weeks,
programmers estimate tasks and commit to what will be
undertaken for current iteration.
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
2
7
Customer Tests
 as part of presenting each desired feature, the
customer defines one or more automated acceptance
tests
Team builds the tests first, then uses them to prove
that the feature is implemented correctly
 Use automated testing and always run the full set of
regression tests
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
2
8
Small Releases
 the team releases running, tested software,
delivering business die you chosen by the customer,
with every iteration.
 always release software to the end-users frequently.
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
2
9
Simple Design
 bill into a simple design.Start simple, and stay simple.
Design fits current functionality
Design is neither one time nor upfront, but all-the-
time.
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
3
0
Pair Programming
 two programmers sit side-by-side at the same
machine to build production software
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
31
Test Driven Development
Add a test, then make the function work
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
3
2
Design Improvement
Deliver business value in every iteration
continuous design improvement through re-factoring
Remove
duplication
Increase cohesion and lower coupling
 comprehensive testing
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
3
3
Continuous Integration
 build many times and test every time
Infrequent integration means
lack of practice with integration
 more bugs
Long code freezes

Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
3
4
Collective Code Ownership
 any pair of programmers can improve any code any
time
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
3
5
Coding Standard
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
3
6
Metaphor
Simple description of how the program works
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
3
7
Sustainable Pace
 work hard but sensibly
Maximize productivity week in and week out
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
3
8
Other practices sometimes used
 open workspace
 Retrospectives: feedback on how performing
 self-directed teams: the team makes the decisions
 customer teams: instead of one Customer, a team
that handles multiple stakeholders, resource
allocation, and feedback
Lindstrom and Jeffries (2004)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
3
9
Making Agile Methodologies Work
Management and organizational issues
Conflict with organizational culture
 Management style: shift from command-and-control to
leadership-and-collaboration. Project manager role
changes from planner/controller to facilitator
 Organizational forms: blend autonomy and cooperation to
provide flexibility, responsiveness, and synergy
 Move from managing software development knowledge
through documentation to tacit knowledge in teams
 Teams more important than individual roles, requiring
changes in performance measurements and reward systems

Nerur, Mahapatra, and Mangalaraj (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
4
0
Making Agile Methodologies Work
People issues
Agile methodologies require cooperative social process,
communication, collaboration, community of members
who value and trust each other (a team). Programmers
used to working alone find shared learning, reflection
workshops, pair programming, and collaborative decision
making hard.
 Requires high level of competence.
 Requires customers to be collaborative, representative,
authorized, committed, and knowledgeable – can the
company find such customers?

Nerur, Mahapatra, and Mangalaraj (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
41
Making Agile Methodologies Work
Process issues
changing focus from process to people and
features difficult
 Changing to short, iterative, test-driven
development emphasizing adaptability
 can agile methods be used with large, scalable
projects?
 selecting an appropriate agile method

Nerur, Mahapatra, and Mangalaraj (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
4
2
Making Agile Methodologies Work
Technology issues (tools and techniques)
Appropriateness of existing technology and tools
 new skill sets – refactoring, configuration
management, JUnits

Nerur, Mahapatra, and Mangalaraj (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
4
3
What research shows?
 A few case studies and experience reports
 pair programming studies
“hard, empirically-based economic evidence is
lacking” (p. 95)
Erickson, Lyytinen, and Siau (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
4
4
Traditional patterns or processes
 Systems development life cycle (SDLC)
 Spiral method
 Waterfall approach
 Rapid Application Development
 Unified Process
 Object-oriented
 Prototyping
CMM and CMMI
 Almost all have analysis, design, coding, test steps
Erickson, Lyytinen, and Siau (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
4
5
XP Principles and Activities
 Four values
 Four Activities
Communications
Coding
Simplicity
Testing
Feedback
Listening
Courage
Debugging
Erickson, J., Lyytinen, K., & Siau, K. (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
4
6
Agile Modeling
 simplicity
Iterative development
Robustness
Incremental releases
Staying on task
Producing a quality product
Creating models and accompanying documentation only as
necessary
Multiple models
Fast and clear feedback on changes to the model
Discard models and documentation to go back more than a
few iterations
Erickson, J., Lyytinen, K., & Siau, K. (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
4
7
What is wrong with this picture?
 60% of a typical system’s O&M budget goes to
band-aid solutions to inadequate analysis and
development
2/3 to ¾ of information systems developed are
failures because they do not provide required
functionality
 programmers are taught to build throwaway
systems which are often obsolete before the project is
complete
The users of systems are systematically excluded from
development (p. 97)
Erickson, J., Lyytinen, K., & Siau, K. (2005)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
4
8
Is this a paradigm change?
 Kuhn: paradigm is “coherent tradition of scientific
research” including knowledge, techniques, research
agendas, etc.
 Consider paradigm as “coherent tradition of
software development”
 History
Software starts in 1950s
1960s: software engineering and waterfall
metaphor
Rajlich (2006)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
4
9
Is this a paradigm change?
 Software evolution based on
Empirical
studies of actual software life cycles
 Development
 Evolution or
growth
 Servicing and code decay
 Phase-out
 Close-down

Iterative program development
Rajlich (2006)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm
5
0
New Research Agenda
 Incremental change
How
can we summarize, model, formalize, improve, teach,
and support the practice of incremental change?
 Concept location: where do changes in existing software
have to be made?
 Impact analysis: what components will be affected by an
incremental change? What change propagation needs to
happen to make the change?
 Refactoring
 Code decay
Cognitive aspects of software development and program
comprhension
Rajlich (2006)
2007/4/1
IT Specialist Program Initiative for
Reality-based Advanced Learning
http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm