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.

Transcript

1. Agiles Software Engineering www.uni-stuttgart.de Warum funktioniert Stefan Wagner @prof_wagnerst infos-Mitgliederversammlung 11. November 2015 ?
2. 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
3. My Company Practices Agile yes no 16 84 Source: 7th Annual State of Agile Development Survey (2013) in % of respondents
4. Why agile successful? is so
5. „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
6. Fast feedback loops are an important success factor for agile software engineering.
7. Levels of Fast Feedback Release Daily organisation Single story development
8. Levels of Fast Feedback Release
9. Waterfall Analysis Design Coding Test Months of feedback delay
10. Improved Waterfall Analysis Design Coding Test Months of feedback delay Reviews Prototypes
11. 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
12. 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
13. 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.
14. Background
 Scrum Guide as Comparison http://www.scrumguides.org/scrum-guide.html
15. 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
16. 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
17. Results - Sprint Review Only one company did not do Sprint Reviews in every Sprint.
18. Results - Sprint Retrospectives Seven out of ten companies did Retrospectives in every Sprint.
19. 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.
20. Levels of Fast Feedback Release Daily organisation Single story development
21. Levels of Fast Feedback Release Daily organisation
22. Daily Scrum
23. Results - Daily Scrum Seven out of ten companies did Daily Scrums of 15 to 30 minutes length.
24. Nightly Builds
25. Levels of Fast Feedback Release Daily organisation Single story development
26. Levels of Fast Feedback Single story development
27. 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
28. 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
29. 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
30. Class A Class B
31. Class A Class B
32. Class A Class B
34. Often 20%–30% redundancy
35. Compare View (~20 LOC) Seesoft View (~400 LOC) Tree Maps (>1.000.000 LOC) Trends over Time Visualisation of
    clone detection results
36. Control of Cloning 8.8 Evaluatio
37. 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
38. Inconsistencies Can you spot the difference?
39. 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
40. 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
41. 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
42. 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
43. 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
44. 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
45. Our Second Study • Investigating evolution of type-3 clones • Relationship with documented faults from issue tracker • Industrial systems
46. 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 |
47. Data Collection and Analysis rt HTML Dash- board v1 v2 v3 Extract Analyse Query for relationships and evolution Extract
48. 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.
49. 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
50. 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.
51. Making the feedback loop shorter https://www.cqse.eu/en/blog/practical-guide-to-code-clones-part2/
52. Fast feedback loops are an important success factor for (agile) software engineering.
53. Three conclusions
54. More and even shorter feedback loops
55. Understand other sociological and psychological factors
56. 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:
57. Fast feedback loops are an important success factor for agile software engineering.
58. 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)