5. Software dev-methods comparison, Macadamian - Ani Karapetyan


Published on

Published in: Technology, Business
  • 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

5. Software dev-methods comparison, Macadamian - Ani Karapetyan

  1. 1. Confidential 10/7/2013 1 AGILE TOUR YEREVAN 05, October, 2013 Software development methods Ani Karapetyan Software Developer, PSM
  2. 2. • Ad-Hoc • Waterfall • Agile 2 Scope of the presentation
  3. 3. Preface  Software methodologies are concerned with the process of creating software - not so much the technical side but the organizational aspects.  This whole presentation is one big analogy.  Many of the concepts in software development are abstract and hard to grasp, but using a familiar real- world situation, like taking a taxi to the hotel, can clarify the ideas. 3
  4. 4. Ad-hoc  Historically, the first methodology was basically no methodology at all. This is generally called the "ad hoc" methodology.  We'll start with a simple scenario. You are to meet your friend Jim at the Station Hotel. You have no idea where that is but you jump in a cab and tell the taxi driver where you want to go. In this analogy you are the "customer" and the taxi driver is the "developer". 4
  5. 5. 5
  6. 6. Let’s Consider these variations  The ideal case: customer knows where he wants to go developer knows how to get there A few minutes later you arrive at your destination safely and without wasting any time! Unfortunately the real world is never this simple. 6
  7. 7. Problems  Taxi driver misheard you and you end up at the train station.  "Which one?“ There are three within a ten mile radius. 7
  8. 8. Problems  The destination is quite distant and you do not have enough money.  The taxi takes you straight to the hotel but it's closed for business. 8
  9. 9. Problems  Jim calls your mobile and says that he has gone to a different hotel. 9
  10. 10. Summary  If the customer knows exactly what they want and the developer knows how to give it to them and has the right tools to do so then there is a good chance of success.  The above scenarios represent several common problems seen in software development: miscommunication customer doesn't know exactly what they want changing requirements inexperienced developers 10
  11. 11. Waterfall  Let’s try to avoid all the mentioned problems  You find that you need an "analyst" to work out where you really want to go and a "designer" to provide detailed instructions on how to get there.  The essential point of the specification is to have the trip completely and thoroughly planned before starting out. But  While the analyst/designer is busy at work you (the customer) are getting a bit nervous. It's been some time and you still haven't gone anywhere. You want feedback that once you start the trip everything will stay on track. 11
  12. 12. Problems  The taxi driver has to read and understand the whole specification before starting out.  There are a few small ambiguities in the specification and taxi driver makes a wrong assumption. 12
  13. 13. Problems  Unexpected events that nobody could have anticipated - a major accident that causes traffic chaos or some roadwork.  Things that you (the customer) forgot to mention - you need to stop at the bank to get some cash on the way. 13
  14. 14. Problems  The taxi driver becomes annoyed and frustrated with the process. "Just tell me where you want to go!“ 14
  15. 15. Problems  The project estimate is one hour. But the taxi driver thinks it will take half that time (he knows a shortcut) and starts to take care of some personal business. In the end he makes a huge effort and only arrives 20 minutes late. 15
  16. 16. Problems  You contact Jim and arrange to meet him at a nearby hotel which is actually more convenient for both of you. This completely invalidates the specification. 16
  17. 17. Summary  The main problem with the waterfall approach is that it takes a lot of up front effort in planning, analysis and design.  The model can work if everything goes to plan, but in a complex project things rarely do. For example: 1. difficulty of understanding and following the spec 2. getting them right in the first place 3. process does not cope with change 4. process doesn’t make best use of developers(they may procrastinate at the start) 17
  18. 18. Agile  What if we could divide the project into a sequence of steps so that at each stage we can demonstrate that we are closer to the final product?  After each step we produce a working (but not final) product so that the customer can see that the project is on the right track. 18
  19. 19. Agile  For example, start our journey immediately by taking the main road into town. When we come to a point where there is uncertainty we stop to assess the position and choose the best path.  Further, by continually re-assessing we can adapt to any unforeseen and new developments. 19
  20. 20. Problems  The trip proceeds smoothly but when you get there you find that nobody else thinks it is the right place. Jim is not there but at another hotel. 20
  21. 21. Problems  The quickest way would have been the direct route but was not seen as the "right" way to do it.  There are two equally good ways to the destination, but they choose the worst possible way. 21
  22. 22. Summary  Advantages  Development team is happy since they are empowered not just to drive the taxi but to ensure that everything goes smoothly.  Customer is happy since he knows the driver is not lost and, even if he is late, he knows where he is and has a good idea when he will get there.  Disadvantages  Sometimes you can't evolve the existing software into what is really required.  Group decisions may not always be the best decisions. 22
  23. 23. 23
  24. 24. 24
  25. 25. 25
  26. 26. 26
  27. 27. However…. the secret of success mainly depends on the successful team building 27
  28. 28. Realize your role in the team 28
  29. 29. And you will definitely succeed !!!!!!! 29