Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Agile Methodologies - High Res Version

The presentation for the Agile methodology workshop. Final copy without embedded PDF's for speed.
by

Evan Leybourn

on 1 July 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Agile Methodologies - High Res Version

AKA:
Requirements Gathering
Sprint 0 (Scrum)
Iteration 0 (XP)
Cost, Time and Scope
Work in priority order
Release in short increments
Monitor burn rate
Time and Scope
Agile Estimating and Planning - Mike Cohn
Sprint Planning Meeting
meeting time (hours)
1
Product Owner
Convert the backlog into a
realistic goal for this sprint
Role:
Typical:
Begin the project
Define and prioritise requirements
End the project
Not:
A user (usually)
Control development
Internal manager
External client
Role:
Typical:
Maintain backlog
Represent stakeholder
Approve estimates
Prioritise features
Approve sprints
Approve releases
Manage multiple teams
Not:
Control development
Customer

Client liaison
Project manager
Product manager
Role:
Typical:
Responsible for scrum process
Manage teams during the scrum
Inspect and report on progress
Refine estimates
Inform the PO of any issues

Code review
Reject developed features
Not:
Prioritise features
Project manager
Team Leader
Team member
Role:
Typical:
Not:
Prioritise features
Typical team size or 7 +/- 2

Cross-functional
Software developers
Interface designers
Documentation writers
Database administrators
Role:
Typical:
Test the features
Approve features
Reject features
Not:
Developer
Customer
A cross section of users
Role:
Typical:
Use the software
Request features
Identify issues
Provide feedback
Not:
Tester
An annoyance
Control development
There is no typical user
sprint time
*
Client
Description
Requirements
Analysis
Product
Design
Detailed
Design
Released
Software
Stories
Epics
Expert opinion
Comparison
Components
Planning poker
Generic industry standard:

Modify as required
Staff
4
8
Backlog
Part 1
Scrum Master
Team
Testers
Part 2
Goal
Scrum Master
Team
Testers
Reprioritise
Write Test Case
Develop Feature
Run Test
Pass
Fail
Defect
Functionality
Usability
Data
Backlog
Update Test
Add to Test Case
Catalogue
Priority
Low
High
1000: Lowest Priority Feature
Scrum Meeting
time (minutes)
1
Product Owner
15
Scrum Master
Team
Testers
1. What did you do yesterday?
2. What will you do today?
3. Are there any issues?
Committed
Involved
Discuss
Users
Customer
Management
Burndown Chart
Progress Problems
Attend scrums
Customers can:
But not talk. Questions should be directed to the Product Owner or Scrum Master
View progress against the release
Improve future estimates
Identify problem trends early
The chart should be public
Don't manage by numbers
Discovery
Issues identified after the sprint begins
or
Refined estimation after the sprint begins

Watch the progress carefully.
If necessary review the tasks in the Sprint
See the backlog
View progress
Progress Monitoring
Everyone should have access to the Dashboard
and see the latest build and test results
Books
Links
http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415/ref=sr_1_1?ie=UTF8&s=books&qid=1256874584&sr=8-1
Presentation Thanks
http://www.afterglow.ie/icons.html
http://www.dezinerfolio.com/freebie/project-icon-set
http://watir.com
http://en.wikipedia.org/wiki/Iterative_and_incremental_development
http://en.wikipedia.org/wiki/Agile_software_development
Software functions
Boundary cases
User interface
User experience
Non-functional components
Performance
xUnit
Everyone must participate
Prepare beforehand.

This is a creative, problem solving process. Encourage brainstorming.

Ensure the planning room has plenty of paper, a whiteboard and a computer with Google access.
http://www.agileadvice.com/
http://en.wikipedia.org/wiki/IEEE_829
http://www.ddj.com/architect/201202925?pgno=4
aka daily standup
Scrum of scrums
All about risk mitigation
http://en.wikipedia.org/wiki/Scrum_(development)
http://www.ambysoft.com
http://trac.edgewall.org/
http://en.wikipedia.org/wiki/Agile_testing
http://agilemanifesto.org/
http://en.wikipedia.org/wiki/Agile_software_development
Units of work or estimation - not hours
Managing Agile Projects - Kevin J. Aguanno
http://www.amazon.com/exec/obidos/ASIN/1895186110/ambysoftinc
Must be able to accurately represent the customer
Tools
The Agile Manifesto
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.
Working 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-organising teams.
At regular intervals, the
team reflects on how to
become more effective,
then tunes and adjusts its
behaviour accordingly.
Rapid Application
Development

