Agile Engineering - ODU ACM

Agile Development November 3rd, 2011 Justin F. Brunelle

Purpose• Introduction to Agile methodologies – Who what where when why• Introduction to SCRUM – Implementation of Agile in Sprints

Surprise!• Most programmers already implement agile engineering! – Rapid Prototyping – Cyclic development cycles – Stakeholder feedback – Ever-growing queue of requirements

Waterfall • Traditional Development • Incremental • Linear • What happens if you fail at Verification?http://en.wikipedia.org/wiki/File:Waterfall_model_%281%29.svg

Daily Trivia• First presentation on Waterfall Model?• MITRE! – Development of SAGE (Semi-Automated Ground Environment) • Messages to bomber aircraft – 1950s

Goal of Agile Development• Continuous delivery of working software – Iterative – User feedback driven• Iterations produce releasable product• Goal is not speed!

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

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.

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

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

SCRUM• Type of Agile• Self-organizing teams• Product Backlog• Sprints• Releases/Retrospective• Rinse and repeat

SCRUMStoryboarding User Feedback Incorporated Into Product Backlog

Who SCRUMS?• Defined roles – Product Owner – Scrum Master – Scrum Team• No “Bus Person”

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

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

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

Storyboarding• Creation of user stories – Populates the backlog – Multiple backlog entries per story• Methods – Whiteboard – Photoshop – Layout “Straw-men” – Verbal Process

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”

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

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

Sprint Retrospective• Retrospective (15-30 min. mtg): – What went well? – What went wrong? – What will we do different?

“SCRUMmary”• Incremental• Iterative• Fail early• User involvement

Will it work for You?• Shouldn’t be a “Big Bang” – Phased implementation• Identify Roles• Create backlog• Determine sprint length• RUN!

http://ws-dl.blogspot.com	69
http://ws-dl.blogspot.in	1
http://ws-dl.blogspot.se	1

Agile Engineering - ODU ACM

by Justin Brunelle on Nov 04, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 71

Statistics

Agile Engineering - ODU ACM — Presentation Transcript