Institut für Informatik AG Software Engineering. 15. März 2012 Seminar Beiträge zum Software Engineering

Transkript

1 Institut für Informatik AG Software Engineering 15. März 2012 Seminar Beiträge zum Software Engineering

2 Was? explorative Prozessanalyse in einem Unternehmen Ermittlung des Soll-Zustandes Untersuchung des gelebten Prozesses Erstanalyse: Ansatzpunkte für detailliertere Analysen finden Warum? Prozessverbesserung Prozessforschung 2

3 Wie? Zwei Beobachtungstage ( November) neun strukturierte Interviews rund sechs Stunden Online-Fragebögen 45 Seiten Beobachtungsnotizen 3

4 4

5 5

6 6

7 7

8 Product Owner war nicht vor Ort im Team Unterschiedliche Sprintzyklen POs nahmen an beiden Stand Ups teil 8

9 Aufgabe: Kontaktstatistik für Makler Bestbewertete Praktiken: Zeit in Primärrolle (z.b. ): 60-80% Benotung der Arbeitssituation: 9

10 Aufgabe: Kontaktstatistik für Makler Bestbewertete Praktiken: Zeit in Primärrolle (z.b. ): 60-80% Benotung der Arbeitssituation: 2,64 10

11 Aufgabe: Kontaktstatistik für Makler Bestbewertete Praktiken: Zeit in Primärrolle (z.b. ): 60-80% Benotung der Arbeitssituation: 2,64 11

12 12

13 PO gab in User Stories zusätzliche Details vor bewusste Entscheidung wurde im Team positiv aufgenommen 13

14 Sprintzyklen: Hindernis sollten angepasst werden Zwecks Erfahrungsaustausch: gemeinsame Retrospektive der beiden Teams geplant Entwickler sollten früher in der Planung mit einbezogen werden. 14

15 15

16 es kamen viele Tools zum Einsatz Wikis, Jira, Jive, mehrere Visualisierungen/Boards trotzdem konnten Informationsbedürfnisse nicht gedeckt werden Einträge sind nicht aktuell. Nach zwei Tagen Abwesenheit braucht man einen halben Tag, um sich wieder auf den aktuellen Stand zu bringen. 16

17 SM: Verteilung der Teams Aufteilung der Stories oft unklar Sprachbarriere (Berlin) selten direkte, synchrone Kommunikation passiver Modus (Berlin) Team: Infrastruktur instabile Build- /Testumgebung viel Bugfixing kommt kaum zur Feature-Entwicklung Wenn der Scrum Master die Hindernisse des Teams nicht richtig versteht, kann er auch nicht bei der Lösung helfen. 17

18 Team: Anforderungen sind unklar. Warum kommt was ins Backlog? Anforderungsänderungen während des Sprints werden schlecht kommuniziert Tests passen nicht mehr. Product Owner: Team ist manchmal unflexibel und festgefahren. agil = Sachen ändern sich halt Änderungen dürfen nicht während des Sprints erfolgen. Eine Kommunikation dieser Änderung sollte gar nicht nötig sein. 18

19 Fachliche Anforderungen müssen nachgefragt werden Längere Antwortzeiten bei Fragen aus dem Team Entwicklung verzögert sich 19

20 Den Product Ownern der Service Line Anbieten fehlt eine gemeinsame Stoßrichtung. Unklare Priorisierung der Projekte Überbelastung der Product Owner Sachen fallen hinten runter. Teams fällt Einordnung der Projekte in einen höheren Kontext schwer Entwickler sehen nicht den Zweck ihrer Arbeit Team stellt alles in Frage, ist sehr skeptisch. 20

21 Informationsbedürfnisse nicht ausreichend gedeckt Agilität: Umgang mit Anforderungen Impediments: Team und Scrum Master sehen verschiedene Hindernisse Kommunikation Lange, indirekte Kommunikationswege durch Verteilung Hierarchien der Product Owner und unklare Vision erschweren Informationsfluss 21

22 22

23 23

24 Aufgabe: Entwicklung der iphone-/ipad-app Bestbewertete Praktiken: Zeit in Primärrolle (z.b. ): % 60-80% Benotung der Arbeitssituation: 24

25 Aufgabe: Entwicklung der iphone-/ipad-app Bestbewertete Praktiken: Zeit in Primärrolle (z.b. ): % 60-80% Benotung der Arbeitssituation: 1,65 : 2,64 25

26 Aufgabe: Entwicklung der iphone-/ipad-app Bestbewertete Praktiken: Zeit in Primärrolle (z.b. ): % 60-80% Benotung der Arbeitssituation: 1,65 : 2,64 26

27 27

28 Innensicht Gute Noten für eigene Arbeitssituation Freundliche Atmosphäre bei Retrospektive, Stand- Up und Alltag Außensicht App: hohe Downloadzahlen/gute Bewertungen Vertrauen vom Management Eines der besten Teams im Unternehmen. 28

29 1. Team produziert hohe Qualität Großzügiger Einsatz fördernder Praktiken: Unit Tests, Continuous Integration, Refactorings Pair Programming ist die Regel Code-Defekte werden vermieden Know-How kann sich im Team gut verbreiten 2. Team kann unabhängig arbeiten Neuentwicklung & stabiles Team Know-How im Team präsent Keine Releasevorgaben von oben, Team entscheidet selbst Featurewünsche von Benutzern kanalisiert durch PO 29

30 Ein Entwickler ist sehr kompetent und war einige Wochen an anderes Projekt ausgeliehen. Team hat sich entwickelt, konnte sich entfalten. Größte Herausforderung: Reintegration. 30

31 31

32 bis zu 50% der Arbeitszeit sind Refactorings vom Product Owner geduldet und akzeptiert Qualitätsverbesserung ist ein ständiges Thema Gefahr von zu hoher Qualität 32

33 alle Informationen sind am Teamboard, keine Softwareunterstützung ungeplante, diffuse Kommunikation von Know-How Problem ist bekannt, aber nicht präsent 33

34 Positive Innen- und Außensicht Weiterentwicklung des Teams durch Abwesenheit eines Entwicklers Starker Fokus auf Qualität tendenziell zu hohe Qualität monolithische Betrachtung von Qualität Papierbasiertes Informations- und Wissensmanagement am Teamboard Was passiert bei personellen Veränderungen und wachsender Projektgröße? 34

35 Eigener Prozess, Teile von Scrum und Kanban einstimmig Scrum evtl. zu starr nur Teamboard ausreichend Toolunterstützung nicht ausreichend Minimum Viable Product + Anwenderfeedback nicht präzise 35

36 36

37 37

38 38