softwaretechnikprojekt - freie universitätkurze e-mail an zieris@inf.fu-berlin.de klonen über...
Post on 17-Jun-2020
2 Views
Preview:
TRANSCRIPT
Softwaretechnikprojekt:„Agile Softwarenentwicklung in einem Open-Source-Projekt“
Sommersemester 2016
Franz Zieris, M.Sc.AG Software Engineering
Freie Universität Berlin
15.08.2016
Das Projekt: Worum geht es?
• Teilnahme an der Entwicklung eines wachsenden, lebendigen, Open-Source-Projekt
• Das Projekt:? Saros
– Ein IDE-Plug-In, entwickelt u.a. hier am Fachbereich
• Ziele:
– Praxis – Phasen der Softwareentwicklung durchlaufen,in einem komplexen Umfeld
– Selbstorganisation – Teamarbeit koordinieren, Probleme erkennen und Reibungsverluste minimieren
– Kommunikation – einen Open-Source-Prozess kennenlernen
2Franz Zieris, zieris@inf.fu-berlin.de
§2 Qualifikationsziele
(1) […] Sie können ein Softwaresystem moderater Komplexität allein oder im Team konstruieren, imple-mentieren, dokumentieren, testen und in guter Qualität liefern.
Sie setzen dafür moderne Arbeitsprozesse, Entwicklungswerkzeuge, Programmiersprachen, Standard-systemstrukturen, Softwarekomponenten und Algorithmen nach technischen und wirtschaftlichenGesichtspunkten geeignet ein.
Analog können sie größere Projekte anteilig im Team übernehmen, um Teilaufgaben selbstständig zubearbeiten, die Ergebnisse anderer aufzunehmen und die eigenen Ergebnisse weiterzugeben. […]
Sie können sich selbstständig und zügig in neue Anwendungsgebiete und Technologien einarbeiten.
Sie können kritisch urteilen und handeln verantwortlich.
Sie können mithilfe dieser Grundlagen und Techniken neue Probleme der Informatik analysieren undverstehen und fehlende Fertigkeiten selbstständig erwerben.
§8 Lehr- und Lernformen
(1) […] 8. Projektseminar (PrjS): Es dient der anwendungs und problembezogenen Vertiefung fachwissen-schaftlicher Kenntnisse und Methoden. Die Projektarbeitsgruppen sind von Studentinnen undStudenten selbstständig organisierte und von Dozenten betreute Kleingruppen, die der begleitendenBearbeitung des Projektes dienen.
Aus der Studien- und Prüfungsordnung
Franz Zieris, zieris@inf.fu-berlin.de 3
Aus der Modulbeschreibung
Qualifikationsziele:
Die Studentinnen und Studenten können ihre softwaretechnischen Kenntnisse und Qualifikationen
erfolgreich in einem kleinen Softwareprojekt einsetzen und die entsprechenden Verfahren anwenden. […]
Sie verstehen Qualitäts-, Aufwands-, Akzeptanz- und Erfolgsfaktoren eines Softwareprojekts.
Sie können mündlich und schriftlich in einem Projektteam mit mehr als fünf Personen kommunizieren,
sich koordinieren und ein Softwareprojekt unter Anleitung erfolgreich planen.
Sie können ihre Arbeiten selbst verwalten. Sie sind fähig, die Qualität ihrer Lösungsbeiträge im Kontext
des Gesamtprojekts zu beurteilen. […]
Sie können ihre Ergebnisse mündlich und schriftlich geeignet darstellen.
Inhalte:
[…] Dabei sollen alle Phasen eines Softwareprojekts, so wie sie in einem Unternehmen heute stattfinden,
durchlaufen sowie typische Methoden, wie sie im Modul Softwaretechnik kennen gelernt wurden, anhand
der im Unternehmenseinsatz typischen Werkzeuge und Hilfsmittel durchgeführt werden.
Es werden exemplarisch unternehmenstypische Softwarekomponenten und Werkzeuge zur Durchführung
aller auftretenden Aufgaben vorgestellt und erprobt.
Franz Zieris, zieris@inf.fu-berlin.de 4
Bewertungsmaßstab &
Modulkriterien
Organisatorisches (I)
5Franz Zieris, zieris@inf.fu-berlin.de
Modulkriterien
• wochenweise Gruppen- und Einzelnoten
• Jede/r Einzelne ist nicht nur für sich selbst,
sondern auch für das Gesamtprojekt verantwortlich
6Franz Zieris, zieris@inf.fu-berlin.de
Modulkriterien – Gruppennote
• Im Kern: Produktivität und Qualität der Zusammenarbeit
• Im Einzelnen:1. Größe der vorgenommenen Arbeit in einer Iteration
nicht zu wenig
nicht zu viel
2. Grad des Erfolgs nicht nur funktionaler Umfang, sondern auch
Qualitätssicherung und Dokumentation
3. Prozess/Prozesssteuerung Durchführungsqualität der Praktiken
Umgang mit Problemen, Innovation
Art der Zusammenarbeit
7Franz Zieris, zieris@inf.fu-berlin.de
Modulkriterien – Einzelnote
• „Wie kann ich dafür sorgen, dass meine individuelle Leistung auch gewürdigt wird?“
– jeden Freitag bis 12:30 Uhr im KVV beantworten:
Was waren meine drei Hauptleistungen diese Woche?
Was waren die größten Probleme, die ich diese Woche hatte?
Auf welche Weise habe ich versucht diese Probleme zu lösen?
Erfolgreich?
Wer von meinen Kolleg/inn/en hat mich am besten unterstützt? In
welcher Weise?
8Franz Zieris, zieris@inf.fu-berlin.de
Modulkriterien – Einzelnote
• Ausgangspunkt: Wochenbericht
• Vor diesem Hintergrund im Einzelnen:1. Entwicklungsleistung in der Woche
(inkl. Qualitätssicherung)
2. Beteiligung bei Sprint Planning/Review/Retrospektive
3. Unterstützung der anderen (z.B. Wissenstransfer)
4. Eigeninitiative (z.B. Prozessverbesserung, Übernehmen von Verantwortung)
5. Umgang mit Problemen
6. Wissen über den Stand des Projektes Jede/r Teilnehmer/in muss zu jedem Zeitpunkt darüber Auskunft
geben können, wo er/sie und das Team gerade stehen (in der Iteration).
Franz Zieris, zieris@inf.fu-berlin.de 9
Bewertung – Einzel- und Gruppennoten
Gesamtnote =
Einzelnote =
Gruppennote =
10
2 · Einzelnote + Gruppenote
3
⎳⎲
k=1
6Einzelnotek
6
⎳⎲
k=2
6( Gruppennotek)– p · Gruppenotez
5 – p
p = 1 Woche z soll nicht gewertet werden (Teamentscheidung bei Sprint Review z)
p = 0 alle Wochen werten
wird bekannt gegeben
nur intern
Franz Zieris, zieris@inf.fu-berlin.de
Anwesenheitsregeln
• 40 Stunden Projektarbeit pro Woche– Ausnahmen (andere
LVs/Nachklausuren) werden nachgearbeitet
– Sprints: Mo-Fr keine Projektarbeit am Wochenende
• bis zu 10 Stunden pro Woche Telearbeit– exkl. Sprint Planning / Review /
Retrospektive
– wenn Telearbeit: dann ständig erreichbar (Telefon, Skype, IM, E-Mail)
• Kernarbeitszeit: 10 – 15 Uhr– wenn anwesend, dann in der vollen
Kernarbeitszeit
• Fehlzeiten– Krankheit: Attest vorlegen
entschuldigtes Fehlen
– unentschuldigtes Fehlen in Woche k Auswirkung auf Einzelnotek
– Scheinkriterium: max. 10% Fehlzeiten• (= 3 volle Tage, bzw. 24 Arbeitsstunden)
Franz Zieris, zieris@inf.fu-berlin.de 11
Kontext & Teamstruktur
Organisatorisches (II)
12Franz Zieris, zieris@inf.fu-berlin.de
Kontext
• Fiktives Mittelstandsunternehmen agsedo
– entwickelt Individualsoftware für eine Reihe namhafter Firmen
– Zwei Standorte in Deutschland
– Nutzen seit einem Jahr Saros und wollen nun etwas
zurückgeben
Vor allem: haben selbst auch Featurewünsche entwickelt
– Budget für ein Team (ihr) für die Dauer von sechs Wochen ist
bewilligt
Franz Zieris, zieris@inf.fu-berlin.de 13
ooagsedoo
Personelle Strukturierung des Projekts
Open-Source Community
Entwicklungs-
team
Scrum Master
unterrichtet Team in
Prozessdingen,
bestehender Kontakt
zum OS-Projekt
Product Owner
vertritt Agsedos
wirtschaftliche Interessen;
stellt Anforderungen,
nimmt Ergebnisse ab
Externe Entwickler Saros-Team an der FU
ooagsedoo
Franz Zieris, zieris@inf.fu-berlin.de 14
ooagsedoo
Ziele der Agsedo GmbH
• Neue Anforderungen des Marktes schnell erkennen
• Nachhaltige Produktentwicklung
• Zufriedene Kunden
• Wichtig: Effektiver Wissenstransfer über
Standortgrenzen hinweg
– Tool "Saros" im letzten Jahr erfolgversprechend
evaluiert
15
ooagsedoo
Projekt "Saros-Erweiterung"
• Ressourcen:
– 1 Team (5-6 Entwickler/innen, 1 Scrum Master,
1 Product Owner)
– sechs Sprints
• Sprint 0: Einarbeitung
• Sprint 1-5: Umsetzung der Agsedo-Anforderungen
16
ooagsedoo
Vorschau: Product Backlog
Achtung: Endgültige Freigabe durch das Board steht
noch aus (wir sind mitten im Quartal)
Themen
• Herstellung Einsatzfähigkeit von Saros für Intellij
• Verbesserung der Awareness
– Selektionen, Textänderungen, Overlays, Dialoge
17
Zeitliche Strukturierung des Projekts
6 Wochen: Einführung + 5× einwöchige Iterationen
Iteration: 5 Tage
KW 33 KW 34 KW 35 KW 36 KW 37 KW 38
Einführungs
-wocheSprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Montag Dienstag Mittwoch Donnerstag Freitag
Sprint
PlanningTeamarbeit Teamarbeit Teamarbeit
Teamarbeit
TeamarbeitSprint Review
Sprint Retro
18Franz Zieris, zieris@inf.fu-berlin.de
Grobüberblick zur Infrastruktur
Technisches (I)
19Franz Zieris, zieris@inf.fu-berlin.de
Code Review und
Continuous IntegrationDurchsichten
– Instrument der statischen, analytischen Qualitätssicherung
– abc– wir nutzen dafür Gerrit
Continuous Integration
– (u.a.) Instrument der dynamischen, analytischen
Qualitätssicherung
– Merkmale: kleinteilige Änderungen
automatisierter Bau und Test des Systems
Integrationsprobleme früh aufdecken
– wir nutzen dafür Jenkins
20Franz Zieris, zieris@inf.fu-berlin.de
Code Review und
Continuous IntegrationBlessed Repository
Gerrit Code Review
JenkinsDeveloper‘s
System
- entire history
- master branch
- continuous integration
- builds code and
runs JUnit
- entire history
- index and working
directory
11
git addgit commit
22
3344
55
66
Franz Zieris, zieris@inf.fu-berlin.de 21
URLs der Dienste
http://saros-build2.imp.fu-berlin.de/gerrit
http://saros-build2.imp.fu-berlin.de/jenkins
Franz Zieris, zieris@inf.fu-berlin.de 22
Gerrit Code Review
Jenkins
später mehr dazu …später mehr dazu …
Wie geht‘s jetzt weiter?
Und nu?
23Franz Zieris, zieris@inf.fu-berlin.de
Informationsquellen
• http://www.saros-project.org
– Offizielle Saros-Homepage
Falls ihr Verbesserungen vornehmen wollt:
Einloggen mit Zedat-Daten möglich, extra Freigabe für
Schreibzugriff ist aber nötig
• http://www.saros-project.org/getinvolved
– Einstieg Saros-Entwickler-Dokumentation
• http://www.saros-project.org/coderules
– Coding Guidelines and Rules
24Franz Zieris, zieris@inf.fu-berlin.de
Mailinglisten des Saros-Projekts
• Auf Sourceforge– dpp-devel@ die Entwicklerliste
– dpp-announce@ Release-Ankündigungen
– dpp-robot@ automatische Nachrichten (Bugtracker, Gerrit, Commits)
• Bei Spline– saros@ interne Mailingliste (Raumbelegungen, etc. – was für
Externe nicht relevant ist)
25Franz Zieris, zieris@inf.fu-berlin.de
Hausaufgaben zu Morgen
1. Saros als Nutzer/in ausprobieren Eclipse installieren (Version egal)
Saros von Update-Site: http://dpp.sf.net/update
Account aus Saros heraus anlegen• Im KVV bekannt geben
Saros-Sitzung mit Team-Mitgliedern starten und ein bisschen herumspielen
2. Entwicklungsumgebung aufsetzen Einstiegspunkt: http://www.saros-project.org/getinvolved
Installieren und einrichten der nötigen Software(Eclipse: Version nicht egal; IntelliJ; Git, …)
Nachdem Gerrit-Account angelegt wurde:Kurze E-Mail an zieris@inf.fu-berlin.de
Klonen über Gerrits SSH-Verbindung
Installieren des Gerrit Commit-Hooks
3. Saros als Entwickler/in starten Saros/E aus Eclipse heraus starten
Saros/E mit neuer HTML-GUI starten
Saros/I aus IntelliJ heraus starten
Saros/I mit neuer HTML-GUI starten
4. Abonnieren der Entwickler-Mailingliste https://lists.sourceforge.net/lists/listinfo/dpp-devel
Archiv der Liste auf Gmane.org finden.
5. Saros-Quellcode durchstöbern mit JTourBus Tour: „Some Basics“
Tour: „Architecture Overview“
Tour: „Invitation Process“
Tour: „Activity sending“
Tour: „Creating a new activity type“
6. Verantwortlicher Umgang mit Mängeln Im Produkt: Beim Ausprobieren von Saros
In der Doku: Beim Befolgen der Schritte
In der Doku: Beim Verfolgen der Touren
…
Schreibt Fehlerberichte, sodass wir später darüber sprechen können.
Franz Zieris, zieris@inf.fu-berlin.de 26
Praktiken
Hinweise zum Arbeitsstil
Franz Zieris, zieris@inf.fu-berlin.de 27
Arbeitsstil, Praktiken
• Zusatz-Scrum-Frage: Wer legt die Praktiken fest?
– Musterantwort: Das TeamStichwort: Selbstorganisation.
• Aber: Wir sind fies und machen zwei Vorgaben:
– geborgt aus Kanban: Kanban-Board (mehr dazu gleich)
– geborgt aus eXtreme Programming: Paarprogrammierung
lokal und verteilt
28Franz Zieris, zieris@inf.fu-berlin.de
Paarprogrammierung
Franz Zieris, zieris@inf.fu-berlin.de 29
• entwickeln zu zweit
• klassische (simple) Betrachtungsweise:
– Driver: tippt, treibt die Sitzung voran
– Observer: achtet auf Fehler (im Kleinen und Großen)
• nicht nur „programmieren“ (sondern auch entwerfen, testen, diskutieren …)
• im Projekt: Standardfall
– Ausnahmen müssen auf den Story-Cards begründet werden
Kanban
Grundidee
• Prozess visualisieren
– Aufgaben == Karten
– Stadien == Spalten
– Karten wandern durch
Spalten
• Work in Progress begrenzen
– Anzahl der Karten pro Spalte
• Engpass aufspüren
• Engpass beseitigen
Kanban-Board
Franz Zieris, zieris@inf.fu-berlin.de 30
praktisches Beispiel
Kanban-Board
31
Comic von: http://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000
Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
32Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
33Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
34Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
35Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
36Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
37Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
38Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
39Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
40Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
41Franz Zieris, zieris@inf.fu-berlin.de
Kanban-Board
42Franz Zieris, zieris@inf.fu-berlin.de
Kanban
• „Welche Spalten sollen wir für unser Kanban-Board nehmen?“– Das ist euch überlassen. Diskutiert.
– Ihr dürft das Board im Laufe der Zeit umstrukturieren,wenn es seinen Zweck nicht gut genug erfüllt.
• „Wie hoch soll das Limit für eine Spalte festgesetzt werden?“– Niedrig.
– Später eventuell anheben.
– Dran denken: Das Limit ist wichtig, um euch den aktuellen Flaschenhals aufzuzeigen.
• Bastelmaterial (z.B. Stifte und Karten) bekommt ihr von uns.
Franz Zieris, zieris@inf.fu-berlin.de 43
Irgendwas ist komisch …
Obacht, Fußangeln!
44Franz Zieris, zieris@inf.fu-berlin.de
Abweichungen vom normalen Ablauf
normal SWTP
origin ssh://<user>@saros-build:29418/saros.git ssh://<user>@saros-build2:29418/saros-swtp2016.git
45Franz Zieris, zieris@inf.fu-berlin.de
Sourceforge
Gerrit
saros-swtp2016
clone
replicate
reintegrate
develop/review
Githubsaros
saros
sarosHauptentwickler/in
Projektteilnehmer/in
In JTourBus werden keine Touren angezeigt!
• Rechtklick im JTourBus-View (Re)build Tours
46Franz Zieris, zieris@inf.fu-berlin.de
Was tun, wenn man nicht weiterkommt?
• Sitzt jemand neben dir/in der Nähe? Oder ist bei Skype online?– Frag‘ sie/ihn. Sonst:
1. Hat es konkret mit diesem Projekt zu tun?– Diesen Foliensatz anschauen, falls nichts gefunden:
– Frag‘ im KVV
2. Hat es mit Saros allgemein zu tun?– Recherche auf www.saros-project.org, falls nichts gefunden:
– Mail an dpp-devel@lists.sourceforge.net (englisch)
• Immer noch ratlos?– Sitzt jetzt vielleicht jemand neben dir?
– Notnagel: Franz Zieris, zieris@inf.fu-berlin.de
– in eiligen Fällen: Franz Zieris, Raum 007
Franz Zieris, zieris@inf.fu-berlin.de 47
Franz Zieris, zieris@inf.fu-berlin.de 48
Bis morgen!10 Uhr, Raum K048
Bildquellen
Franz Zieris, zieris@inf.fu-berlin.de 49
http://en.wikipedia.org/wiki/File:Pair_programming_1.jpg
http://en.wikipedia.org/wiki/File:Simple-kanban-board-.jpg
http://www.iconarchive.com/show/oxygen-icons-by-oxygen-icons.org/Status-mail-task-icon.html
http://www.iconfinder.com/icondetails/40736/128/certificate_icon
http://www.iconfinder.com/icondetails/8810/128/calendar_date_time_icon
http://www.iconarchive.com/show/crystal-clear-icons-by-everaldo/Mimetype-schedule-icon.html
http://www.iconfinder.com/icondetails/34297/128/friends_group_guy_msn_people_users_icon
http://www.iconarchive.com/show/vista-hardware-devices-icons-by-icons-land/Home-Server-icon.html
http://www.iconfinder.com/icondetails/61577/128/database_orange_icon
http://www.iconarchive.com/show/vista-hardware-devices-icons-by-icons-land/Computer-icon.html
http://git-scm.com/downloads/logos
https://wiki.jenkins-ci.org/display/JENKINS/Logo
http://www.iconarchive.com/show/pretty-office-2-icons-by-custom-icon-design/FAQ-icon.html
top related