1 / 29

Agile Software Engineering

Agile Software Engineering. Bharath Padmanabhan ∙ University of Kansas ∙ Spring 2014. Scrum & Engineering Practices: Experiences of Three Microsoft Teams. Gabe Brown, Adam Meltzer, Nachiappan Nagappan Microsoft Corporation Redmond, WA 98052, USA

beau
Télécharger la présentation

Agile Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Agile Software Engineering • Bharath Padmanabhan ∙ University of Kansas ∙ Spring 2014

  2. Scrum & Engineering Practices:Experiences of Three Microsoft Teams Gabe Brown, Adam Meltzer, NachiappanNagappan Microsoft Corporation Redmond, WA 98052, USA {gabeb, ameltzer, nachin}@microsoft.com • Laurie Williams • North Carolina State University • Raleigh, NC 27695, USA • williams@csc.ncsu.edu Laurie Williams, Gabe Brown, Adam Meltzer, and Nachiappan Nagappan. Scrum + engineering practices: Experiences of three microsoft teams. In ESEM, pages 463-471. IEEE, 2011. 2

  3. Abstract • Experiences of three teams at Microsoft using the Scrum methodology with an additional nine sound engineering practices indicate that these teams were able to improve quality, productivity, and estimation accuracy through the combination. 3

  4. Sections • Introduction • Scrum • Background and Related Work • Microsoft Team and Process • Results • Limitations • Lessons Learned 4

  5. INTRODUCTION 5

  6. Scrum is the most often used agile software development methodology • From a large scale survey in mid-2008 across 80 countries: • 49% used Scrum • 29% used Scrum + XP • From a survey of 10% of engineers at Microsoft: • More than 60% used Scrum 6

  7. 7

  8. The Problem Scrum process is centered on project management activities but deliberately omits any technical practices (for flexibility reasons). The Solution Engineering practices are needed even though Scrum doesn't mandate them to prevent "flaccid scrum". 8

  9. SCRUM 9

  10. 10

  11. BACKGROUND AND RELATED WORK 11

  12. Scrum Research Case Study Research • Quantitative research as opposed to qualitative research of which there is plenty • Pattern among published studies shows successful Scrum teams also use proven engineering practices • Gaming company, using Scrum and XP, managed to exceed expectations even after team reduced in half • Dev team for internet portal, who initially ran into cumulative and irreversible problems using just Scrum, managed to implement higher quality product by adopting some engineering practices • Experiences shared in this paper can be classified as case study research • Tests theories and collects data through observation of a project in an unmodified setting • Involve factors that staged experiments generally do not exhibit such as scale, complexity, unpredictability, and dynamism • Very significant for industrial evaluation of software engineering methods and tools 12

  13. MICROSOFT TEAM AND PROCESS 13

  14. Research Methodology Gabe Brown, Adam Meltzer, NachiappanNagappan Microsoft Corporation Laurie Williams North Carolina State University • The second and third authors participated as software engineers on the three teams • The first author obtained information about the teams' experiences by interviewing the second author • The fourth author also participated in the interviews • The second and third authors provided quantitative data, which was interpreted and analyzed by the first and fourth authors 14

  15. Team Demographics and Context • Information about the exact Microsoft products the teams implemented were not shared to share more information about the team's results • Teams were working on the first release of their products in either C# or C++ • Teams produced between 9 and 31 thousand lines of implementation code during a period of between 11 and 18 months long • Teams B was co-located teams while Teams A and C were distributed between the US and China 15

  16. Engineering Practices Used In Addition To Scrum • Source Control • Code Coverage • Peer Review • Static Analysis Tools • XML Documentation • Planning Poker • Continuous Integration • Unit Test-Driven Development • Quality Gates ("Done Criteria") 16

  17. Planning Poker • Teams used Planning Poker to estimate the person-hours required to complete functionality within an iteration • Played by the team as part of the Sprint Planning meeting • Most often, only one or two Planning Poker rounds are necessary on a particular requirement before consensus is reached 17

  18. Planning Poker • Obtaining a shared understanding • Exposing hidden assumptions of the technical aspects of implementation and verification • Discussing the implications throughout the system for implementing a requirement • Surfacing and resolving ambiguities realized via divergent perspectives on the requirement • Exposing easy and hard alternatives for achieving desired goals 18

  19. Traditional Estimation Funnel vs Microsoft Story Point Accuracy 19

  20. Continuous Integration • Teams checked in their new code at least once per day which initiated a build and ran automated unit tests and associated test coverage computation • Email confirmation of completion of the build providing test results; all tests must pass for the build to be considered successful • Quality benefit comes with a cost; when builds or tests fail, engineers need to deal with issues such as bad merges, build system problems, and source control integration problems 20

  21. Unit Test-Driven Development • Teams wrote automated unit tests after completing a major piece of functionality or completing a class • Writing test cases added approximately 20% to their development time • The ratio of test lines of code (LOC) to source LOC ranged from .46 to .84; test coverage ranged from 53% to 82% 21

  22. Quality Gates ("Done") • All unit tests must pass • Unit test code coverage must be at least 80% (for all teams except Team B) • All public methods must have documentation • All non-unit test code must not have any static analysis errors or warnings • Build must compile with no errors or warnings on the highest level 22

  23. RESULTS 23

  24. Productivity • Although the transition to the new Scrum process did temporarily reduce the productivity of the team, they recovered and improved productivity by the end of the 4th iteration • Team A was able to achieve a 250% improvement in the number of lines of code produced in each sprint by the fourth sprint • The improved productivity directly translated into capacity the teams leveraged to complete more user stories and Sprint tasks while meeting all of the quality gates 24

  25. Defect Density • The Scrum projects had lower defect density (defects per line of code) than the non-Scrum projects except in the case of Team B • Team B's testing effort was relatively low (Source/test LOC ratio is 0.53) indicating the lowest effort amongst all Scrum projects • To compare and contrast the quality of the software systems produced, a comparison was made against prior published defect density rates of a non-Scrum project at IBM 25

  26. LIMITATIONS 26

  27. Results are only valid in the context of these three teams and the results may not generalize beyond these three teams • Comparisons are not on the same projects as the same teams could not repeat the projects in a non-Scrum environment • Since all three Microsoft teams were relatively small teams, this research does not address scalability of Scrum to larger teams • Productivity of teams compared relative to their productivity prior to Scrum wherein other factors may have been involved • Unable to distinguish specifically which of the nine additional engineering practices were the biggest drivers in the productivity and quality results observed 27

  28. LESSONS LEARNED 28

  29. Teams transitioning to the use of an agile software development should plan for a temporary productivity decrease (due to their unfamiliarity of Scrum) but that should eventually pass • Teams that used Scrum and sound engineering practices showed better quality in terms of defect density compared with similar non-Scrum teams including data benchmarked across 40 projects from nine companies • Results also indicate that estimation accuracy was enhanced by the use of the Planning Poker practice 29

More Related