Another Agile Intro
Download as KEY, PDF0 likes671 views
This document summarizes key aspects of agile software development processes. It discusses that software development involves managing risks, and that agile processes are designed to help manage risks that change rapidly, unlike traditional waterfall approaches. It outlines some common risks in software projects. It then provides a brief history of software development processes, from waterfall to more iterative agile methods. Finally, it summarizes some core values and practices of agile development, such as rapid delivery of working software, transparency, reducing waste, and continuous improvement through retrospectives.
Another Agile Intro
- 1. Agile
- 2. “Modern software systems are hard to build, because we’ve already built the easy ones” - Tom DeMarco
- 3. Software development processes are all about risk
- 4. Pure Waterfall Modified Waterfall Spiral Evolutionary Delivery Staged delivery Evolutionary Prototyping Design-to-schedule Commercial Off The Shelf Code and fix
- 5. People are risk management devices
- 7. What does this tell us?
- 8. We evolved to deal with risks that change rapidly
- 9. Software risks aren’t like that
- 10. Development Risks • Feature creep • Silver bullet syndrome • requirements or • Research Oriented developer gold plating development • Shortchanged quality • Weak personnel • Overly optimistic • Contractor failure schedules • Friction betwen • Inadequate design developers and customer “Rapid Development”, Steve McConnell
- 11. Development Risks • unrealistic schedules and budgets • failure to manage end user expectations • unclear or misunderstood scope/ • inadequate knowledge/skills objectives • misunderstanding the • lack of senior management requriements commitment to the project • continuous requirement changes • subcontracting • developing the wrong software • resource usage and performance functions • introduction of new technology • failure to gain user involvement • gold plating Unknown
- 12. Sources of failure • Lack of user • Lack of planning involvement • Absence of need • Lack of resources • Incomplete • Unrealistic expectations requirements • Lack of executive • Changing support requirements Standish CHAOS Report, 1995
- 13. What’s the biggest risk for your project?
- 14. Process History
- 16. Waterfall?
- 17. 1970 - Winston Royce “Managing the Development of Large Software Systems”
- 19. Adopted for commercial development
- 20. Worked ok
- 21. Biggest risk - cost of delivery
- 22. Requirements well defined by existing processes
- 23. But what did Royce build?
- 28. 1. Program Design Comes First
- 29. 2. Document the Design
- 30. 3. Do it Twice
- 31. 4. Plan, Control and Monitor Testing
- 32. 5. Involve the Customer
- 33. We see hints of something more than just waterfall
- 34. “If the effort runs 30 months then this early development of a pilot model might be scheduled for 10 months.”
- 35. “In this case a very special kind of broad competence is required on the part of the personnel involved. They must have an intuitive feel for analysis, coding, and program design. They must quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren't worth studying at this early point, and finally arrive at an error-free program.”
- 36. Fast forward - February 2001
- 39. Agile Methods
- 40. Scope, Time, Money, Quality
- 41. Quality is a highly non-linear control variable
- 42. Fix Quality!
- 43. Our biggest risk is uncertainty - embrace it!
- 44. Put a stake in the sand
- 45. Assume our guesses are roughly right, but they will need to change
- 46. Unity and Focus
- 47. One application, one team, one goal
- 48. Delivering the best application we can for the time and money available
- 49. Agile Values
- 50. Plenty of subtly different alternatives
- 51. Transparency Rapid Feedback Reduce Waste Be Adaptive
- 52. Waste Partially Done Hand-offs Work Delays Extra Features Defects Task Switching Relearning
- 53. Agile Practices
- 54. Some are from Scrum
- 55. Some are from Extreme Programming
- 56. Some are from Feature Driven Development
- 57. All are consistent with values
- 58. I won’t go into them all
- 59. Whole Team
- 60. Feature Team
- 62. Eliminate anything that doesn’t deliver value
- 63. Make sure everything relates to a need
- 64. Epics
- 65. User Stories
- 67. All Just-In-Time
- 69. Deliver Working Software
- 70. It’s not done until it does what the customer expected
- 71. It’s not done until it’s ready for production
- 72. Keep the cost of change low
- 73. Automated tests
- 74. Unit tests
- 75. Functional Tests
- 78. Pair programming
- 80. It can be fun
- 82. Be prepared to learn
- 83. About the problem domain
- 84. About the technical solution
- 85. New skills
- 86. Differentiate on skill and knowledge, not on title
- 87. Be prepared to step outside your role
- 88. Feedback on technical performance
- 91. Duplication
- 92. Builds need to be FAST
- 93. Rapid testability is a constraint, not an option
- 94. Architectures and tools will need to adapt too
- 95. Learn TDD
- 97. Learn to write as little as possible
- 98. Learn to answer questions without certainty
- 99. Share
- 100. Standup meetings are mandatory
- 101. Err on the side of sharing too much
- 102. Big Visible Charts
- 104. Collaborate
- 105. We succeed or fail as a team
- 106. Reflect
- 108. Change practices and tools
- 109. Don’t be afraid to experiment
- 110. But know when to stop
- 111. Understand what you’re trying to get better AT
- 112. Escalate
- 113. Ask politely and reasonably
- 114. Set expectations
- 115. Don’t be afraid
- 116. Don’t wait
- 117. Change
- 119. Forming Storming Performing Norming
- 120. Will try to keep teams intact
- 121. “If members of a team don’t care about each other and what they are doing, XP is doomed” Kent Beck
- 122. Deliver a minimal viable system asap then extend it
- 123. http://electsp.blogspot.com http://sites.google.com/site/ agileplanning/ steve.hayes@cogentconsultin g.com.au
- 124. Question Time