Agile Engineering Practices
Download as PPT, PDF18 likes9,586 views
The document outlines a presentation on agile engineering practices delivered by Vernon Stinebaker at the Hangzhou Scrum Forum in May 2009. It discusses key agile principles, various methodologies including Scrum, Extreme Programming (XP), and Feature Driven Development (FDD), highlighting their roles in software engineering. The presenter emphasizes the importance of people, communication, and adaptable practices for effective project management and delivery.
Agile Engineering Practices
- 1. Agile Engineering Practices Hangzhou 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
- 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. 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
- 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?
- 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!