Introduction to Agile Principles, Practices, and Processes

Columbia, Maryland - Summer 2011

Introduction to Agile Principles, Practices, and Processes

Steve BohlenSenior Software Engineer

SpringSource/VMware


Do I suck?Let me (and the world) know!

http://spkr8.com/t/7941


Who am I?• …and why should you care?• Steve Bohlen• I Read Books + Write Software• vs. “Read Software + Write Books”

• Blog, Screencast, Speak, Share, Learn


Steve BohlenNearly 20 years developing softwareLISP, Delphi, C/C++, VB, VB.NET, C#Senior Engineer Springsource/VMwareCo-Founder, NYC Alt.Net User Group

http://nyalt.netCo-Organizer, NYC DDD User Group

http://dddnyc.orgContributor: various OSS projects

NHibernate http://www.nhforge.orgNDbUnit http://www.googlecode.com/ndbunitSpring.NET http://www.springframework.net

blog: http://blog.unhandled-exceptions.come-mail: [email protected]: @sbohlen

CYND D D


RAD Controls for ASP.NET AJAX

RAD Controls for Silverlight

RAD Controls for Windows Phone

RAD Controls for Winforms

RAD Controls for WPF

Telerik Reporting

Telerik OpenAccess ORM

Telerik JustCode

Telerik JustMock

Telerik Extensions for ASP.NET MVC

Test Studio Express

Telerik TeamPulse

Telerik Test Studio

Sitefinity CMS

Telerik JustDecompile

C#/VB.NET Converter

ASPX to Razor Converter


85!


Agenda• What is Agile (and why Should I Care)?• Estimation in the Age of Agile• You Test, I Test, we all Test• Continuous Integration as Transparency Tool


What is Agile (and Why)?


“Courage is the power to let go of the familiar.”-Raymond Lindquist


The Agile Manifesto

We are uncovering better ways of developing

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 a plan

That is, while there is value in the items on

the right, we value the items on the left more.


Thanks for Coming Out Tonight

Don’t forget to complete an evaluation on your way out the door!

(kidding!)


Iteration 1

Iteration 2

Iteration 3

Iteration 4

Iteration 5

Traditional Building of an Application

Database

Data Access Layer

Business Logic Layer

User Interface Layer

(whatever)

BV = 0%

BV = 0%

BV = 0%

BV = 0%

BV = 100%

0% VALUE


Iteration 2 Iteration 3 Iteration 4 Iteration 5Iteration 1

Database

Data Access Layer


UI

(whatever)

BV = 20%

Database

Data Access Layer


UI

(whatever)

BV = 40%

Database

Data Access Layer


UI

(whatever)

BV = 60%

Database

Data Access Layer


UI

(whatever)

BV = 80%

Database

Data Access Layer


UI

(whatever)

BV = 100%

60% VALUE

Agile Building of an Application


Business Value of Work Executed Over Time

Another way to Visualize this Relationship

Iteration 0

Iteration 1

Iteration 2

Iteration 3

Iteration 4

Iteration 5

0%10%20%30%40%50%60%70%80%90%

100%

TraditionalAgile


Traditional Application Development

Horizontal Layers of Functionality

• Build from the Ground Up

• Lower Layers ‘Baked’• Expensive to Change

Later• No Penalty for Tight-

Coupling


Much Work Remains to Be Done Before We Can Announce Our Total Failure to Make Any Progress



Complexity



Business Value


ZERO!


Traditional Component Stabilityduring Project Lifecycle

Iteration 0 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 50%

20%

40%

60%

80%

100%

120%

DBDALBLLotherUI

Percent Stability over the Life of the Project(100% = totally stable component)

Done

This model is an unattainable hypothetical that isn’t borne

out by experience


Traditional Component Stabilityduring Project Lifecycle


20%

40%

60%

80%

100%

120%

DBDALBLLotherUI


Done

Something always happens

here

…or here…

…or here…

…or here…

…or here…

…or here…

…or here……or here…

…or here…

…or here!

The Point:This model is an unattainable hypothetical that isn’t borne

out by experience


Agile Application Development

Vertical Slices of Functionality



Penalty for Tight Coupling



No BDUF Required


Agile Component Stabilityduring Project Lifecycle


20%

40%

60%

80%

100%

120%

DBDALBLLotherUI


Done

Everything maintains a similar level of stability until the end of

the project

Nothing is inviolate for change

Solution can adapt to changing conditions as needed


Agile vs. Traditional Methodologies

Chaos is BAD!



Cowboy Coders!



Tools to Manage Chaos



Perfect Scope



Building the Thing Right…