DSDM
Lean Development
XP
Scrum
RUP
Crystal Clear
TDD
FDD
RAD
BDD
Agile Unified Process
Iterative design process
Continuous stakeholder engagement
Aims for quality and reliable software
Deliver regularly
Highly flexible framework
Greater customer satisfaction
Easy to monitor progress
Higher likelihood for completion
Iterative management process
Work is split into 1-4 week Sprints
Formal roles (Product Owner, Scrum Master, Team)
Timeboxed (Fixed duration) meetings
Fixed
Cost
Time
Scope
Cost and Scope
Cost and Time
Focus on backlog definition
and estimation
Work in priority order
Enforce sprint duration
Increase the estimate risk during Sprint 0
Update delivery date as required
Calculate total cost as cost per sprint
Pre-assign work to iterations
Pad schedule with extra iterations
Cancel the project
Fixed
Fixed
Fixed
Fixed
Fixed
Fixed
Domain Object
Modelling
Define the domain of the
problem to be solved
and create an object
framework.
Develop Overall
Model
High level scoping
Create domain walkthroughs for
each modelling area
Peer review of each model
Merge into complete system
model
aka. The Planning Game (XP)
Sort by
Priority,
Value and
Risk
Person
Testing
Software
Writes
Unit Tests
Manual Test
Tests are written by the Customer and Developer together.
TDD can help you prove where a project headed.
Tests are written before the code.
Write both automated unit tests and UAT tests.
Make informed decisions.
Can use IEEE 829 and IEEE1008 to document and write tests.
Brings together Scrum Masters from multiple teams
Run any compile or make scripts.
All commits should compile.
Sprint Review
time (hours)
1
Product Owner
4
Scrum Master
Team
Customer
Users
1. Present the completed work to the stakeholders
2. Review the work that was completed
3. Review the work that was not completed
Present
Discuss
Sprint Retrospective
time (hours)
1
3
Scrum Master
Team
Testers
1. Reflect on the sprint
2. Make any process improvements
3. Discuss what went well during the sprint
4. What could be improved during the sprint
Present
Discuss
Release Burndown Chart
After each Sprint, review the project velocity
Calculate and plot investment to date
Units of work or estimation - not hours
Technical Specifications
Estimate effort
Test driven development (TDD)
Research tasks should have a high estimate risk
Break large tasks into the smallest possible tasks
Split tasks that involve waiting into separate tasks
Tasks can be created. Features can't
Simple design is preferred - XP
Redesign as required - Refactor as necessary - XP
An alternative is to record the scrums and make the recording available to the customer
Functions are broken into the smallest possible part and developed in the
order of priority.
Developing by
Feature
Each code class is assigned to a single owner who is responsible for the consistency, and performance of the class.
Individual Class
Ownership
A log of all features and the source code that have been completed to date.
Configuration
Management
Carried out to ensure good quality design and code.
Inspections
Feature Teams
A small, dynamically formed team that designs and develops each feature.
Ensures there is always a fully functional system.
Regular Builds
Frequent, appropriate, and accurate progress reporting.
Visibility of
progress and
results
Build Feature
List
Split domain into subject areas
•Separate subject areas into business activities
•Separate business activities into individual features
e.g. Confirm the password of user
Plan by Feature
Assign features to classes
Assign classes to developers (or development teams)
Build by Feature
Develop the code for each feature and class
Unit test
Promote to build
Design by
Feature
Create a set of features to be developed within two weeks
Build sequence diagrams for each feature
Refine model for each feature
Inspect and review the design
Based on the technical design and should verify that the implementation is complete
Based on the user stories and verify the feature is complete.
Reducing Risk
Reducing
Uncertainty
Improved
Decision Making
Cost planning
Including Staff Hiring
Integration
With Long term
Goals
Information
Gathering
Agile projects
have minimal
ramp up
The full team
should be
available at
inception
Ensure the
customer is
fully aware of
their role.
Don't use
MS Project or
Gantt charts.
Create the product backlog
Estimate the product backlog
Anywhere from 1 day to 4 weeks.
Each sprint should accomplish something releasable

Developer welfare (XP) - Short sprints can reduce overtime
Plan length of sprint
In Low detail

Allow customers to slowly build the requirements.
Plateau
Features are more difficult than estimated
or
Unexpected staffing issues

Review the tasks in the sprint
Tracking
Epics
Individual stories are too large and
difficult to track

Keep each task under 1 day of work
Scope
Creep
Tasks are being added mid-release.

Identify who is adding tasks. Stop this
behaviour at all costs.
Too Many
Features
Features are more difficult than estimated

Review the estimation process and remove
tasks from the Sprint
Poor
Estimation
Features are slightly more difficult
than estimated

Review the estimation process. Consider
extending the Sprint
http://www.scrumalliance.org
Roadmap
An overview of each Sprint
Sprint Planning
Sprint Review
Sprint Retrospective
Daily Scrum
8 hours
4 hours
3 hours
15 minutes
Developers write unit and UAT tests first
Code is run against the tests
Promotes good code
Process

1. Create a test
2. Add the test to the test catalogue
3. Write the code
4. Run the tests (all of them)
5. Clean up the code as required. (Refactor)
Writing the
Software
Pair
Programming
Two developers working
together. 1 Coder and 1 reviewer
Regularly and automatically
Testing the
Software
An application framework to reduce unnecessary
dependencies between features
Designing or
Refactoring
Listening to
the Customer
Common Code
Standards
Documentation, naming conventions, whitespace
Clear System
Metaphor
All class and function names
should be understandable
Collaboration
Add any team
training to the
backlog as tasks
Very Good:

