Upload
others
View
12
Download
0
Embed Size (px)
Citation preview
Agile Software Development
T-110.6130 Systems Engineering in Data Communications Software P
29.9.2011
Kristian Rautiainen, Aalto University
Agenda
• Agile Software Development Basics
• eXtreme Programming (XP)
• Scrum
• 10 Ways to Fail when Going Agile
29.9.2011 2
Kristian Rautiainen
Agile Software Development Basics
29.9.2011 3
Kristian Rautiainen
Agile software development
• Structured and disciplined, fast-paced Iterative and Incremental Development (IID)
– NOT “build-and-fix” or “hack away”
• Packages existing good software engineering practices
– Nothing new, except the underlying philosophy and the combination of practices
• Embraces change rather than controls it
– Suitable for extremely turbulent environments
• Focuses on delivering business value in frequent increments
– Customer/User involvement paramount
• Can’t be used in all projects!
– E.g. small teams recommended
• More information:
– http://www.agilealliance.org/
29.9.2011 4
Kristian Rautiainen
Agile Manifesto
• Signed by authors of ASD, XP, Scrum, Crystal, FDD, DSDM, and ”pragmatic programming” + some others in Feb 2001
• Agree at the first level – need to respond to change
• Agree at the second level (Agile Manifesto) – individuals and interactions over processes and tools – working software over comprehensive documentation – customer collaboration over contract negotiation – responding to change over following a plan
• Agree at the third level – 12 more detailed statements (Principles)
• Don’t agree at the fourth level – detailed project tactics
29.9.2011 5
Kristian Rautiainen
6
Principles of the Agile Alliance
• Satisfy the customer through early and continuous delivery of valuable software
• Agile processes harness change for the customer’s competitive advantage
• Deliver working software frequently
• Working software is the primary measure of progress
• Agile processes promote sustainable development at a constant pace
• Business people and developers must work together daily
• Build projects around motivated individuals, give them support and trust them to get the job done
• The most efficient and effective way of
conveying information is face-to-face
conversation
• 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 tunes and
adjusts its behavior to become more
effective
29.9.2011 Kristian Rautiainen
Agile process models
• Provide the “project tactics” – A set of specific values, principles, and practices
• Many models have been proposed
– eXtreme Programming (XP) – Adaptive Software Development (ASD) – Rapid Application Development (RAD) – Dynamic Solution Delivery Model (DSDM) – Scrum – Crystal – Feature-Driven Development (FDD) – Lean Development (LD) – ...
• Most agile process models employ time pacing
29.9.2011 7
Kristian Rautiainen
The concept of time pacing
• Time pacing refers to – Creating a rhythm for product development by timeboxing
development work
• The schedule is fixed
• The scope is flexible (prioritization needed)
• Time pacing can be done on several time horizons – Time horizon = planning time horizon, i.e. the length of the timebox
– Long-term goals are split into short-term sub goals
– This provides
• visible progress on shorter time horizons by reaching the sub goals
• flexibility to reflect on and change plans and goals in the control points based on visible and concrete progress
29.9.2011 8
Kristian Rautiainen
Agile philosophy and time horizons
29.9.2011 9
Product Backlog
Release Backlog
Iteration
Backlog
Release Backlog
planned scope for release allocated into
Iteration
Backlog
Iteration
Backlog
parts chosen and allocated into
consists of tasks that are needed to
implement the allocated backlog items
Every idea, feature, bug, etc.
considered for the product is kept in
Go
vern
ance
Pro
gre
ss s
tatu
s
Progress status of the tasks of an Iteration checked in Daily Heartbeat meetings
Progress of a Release checked in Iteration Demo
Roles: 1 Product Owner
1 Team 1 Coach
Kristian Rautiainen
Sweet spots of agile software
development • 3-8 people in one room
– Information moves the fastest face-to-face
• Onsite expert user – Minimized time for feedback of the solution
– Possibility to ask questions immediately fastest response time
• One-month (max) iterations – Feedback of the product and the process
– Today’s “industry standard” is 2-week iterations
• Supporting infrastructure/technology in place – Continuous Integration environment with automatic build process
– Fully automated regression tests • Confidence to changing and improving the system
29.9.2011 10
Kristian Rautiainen
Comparing process models
29.9.2011 11
Specification
Design
Implementation
Test
Sequential Iterative &
Incremental (IID)
eXtreme
Programming (XP)
Tim
e
Kristian Rautiainen
eXtreme Programming (XP)
(Based on the original book by Kent
Beck)
29.9.2011 12
Kristian Rautiainen
XP Values (1/2)
• Communication
– Lack of it is the reason for most
problems
– Punishment from bad news kills it
– XP employs practices that keep
programmers, customers and
managers communicating
• Simplicity
– What is the simplest thing that
could possibly work?
– General vs. simple design
• anticipatory design assumes
more work today saves work
later
– YAGNI
• low rate of changes
– anticipatory design
• high rate of changes
– refactoring and
continuous design
– A simple solution is easier to
understand
29.9.2011 13
Kristian Rautiainen
XP Values (2/2)
• Feedback
– Concrete feedback about the state
of the system
– Scale of minutes or days
• unit tests, quality of stories
(requirements), progress of
tasks
– Scale of weeks or months
• acceptance tests, schedule,
system in production
• Courage
– Changing the system
– Throwing code away
– Pair programming
29.9.2011 14
Kristian Rautiainen
XP Principles
• Fundamental principles
– rapid feedback
• critical for learning
– assume simplicity
• treat every problem as if it can be solved with simplicity
– incremental change
• series of smallest changes that make a difference
– embracing change
• best strategy preserves most options while actually solving your most pressing problem
– quality work
• excellent quality
• nobody likes doing a bad job
• Secondary principles
– teach learning
– small initial investment
– play to win
– concrete experiments
– open, honest communication
– work with people’s instincts, not
against them
– accepted responsibility
– local adaptation
– travel light
– honest measurement
29.9.2011 15
Kristian Rautiainen
XP Practices
• Practices
– planning game
– small releases
– test driven development
– continuous integration
– system metaphor
– simple design
– refactoring
– pair programming
– collective code ownership
– coding standard
– whole team (on-site customer)
– sustainable pace
29.9.2011 16
Kristian Rautiainen
XP Process
29.9.2011 17
Kristian Rautiainen
Scrum
29.9.2011 18
Kristian Rautiainen
Scrum Process Overview
29.9.2011 19
Kristian Rautiainen
Scrum roles – Product Owner (PO)
• Represents the interests of everyone with a stake in the project/product
• Creates the project’s ROI objectives and release plans
• Manages and controls the Product Backlog (PBL)
– Ensures that the PBL is visible to everyone
– Sets priorities for the items in the PBL
– For PO to succeed, everyone must respect his/her decisions
– Works with others to estimate items in backlog (for total effort)
– Participates in Sprint Planning Meeting (and Sprint Review)
– Participates in re-scoping or re-prioritizing the sprint
• PBL
– PBL is an evolving, prioritized queue of business and technical functionality that needs to be developed into a system
– PBL emerges from many sources
• Marketing, Sales, R&D, Support, ...
29.9.2011 20
Kristian Rautiainen
Scrum roles – Scrum Master
• Agile coach
– Master of the Scrum process and practices
– Coaches the team members
• Facilitator/impediment remover
– Shields the team from outside interruptions
– Helps remove impediments
29.9.2011 21
Kristian Rautiainen
Scrum roles – Development team
• Responsible for realizing the PO’s vision for the product
– The team makes the technical choices and delivers working
software to demo at the end of Sprints
• Shared responsibility
• Self-organized and empowered
– The team chooses its ways of working
– No appointed team leaders, leaders emerge for different
situations
29.9.2011 22
Kristian Rautiainen
10 Ways to Fail when going Agile
29.9.2011 23
Kristian Rautiainen
Ceremony Without Understanding
• Doing everything as before, but calling it Agile
– New terminology, but same routines
– E.g. Weekly meeting => weekly Scrum...
• ...or Daily Scrum that lasts as long as a weekly meeting
• Fallacy of allowing feature creep during iterations
– ”because we’re supposed to be agile”
29.9.2011 24
Kristian Rautiainen
Underestimating Transition Effort and
Time
• Organisational change or process improvement is
always challenging and takes a lot of time
– ”This agile thing doesn’t work for us. We tried it for a couple of
months, but...”
– Fallacy of not risking some time now in order to win a lot of time
in the future
• Transition to Agile slows down productive work for an unknown
period of time
– Business representatives tend to be impatient...
29.9.2011 25
Kristian Rautiainen
Throwing Away Existing Good Practices
• ”Let’s start from scratch with this Agile thing”
• ”We used to observe users to elicit requirements. Now
we invite them to iteration demos instead”
• ”Something that works for us is not considered Agile. We
have to throw it away.”
29.9.2011 26
Kristian Rautiainen
Cultural Conflicts
• Project manager => Scrum Master
– You often see this role transition in companies
• But the differences in the roles cause trouble and confusion
• (technical) project manager => (technical) product owner is actually
an easier transformation
• Breaking down ”silos”
– Creating truly cross-functional teams is a big challenge...
• ...but without them lots of effort for coordination is needed
29.9.2011 27
Kristian Rautiainen
Challenging Roles
• Product Owner
– Need I say more...?
• Empowered, self-organised team
– ”Say what?”
– A transition from a ”clear roles and responsibilities + a project
manager to tell us what to do” to self-organised is rocket science
and a huge step for most people
• A lot of coaching and support is needed for the role
transitions (also for top-level managers!)
29.9.2011 28
Kristian Rautiainen
Lacking Competence
• Getting rid of the difficult practices because they take
too much time to learn
– ”Test-Driven Development (TDD) was really hard to understand
and learn, so we stopped doing it”
– You need to understand the trade-offs and underlying
assumptions, otherwise you end up in total ad-hocracy
• Working at high velocity requires high discipline and
skills + good-quality software
– Work on building competence to the people, it will always pay off
29.9.2011 29
Kristian Rautiainen
Minimal Plans = Minimal Planning
• Fallacy of planning only in Release or Iteration planning
sessions
– ”I just saw the demo. Now I need time to figure out what you
should do next”
– Planning should be made ”continuously” in a rolling wave
fashion
• Requirements refinement (Agile Product Management)*
• 5% workshops (aka story time) have not been around in most
companies (not for long, anyhow)
29.9.2011 30
*K. Vlaanderen, S. Jansen, and S. Brinkkemper, “The agile
requirements refinery: applying scrum principles to software
product management,” in Proc. 3rd International Workshop
on Software Product Management, 2009.
Kristian Rautiainen
Emerging architecture =
no upfront architectural work • Working in short iterations may compromise the
architecture – ”The best architectures emerge”
• Sure thing, as long as you have the best people
– ”Just enough arcitecture”
• How do you know how much is enough?
– ”We have these 10 teams working on the release of this product”
• ”Architectural runway” is a must
• Architectural work is challenging no matter what you call the development process!
29.9.2011 31
Kristian Rautiainen
Anyone Seen the Onsite Expert User?
• Working with a simple backlog may cause losing sight of
the ”Big Picture”
– Most backlogs only contain vague one-liners, not even proper
user stories
– If the onsite expert is not there to explain things, the end result
might be completely off target
• The positive thing is that we know it pretty fast, but it is still waste
– How much explanations should be written?
29.9.2011 32
Kristian Rautiainen
Agile Only Concerns R&D
• After all, the Product Owner is part of the team and is responsible for all ”that other stuff” – Still, agile (and lean especially) does change the way everybody
should be thinking about developing software
• Agile requirements (= backlogs, stories, ...) mean that Business representatives need to work in new ways too!
• Customers still want detailed plans and contracts! – Business/sales representatives force the teams to produce
detailed plans upfront
– Who trains the customers?
29.9.2011 33
Kristian Rautiainen
Questions or comments?
29.9.2011 34
Kristian Rautiainen