…Building the Right Thing!Building the Thing Right…


Why the Focus on Tests?

Iteration 5Iteration 1

Database

Data Access Layer


UI

(whatever)

BV = 20%

Database

Data Access Layer


UI

(whatever)

BV = 100%

High rate of Change to all components always

(until done!)


Surviving the Chaos: Feedback Loops


Feedback Loops: Examples

• Unit Tests– Rapid feedback on the impact of my own changes

• If manual testing is req’d to validate every change, then the cost of change becomes too high to consider making it

• Continuous Integration– Rapid feedback on the impact of everyone else’s changes

• Duration between breaking changes and awareness of issue is zero!

• Iterations/Sprints/Intervals/Whatever– Stakeholder feedback on the impact of changes

• Confirm/Verify/Validate direction of solution


Different Solutions to The Same Problem: Change

• Traditional Software Development Approach– Assumes change is avoidable– Tries to manage change by sufficient pre-planning and design to avoid change altogether

• BDUF approach– Treats the process of constructing software as if it’s a building construction project

• Wrong metaphor• Agile Software Development Approach

– Assumes change is inevitable and unavoidable– Assumes its impossible (or at least impractical) to attempt to plan-around or design-

around change– Tries to manage change by ensuring that the software remains flexible enough to respond

to the change– Ensures that sufficient tooling, process, and methods are in place to allow response to

change within the context of an incredibly tight feedback loop


Software Development


Estimation During ourJourney of Discovery


Estimation • Wikipedia: Estimation is the calculated

approximation of a result which is usable even if input data may be incomplete or uncertain.

• Problem is that estimates become a unbreakable schedule, where any deviation is considered bad


Problem #1 with Estimates• Estimate for our project:– 1 month for design and architecture– 4 months for development – 1 month for testing

• Scenario:– Your first estimate is wrong by 1 week (design)– What do you do???


The Estimation Problem• When you come up with a project idea, your first

estimate is off by +/ 4x– Not enough details are known

• Traditionally too much time is spent on building a specification which is not complete – Again, not enough details are known

• As time progresses, more details emerge about the system and its details– The cone of uncertainty


Cone of Uncertainty


Agile Estimation• Wikipedia: Estimation is the calculated approximation of

a result which is usable even if input data may be incomplete or uncertain.– Problem is that estimates become a unbreakable schedule,

where any deviation is considered bad• Agile Estimation throws this logic away and always re-

estimates a project after each iteration– Different value system: deviations are not deviations, they are

more accurate estimations– Uses the cone of uncertainty to your advantage


How to Estimate• User Stories• Story Points• Product Backlog• Velocity• Re-estimation


User Stories• Users break down the functionality into “User

Stories”• User Stories are kept small• User Stories include acceptance criteria• Mike Cohn suggests:– As a (role) I want (something) so that (benefit).


User Story Modeling

Narrative:(Who) wants (what) so that (why)

• A story is a conversation starter, and gets more detailed over time


User Story Modeling

GOOD: Billing wants to see a summary

page of all unpaid accounts, so that they can collect payments.

BAD: Users want rounded corners on

the search button.Our company wants a new

website to increase sales.

Good stories satisfy INVEST:– Independent– Negotiable– Valuable– Estimable– Small– Testable


Story Points• Break down user stories to units of relative size – So you can compare features– Alternative to time

• Story Points are not a measurement of duration, but rather a measurement of size/complexity

• Start with 1 standard feature and then other features are either 1x, 2x, etc larger or smaller than that relative feature in size/complexity


Product Backlog• All User Stories are put into a bucket• This represents all of the tasks for the project

(work items)• Backlog items have estimates!– Remember this estimate is not time based, but

point based• Backlog can also contain the item priority


Iteration 1• Developers will commit to ## story points• Warning, they will usually over commit!• After the end of Iteration 1, you have your first

Velocity measurement


Team Velocity • Velocity is the number of story points per iteration completed• You calculate velocity to predict how much work to commit to

in an iteration• Velocity only works if you estimate your story points

consistency • Over time you will know: team has a velocity of 32 story

points per iteration– Over time this will self-correct– Over time you will be able to predict the project schedule (and

release)


Calculating Team Velocity• Select a regular time period (iteration length)

over which to measure Velocity• Add up the story points of the stories 100%

completed• At the end of the iteration, the figure you have is

your Velocity• You can then use your Velocity as a basis for

your future commitments


Re-estimation• As you complete more iterations, your velocity will

change– Velocity changes because of minor inconsistencies in the story

point estimates– Team velocity will typically stabilize between 3 and 6 iterations

