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 Software Development - MR

No description
by

Christopher Lam

on 13 June 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Agile Software Development - MR

Collaboration
Agile Software Development
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
Waterfall
Agile
vs.
Change is expensive
Change is inevitable
Resources are interchangeable
People are creative and unique
Command and control
Self organizing and managing
Change
Reduce WIP
Remove Fear
Delay decisions until last responsible moment
Eliminate Waste
Business Value
Story Prioritization
Story is a placeholder for a conversation
Short feedback loops
- make it cheap
- maximize
Trust
Decisions made by the team
Open and honest communication
Team commitments
Avoid BDUF - big design up front
Collaboration
Business and IT working together
Supercharge communication
Big and visible
Face to face
Daily
Encourage debate
Challenge each other
Everyone responsible for success
Continuous Improvement
Drop practices that don't provide value
Try new things
Reflect regularly
Fun
Avoid burn-out
Improves collaboration
Promotes creativity
Focus on the users
- have it
- work together
- bigger, better, faster
- the team
Values
Continuous
Improvement
Collaboration
Fun
Trust
Change
Business
Value
Transparency
Share ideas across teams
Sprint Planning Meeting
meeting time (hours)
1
Product Owner
Convert the backlog into a
realistic goal for this sprint
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
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
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.
aka daily standup
Scrum of scrums
All about risk mitigation
Units of work or estimation - not hours
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
Based on the technical design and should verify that the implementation is complete
Based on the user stories and verify the feature is complete.
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
Roadmap
An overview of each Sprint
Planning
Deploy
Development
Sprint
Product Owner
Tips
TDD
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
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
Dashboard
Documentation Written?
User Acceptance Testing?
Built / Compiled?
Testing
Deploy
What does done mean?
Differs by Organization
Done
TDD in Development
Test Case
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
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
Continuous Integration
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
Must be able to accurately represent the customer
Interested Roles
Has an interest in the release
Kept informed of progress
The Users
Committed Roles
Responsible for the release
"Do" the work
The Customer
The Team
Develop features
Resolve issues
Self managing
The Testers
The Product
Owner
The Scrum
Master
Agile Software Development
Roles


Higher Employee Satisfaction

•Empowerment; no iteration is committed to unless the team agrees it can be done

•Less 18-hour days; less “heroics”

•Regular retrospectives encourages continuous improvement

•Less documentation, more conversation

•Better understanding of fellow colleague’s work; less silos

•See workable product in regular intervals

•Ability to work outside your traditional “role portrait”
What Are User Stories?
A User Story Is...
Benefits
A User Story Is Not...
Not use cases
Not scenarios
Not IEEE 830 standard requirements
Not detailed requirements
Not design specs
Not artifacts of analysis, but user desired features in a system
Emphasize verbal communication
Stories shift the focus from writing to talking
Comprehensible by both customer and developer
Right size for planning
Stories support and encourage iterative development
Encourage deferring detail until you have the best understanding you want to
Stories emphasize the user's goals not the systems attributes
User Stories as a requirements process saves time, eliminates rework, and leads to better software
A high level software system feature or requirement formulated as one sentence in the everyday language of the user
A place holder for a conversation to be held later
Written by the business or Product Owner
Prioritized by the business with the help of the Product Owner to indicate which are most
important for the system
Detailed requirements for a User Story are gathered later, closer to when the story is actually implemented
Must include acceptance/test criteria
Can initially be large (called Epics) and broken down later
Are simple, but they are not always easy
User Story Format
Full transcript