Agile Software Development Overview

945 views
871 views

Published on

Agile Software Development Overview

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
945
On SlideShare
0
From Embeds
0
Number of Embeds
188
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agile Software Development Overview

  1. 1. Agile Software Development Overview Sunil Kumar | 18-04-08 | London www.exploreagile.blogspot.com
  2. 2. Agenda <ul><ul><li>What is Agile Software Development? </li></ul></ul><ul><ul><ul><li>Introduction </li></ul></ul></ul><ul><ul><ul><li>Waterfall model Vs. Agile </li></ul></ul></ul><ul><ul><ul><li>Agile Principle </li></ul></ul></ul><ul><ul><li>Elsevier Agile Development Process </li></ul></ul><ul><ul><li>Extreme Programming. </li></ul></ul><ul><ul><li>Questions. </li></ul></ul>
  3. 3. What is Agile Software Development?    Introduction <ul><li>                                                               </li></ul>
  4. 4. Introduction <ul><ul><li>A new software development methodology </li></ul></ul><ul><ul><li>Faster software development </li></ul></ul><ul><ul><li>Ability to react to changing situations </li></ul></ul><ul><li>      quickly, appropriately, and effectively. </li></ul><ul><li>&quot;Agile is about being open about what we’re capable of doing, and then doing it&quot; – Kent Beck </li></ul>
  5. 5. Waterfall Vs. Agile
  6. 6. Waterfall Vs. Agile <ul><li>  Waterfall: </li></ul><ul><ul><li>collect and document all of the system requirements </li></ul></ul><ul><ul><li>produce a set of design documents </li></ul></ul><ul><ul><li>write code that implements the pieces specified in the design </li></ul></ul><ul><ul><li>integrate all of the pieces and test to make sure the system satisfies the requirements </li></ul></ul><ul><ul><li>package the system and ship to the customer </li></ul></ul>
  7. 7.   Waterfall Vs. Agile <ul><li>  Agile: </li></ul><ul><ul><li>analyze a little, </li></ul></ul><ul><ul><li>design a little, </li></ul></ul><ul><ul><li>  code a little </li></ul></ul><ul><ul><li>spiral process or iterative </li></ul></ul><ul><ul><li>more difficult to manage, hard to know when you are “done” </li></ul></ul><ul><ul><li>you get to deliver early versions of the most important features, get customer feedback quickly </li></ul></ul><ul><ul><li>you can get by with less documentation </li></ul></ul><ul><ul><li>it is easier to react to customer changes </li></ul></ul>
  8. 8. Agile Principles
  9. 9.   Agile Principles <ul><li>1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan </li></ul><ul><li>http://agilemanifesto.org/ </li></ul>
  10. 10. Elsevier Agile Software Development
  11. 11.   Model Type <ul><ul><li>XP based weekly iterative Agile development model </li></ul></ul>
  12. 12. Different parties involved in the process. <ul><ul><li>Customer Team( Product manager, Business Analyst) </li></ul></ul><ul><ul><li>UCD Team (User Centre Design) </li></ul></ul><ul><ul><li>Development Team </li></ul></ul><ul><ul><li>QA(Quality Analyst) </li></ul></ul><ul><ul><li>Project Manager, Iteration Manager </li></ul></ul><ul><ul><li>Shared Team ( Architecture team, content team and GWS) </li></ul></ul><ul><ul><li>Various management stack holders ( e.g. sales team) </li></ul></ul>
  13. 13.   Elsevier Agile Software Development -Principles <ul><ul><li>Communication </li></ul></ul><ul><ul><li>Simplicity </li></ul></ul><ul><ul><li>Courage </li></ul></ul><ul><ul><li>Feedback (e.g. Developer measures) </li></ul></ul><ul><ul><li>Respect </li></ul></ul>
  14. 14.   Product Owner <ul><ul><li>Decide on the project vision </li></ul></ul><ul><ul><li>continuously make decisions on the product priorities </li></ul></ul><ul><ul><li>Build product that delivers business value early and continuously </li></ul></ul>
  15. 15. Project Manager <ul><ul><li>PMs are responsible for the successful delivery of a project </li></ul></ul><ul><ul><li>Project forecasting and budgeting, </li></ul></ul><ul><ul><li>Project resource planning and </li></ul></ul><ul><ul><li>Project scheduling (Release Planning) </li></ul></ul>
  16. 16.   Business Analyst <ul><ul><li>A facilitator;   act as a communications bridge between product owner/UCD and development team, as well as between the business and technology. </li></ul></ul><ul><ul><li>He is a bit technical as well. </li></ul></ul><ul><ul><li>Convert requirements into Stories. </li></ul></ul><ul><ul><li>Finally sign it off. </li></ul></ul>
  17. 17.   UCD <ul><ul><li>Prototype preparation </li></ul></ul><ul><ul><li>UI preparation for stories </li></ul></ul><ul><ul><li>Provides CSS, Page structure </li></ul></ul>
  18. 18. Iteration Manager <ul><ul><li>IM facilitate iteration planning sessions, </li></ul></ul><ul><ul><li>Track progress throughout the course of an iteration, </li></ul></ul><ul><ul><li>Facilitate effective interaction within the team as well as with other teams, </li></ul></ul><ul><ul><li>Report on iteration status  </li></ul></ul><ul><li>       and work to remove        impediments to development        team productivity </li></ul>
  19. 19. Developer <ul><ul><li>Developers are experienced software development professionals able to write code in the language(s) required by the project </li></ul></ul><ul><ul><li>Developers will pair together, so they must also have good communication and team skills. </li></ul></ul>
  20. 20. Lead Developer <ul><ul><li>Lead Developers set the technical direction on a day-to-day basis, within the guidelines set out by the architect </li></ul></ul><ul><ul><li>A Lead Developer may also provide high level estimates on stories for the purposes of release planning when it is not practical to have the whole team doing estimating as would happen at an Iteration Planning Meeting. </li></ul></ul>
  21. 21.   Quality Analyst <ul><ul><li>QA team ensure that the whole application is bug free and meets the requirements. </li></ul></ul><ul><ul><li>The QA therefore works with the Product Manager and the Analyst to specify the story. </li></ul></ul><ul><ul><li>  when each story has been </li></ul></ul><ul><li>        implemented they verify        that those tests execute        against the application </li></ul><ul><ul><li>They also look at higher level </li></ul></ul><ul><li>       testing such as integration,        system, performance and       user acceptance testing </li></ul>
  22. 22.   Extreme Programming
  23. 23.   Some Rules Of Extreme Programming <ul><li>Planning rules </li></ul><ul><ul><li>do project planning via “user stories” </li></ul></ul><ul><ul><li>plan a series of very small internal releases </li></ul></ul><ul><ul><li>start each day with a “stand-up meeting” </li></ul></ul><ul><li>Design rules </li></ul><ul><ul><li>keep the design simple (use the simplest thing that could work) </li></ul></ul><ul><ul><li>refactor as needed </li></ul></ul><ul><li>Coding rules </li></ul><ul><ul><li>talk with the customer throughout the coding process </li></ul></ul><ul><ul><li>always code in pairs </li></ul></ul><ul><ul><li>code unit tests first </li></ul></ul><ul><ul><li>follow coding standards </li></ul></ul><ul><li>Testing rules </li></ul><ul><ul><li>unit tests for all code </li></ul></ul><ul><ul><li>acceptance tests for each user story </li></ul></ul>
  24. 24. Questions

×