• Re-estimation of the entire project happens after each sprint– New Velocity– New story points added and removed (completed)– Use the cone!


Bites at the Apple

& AccuracyConsistency


Test-Driven DevelopmentA Feedback Loop for the State

of My Code


The Rationale for Unit Tests

99 little bugs in the code, 99 bugs in the code — We fixed a bug, compiled it again, 101 little bugs in the code ♫


The Rationale for Unit Tests

Debatable Software Engineering ‘Facts’(Agile/XP/SCRUM/etc.) is better than (Agile/XP/SCRUM/etc.)Test-first (TDD?) is better than Test-After

Non-Debatable Software Engineering Facts:There will always be bugsComplex programs have more bugs than simple programsCode is more maintainable when its divided into bite-sized

chunksThe cost of fixing a bug escalates non-linearly over time

as the project progresses


‘Code Complete’ Defect Cost Graph


Allocation of Developer EffortCoding 25%

Debugging 45%

Integration Testing 15%

QA Testing 10%

User Testing 5%

Effort Allocation without Unit Tests

Coding 25%

Unit Testing 35%

Debugging 15%

Integration Testing 10%

QA Testing 10%

User Testing 5%

Effort Allocation with Unit Tests


What is Test-Driven Development?

Testing while coding

not before or after



Think “Test-Driven Design”or

“Specification-Driven-Development”

Consider your design from the perspective of the consumers of your methods, classes, etc.

Outside-in design instead of Inside-Out design



“How-Do-I-Use-This-Driven-Development”

For every line of code you write, ask yourself a simple (but powerful) question:

“HOW WILL I TEST THAT?”


What about…

Costs

Additional time spent on code that isn’t part of delivery.


What about…

Costs

We are programmers, not testers!We should concentrate on developing features, not testing!


What about…

Benefits

Every class and method immediately has at least TWO consumers:

Your APP and your TEST!


What about…

Benefits

Better-isolated code leads to easier to extend, enhance, replace, maintain (lifecycle costs)


What about…

Benefits

Waiting until code is written to write the tests often means hard (impossible?) to test code!


What about…

Benefits

Less likely to write code that you eventually don’t need

Write nothing that you think you will need(YAGNI – You Ain’t Gonna Need It!)


Of course you can't count on tests to find everything. As it's often been said: tests don't prove the absence of bugs. However perfection isn't the only point at which you get payback for a self-testing build. Imperfect tests, run frequently, are much better than perfect tests that are never written at all.

- Martin Fowler


Continuous IntegrationA Feedback Loop for the State of my Whole Development Team


Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

Many teams find that this approach leads to significantlyreduced integration problems and allows a team to develop cohesive software more rapidly.

--Martin Fowler


Benefits of Continuous Integration•Broken build•Failed tests•Can’t deploy

Shorten feedback loop

•Exercise whole build and deployment processReduce risks

•Unit, integration, functional testing•Code metrics•Code conformance

Provide confidence of quality


Components

CI Server

• Background process• Web site• Notification (email, system tray, RSS, etc.)

Build Scripts

• Compile• Deploy• Run tests


Manage Dependencies• Consider adding 3rd party tools to SCC• Add 3rd party libraries to SCC– Commit binaries so that you don’t need to build

these every time.– Prefer a public release. Avoid custom changes.– Document clearly which version you use.


Oops, Steve Broke the Build again!• Build status must be visible• Use the systray app for your CI server• Consider adding the Build Dashboard to an

“Information Radiator”• Some have used ambient lights, lava lamps, or

even songs to let the whole team know when a build breaks


Notifications

Emails

System Tray utilities (CCTray, CCMenu, etc.)

RSS feed

Text Message


Notifications – Lava Lamps

http://agileworks.blogspot.com/2009/02/lava-lamp-with-cruisecontrol.html


Notifications – iPhone app


Getting Started with CI• Compile-Only builds can work as “training

wheels” for a team that is new to CI.• Add metrics early so that you can measure your

progress as you add automated testing.• Add automated tests ASAP.• Make a clear distinction between automated Unit

Tests and Functional Tests.• Automate deployment.


Quality in Depth

Compilation

Unit Testing

Functional/UI Testing

Code Metrics

Deployment


Extending the Value of the Build• NUnit, MbUnit, xUnit.NET, MSTest• PartCover, NCover, OpenCover, Clover.NET• NDepend, Structure101• Simian, FxCop• StyleCop


Wrap Up(I thought we’d never get here!)


Software Development


Introduction to Agile Principles, Practices, and Processes

fini

Introduction to Agile Principles, Practices, and Processes

Documents

Transcript of Introduction to Agile Principles, Practices, and Processes