Agile Engineering - ODU ACM


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Engineering - ODU ACM

  1. 1. Agile Development November 3rd, 2011 Justin F. Brunelle
  2. 2. Purpose• Introduction to Agile methodologies – Who what where when why• Introduction to SCRUM – Implementation of Agile in Sprints
  3. 3. Surprise!• Most programmers already implement agile engineering! – Rapid Prototyping – Cyclic development cycles – Stakeholder feedback – Ever-growing queue of requirements
  4. 4. Waterfall • Traditional Development • Incremental • Linear • What happens if you fail at Verification?
  5. 5. Daily Trivia• First presentation on Waterfall Model?• MITRE! – Development of SAGE (Semi-Automated Ground Environment) • Messages to bomber aircraft – 1950s
  6. 6. Goal of Agile Development• Continuous delivery of working software – Iterative – User feedback driven• Iterations produce releasable product• Goal is not speed!
  7. 7. Agile Approach• Adaptive, empirical process – Small repeating cycles – Short-term planning with constant feedback, inspection and adaptation• Fail-early lifecycle – Iterative development brings most of the risk and difficult work forward to the early part of a project
  8. 8. Agile Manifesto• Our highest priority is to satisfy the customer  Working software is the primary measure of through early and continuous delivery of progress. valuable software.• Welcome changing requirements, even late in  Agile processes promote sustainable development. development. Agile processes harness change for The sponsors, developers, and users should be the customers competitive advantage. able to maintain a constant pace indefinitely.• Deliver working software frequently, from a couple of weeks to a couple of months, with a  Continuous attention to technical excellence preference to the shorter timescale.• Business people and developers must work and good design enhances agility. together daily throughout the project.  Simplicity--the art of maximizing the amount• Build projects around motivated individuals. Give them the environment and support they of work not done--is essential. need, and trust them to get the job done.  The best architectures, requirements, and designs• The most efficient and effective method of conveying information to and within a emerge from self-organizing teams. development team is face-to-face conversation.  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  9. 9. User Role in Agile Plan Plan Plan Plan Assess Design Assess Design Assess Design Release Assess Design Test Code Test Code Test Code Test Code Shippable Plan Product Assess Design The User is involved in all aspects of the iteration – this helps ensure true user driven development Test Code9
  10. 10. What is “Done”?• At the end of every iteration, the only work that is declared “Done” is work that has gone through the proper engineering activities and could be used by Clients – Requirements – Code – Testing (unit, integration, user) – Stakeholder feedback
  11. 11. SCRUM• Type of Agile• Self-organizing teams• Product Backlog• Sprints• Releases/Retrospective• Rinse and repeat
  12. 12. SCRUMStoryboarding User Feedback Incorporated Into Product Backlog
  13. 13. Who SCRUMS?• Defined roles – Product Owner – Scrum Master – Scrum Team• No “Bus Person”
  14. 14. Product Owner• Define the features of the product• Decide on release date and content• Be responsible for the success of the product• Prioritize features according to market value• Adjust features and priority every iteration, as needed• Accept or reject work results
  15. 15. The ScrumMaster• Represents management to the project• Responsible for enacting Scrum values and practices• Removes impediments• Ensure that the team is fully functional and productive• Enable close cooperation across all roles and functions• Shield the team from external interferences
  16. 16. The Team• Typically 5-9 people• Cross-functional: – Programmers, testers, user experience designers, etc. • Everyone knows a little about a lot• Teams are self-organizing – Ideally, no titles but rarely a possibility
  17. 17. Storyboarding• Creation of user stories – Populates the backlog – Multiple backlog entries per story• Methods – Whiteboard – Photoshop – Layout “Straw-men” – Verbal Process
  18. 18. Backlog• The requirements expressed as user stories – [COUGH – CRC Cards – COUGH]• A list of all desired work• Prioritized by the product owner• Reprioritized at the start of each sprint• “I want the product to do X”
  19. 19. SCRUM Sprints• Scrum projects make progress in a series of “sprints”• 2–4 weeks• “Byte”-sized chunk of the project is designed, coded, and tested during the sprint – Normally: • Subset of backlog • 2-3 stories
  20. 20. Sprint Review Process• Review Process: – Demo Software • Entire team (remember the “Bus Person”) – Get Feedback – Update Backlog • Reprioritize • Entries not taken out until next sprint
  21. 21. Sprint Retrospective• Retrospective (15-30 min. mtg): – What went well? – What went wrong? – What will we do different?
  22. 22. “SCRUMmary”• Incremental• Iterative• Fail early• User involvement
  23. 23. Will it work for You?• Shouldn’t be a “Big Bang” – Phased implementation• Identify Roles• Create backlog• Determine sprint length• RUN!