agile engineering practices
DESCRIPTION
Agile engineering practices from XP and FDD focusing on FDD. (Based on cultural challenges that XP faces.)TRANSCRIPT
Agile Engineering PracticesHangzhou Scrum Forum 2009
May 2009
2
Agenda
Ground rules Purpose and expected outcomes About the presenter Agile – concepts and methodologies Agile and Engineering Practices
– Scrum– XP– FDD
3
Ground Rules
Mute your cell phone
Participate – ask and answer questions
Do Don’t
4
Purpose and Outcomes
Purpose:– Review key Agile principles– Discuss Agile Software Engineering Practices
Outcomes:– Gain an understanding of key Agile Software Engineering
Practices– Recognize there are multiple sources from which to learn
and implement Agile Engineering Practices – Develop a basic understanding of Feature Driven
Development as an Agile alternative to XP practices (which are often challenging to implement)
5
About Me
Vernon Stinebaker (史文林)http://www.linkedin.com/in/vernonstinebaker– Director of Technology/Principal Architect– 20+ years software development and process experience
• CMMI, SDLC/waterfall, and agile methodologies– Certified ScrumMaster/Certified Scrum Practitioner– 9+ years experience with Feature Driven Development– Founding member of the open source FDDTools project
6
Agile Manifesto
7
Agile Manifesto 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. 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-
organizing teams. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
8
First things first…
The most important contributor to the success of projects is…
People!
9
Scrum eXtreme Programming (XP) FDD DSDM Crystal Perficient’s Enable-M …
But they share the same objectives -- those described in the Agile Manifesto
No “one” Agile
10
Today’s Focus
XP
FDD
11
First let’s talk about
Scrum
12
Scrum
3 Roles– Product Owner– ScrumMaster– Team
3 Ceremonies– Sprint Planning– Daily Stand-up– Sprint Demo
3 Artifacts– Product Backlog– Sprint Backlog– Burn-down Charts
13
Scrum in one slide
Mountain Goat Software, LLC
Product Owner
Team
ScrumMaster
14
Scrum is…
Simple, but not easy!
15
Characteristics
Self-organizing teams Product progresses in a series of month-long
“sprints” Requirements are captured as items in a list of
“product backlog” No specific engineering practices prescribed Uses generative rules to create an agile
environment for delivering projects One of the “agile processes”
Mountain Goat Software, LLC
16
OMG! No specific engineering practices prescribed!
17
Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.
Rather than doing all of one thing at a time...
...Scrum teams do a little of everything all the time
Requirements Design Code Test
Sequential vs. overlapping development
Mountain Goat Software, LLC
18
So…
We still have to do– Requirements gathering– Design– Coding– Testing
But how?
19
I like XP!
20
XP Practices
eXtreme Programming describes engineering practices– On-site Customer– Metaphor– 40 Hour Week– Planning Game– Refactoring– Simple Design– Pair Programming– Testing– Short Releases– Coding Standards– Collective Ownership– Continuous Integration
21
Which practices have you implemented?
On-site Customer Metaphor 40 Hour Week Planning Game Refactoring Simple Design Pair Programming Testing Short Releases Coding Standards Collective Ownership Continuous Integration
22
What does the project process look like?
Is this simple? (Easy or not?) What happened to those practices?
23
Scrum doesn’t prescribe engineering practices.
XP is great! But are their alternatives?
24
Feature Driven Development
25
FDD in a slide
Simple?YES!!!
But not easy
26
The whole process in one slide
ETVX. Really simple. Not one book. One slide.– (Well, OK. 10 pages actually.)
FDD Process copyright Nebulon 2009
27
Develop an Overall Model
What’s this? Modeling?
Yes. Agile modeling!
28
Build a Feature List
User valued, user verifiable functionality <action><result><object>
– Calculate the total value of a sale.– Display the result of a translation.
29
Plan by Feature
Features must take less than two weeks– Can be much less
Features are collected into Work Packages – Which are released within two weeks
Resources are the only challenge to scalability– Used successfully on projects with team size of 500+ – An unlimited number of Work Packages may be under
simultaneous development
30
Design by Feature
More Design?– Conversations happen!– Inspection – bench testing (TDD?)– Communication is the second key to successful projects
People are the first!
31
Build by Feature
Class ownership Code inspection Unit Testing Promote to Build
32
What? Traditional Software Engineering Activities?
Design Inspections Testing Builds
Can you implement these?
33
What? Traditional roles?
Customer– SMEs
Project Manager Architect Chief Programmer Developers Testers
Easier for some organizations to accept
34
FDD is…
Evolutionary, not revolutionary Builds on software engineering best practices Makes sense to ‘traditional’ engineers and managers
Agile!
Simple. But not easy.
Can be used to complement Scrum by providing familiar and implementable engineering practices
35
Summary
Scrum doesn’t prescribe engineering practices– so we go looking elsewhere
XP provides engineering practices– But they’re eXtreme.
FDD provides engineering practices– Simple– Evolutionary, not revolutionary– Can augment Scrum with proven, best practice practices
(And can also be used on independently of Scrum)
36
Q&A
Thank you!