Agile methods

6,749 views

Published on

A brief introduction to agile software development

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

No Downloads
Views
Total views
6,749
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
589
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • film
  • A research and reflection of SomeBody:We are living in chaos: eco crisis, tech boom, changes …
  • How to create a software from scratch?
  • Parties:UsersHas problems to be solvedUsually disorganized, chaotic, groupCustomersProvides requirements and validationShould speak with “one voice”Developers Actually builds the stuff Lots of different roles hereBusiness Owner Manages resources and money Often ignored in Development Process…Tech concernsRequirementsDetermine What the Software has to do…Challenge: Satisfy the UsersProduction Actually Build the Software Challenge: Deliver Quality ProductMaintenance Modify Software to satisfy new requirements Challenge: Maintain Quality
  • For reference and printing if needed, not for presenting
  • Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. pp. 55–57. ISBN 0-321-18612-5.
  • Inherit from RAD
  • Film firstVẽrađồhình Scrum3 PhútBạnnàocóthểgiúptôicắtnghĩatừ framework nhỉ? “độtnhiêntôithấybítừ”Kháiniệmkhunglàmviệc (framework) làgì?Tạisaokhônggọi Scrum làquytrình?
  • Cross the mountainTraditional managers => ScrumMaster
  • cross-functional = there is no strict role for individualsCode are collectively developed
  • The importance of planning, not plan documentThe importance of responsibility -> select itemsThe importance of prioritizing -> reduce risksMake things clear
  • Image , point to position
  • Sutherland
  • Architectural spike():very simple program to explore potential solutions, Most spikes are not good enough to keepMetaphor(an du): common vision of how the program works
  • Courage(kien quyet)
  • Introduced in XP
  • SCM: svn,cvs, gitAutomated Build:Ant, Maven, MSBuild or IBM Rational Build ForgeAutomated tools: CruiseControl, Jenkins, Hudson
  • Introduced in XP
  • What does it mean?
  • Agile methods

    1. 1. Agile Methods<br />A brief guide to agile software development<br />Duong Trong Tan<br />tandt@fpt.edu.vn<br />HCM city, 9- 2011<br />
    2. 2. Objectives<br />Software Engineering history & agile<br />What is agile development?<br />The Agile Manifesto<br />The diversity of methods<br />Scrum<br />XP<br />RAD<br />TDD<br />Crystal<br />Kanban<br />Agile mashup<br />The cooperative game<br />A brief introduction to Agile Software Development<br />2<br />
    3. 3. Agile Basics<br />“Agile projects succeed when the team gets the spirit of agility.” – Ron Jeffries<br />A brief introduction to Agile Software Development<br />3<br />Image courtesy of Pollyanna Pixton<br />
    4. 4. A brief introduction to Agile Software Development<br />4<br />Continuous improvement<br />Hyper productive<br />Kaizen<br />Agile<br />Small teams<br />Buzzwords<br />Incremental<br />Lean<br />Changes<br />Earned Value Based<br />Iterative<br />Rapid<br />Adaptive<br />
    5. 5. History<br />A brief introduction to Agile Software Development<br />5<br />SE<br />Scrum<br />Weinberg: psychology of computer program<br />Declaration of Independence<br />deMarco: Peopleware<br />XP<br />2005<br />2011<br />2001<br />1970<br />1980<br />1995<br />1990<br />AgileAlliance.org<br />1968<br />Gilb: Principles of Software Engineering<br />Royce: managing the development of large software systems<br />PMI developed agile certifications<br />RAD<br />DSDM<br />
    6. 6. A brief introduction to Agile Software Development<br />6<br />So, what are software projects?<br />
    7. 7. Partiesand Concerns<br />Users?<br />Customers?<br />BO?<br />Developers?<br />A brief introduction to Agile Software Development<br />7<br />
    8. 8. A brief introduction to Agile Software Development<br />8<br />What is agile development?<br />
    9. 9. The Agile Manifesto <br />We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:<br />Individuals and interactions over processes and tools<br />Working software over comprehensive documentation<br />Customer collaboration over contract negotiation<br />Responding to change over following a plan<br />A brief introduction to Agile Software Development<br />9<br />That is, while there is value in the items on the right, we value the items on the left more.<br />AgileAlliance.org<br />
    10. 10. The Twelve Principles of Agile Software <br />Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.<br />Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.<br />Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.<br />Business people and developers must work together daily throughout the project.<br />Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.<br />The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.<br />Working software is the primary measure of progress.<br />Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.<br />Continuous attention to technical excellence and good design enhances agility.<br />Simplicity--the art of maximizing the amount of work not done--is essential.<br />The best architectures, requirements, and designs emerge from self-organizing teams.<br />At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.<br />A brief introduction to Agile Software Development<br />10<br />AgileAlliance.org<br />
    11. 11. Home ground comparison<br />A brief introduction to Agile Software Development<br />11<br />
    12. 12. The diversity of methods<br />A brief introduction to Agile Software Development<br />12<br />
    13. 13. Rapid Application Development<br />One of the earliest method<br />A strategy instead of comprehensive process<br />Utilizing of Prototyping<br />“VB – Access Method”<br />Still useful, esp. prototyping technique<br />A brief introduction to Agile Software Development<br />13<br />
    14. 14. Prototyping<br />Early visibility of the prototype gives users an idea of what the final system looks like<br />Encourages active participation among users and producer<br />Increases system development speed (in RAD)<br />Steps:<br />Identify basic requirements<br />Develop Initial Prototype<br />Review<br />Revise and Enhance the Prototype<br />14<br />A brief introduction to Agile Software Development<br />
    15. 15. Scrum<br />A hyper-productive development model<br />A brief introduction to Agile Software Development<br />15<br />
    16. 16. Scrum<br />One of the most successful agile methods because of its hyper-productivity<br />It is management – oriented<br />Somewhat CMM Level 3 equivalence<br />Widely used in various types of projects<br />Google AdWorlds project<br />3M<br />Universities RnD projects<br />In VN: LogiGear, KPM, FSOFT, FAT, etc.<br />A brief introduction to Agile Software Development<br />16<br />
    17. 17. Scrum Framework<br />A brief introduction to Agile Software Development<br />17<br />Scrum Team<br />Rules<br />Rules<br />Scrum<br />Transparency<br />Inspection<br />Adaption<br />Artifacts<br />Scrum Events<br />Rules<br />
    18. 18. A brief introduction to Agile Software Development<br />18<br />Image courtesy of ScrumAlliance<br />
    19. 19. Scrum Roles<br />Scrum Master<br />Product Owner<br />Development Team<br />Other parties (all kinds of ‘chicken’)<br />A brief introduction to Agile Software Development<br />19<br />
    20. 20. Transition of roles<br />Project Manager<br />Tester<br />Developer<br />System Designer<br />QA<br />Graphic Designer<br />A brief introduction to Agile Software Development<br />20<br />Cross-functional Scrum Team<br />
    21. 21. Management Transformation<br />21<br /><ul><li>Managers tell people what to do and make sure they do it properly
    22. 22. Managers maintain the right to authorize decision
    23. 23. Managers limit the information or resources available to workers
    24. 24. People decide what, and how to do
    25. 25. Team makes decisions
    26. 26. Information is transparent</li></ul>TO<br />A brief introduction to Agile Software Development<br />
    27. 27. Transition of organization<br />Self-directed Team<br />Multi-functional Team<br />A brief introduction to Agile Software Development<br />22<br />Customer-driven<br />Multi-skilled workforce<br />Few job descriptions<br />Information widely shared<br />Few levels of management<br />Whole-business focus<br />Shared goals<br />Seemingly chaotic<br />Purpose achievement emphasis<br />High worker commitment<br />Continuous Improvements<br />Self-controlled<br />Values/Principles based<br />Management-driven<br />Workforce of isolated specialists<br />Many job descriptions<br />Information limited<br />Many levels of management<br />Function/Department focus<br />Segregated goals<br />Seemingly organized<br />Problem-solving emphasis<br />High management commitment<br />Incremental Improvements<br />Management-controlled<br />Policy/Procedure based<br />
    28. 28. Development Team<br />Team is cross-functional and consists of 5-9 people<br />There are no set project roles within the team<br />Team defines tasks and assignments<br />Team is self-organizing and self-managing<br />Maintains the Sprint Backlog<br />Conducts the Sprint Review<br />A brief introduction to Agile Software Development<br />23<br />
    29. 29. ScrumMaster<br />Holds Daily Scrum meeting<br />Assures every people related to the project follow the Scrum rules<br />Removes obstacles<br />Shields the team from external interference: “Keep Chickens away from Pigs”<br />Conducts Sprint Retrospective at the end of a Sprint<br />Is a facilitator, not a manager<br />A brief introduction to Agile Software Development<br />24<br />
    30. 30. Product Owner (PO)<br />Accountable for product success<br />Defines all product features<br />Responsible for ordering product features<br />Maintains the Product Backlog<br />Insures team working on highest valued features<br />A brief introduction to Agile Software Development<br />25<br />
    31. 31. Product Backlog<br />List of all desired product features<br />List can contain bugs, and non-functional items<br />Product Owner responsible for ordering the items<br />Items can be added by anyone at anytime<br />Each item should have a business value assigned<br />Maintained by the Product Owner<br />A brief introduction to Agile Software Development<br />26<br />
    32. 32. Examples of Product Backlog<br />A brief introduction to Agile Software Development<br />27<br />
    33. 33. A Sprint<br />Time box: 2-4 weeks (why?)<br />An iteration for building a piece of increment (potentially shippable) of the whole system<br />It’s the working time, not planning or asking what to do.<br />The team manages itself during a Sprint<br />The team commits to Product Backlog during the Sprint planning meeting<br />The Sprint Backlog is updated during a Sprint<br />A brief introduction to Agile Software Development<br />28<br />
    34. 34. Sprint Backlog<br />A brief introduction to Agile Software Development<br />29<br />Each item is prioritized and estimated<br />
    35. 35. A brief introduction to Agile Software Development<br />30<br />The Scrum Skeleton<br />2.Daily Scrum Meeting<br /><ul><li> What have you done?
    36. 36. What will you do?
    37. 37. What is impeding you?</li></ul>3. A Sprint (2-4 weeks)<br />4. Sprint Review Meeting<br />1. Sprint Planning Meeting<br />5. Sprint Retrospective Meeting<br />
    38. 38. Sprint Planning Meeting<br />Time box: 8 hours<br />Product backlog prepared prior to meeting<br />First Half<br />Team selects items committing to complete<br />Additional discussion of Product Backlog occurs during actual Sprint<br />Second Half<br />Occurs after first half done – PO available for questions<br />Team solely responsible for deciding how to build<br />Tasks created / assigned – Sprint Backlog produced<br />A brief introduction to Agile Software Development<br />31<br />
    39. 39. Scrum Daily Meeting<br />Held every day during a Sprint<br />The most important inspection event in Scrum<br />Timebox:15 minutes<br />Team members talk to the whole Development Team, not Scrum Master<br />Asks 3 questions during meeting<br />“What have you done since last daily scrum?”<br />“What will you do before the next daily scrum?”<br />“What obstacles are impeding your work?”<br />Opportunity for team members to synchronize their work<br />It helps removing burdens between members<br />A brief introduction to Agile Software Development<br />32<br />
    40. 40. Sprint Review<br />Time box: 4 hours<br />Team presents “done” code to PO and stakeholders<br />Functionality not “done” is not shown<br />Feedback generated – Product Backlog maybe reprioritized<br />ScrumMaster sets next Sprint Review<br />A brief introduction to Agile Software Development<br />33<br />
    41. 41. Sprint Retrospective<br />Time box: 3 hours<br />Participants<br />ScrumMaster<br /> Scrum Team. <br />Product Owner is optional<br />Questions<br />What went well and what can be improved?<br />ScurmMaster helps the team in discovery – not provide answers<br />A brief introduction to Agile Software Development<br />34<br />
    42. 42. Sprint Backlog<br />A kind o f To-do list for a Sprint<br />Created by the Scrum Team (can be originated by one member, responsibility belongs to another)<br />Product Owner has defined as highest priority<br />Used for synchronizing works between team members<br />A brief introduction to Agile Software Development<br />35<br />
    43. 43. Sprint Backlog examples<br />A brief introduction to Agile Software Development<br />36<br />“digital” Sprint Backlog<br />“analog” Sprint Backlog >><br />
    44. 44. The Burn-down Chart<br />A brief introduction to Agile Software Development<br />37<br />Burndown Chart shows the Sprint trend,<br /> the performancevelocity of the team through Sprints<br />
    45. 45. Potentially Shippable Product<br />Selected items are fully implemented, tested and ready for use<br />Small but complete, “it will be bigger”<br />Scrum Team needs to define what does “done” mean, in what aspects and contexts.<br />“DONE” may be executable, “passed all tests”, “approved by senior engineers”, “reviewed by peers” or just nothing to do more with the item.<br />A brief introduction to Agile Software Development<br />38<br />
    46. 46. Distributed Scrum<br />Isolated Scrums - Teams are isolated across geographies. <br />Distributed Scrum of Scrums –Scrum teams are isolated across geographies and integrated by a Scrum of<br />Totally Integrated Scrums – Scrum teams are cross-functional with members distributed across geographies.<br />A brief introduction to Agile Software Development<br />39<br />Sutherland et al. <br />
    47. 47. Top Distributed Scrum Issues<br />Difficult leveraging available resources, best practices are often deemed proprietary, are time consuming and difficult to maintain<br />Difficulty synchronizing work between distributed sites<br />Lack of effective communication mechanisms<br />Conflicting behaviors, processes, and technologies<br />Incompatible data formats, schemas, and standards<br />Ensuring electronic transmission confidentiality and privacy<br />Difficult to share values [Bas Vodde]<br />A brief introduction to Agile Software Development<br />40<br />Sutherland et al. <br />
    48. 48. eXtreme Programming<br />From hacking code to a real process<br />A brief introduction to Agile Software Development<br />41<br />
    49. 49. eXtreme Programming Project<br />A brief introduction to Agile Software Development<br />42<br />
    50. 50. XP Values<br />Simplicity <br />encourages starting with the simplest solution<br />Communication<br />favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback<br />Feedback<br />From the system, customer and from the team, to avoid optimism<br />Courage<br />design and code for today and not for tomorrow<br />Respect<br />respect for others as well as self-respect<br />A brief introduction to Agile Software Development<br />43<br />
    51. 51. A brief introduction to Agile Software Development<br />44<br />
    52. 52. XP Roles<br />The Customer<br /> Sets project goals and makes business decisions<br />The Developer<br /> Turn customer stories into working code<br />The Tracker<br /> Keeps track of any metrics used by team<br />The Coach<br /> Guides and mentors the team<br />A brief introduction to Agile Software Development<br />45<br />
    53. 53. Test Driven Development<br />Tests created before coding<br />Focus on quality<br />Not a complete development strategy<br />Derived version: Behavior-Driven Development (BDD)<br />A brief introduction to Agile Software Development<br />46<br />
    54. 54. TDD Rationale<br />A brief introduction to Agile Software Development<br />47<br />
    55. 55. TDD Strategy<br />You don’t start programming until you have designed your tests!<br />Strategy<br />Make it Fail<br />No code without a failing test<br />Make it Work<br />As simply as possible<br />Make it Better<br />Refactor(code, design, test, documentation)<br />Believe in testing<br />A brief introduction to Agile Software Development<br />48<br />
    56. 56. Acceptance TDD<br />3D strategy<br />Discuss in requirement workshop<br />To make tests library<br />Develop in concurrence<br />To create more Passed features<br />Deliver for acceptance<br />To meet DONE definition, accepted by users<br />49<br />A brief introduction to Agile Software Development<br />
    57. 57. Continuous Integration<br />Continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently.<br />Supported by a CI system with lots of automated tests, builds and other generated artifacts.<br />Benefits:<br />Increases transparency<br />Increases cooperation and communication<br />Enables people to work on same code<br />50<br />A brief introduction to Agile Software Development<br />
    58. 58. CI System<br />51<br />A brief introduction to Agile Software Development<br />
    59. 59. Incremental Design<br />Flexible complex design on paper|CASE tool<br />Incremental Design (not simplistic)<br />52<br /><ul><li>Something unexpected always changes
    60. 60. Something unexpected always changes</li></ul>More complexity than needed. Hard to maintain. <br />Easier to adopt. ID is easier to change. Less complexity<br />A brief introduction to Agile Software Development<br />
    61. 61. Pair Programming<br />A pair of developers shares a problem, a computer, a keyboard and a goal: solve the problem<br />PP was defined in XP<br />Utilize the R-mode activities<br />Improve communication and effectiveness<br />Improve software quality<br />Widely ADOPTED, but CONTROVERSAL!<br />2 roles: Driverand Navigator:<br />The Driver doesn’t see the big picture<br />The Driver should “step a way from the keyboard”<br />The Navigator tends to use pattern-matching problem solving technique<br />53<br />A brief introduction to Agile Software Development<br />
    62. 62. Refactoring<br />You practice “code a bit, fix a little” => result in dirty code & bad design.<br />Refactoring helps in restructure or design your code to make it better. <br />what does “better” mean?<br />Keep in mind:<br />Maintainability<br />Extensibility<br />High Cohesion<br />Low Coupling<br />54<br />A brief introduction to Agile Software Development<br />
    63. 63. Crystal Clear<br />“A human-Powered methodology for small team”<br />A brief introduction to Agile Software Development<br />55<br />
    64. 64. Crystal Clear Practices<br />Frequent Delivery<br />Reflective Improvement<br />Osmotic Communication<br />Personal Safety<br />Focus<br />Easy Access to Expert Users<br />Automated Tests<br />Configuration Management<br />Frequent Integration<br />A brief introduction to Agile Software Development<br />56<br />
    65. 65. Crystal Clear<br />“The team can reduce intermediate work products as it produces running code more frequently, as it uses richer communication channels between people.”<br /> - Alistair Cockburn<br />A brief introduction to Agile Software Development<br />57<br />
    66. 66. Crystal Clear<br />Every product is slightly different and evolves over time, so the methodology, the set of conventions the team adopts, must be tuned and evolve.<br /> - Alistair Cockburn<br />A brief introduction to Agile Software Development<br />58<br />
    67. 67. Crystal Clear Roles<br />Sponsor<br />Allocates money for the project<br />Expert User<br />Lead Designer<br />Lead Technical person, mentors less experienced team members<br />Designer-Programmer<br />Each person designs and programs<br />A brief introduction to Agile Software Development<br />59<br />
    68. 68. Kanban<br />Kanban literally means “visual card,” “signboard,” or “billboard.” <br />Toyota originally used Kanban cards to limit the amount of inventory tied up in “Work In Progress” on a manufacturing floor<br />A brief introduction to Agile Software Development<br />60<br />…<br />Step 1<br />Done<br />Step 2<br />Step n<br />In<br />Process<br />In<br />Process<br />In<br />Process<br />Queue<br />Queue<br />Queue<br />…<br />Work Items<br />
    69. 69. A brief introduction to Agile Software Development<br />61<br />Why use Kanban in Software Development?<br />
    70. 70. Time-boxed iterative development has challenges <br /><ul><li>Short time-boxes give more frequent opportunity to measure progress and inspect software but force development items to be smaller
    71. 71. Smaller development items are often too small to be valuable and difficult to identify
    72. 72. Quality of requirements suffers as analysts rush to prepare for upcoming cycles
    73. 73. Quality of current development suffers when busy analysts are unable to inspect software or answer questions during development
    74. 74. Quality often suffers as testers race to complete work late in the development time-box </li></ul>A brief introduction to Agile Software Development<br />62<br />
    75. 75. The time-boxed iteration drama<br />A brief introduction to Agile Software Development<br />63<br />
    76. 76. A brief introduction to Agile Software Development<br />64<br />Using a Kanban approach in software drops time-boxed iterations in favor of focusing on continuous flow.<br />
    77. 77. Kanban queue<br />A brief introduction to Agile Software Development<br />65<br />…<br />Done<br />Step 2<br />Step n<br />Work Items<br />Step 1<br />In<br />Process<br />In<br />Process<br />In<br />Process<br />Queue<br />Queue<br />Queue<br />…<br />
    78. 78. Kanban queues (cont’d) <br />Large enough to keep the team busy<br />Small enough to avoid premature prioritisation<br />Ideally should be FIFO<br />A brief introduction to Agile Software Development<br />66<br />
    79. 79. Kanban - Work In Progress<br />Reduce multi-tasking<br />Maximize throughput<br />Enhances teamwork<br />A brief introduction to Agile Software Development<br />67<br />
    80. 80. The multitasking issues<br />Facts:<br />20% time lost to context switching per ‘task<br />Sequential yields results sooner<br />A brief introduction to Agile Software Development<br />68<br />A<br />A<br />A<br />B<br />B<br />B<br />C<br />C<br />C<br />A<br />B<br />C<br />Chart courtesy of Yahoo!<br />
    81. 81. Throughput<br />A brief introduction to Agile Software Development<br />69<br />Organizational overhead goes up as work in progress increases<br />Total Cycle Time = Number of Things in Process<br /> Average Completion Rate<br />to improve cycle time<br />Improve Average Completion Rate<br />Reduce Number of Things in Process<br />
    82. 82. Enhances Teamwork<br /><ul><li>Team focus on goals that add value not individual tasks</li></ul>A brief introduction to Agile Software Development<br />70<br />
    83. 83. Kanban Example 1<br />A brief introduction to Agile Software Development<br />71<br />Image courtesy to Jeff Patton<br />
    84. 84. Kanban Example 2<br />A brief introduction to Agile Software Development<br />72<br />
    85. 85. Kanban Example 3<br />A brief introduction to Agile Software Development<br />73<br />
    86. 86. Agile Mashup<br />It follows the Agile Manifesto and keeps the sprit of agility<br />It utilizes practices from several methods, for example:<br />Use sprint backlog and user stories with TDD and standup meeting with a kanban liked dashboard.<br />Use stand up meeting in daily Scrum<br />Use Burn down chart in Kanban<br />A brief introduction to Agile Software Development<br />74<br />
    87. 87. A brief introduction to Agile Software Development<br />75<br />Agile Software Development - a cooperative game.<br />Alistair Cockburn<br />
    88. 88. 76<br />Paper<br />Face-to-face communication is better<br />2 people at<br />whiteboard<br />2 people <br />on phone<br />Communication Effectiveness<br />Videotape<br />2 people<br />on email <br />Richness of communication channel<br />A brief introduction to Agile Software Development<br />Slide courtesy to Cockburn. A.<br />
    89. 89. References and Further Readings<br />Agile Software Development: The Cooperative Game, 2ndEdn. By Alistair Cockburn.<br />Scrum Guide 2010 by Ken Schwaber and Jeff Sutherland<br />Agile Project Management with Scrum by Ken Schwaber <br />Agile Java Crafting Code with Test-Driven Development By Jeff Langr<br />Test-Driven Development in Microsoft .NET by James W. Newkirk and Alexei A. Vorontsov <br />Extreme Programming Explained by Kent Beck <br />XP introduction,<br />http://www.extremeprogramming.org/<br />http://xprogramming.com/<br />http://www.agilealliance.org/<br />Kanban Oversimplified<br />http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html<br />Ken Schwaber & Jeff Sutherland, Scrum Guide, Scrum.org<br />Pete Deemer, Gabrielle Benefield, Craig Larman & Bas Vodde, Scrum Primer, GoodAgile.com <br />HanoiScrum.net<br />AgileVietnam.org<br />ScrumAlliance.org<br />AgileAlliance.org<br />A brief introduction to Agile Software Development<br />77<br />
    90. 90. Q&A<br />A brief introduction to Agile Software Development<br />78<br />
    91. 91. A brief introduction to Agile Software Development<br />79<br />Thank you!<br />Let’s Go Agile!<br />Sunday October 23rd 2011<br />FPT University, Innovation Building, Quang Trung Software City, District 12, HCMC, Vietnam<br />

    ×