What is agile


Published on

Family of methodologies that advocate “lightweight” and “human” software development processes

Published in: Technology
1 Like
  • Be the first to comment

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

No notes for slide

What is agile

  1. 1. What is Agile?Introduction to Agile Software Development
  2. 2. How Projects Really Work
  3. 3. How the customer explained it
  4. 4. How the project leader understood it
  5. 5. How the analyst designed it
  6. 6. How the programmer wrote it
  7. 7. How the business consultant described it
  8. 8. How the project was documented
  9. 9. How much the project cost
  10. 10. What the customer really needed
  11. 11. Agenda What is Agile? Agile Manifesto Benefits Values Selected Practices Agile at Orange & Bronze
  12. 12. What is Agile? Family of methodologies that advocate “lightweight” and “human” software development processes Extreme Programming (XP), Scrum, Kanban, Lean, Crystal, Agile Unified Process... Coined in 2001 by the creators of similar methodologies reacting to “heavyweight” methodologies “heavyweight”: too much work
  13. 13. What is Agile? Emphasis on... Customer satisfaction Job satisfaction Remove things that do not contribute to above Culture Values and attitude of people involved are just as important as processes
  14. 14. The Agile ManifestoWe are uncovering better ways of developing softwareby doing it and helping others do it. Through this workwe have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a planThat is, while there is value in the items on the right, wevalue the items on the left more.
  15. 15. BenefitsStudies show... Improved customer satisfaction Higher quality Better predictability Improved employee retention Higher job satisfaction Mainstream acceptance Your clients are probably adopting agile
  16. 16. Values Communication Simplicity Feedback Courage Respect
  17. 17. Communication Goal is shared view Documentation should have a purpose Face-to-face is preferred Common work area Cubicles discouraged
  18. 18. Simplicity YAGNI – You Aint Gonna Need It Dont overcomplicate with what might be needed in the future. Things may will change. Use simplest possible solution Design, code, documentation, tools, etc Improves communication
  19. 19. Feedback From System Automated tests and continuous integration From Customer Acceptance tests and frequent interactions From Team Team communicates estimates and issues with customer and among themselves Feedback becomes input to project leading to continuous improvement
  20. 20. Courage Find and discuss problems early Especially with client Say when you need help Change and experiment to continuously improve New requirements Refactoring New processes and practices New technologies and tools
  21. 21. Respect Dont commit broken code Keep automated tests running Dont delay the work of others Maintain quality and communication Keep teammates motivated
  22. 22. Selected PracticesTo be discussed: Others: Whole Team Continuous Integration Customer/Developer Stand-Up Meetings Roles Self-Managed Teams Short Iterations Pair Programming Test-Driven Refactoring Development User Stories Planning Planning Boards Tracking Burn-Down Charts Sustainable Pace Retrospectives Collective Code
  23. 23. Whole Team Everyone involved should feel part of one team, including customer Often requires educating customer Everyone should be easily accessible for questions and other impromptu communication Common work area where possible, frequent meetings where not Shared access to resources Common repository, issue tracker, etc Focus People ideally should have only one project at a time
  24. 24. Customer/Developer Roles Customer Developer Developer Customer
  25. 25. Short IterationsWhats the problem with“Waterfall”? Mistakes are hard to find in early stages Difficult to validate Change becomes more expensive in later stages
  26. 26. Short IterationsReality... Customers dont know what they want until they see it Developers dont know how hard a problem is until they start Business needs change
  27. 27. Short Iterations Evolutionary approach Each iteration is complete development cycle Analysis, Design, Implementation, Testing, and sometimes incremental Deployment Output is working, usable software! Demo session held with customer at end of iteration gain feedback adjust plans for succeeding iterations 1 – 3 weeks
  28. 28. Test-Driven Development Tests are central to development process Types Unit Tests: method and class level Integration Tests: between classes, components and other systems Acceptance Tests: customer requirements defined as tests Tests are automated where possible Unit, Integration – always
  29. 29. Test-Driven Development Tests are unambiguous requirements specifications Avoid misunderstandings by defining requirements as acceptance tests! Unit tests cut the time spent finding bugs Fixing a bug is usually easy, finding it is a nightmare! Unit tests shape design Components are decoupled, interfaces well-thoughtTests are written before and during implementation
  30. 30. Planning1. Customers define and prioritize requirements Often as “user stories” - lightweight use cases2. Dev team collectively estimates cost of each requirement Assign “points” to each3. Customers review requirements against cost and may re-prioritize4. Dev team distributes requirements across iterations, according to estimated team “velocity” Higher priority requirements go to earlier iterations
  31. 31. Tracking Dev team tracks progress each day, usually via “burn down chart”
  32. 32. Tracking If dev team sees that iteration schedule will not be met, they inform customer immediately Too much work – inform customer which requirements will not be delivered at iteration ind Too little work – request more work from customer or pull from “backlog” Iteration end date does not move. Only workload changes.
  33. 33. Sustainable Pace Studies show that productivity drops when developers work long hours for extended periods Overtime should be controlled and avoided where possible Communication and courage with customer is important Track velocity and inform customer early if expected schedules will not be met Use experience as input for future schedules, ask customer to review and re-prioritize requirements
  34. 34. Agile at Orange & Bronze Been doing Agile since its foundation in 2005 Before it became mainstream Weve tried different methodologies and practices XP, Scrum, Kanban Not all practices work in all conditions The first to offer training in Agile methodologies and practices Scrum, TDD, Agile Business Analysis, Agile QA, etc Trainers are seasoned practictioners
  35. 35. Open Workspaces
  36. 36. Planning Board
  37. 37. Online Charts
  38. 38. Domain Design
  39. 39. Agile Training (internal)
  40. 40. For our Agile and Java training courses, go to:http://orangeandbronze.com/course-offerings