View
4.431
Download
0
Tags:
Embed Size (px)
DESCRIPTION
An overview of the Agile Manifesto and the principles and practices that define Agile software development. A comparison of Agile Development methodologies and an organisational culture that supports them
Citation preview
Agile Software Development
Primer
What is Agile Development?
"The ability to move faster than those things that can harm your project…"
Agile Development is a method
of building software by empowering and
trusting people, acknowledging change as a norm, and promoting
constant feedback
Agile Software Development ... the History
1974 An adaptive software development process documented, 1991 “Rapid Application Development” published1995 DSDM Framework published1995 SCRUM presented at OOPSLA1996 XP Practices developed on C3 project1997 FDD processes designed by Jeff De Luca1999 FDD described in “Java Modeling in Color with UML”1999 “Extreme Programming Explained” published1999 “Adaptive Software Development” published2001 Crystal Light methodologies described in Cutter IT Journal, 2001 Agile Manifesto written2003 “Lean Software Development: An Agile Toolkit for
Software Development Managers” published
Kent Beck – Creator of XP, TDD Mike Beedle – “Agile Software Development with Scrum” c.Ken Schwaber, 2002 Arie van Bennekum – RAD, DSDM Alistair Cockburn – Use Cases, Crystal Methodologies Ward Cunningham – Creator of XP, wiki’s, design patterns Martin Fowler – the UML, Author of “Refactoring” & “Planning XP” c.Beck James Grenning Jim Highsmith – Creator of ASD, “Adaptive Software Development” (1999) Andrew Hunt – Author, Partner “The Pragmatic Programmer” c. D. Thomas Ron Jeffries – Creator of XP, “Extreme Programming Installed” (2000) Jon Kern - Brian Marick – Context Driven Testing Robert C. Martin – Author “Designing Object Oriented C++” (1995) Steve Mellor - Shlaer-Mellor method, Executable UML, MDA Ken Schwaber- Creator of SCRUM, “The Enterprise & SCRUM” 2007 Jeff Sutherland – Creator of SCRUM Dave Thomas – Author, Partner “The Pragmatic Programmer”
Agile Software Development ... the History
The Manifesto for Agile Software Development
That is, while there is value in the items on the right, we value the items on the left more
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
We are uncovering better ways of developing software by doing it and helping others do it. Through this work
we have come to value:
These are MORE Valuable
These are Valuable
• Let good people do what they’re good at• People work together to write software• People use software
Individuals & interactions
• Are important and needed, but don’t be a slave
Processes & tools
• The software is for a customer for a purpose
Customers & collaboration
• Contracts should reflect the purpose and encourage collaboration
• Target costing
Contract Negotiation
• What the software does should be useful
Working software
• Agile does *NOT* say no documentation• LEAN says just enough documentation• Not at the expense of face-to-face
Comprehensive Documentation
• Change happens ... work with it• Short feedback loops
Responding to change
• Plan for changes• Should support timely decision making
Following a plan
Agile Principles
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them 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.
Agile Principles
1. Satisfy the Customer
2. Welcome Change
3. Deliver Frequently
4. Work as a Team
5. Motivate People
6. Communicate Face to Face
Agile PrinciplesWorking software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
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 adjusts its behaviour accordingly.
Agile Principles7. Measure working software
8. Maintain constant pace
9. Excel at quality
10. Keep it simple
11. Evolve designs
12. Reflect regularly
Agile Practices
Agile PracticesDesign & Programming
* Build Automation
* Automated Deployment
Continuous Integration
* Simple Design
Collective Ownership
Feature Teams
* Refactoring
Pair Programming
Testing
* Automated Unit Testing
Acceptance Tests
* Test Driven Development
Small Releases
Planning Game
Blitz Planning
Iterative Development
Working Without Iterations (Wall work Queue)
Short Iteration Cycles
The Task Cycle
Communication & Collaboration
Stand Up Meetings
Daily “Scrum” Meeting
Co-located Team
Documentation
Start of Project Documentation
Design Documentation
Other approaches
Design & Programming
*Build Automation
*Automated Deployment
Continuous Integration
*Simple Design
Collective Ownership
*Refactoring
Pair Programming
Build Automation
•A simple “push of a button” Build Process
•Any team member can use it
Goal:
•Free up programmers from repetitive and mundane tasks
•Increase responsiveness, Improve Quality
•Reduce time chasing compilation or convergence issues
Purpose/Benefit:
•Batch & Shell scripts?
•Build tools? (Eg. CruiseControl)
How:
•Keep Compile time short
•Mind the 20:80 rule
Opportunities/Obstacles:
Automated Deployment
•Streamline and make predictable the process of promoting builds from development through testing and into production
Goal:
•Provide Testers and Customers latest code quickly
•Reduce mix-ups caused by manual build deployment and promotion
Purpose/Benefit:
•Automate process before any coding begins
•Make target machine resemble production environment
How:
•Helps to identify and address compilation and functional issues before UAT deployment
•Allow test team to promote builds into test
Opportunities/Obstacles:
Continuous Integration
•Less ‘branch’ code residing on individual workstations
•Small chunks of functionality integrated into central codebase
Goal:
•Save time
•Reduce Defect Rates
Purpose/Benefit:
•Code integrated one developer at a time
•Build Machine performing automatic compile and test of codebase
How:
•Getting into the habit of checking in code every few hours
Opportunities/Obstacles:
Simple Design
• All Code should ... compile and pass all the tests
• ... Result in no Duplicated Logic
• ... Do everything it needs to
• ... Leave behind the fewest necessary classes and methods
Goal:
•Changes to code only need to be made once
•Code is easier to understand
•Increases confidence and reduces criticism
Purpose/Benefit:
•Code for today and forget about tomorrow ... (because the spec might change)
•Consider the simplest thing that could possibly work
•Collaborate before coding
How:
•Two Heads are better than one
•Don’t forget to write unit tests
•Don’t re-invent the wheel vs. If you’ve got a hammer not everything is a nail
Opportunities/Obstacles:
Collective Ownership
•To remove explicit and implicit relationships between programmers and components
Goal:•Reductio
n of wasted time and duplicate code
•Anyone can change any code
•Reduces time to fix defects
Purpose/Benefit:
•Foster a sense of owning all the code
•Deliberately allocate tasks across the code to different people
•Short iterations / small releases
How:
•Team wide coding standards
•Unit tests will provide confidence in changing someone elses code
•Don’t let ego’s get in the way
Opportunities/Obstacles:
Feature Teams
•Better design and Easier maintenance
Goal:
•Benefits of Collective Ownership and class Ownership combined
•Distributed Knowledge across entire project team
•Responsibility for classes clear, design should improve
Purpose/Benefit:
•Each Programmer becomes owner of one or more classes
•Features are assigned to owners (Chief Programmer)
•Feature teams dynamically assembled to complete specific code
How:
•Can slow down speed of projects
•Can conflict with Continuous integration
•One class owner required on multiple feature teams
Opportunities/Obstacles:
Refactoring
•Keep the code fresh and clean
Goal:•
Recovery of poorly written systems
•Maintain ‘newness’ of code longer, therefore system lifecycle
Purpose/Benefit:
•Simplifying complex code
•Replacing similar operations into reusable code
•Removing duplicate code
How:
•Sufficient coverage of unit test required before refactoring
•Lots of small changes rather than a few big ones
•Seek buy-in of the whole project team
Opportunities/Obstacles:
Pair Programming
•Better Code Quality
Goal:•Mentori
ng/Training
•Knowledge Sharing
•Consistent use of Coding standards
Purpose/Benefit:
•Two people, one workstation, one piece of code
•Both take turns at “driving”
How:
•Adopt slowly ... Perhaps start with problem solving or bug fixing
•Part-time pairing before full-time pairing
•Try side-by-side programming instead
Opportunities/Obstacles:
Testing
*Automated Unit Testing
Acceptance Tests
*Test Driven Development
Automated Unit Testing
•A suite of tests that can be run at the push of a button
•Improved code quality
Goal:•Reduce
time identifying and correcting defects
•Reduce turnaround and increase confidence in small changes to code
Purpose/Benefit:
•Test meaningful functionality
•Rely only on restorable data
•Start with new and modified code, not legacy code
How:
•Don’t allowed repeated failures of the test suite
•Make sure the tests don’t take too long to run
•Everyone must write and run tests
Opportunities/Obstacles:
Acceptance Tests
•A mechanism for the customer to accept a feature
Goal:•Automa
ted tests ensure testing effort doesn’t expand with each additional release
•Reduction in number of defects
Purpose/Benefit:
•Should be written prior to development of story starting
•Should test everything required for sign off
How:
•Its not acceptable to complete a story without an acceptance test that passes
•This practice provides a good basis for also doing load testing
Opportunities/Obstacles:
Test Driven Development
•Quality of Code
Goal:•Ensures
exhaustive test coverage
•Ensures testable code
•Makes maintenance easier for all programmers
Purpose/Benefit:
•Write a test (an ensure it fails)
•Write just enough code so that the test (and all others) pass
•Repeat the cycle until the feature is completed
How:
•Its a change of mindset
•Start with something small and simple
•Best learnt in pairs
Opportunities/Obstacles:
Agile Management
User Stories / Story Writing Workshop
Release Planning Activities
Iterative Development
The Customer
Communication & Collaboration
Documentation
Release Planning Activities
Step 1: Update the List of Work
Step 2: Prioritise the List of Work
Step 3: Determine the Release Date and amount of work that can be completed
Step 4: Select the Work to be completed in the release
Step 5: Plan activity for 1st iteration of release
Release Planning Specifics
The Planning Game
•Reduce conflict relating to scope, scheduling and releases.
Goal:•Foster
collaboration between customer and developer
•Clearly defined roles for customer and development team
Purpose/Benefit:
•Exploration Phase – write stories (B) / estimate stories (D)
• Commitment Phase – Sort by Value (B) / Risk (D), Set Velocity/Scope
•Steering Phase – Repeat and review for each iteration
How:
•Customer & Developers commit to a realistic and mutually agreed plan
•Provides a framework for change
Opportunities/Obstacles:
Blitz Planning
•Focus on project initiation activities, getting project started or authorised quickly
Goal:
•Single meeting resulting in plan agreed by every project stakeholder
•Addresses technical issue’s often overlooked in initiation processes
•Promotes collaboration
Purpose/Benefit:
•Brainstorm tasks, Estimated and owner assigned
•Sort in sequence of development
•Walking Skeleton, Earliest Release, Earliest Revenue/Savings
How:
•Requires commitment from user, business and developers
•Promotes tough decision making
Opportunities/Obstacles:
What are the benefits and pitfalls of Iterative Development?
What is the role of the Customer in an Agile Project?
What to look for in a good Customer
Communication & Collaboration
Stand Up Meetings
Daily “Scrum” Meeting
Co-located Team
Stand-up Meetings
•5-10 minutes status updates, co-ordination, work plans
•STANDING ONLY
Goal:
•Standing encourages shorter meetings and therefore focus
•Identify topics/issues and sideline for appropriate people/time
•Mainly for programmers
Purpose/Benefit:
•Depends on office layout, if closeby, less valuable
•Same place, same time everyday
•Whats completed, Whats next, Roadblocks?
How:
•Evolve over time based on participants and projects
Opportunities/Obstacles:
Daily SCRUM Meeting
•Provides a forum for all stakeholders to observe
Goal:
•Opportunity for tuning team priorities
•Keeps everyone informed on progress
•Flush out obstacles, track progress
Purpose/Benefit:
•Only Pigs can speak (Team members)
•All team members to attend
•Whats completed, Whats planned next, Whats in the way?
How:
•Evolve over time based on participants and projects
Opportunities/Obstacles:
We value working software over comprehensive documentation
When is Documentation Important
1. To communicate information during development
2. To Specify something
3. To Permanently record something
4. To conform to regulations
Fundemental Advice
1. Prefer executable specifications over static specifications (documents)
2. Single source information
3. Document stable concepts, not speculative concepts, and thereby document as late as possible in the life cycle
4. Documentation is the least effective means of communication
Reviewing Current DocumentationFactor Improvement Strategy
How correct is the document?• Minimise the information contained• Single Source Information• “Pair” Author / Have shared ownership • Document stable, not speculative concepts
Will the document be read? • Work closely with the audience
Will the document be understood? • Take an iterative and incremental approach
Will the document be followed?
• Prefer executable specifications, such as customer tests and developer tests, over static specifications• Capture high-level information in documentation
Will the document be trusted? • Work closely with the audience of the document• Take an iterative and incremental approach
Common Agile Methodologies
eXtreme Programming (XP)
SCRUM
Feature Driven Development
Dynamic Systems Development Methodology
Adaptive Software Development
Lean Software Development
Common Theme’s
Focus on Features, not Tasks
Responsive to Change
Documentation Secondary to working software
Timeboxing
Planning & Estimation is a team activity
Short iterations, regular feedback loops
No amount of process can replace good people
XP
SCRUM
Feature Driven Development
ASD
DSDM
LEAN
Not a specific set of practices or processes
Process, Documentation, Best practices take a back seat to goal of operational excellence.
Defined by how quickly and reliably an organisation can serve its customers.
Seven LEAN Prinicples
Eliminate Waste
Amplify Learning
Decide as Late as Possible
Deliver as fast as Possible
Empower the Team
Build in Integrity
See the Whole
Teams
Self-governing
Self-organising
Self-managing
Manager-led
Team Type/
Activity
Setting Overall Direction
Designing the team and its
context
Managing work process and monitoring
progress
Executing the team tasks
Self-Organising Teams
Communication & Collaboration
Accountability & Responsibility
Learning Teams
Why are Self-Organising Teams Better?
Engendering a Communicative and Collaborative culture
working in an ARO
culture
3 domains
ACCOUNTABILITY
RESPONSIBILITY
OWNERSHIP
PERSONAL
MUTUAL
SHARED
ACCOUNTABILITY
RESPONSIBILITY
OWNERSHIP
personal
shared
mutual
control
influence
solidarity
about …
delivery
collaboration
unity
WHO IS US?
initiative
leadership
DEG
REE O
F C
ON
TR
OL
personal accountabilityI have the control leversDefines the decisions that are ultimately mineIs the set of things my boss will hold me to and for which I am employed.‘I assure you’ rather than ‘trust me’Included in my performance agreement
This defines what is important or central in my work. I do not have to be asked to go here … it is my job to be here.
Expect others to come here when your behaviour has an impact on an arena for which they are accountable, or when there is overlap with an arena for which they have shared responsibility.
mutual responsibilityI have the responsibility to influenceAnything that is impacted by my behaviour or my decisions is within my influenceWill include cultural and environmental dimensions, and will therefore be a significant component of my performance review conversationSomeone must be accountable, but I have the responsibility to give input, state my case, and ensure alignment with my arena of accountability
Go here when invited or when it impacts an arena for which I am accountable.Remember that this patch may be an arena that someone else is ultimately accountable
shared ownership
Solidarity, who is ‘we’?The domain that falls outside the sphere of my influence, but that remains part of the whole of which I am a partAs broad as possibleAll that sits under the strategic plan, that wears our brand
Go here when the brand or the ‘whole’ is threatenedBe careful because others will know more than you
Behaviour in an ARO culture is …
Focused and targeted, not scatteredProject rather then role or position orientedDisciplinedHigh performance
Communication isEntrepreneurial rather than beaurocraticTransparent: knowledge and power is necessarily sharedRobust and often difficult because there is lots of grey in the shared responsibility domain
Key vulnerabilities in an ARO culture …
ACCOUNTABILITYLack of clarityExcuses
REPONSIBILITYNo one accountableLack of systems thinking
OWNERSHIPfragmentation
Key vulnerabilities in an ARO culture …
competency creep:Supplementing my accountabilities with personal competency and preference
Disempowers those who have accountability in arena of competency creep
Makes me busier
Indicates a local rather than organisational view … has cascading impact on other teams/departments
Requires trust in other’s ability to deliver according to their accountabilities
Organisational Learning
Trust & HonestyTole
ranc
e of
Fai
lure
Slack – time, resources, opportunity
Individual Learning
Empowerment
Man
agem
ent T
ime
Recr
uitm
ent
Rew
ards
& In
centi
ves
Team Learning
Organisational Change
Organisational Learning
Team Change