Agile processes in software engineering and extreme programming : 11th International Conference, XP 2010, Trondheim, Norway, June 1-4, 2010. Proceedings

15 Pages·2010·0.037 MB·English

by  Alberto Sillitti, et al

Speaker's Notes 12/02/02
Agile Methodologies and Extreme
Programming in Context
An Organizationally Targeted Presentation on
Agile/Extreme Methodologies
12/02/02 Agile/Extreme in Context 1
Agile/Extreme in Context 1
Speaker's Notes 12/02/02
Our organization - Strengths and
weaknesses
• Strengths
– Autonomous business units
– Software development (IS) groups collocated with business units
• High degree of autonomy on managing activities
– Head IS functions provide
• Infrastructure planning
• IT architectures
• Service delivery
• Weaknesses
– System enhancements take longer than is desired by clients
– Upgrade implementation take longer than is desired by clients
– Inconsistent spawning of e-commerce web-sites by site marketing
departments
– (perceived) different process models adopted by individual IS units
12/02/02 Agile/Extreme in Context 2
Set the scene by considering where our organization is currently.
Doesn’t need too much detail, attendees should be aware of this.
Putting into the SWAT structure simply provides a useful categorization.
There are a few ambiguities in the information that has been provided, but if
noticed, questions from the audience are likely to clarify the situation.
Agile/Extreme in Context 2
Speaker's Notes 12/02/02
Our organization - Opportunities and threats
• Opportunities
– Replacement of legacy systems with an ERP system
– Consistent coordination of web site development through Business
unit’s IS function
– Integration of web front-ends with Transaction Processing systems
(TPS)
• Threats
– Availability and currency of TPS interface information available to
e-commerce development groups may impede their ability to
respond to market opportunities
– Imposition of organizational processes may diminish autonomy of
Business area IS development groups and impose far-reaching
cultural changes
12/02/02 Agile/Extreme in Context 3
Main threat is probably going to be the responsiveness of the HO IS to the TPS
interface, infrastructure and architecture information needs of the distributed
autonomous group so that they can react fast enough to the e-commerce needs
of their business groups.
The perceived weakness of the ‘different processes’ indicates a potential move
to organization process definitions (possibly as the result of pressure by HO
IS) which may not sit well with the autonomous, ‘fit the process to the team’
philosophy of Agile methodologies. Carefully hint at this contentious area
now, in preparation for later discussion.
Agile/Extreme in Context 3
Speaker's Notes 12/02/02
A Spectrum of Process Methodologies
• Rigorously defined ‘one size fits all’ process-based
methodologies
– Software CMM, ISO 12207, ISO 15504, ISO 9001, or other SE
standards
– Large team processes and high artifact count that ‘confirms’ process
execution
• Tailored sets of loosely defined processes
– Requires tacit understanding of project parameters and process
parameters and outcomes to effectively and successfully scale down
a defined process set
– Results in a subset of processes and artifacts having clearly
articulated work-flows that negate effects of consequent ‘process
gaps’
• Anarchy and/or chaos
– Little/no explicit process; developers concentrate on coding
12/02/02 Agile/Extreme in Context 4
•The ‘defined’ processes and model frameworks have been well-described in many forums over
the last ten years or so; and have been proposed as the solution to the ‘software engineering
crises’.
•As McBreen suggests, we have a systemic problem with smaller applications (ie not DOD,
NASA, Ericsson, PeopleSoft size applications) we have been trying to control and manage these in
that same way that we do the massive projects, with some level of ‘tailoring’
•scaling down is difficult, generally experts with the necessary competencies are not used
to determine an appropriate process, its often a hack and slash approach that becomes more
frenetic as project time slips away.
•Of course, even at the anarchic end of the spectrum there is still process, it is simply
unrecognized, implicit and individual - the heroic process
Winchester’s Yangtse management description is useful here:
• Taoists supported the building of only very low levees beside rivers and letting the rivers devise
their own way to the sea. Thus, as parameters changed the river still ended up at the sea without
too much effort
•Confucianists believed that massive dykes should be built to corral the waterways along man-
made courses of man’s choice. Thus as parameters changed (frequently, due to natural events)
unexpected and undesired effects occurred, requiring massive amounts of rebuilding.
•“Rigorous processes are designed to standardize people to the organization; agile processes are
designed to capitalize on each individual and each team’s unique strengths.” (Cockburn and
Highsmith)
Agile/Extreme in Context 4
Speaker's Notes 12/02/02
Agile Software Development
Manifesto:Purpose
“We are uncovering better ways of software by doing it
and helping others do it. Through this work we have
come to value
• individuals and interactions over processes and tools
• working software over comprehensive documentation
• customer collaboration over contract negotiation
• responding to change over following the plan
That is, while there is value in the items on the right, we
value the items on the left more.”
Agile methodologies are people-centred rather than
following a Taylorist Scientific Management approach.
12/02/02 Agile/Extreme in Context 5
•The agile group are practitioners who ‘mine’ best practices, reformulate them as
abstractions and then disseminate them - they do not sit in offices and simply pontificate!
Although many of them work as managers of projects it is in the context of project
leadership rather than by command and control.
•Corollary to the manifesto - we have to find ways to adapt the way we ‘value’ the things
on the right to achieve the higher value on the left. This does not necessarily imply simply
discarding them.
•Relying on interactions between individuals facilitates sharing of information and
rapid changes to process when needed
•Working software allows us to determine the project velocity and gives feedback
•Increased interactions means that tacit knowledge can be shared, thus minimises
reliance on ‘high maintenance’ documentation
•Customer collaboration puts us on all the same team but we have to make sure that
we have users with domain-experience not simply whoever hasn’t got too much
work to do (the latter has often been the case with customer representatives
•Cast iron contracts often result in delivering the ‘wrong’ product
•Important to note that the Agile approach is a generative approach - i.e. processes emerge
that are useful in the context of the specific project, rather than the more usual inclusive
approaches that try to account for every possible project eventuality.
•This context sensitivity of process means that any centralized control/management
is only going to be at the macro level of detail (what is required) rather than micro
Agile/Extreme lienv Celo (nhtoewxt we achieve what is required). 5
Speaker's Notes 12/02/02
Agile Software Development Manifesto:
Principles
• Customer satisfaction through early and continuous
delivery of software using short (in weeks) iteration cycles
• Accept and accommodate changing requirements at any
time during development
• Developers work daily with business people
• Build the project around team strength’s and provide them
supportive environment
• Minimize documentation and maximize face to face
exchange of information
• Maximize the amount of work not done
• Encourage reflective practitioners and continuous learning
12/02/02 Agile/Extreme in Context 6
•The ‘plan’ is updated for each iteration with information about working software from the
previous iteration and what is to be implemented in the next iteration
•Working software is a measure of progress
•Reduce the elapsed time between making a decision and seeing its consequences
•Accommodating change accepts that the customer’s organization is probably emergent rather
than stable and supports the customer’s need to meet changing organizational goals (possibly
unknown or unidentified earlier in the project)
•useful parameter for determining if Agile is appropriate for a project
•The team environment is the most difficult from a project management perspective;
developers are not interchangeable units; developers are more skilled than their managers in
their ability to produce software which is what the customer wants; managers provide
interfaces, facilitation and coaching rather than command and control; team’s internal
organization may change over time to reflect the current needs of the project (anecdote -
architect to integration champion transition)
•Self-organizing teams; Processes support sustainable development
•Strive for good design and technical excellence
•Developer’s decide what is needed for good design and technical excellence; if there is
an organizational requirement for specific processes/documents then either these need
to be accommodated as required project outcomes, or the feasibility of an agile
approach should be questioned?
Agile/Extreme in Context 6
Speaker's Notes 12/02/02
Consequent Agile Practices
• Feature planning and dynamic prioritization
– features lists
– priorities determined by customer
• Feedback and change
– Working software elicits feedback and change requests
– Clean, maintainable design ensures that such changes can be
accommodated
• Focus on people and teamwork
– Individual competence
– Team competence
– Collaborative work
“Agile teams are characterized by self-organization and intense
collaboration, within and across organizational boundaries.”
(Cockburn and Highsmith, 2001)
12/02/02 Agile/Extreme in Context 7
•Each of the methodologies determines when features can be added and
reprioritized e.g. at the end of iteration N; only interested in current iteration
•plans features not tasks because this is what the customer understands
•Points 1 and 2 both require really close collaboration with a useful customer,
preferable on-site to be part of the team
•Clean design is something that needs to be explained, seen and mentored. Could
be the focus of a presentation or workshop on ‘what is simple design’ not within
scope of this presentation.
•Team independence and team-context-sensitive process is so fundamental that if
the organization culture cannot accept it, any attempt to move to Agile methods is
almost certainly doomed to failure.
•A good pre-indicator of this could be how much flexibility current project
manager’s have in terms of their planning process and plan structure and
detail??
Agile/Extreme in Context 7
Speaker's Notes 12/02/02
Some Agile Methodologies
SCRUM
– Initial architectural phase, backlog, 4 week Sprints, daily scrum meetings,
end of Sprint customer demonstration
• ASD (Adaptive Software Development)
– Mission-driven, component-driven (results), time-limited, timeboxed; risk
driven; change tolerant
• Crystal Clear
– Strong communications; frequent deliveries; reduce overhead; management
by milestones and risk lists
• DSDM (Dynamic Systems Development Model)
– User involvement, stakeholder collaboration; empowered team; frequent
delivery; backtracking to reverse changes; high-level requirements
baselining; iterative and incremental development; integrated lifecycle
testing;
• XP (eXtreme Programming)
– short cycles, continuing feedback, incremental planning, automated tests
12/02/02 Agile/Extreme in Context 8
Insufficient time to go into any detail on these other than these few points.
Audience should be advised to read further if they have an interest.
•More information on SCRUM in PLoP4 p637 - 651 which describes the
process in a pattern language.
•Definitive source of information on ASD is Jim Highsmith’s Adaptive
Software Development, Dorset House, 2000.
•Best source for information about Crystal Clear is Crystal “Clear”: A Human
Powered Software Development Methodology for Small Teams. At
http://members.aol.com/humansandt/crystal/clear.2001
•More about DSDM at the consortium site
http://www.dsdm.org/about/principles.asp
•More about Extreme in the series of six Extreme books published by
Addison-Wesley.
•Important to note that there are few reported case studies (the Chrysler 3C
informs the Extreme methodology) about the efficacy or otherwise of any of
these approached; information is mainly anecdotal and with some apparent
biases.
(Fertile ground for Iterative Action Research style projects).
Agile/Extreme in Context 8
Speaker's Notes 12/02/02
Extreme Programming (XP)
XP is the best-known of the Agile methodologies
XP is decomposed into several perspectives
• Four Values - ie how software development should ‘feel’ is
based on
– Communication; Simplicity; Feedback, and Courage
• Five Principles - used to determine whether a practice can
be used successfully in an XP context
– Rapid Feedback; Assume Simplicity; Incremental Change; Embrace
Work, and Quality Work
• Four Activities - the cornerstone of software development
– Coding; Testing; Listening, and Designing
• Twelve Practices - used to successfully carry out activities
Additionally, Strategies to execute practices in real projects
12/02/02 Agile/Extreme in Context 9
Values, principles and activities are self-explanatory, and can be mapped back
to the Agile Manifest Value statements and Principles.
Next slide covers the twelve practices. Then some proposed strategies.
Agile/Extreme in Context 9
Speaker's Notes 12/02/02
The 12 Extreme Practices
• The planning game
• Small releases
• Metaphor
• Simple design
• Testing
• Refactoring
• Pair programming
• Collective ownership
• Continuous integration
• 40 hour week
• On-site customer
• Coding standards
12/02/02 Agile/Extreme in Context 10
•Planning - scope, business priorities, composition of releases, technical estimates, release dates
•Small releases - most valuable business requirements, short cycles
•Metaphor - overarching, sometimes akin to an architecture - problematic area, metaphor isn’t the
system; metaphor may provide domain vocabulary
•Simple design - runs all tests, no duplicated logic, states intentions to developers and hasn’t
smallest number of classes and methods to achieve goals - area subject to abuse
•Testing - write tests for production methods before methods themselves, use automated testing
framework (eg JUnit), all tests must run - strength, identifying tests encourages better designs
•Refactoring - small low risk steps to clean-up code that has become ugly through iterations, a
direct outcome of code evolution
•Pair programming - dynamic, strategic and operational pair members (thinker and mouser);
whole is better than sum of parts; culturally problematic unless evolved naturally like
brainstorming; skills transfer and mentoring; distribution of tactic knowledge
•Collective ownership - if there’s a problem anyone can fix it (highly dependent on continuous
integration); adding value to code;
•Continuous integration - daily at least; avoids merge clashes, identifies progress, set up and run
integration and regression testing avoid ‘big-bang’ testing problems; easy to identify where
problems are (ie most recent check-ins)
•40 hour week - all about sustainable development and ‘get a life’, productivity and and
identifying schedule problems within an iteration
•On-site customer - set internal priorities; resolve disputes; answer questions; team bonding
•Coding standards - essential for dynamic pair programming and effective refactoring
Agile/Extreme in Context 10