870 likes | 989 Views
Introduction to Agile Principles, Practices, and Processes. Steve Bohlen Senior 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
E N D
Introduction to Agile Principles, Practices, and Processes Steve Bohlen Senior 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 Bohlen Nearly 20 years developing software LISP, Delphi, C/C++, VB, VB.NET, C# Senior Engineer Springsource/VMware Co-Founder, NYC Alt.Net User Group http://nyalt.net • Co-Organizer, NYC DDD User Group • http://dddnyc.org Contributor: various OSS projects NHibernate http://www.nhforge.org • NDbUnit http://www.googlecode.com/ndbunit • Spring.NET http://www.springframework.net blog: http://blog.unhandled-exceptions.com e-mail: sbohlen@gmail.com twitter: @sbohlen
Test Studio Express TelerikOpenAccess ORM RAD Controls for ASP.NET AJAX RAD Controls for Windows Phone ASPX to Razor Converter RAD Controls for WPF TelerikTeamPulse Sitefinity CMS C#/VB.NET Converter TelerikJustDecompile Telerik Reporting TelerikJustMock RAD Controls for Winforms RAD Controls for Silverlight TelerikJustCode Telerik Extensions for ASP.NET MVC Telerik Test Studio
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
“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 interactionsover processes and tools Working softwareovercomprehensive documentation Customer collaborationover contract negotiation Responding to changeover following a plan That is, while there is value in the items on the right, we value the items on the leftmore.
Thanks for Coming Out Tonight Don’t forget to complete an evaluation on your way out the door! (kidding!)
Traditional Building of an Application Iteration 5 User Interface Layer BV = 100% Iteration 4 (whatever) BV = 0% Iteration 3 Business Logic Layer BV = 0% Iteration 2 0% VALUE Data Access Layer BV = 0% Iteration 1 Database BV = 0%
Agile Building of an Application Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 UI UI UI UI UI (whatever) (whatever) (whatever) (whatever) (whatever) 60% VALUE Business Logic Layer Business Logic Layer Business Logic Layer Business Logic Layer Business Logic Layer Data Access Layer Data Access Layer Data Access Layer Data Access Layer Data Access Layer Database Database Database Database Database BV = 20% BV = 40% BV = 60% BV = 80% BV = 100%
Another way to Visualize this Relationship Business Value of Work Executed Over Time
Traditional Application Development Horizontal Layers of Functionality • Build from the Ground Up • Lower Layers ‘Baked’ • Expensive to Change Later • No Penalty for Tight-Coupling
Traditional Application Development Much Work Remains to Be Done Before We Can Announce Our Total Failure to Make Any Progress
Traditional Application Development Complexity
Traditional Application Development Business Value ZERO!
Traditional Component Stabilityduring Project Lifecycle Done This model is an unattainable hypothetical that isn’t borne out by experience Percent Stability over the Life of the Project (100% = totally stable component)
Traditional Component Stabilityduring Project Lifecycle …or here… …or here… Something always happens here Done The Point: This model is an unattainable hypothetical that isn’t borne out by experience …or here… …or here… …or here… …or here! …or here… Percent Stability over the Life of the Project (100% = totally stable component) …or here… …or here…
Agile Application Development Vertical Slices of Functionality
Agile Application Development Penalty for Tight Coupling
Agile Application Development No BDUF Required
Agile Component Stabilityduring Project Lifecycle Everything maintains a similar level of stability until the end of the project Done Nothing is inviolate for change Solution can adapt to changing conditions as needed Percent Stability over the Life of the Project (100% = totally stable component)
Agile vs. Traditional Methodologies Chaos is BAD!
Agile vs. Traditional Methodologies Cowboy Coders!
Agile vs. Traditional Methodologies Tools to Manage Chaos
Agile vs. Traditional Methodologies Perfect Scope
Agile vs. Traditional Methodologies Building the Thing Right…
Agile vs. Traditional Methodologies …Building the Right Thing! Building the Thing Right…
Why the Focus on Tests? Iteration 1 Iteration 5 UI UI High rate of Change to all components always (until done!) (whatever) (whatever) Business Logic Layer Business Logic Layer Data Access Layer Data Access Layer Database Database BV = 20% BV = 100%
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 • Wrongmetaphor • 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
Estimation • Wikipedia: Estimation is the calculated approximationof a result which is usableeven 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
Agile Estimation • Wikipedia: Estimation is the calculated approximationof 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)