Agile development

386 views

Published on

Published in: Education, Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
386
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
22
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Agile development

  1. 1. Agile Development
  2. 2. We want to build software,but how do we go about doing that?
  3. 3. Waterfall Development
  4. 4. Waterfall Development• This is the way industrial engineers builtconcrete items. It works great.• We want to build software, and this is aterrible idea.
  5. 5. Waterfall Development{side story about the USPS}
  6. 6. The average software project fails; therefore,we must strive for excellence.*
  7. 7. The average software project fails; therefore,we must strive for excellence.*-paraphrased from Chef Gordon Ramsay talking about restaurants
  8. 8. What is Agile?Agile manifestoProposed by Kent Beck, Martin Fowler, et al.
  9. 9. What is Agile?Agile manifestoIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
  10. 10. What is Agile?Agile manifestoIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThere is value in the items on the right, butmore value in the item on the left.
  11. 11. What is Agile?Various methodologies:• Scrum• eXtreme Programming (XP)• Lean
  12. 12. Customer satisfaction by rapid delivery of usefulsoftware
  13. 13. Customer satisfaction by rapid delivery of usefulsoftwareRapid delivery means weeks – not months.Useful software means a noticeable difference.
  14. 14. Welcome changing requirements, even late indevelopment.
  15. 15. Welcome changing requirements, even late indevelopment.
  16. 16. Welcome changing requirements, even late indevelopmentRequirements change b/c:Business needs changeUnderstanding changes (yours & theirs)Problems solve themselves or require a new approachCompetitors pop-up
  17. 17. Welcome changing requirements, even late indevelopmentWhen requirements or understandingchanges, you are free to re-estimate timerestraints and put the feature off for anotheriteration.
  18. 18. Working software is delivered frequently (weeksrather than months)
  19. 19. Working software is delivered frequently (weeksrather than months)Notice the word “working.” If you rolloutweekly, you’ll quickly learn to test early andoften rather than putting it off.
  20. 20. Working software is delivered frequently (weeksrather than months)In order to achieve weekly releases, you mustbreak large problems into smaller problems.You also focus on the really important problems.
  21. 21. Working software is the principal measure ofprogress
  22. 22. Working software is the principal measure ofprogress.Users can see and understand working software.They can also see what isn’t working. There isno better metric.
  23. 23. Working software is the principal measure ofprogress.“Almost done” is useless for the customer.
  24. 24. Sustainable development, able to maintain aconstant pace.
  25. 25. Sustainable development, able to maintain aconstant pace.Burnout is a real concern amongst developers.Limit overtime work.
  26. 26. Close, daily cooperation between businesspeople and developers.
  27. 27. Close, daily cooperation between businesspeople and developers.Even if it’s just 5 minutes, daily talks are critical.You don’t want to build excess software.
  28. 28. Face-to-face conversation is the best form ofcommunication (co-location).
  29. 29. Face-to-face conversation is the best form ofcommunication (co-location).Let’s face it, face-to-face is best. You can readmannerisms and tone of voice. You need thefeedback.
  30. 30. Projects are built around motivatedindividuals, who should be trusted.
  31. 31. Projects are built around motivated individuals,who should be trusted.If you can’t trust them, they shouldn’t beworking with you.
  32. 32. Projects are built around motivatedindividuals, who should be trusted.“Oh, Larry is working on it? You’ll have to makehim do it.”
  33. 33. Continuous attention to technical excellence andgood design.
  34. 34. Continuous attention to technical excellence andgood design.Shortcuts will destroy you. I spent 3 weeksbuilding a “shortcut” that should have taken 3days. Now I have bad software that took longerto deliver.
  35. 35. Continuous attention to technical excellence andgood design.Use design patterns (where appropriate), takeadvantage of the language’s features, etc.
  36. 36. Simplicity—the art of maximizing the amount ofwork not done—is essential
  37. 37. Simplicity—the art of maximizing the amount ofwork not done—is essential.Plans change, understanding changes, andsimple things are easier to test.Quit building things that you won’t need.
  38. 38. Self-organizing teams
  39. 39. Self-organizing teamsA “team” isn’t just a group of people with acommon assignment. They should have acommon spirit and exercise individuals’strengths.A good team “jells” well.-Peopleware
  40. 40. Self-organizing teamsA self-organized team requires no job titles. Jobfunctions overlap, and everyone just falls intoplace.
  41. 41. Self-organizing teamsA self-organized team requires no job titles. Jobfunctions overlap, and everyone just falls intoplace.They look for work rather than wait for it to beassigned.
  42. 42. Regular adaptation to changing circumstances.
  43. 43. Regular adaptation to changing circumstances.Things will change:requirementsteam membersleadership/directionfunding
  44. 44. How do I start implementing agile?Agile development should make things easier.Slowly implement techniques starting with yourown work. Then move it out to the team.
  45. 45. How do I start implementing agile?• Get “buy-in” from the user (customer, anotherdepartment, whoever).• Testing (TDD).• Version control (git, subversion).• Break the large problems into small problemsand rank let the customer rank them withpriority.
  46. 46. How do I start implementing agile?Get “buy-in” from the userMeet with the a user, pick a smallfeature, implement it in a week or two. Do itagain.
  47. 47. How do I start implementing agile?Test:unit testsregression testsacceptance tests
  48. 48. How do I start implementing agile?Version control:Use git, mercurial, subversion, etc.
  49. 49. How do I start implementing agile?Break the large problems into small problemsand rank them with priority.Sit with the user and break feature requests intosmaller requests, make time estimates, and letthe user rank them with priority.
  50. 50. Wrap Up
  51. 51. Books on Agile
  52. 52. Thanks!Name: David HaskinsConnect with me on LinkedIn: davidhaskins@ieee.org

×