Agile Engineering Practices
Upcoming SlideShare
Loading in...5

Agile Engineering Practices



Agile engineering practices from XP and FDD focusing on FDD. (Based on cultural challenges that XP faces.)

Agile engineering practices from XP and FDD focusing on FDD. (Based on cultural challenges that XP faces.)



Total Views
Views on SlideShare
Embed Views



3 Embeds 34 22 9 3



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Agile Engineering Practices Agile Engineering Practices Presentation Transcript

  • Agile Engineering Practices Hangzhou Scrum Forum 2009 May 2009
  • Agenda
    • Ground rules
    • Purpose and expected outcomes
    • About the presenter
    • Agile – concepts and methodologies
    • Agile and Engineering Practices
      • Scrum
      • XP
      • FDD
  • Ground Rules
    • Mute your cell phone
    • Participate – ask and answer questions
    Do Don’t View slide
  • 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)
    View slide
  • About Me
    • Vernon Stinebaker ( 史文林)
      • 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
  • Agile Manifesto
  • 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.
  • First things first…
    • The most important contributor to the success of projects is…
    • People!
    • 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
  • Today’s Focus
    • XP
    • FDD
  • First let’s talk about
    • Scrum
  • 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
  • Scrum in one slide Mountain Goat Software, LLC Product Owner Team ScrumMaster
  • Scrum is…
    • Simple, but not easy!
  • 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
    • OMG! No specific engineering practices prescribed!
  • Sequential vs. overlapping development 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 Mountain Goat Software, LLC
  • So…
    • We still have to do
      • Requirements gathering
      • Design
      • Coding
      • Testing
    • But how?
    • I like XP!
  • 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
  • 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
  • What does the project process look like?
    • Is this simple? (Easy or not?)
    • What happened to those practices?
    • Scrum doesn’t prescribe engineering practices.
    • XP is great! But are their alternatives?
    • Feature Driven Development
  • FDD in a slide
    • Simple?
    • YES!!!
    • But not easy 
  • The whole process in one slide
    • ETVX. Really simple. Not one book. One slide.
      • (Well, OK. 10 pages actually.)
    FDD Process copyright Nebulon 2009
  • Develop an Overall Model
    • What’s this? Modeling?
    • Yes. Agile modeling!
  • 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.
  • 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
  • Design by Feature
    • More Design?
      • Conversations happen!
      • Inspection – bench testing (TDD?)
      • Communication is the second key to successful projects
    • People are the first!
  • Build by Feature
    • Class ownership
    • Code inspection
    • Unit Testing
    • Promote to Build
  • What? Traditional Software Engineering Activities?
    • Design
    • Inspections
    • Testing
    • Builds
    • Can you implement these?
  • What? Traditional roles?
    • Customer
      • SMEs
    • Project Manager
    • Architect
    • Chief Programmer
    • Developers
    • Testers
    • Easier for some organizations to accept
  • 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
  • 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)
  • Q&A
    • Thank you!