Clients who add
no overhead
to the project
Very Bad:

Customers who interfere with the
project and will double the expected
completion
Planning
Deploy
Development
Backlog
Methods in Detail
Why Agile?
What does "Agile" Mean
Project Initiation
Sprint
Project Roles
evan@theagiledirector.com
@eleybourn

Evan Leybourn
Agile Methods
References
Interested Roles
Has an interest in the release
Kept informed of progress
The Users
Pig and Chicken
A Pig and a Chicken are having breakfast
when the Chicken says,
"Lets start a restaurant"
Pig: "What would we call it?"
Chicken: "How about Bacon and Eggs"
Pig: "No thanks, you'd only be involved but
I would be committed."
Committed Roles
Responsible for the release
"Do" the work
Benefits
Agile Methods
Key Points
Test Driven
Development (TDD)
Scrum
Feature Driven
Design (FDD)
Extreme
Programming (XP)
Activities
Development
Processes
Activities
The Customer
The Team
Develop features
Resolve issues
Self managing
Outcomes
Specifications in
Agile?

Beginning the
Process

How much is this going to cost?
How long is this going to take?
Whatever you tell us you want.
As much as you're willing to spend.
What am I going to get?
Cost / Time / Scope
As long as it necessary.
Product Owner
Tips
Sprint Backlog
Function
Priority
Estimate
Estimate Risk
0 - 100%
1: Highest Priority Feature
Accuracy
TDD
aka User Stories
aka Feature Driven Design
aka Simple System Requirements
Estimating Effort
Design
Document
1
2
3
5
13
20
40
100
How?
Cost
Comparing a task to another, already
estimated, task.

e.g. "Task A is about twice the effort
of Task B"
If using Planning Poker, estimates must not be mentioned at all during discussion to avoid anchoring. A timer may be used to ensure that discussion is structured; any person may turn over the timer and when it runs out all discussion must cease and a round of poker is played.

Each person lays a card face down representing their estimate of the task, and then simultaneously turns their cards over.

People with high estimates and low estimates are given an opportunity to discuss their estimate before anyone else can speak.

Repeat the estimation process until a consensus is reached.
The team member with specific
understanding, or who is most likely
to develop the task, can provide a
more accurate estimate of effort.

e.g. A database administrator can
better estimate effort for database
tasks.
If a task is too large to accurately
estimate, break it into small sub-tasks.

e.g. User management can be
broken into interface, login,
access control, etc.
Overhead
Customer
Difficulty of customer

Modifier: 0 to 100%
Staff Availability - Estimated leave, illness, breaks, meetings etc.

Modifier: 25%
e.g.
4 x (0.25+1) x (0.2+1) x (0.5+1)
= 4 x 1.25 x 1.2 x 1.5
= 9 hours
Story Cost x
(Staff Overhead + 1) x
(Client Overhead + 1) x
(Estimate Risk + 1)
Calculation
Estimated Time
Key Points
Test Coverage
Test Types
Sprint
Backlog
(Design
Document)
Inspect the developed code for deviations from the internal code standard
Check for correct inline documentation (docblock)
Check for correct variable naming conventions
Check for correct whitespacing conventions
Check for complex code that may require refactoring
Check for incomplete or unused functions
Runs predefined tests to identify software defects
Create tests for each class and function
Create tests for all parameter combinations
Create tests for all edge cases
Create tests to examine the database for logical errors
Create tests to detect interface defects (Selenium)
Tests should be kept in the version control repository
Test in a clone of the production environment
Comments should contain;
Description
Author
Usage
Parameter description
Return description
References to other functions
Copyright (file comments)
Automatically generate software documentation
The following should be commented;
Files
Classes
Functions
Class Variables
Complex Structures
Calculate and display how much of the software is covered by unit tests.
Aim for 80-90% code coverage
The Testers
Effort
Accuracy
Delivered Functionality
Sprints are kept small to ensure this velocity can be tracked
Project Velocity
Velocity
Calculate from previous sprints statistics
Delivered Functionality
How much work can be acheived per sprint
Plotted on the burndown chart to compare current progress
Calculate from previous sprints statistics
The planned burn rate across the entire project
Transparency
Inspection
The Product
Owner
The Scrum
Master
Dashboard
Documentation Written?
User Acceptance Testing?
Built / Compiled?
Testing
Deploy
What does done mean?
Differs by Organisation
Done
TDD in Development
Test Case
Detail
Low
High
Reprioritise
Unit Testing
Code Standards
Documentation
Code Coverage
Compile
Success
Failure
Version Control
Everyone commits every day
Commit
Continuous Integration
Get Highest
Priority Feature
Allow developers to choose their work. Don't assign it.
Pair Programming
One coder + one reviewer
Change regularly
Switch pairs each day
I have never used Pair Programming
Code Standards
A common coding style
(Documentation, Names,
Whitespace, etc)
System Metaphor
All classes and functions
should be named such that
their purpose is understood.
Develop
Emergency Fix
8
Continuous Integration
Full transcript