Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Warum funktioniert Agiles Software Engineering?

Stefan Wagner
November 11, 2015

Warum funktioniert Agiles Software Engineering?

Dieser Vortrag beleuchtet die Rolle von schnellen Rückkopplungsschleifen ("Fast Feedback Loops") im Erfolg von Agilen Techniken im Software Engineering.

Stefan Wagner

November 11, 2015
Tweet

More Decks by Stefan Wagner

Other Decks in Science

Transcript

  1. You can copy, share and change, film and photograph, blog,

    live-blog and tweet this presentation given that you attribute it to its author and respect the rights and licences of its parts. Slide is based on suggestions by @SMEasterbrook und @ethanwhite
  2. My Company Practices Agile yes no 16 84 Source: 7th

    Annual State of Agile Development Survey (2013) in % of respondents
  3. „Scrum addresses the complexity of software development projects by implementing

    the inspection, adaptation, and visibility requirements of empirical process control with a set of simple practices and rules…“ –Ken Schwaber K. Schwaber. Agile Project Management with Scrum. Microsoft Press, 2004
  4. Scrum Retrospective Sprint Review Geschenkpapier Gutscheine Stornieren Stornieren Geschenkpapier Sprint

    2–4 weeks Rücksendung Sprint Goal Sprint Backlog Potentially Shippable Product Increment Product Backlog Gutscheine 24 hours Rücksendung
  5. But do companies really do that? What do practitioners vary

    using Scrum? Why do they vary it in this specific way? P. Diebold, J.-P. Ostberg, S. Wagner, U. Zendler. XP 2015
  6. Case Study Design
 Goal and Research Questions (RQs) What and

    why do they vary in the… role of Product Owner? role of Scrum Master? Sprints? events? requirements engineering? quality assurance? Analyse the Scrum framework to explore its industrial usage 
 with respect to its variations from the perspective of practitioners.
  7. Case Study Design
 Case & Subject selection and description Selection

    based on availability willingness Maximise variation by No. of employees (start-up to 130,000) Different information system domains International customers Interview participant developers and dev. managers past or current projects 10 interviews
  8. Results – Sprints 1 2 3 4 5 6 7

    8 9 10 4 4 4 4 3 2 2 2 2 2 Sprint Length in Weeks
  9. Results - Sprint Review Only one company did not do

    Sprint Reviews in every Sprint.
  10. Conclusion While there are many variation in the usage of

    Scrum (in e.g. the roles), the iteration feedback mechanisms (Sprints, Sprint Reviews and Retrospectives) are popular and perceived as useful.
  11. Results - Daily Scrum Seven out of ten companies did

    Daily Scrums of 15 to 30 minutes length.
  12. Based on: M. Cohn. Succeeding with Agile. Addison-Wesley, 2010 Test

    Code Refactor Test Code Refactor Test Code Refactor Passing acceptance test Refactor the test Customer acceptance Implement acceptance test(s) Failing acceptance tests Acceptance- test-driven development Test-driven development Identify conditions of satisfaction Select a user story
  13. Educative Drives - Rewards Educative drives: the drives to play

    and to explore (curiosity) Rewards Liking Wanting Reinforcement Discount effect: A reward is perceived the less valuable the later it will become available. Partly based on: P. Gray, D.F. Bjorklund. Psychology. Worth, 2014
  14. Continuous Quality Control Quality Model Development Quality Assurance Review Test

    Analysis Quality Requirements Software Product Planning Corrections Results S. Wagner. Software Product Quality Control. Springer, 2013
  15. Compare View (~20 LOC) Seesoft View (~400 LOC) Tree Maps

    (>1.000.000 LOC) Trends over Time Visualisation of  clone detection results
  16. Impression management and cooperation Impression management: the set of ways

    by which people consciously and unconsciously modify their behaviour to influence others’ impressions of them. Partly based on: P. Gray, D.F. Bjorklund. Psychology. Worth, 2014 Cooperation Accountability Reputation Reciprocity
  17. How problematic are these inconsistencies (and clones)? Indicating harmfulness [Lague97]:

    inconsistent evolution of clones in industrial telecom. SW. [Monden02]: higher revision number for files with clones in legacy SW. [Kim05]: substantial amount of coupled changes to code clones. [Li06], [SuChiu07] and [Aversano07], [Bakota07]: discovery of bugs through search for inconsistent clones or clone evolution analysis. Doubting harmfulness [Krinke07]: inconsistent clones hardly ever become consistent later. [Geiger06]: Failure to statistically verify impact of clones on change couplings [Lozano08]: Failure to statistically verify impact of clones on changeability. [Göde11]: Most changes intentionally inconsistent [Rahman12]: no statistically significant impacts on faults
  18. Our First Study at ICSE 2009 • Manual inspection of

    inconsistent clones by system developers No indirect measures of consequences of cloning • Both industrial and open source software analysed • Quantitative data F. Deissenboeck, E. Juergens, B. Hummel, S. Wagner, ICSE 2009
  19. Research Questions RQ1: Are clones changed inconsistently? |IC| / |C|

    RQ2: Are inconsistent clones created unintentionally? |UIC| / |IC| RQ3: Can inconsistent clones be indicators for faults in real systems? |F| / |IC|, |F| / |UIC| Clone Groups C (exact and incons.) Inconsistent clone groups IC Unintentionally incons. Clone Groups UIC Faulty clone Groups F
  20. Study Design Tool detected clone group candidates CC Clone group

    candidate detection • Novel algorithm • Tailored to target program False positive removal • Manual inspection of all inconsistent and ¼ exact CCs • Performed by researchers Assessment of inconsistencies • All inconsistent clone groups inspected • Performed by developers Clone groups C (exact and incons.) Inconsistent clone groups IC Unintentionally inconsistent clone groups UIC Faulty clone groups F → CC → C, IC → UIC, F
  21. Study Objects International reinsurance company, 37.000 employees Munich-based life-insurance company,

    400 employees Sysiphus: Open source collaboration environment for distributed SW development. Developed at TUM. 281 8 Java TUM Sysiphus 197 17 Cobol LV 1871 D 495 2 C# Munich Re C 454 4 C# Munich Re B 317 6 C# Munich Re A Size (kLoC) Age (years) Language Organization System
  22. Results Project A B C D Sys. Sum Clone groups

    |C| 286 160 326 352 303 1427 Inconsistent CGs |IC| 159 89 179 151 146 724 Unint. Incos. |UIC| 51 29 66 15 42 203 Faulty CGs |F| 19 18 42 5 23 107
  23. Our Second Study • Investigating evolution of type-3 clones •

    Relationship with documented faults from issue tracker • Industrial systems
  24. Research Questions Clone Groups C (exact and incons.) Inconsistent clone

    groups CT3 Faulty clone Groups CT3 F RQ1: Do software systems contain type-3 clones? |CT3| / |C| RQ2: Do type-3 clones contain documented faults? |CT3 F | / |CT3| RQ3: Are developers aware of type-3 clones? |IMS | / |IM |, |Cx| / |CT3 F |, |CT2 F ▶︎ CT3 NF |
  25. Data Collection and Analysis rt HTML Dash- board v1 v2

    v3 Extract Analyse Query for relationships and evolution Extract
  26. Study Objects A. Case Description TABLE I. SUMMARY OF THE

    STUDY OBJECTS Size Age System Domain Lang. (KLOC) Revision (Years) Developers A Automotive Java 253 2470 4 10 B Automotive Java 332 1622 5 5 C Automotive Java 454 2181 4 10 B. Share of Type-3 Clones (RQ 1) Table III contains the quantitative results for all research questions in detail. We found a mean share of type-3 clones in all clones and all three systems of 52 %. Yet, it varied quite strongly from 23 % in system B to 79 % in system C. Nevertheless, in all three systems, there is a considerable share of type-3 clones and, hence, it is useful to investigate their relationship with faults.
  27. Some Results Project A B C Overall Share of type-3

    clones 0.56 0.23 0.79 0.52 Share of faulty clone classes 0.33 0.05 0.03 0.17 Share of simultaneously modified type-3 clones 0.58 0.89 0.92 0.85
  28. Conclusions • About half of all clone classes are type-3

    clones. • Rate of faulty type-3 clones is about 17 %. • There is a high awareness of clones and inconsistencies. • This awareness seems to impact how many faults are related to type-3 clones. • Making developers aware of clones seems still to be worthwhile.
  29. Fast feedback in empirical research A. Vetrò, S. Ognawala, D.

    Méndez Fernández, S. Wagner, ICSE 2015 User Story XYZ-123 As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved Why did the implementation of this user story took longer then estimated ? not clear description falsely assumed standard functionality intrinsic difficulty of the problem other:
  30. Pictures Used in this Slide Deck „Ken Schwaber“ by Sebastian

    Wallroth (https://commons.wikimedia.org/wiki/ File:Ken_Schwaber.jpg) „Mercurial Logo“ by Mackall (http://www.selenic.com/hg-logo/) Reusable Scrum Presentation by Mountain Goat Software (https:// www.mountaingoatsoftware.com/agile/scrum/a-reusable-scrum-presentation) „Nightly Build“ by System One Gang (https://flic.kr/p/tmwbV) Figure 8.2 by Elmar Jürgens (http://mediatum.ub.tum.de/doc/997705/document.pdf) „On the couch (Explored“ by Pascal (https://flic.kr/p/8DVMLy)