Softwareprojekt: "Agile Softwareentwicklung in einem Open-Source-Projekt"

Modulbeschreibung

Typ:	Projekt (ECTS: 10)
Dozenten:	Franz Zieris Stephan Salinger
Sprache:	Deutsch
Zeitraum:	19.08.2013 bis 27.09.2013
maximale Teilnehmerzahl:	8 Vor Beginn der Veranstaltung wird es individuelle Vorstellungsgespräche geben
Terminhinweis:	Blockveranstaltung in der vorlesungsfreien Zeit: 19. August - 27. September 2013
Inhalt:	Dieses Softwareprojekt findet im Kontext eines Open-Source-Projektes statt. Die Teilnehmer arbeiten sich – nah an der Berufsrealität – in ein bestehendes Softwaresystem innerhalb eines komplexen Ökosystems ein. Sie folgen dabei einem agilen, iterativen Entwicklungsprozess und durchlaufen mehrfach die typischen Phasen eines Softwareprojekts. Die aus der Vorlesung „Softwaretechnik“ bekannten Methoden und Vorgehensweisen werden hierbei vertieft. Im Einzelnen: - Anforderungsermittlung - Architektur und Modularisierung verstehen, Schnittstellenspezifikation - Wartung, Reengineering bestehender Softwareteile - Durchsichten von Anforderungen, Implementierungen und Testfällen - Modul-, Integrations- und Systemtests; Testautomatisierung - Versions- und Konfigurationsverwaltung, Build-Prozesse, Continuous Integration - Dokumentation von Prozessen und Produkten Eine spätere Ausdehnung der Projekte in Form von Abschlussarbeiten ist möglich.
Zielgruppe:	Studierende im Bachelor- oder Masterstudium Informatik
Voraussetzungen:	- eigene Notebooks werden stark empfohlen - Für Bachelorstudenten: Softwaretechnik, Grundkenntnisse in Git (siehe Literaturhinweise), Grundkenntnisse in Scrum (siehe Literaturhinweise); hilfreich: ALP IV, Erfahrung in Java-GUI-/Eclipse-Plugin-Entwicklung - Für Masterstudenten: empfohlen: Sofwareprozesse
Literatur:	- Einstieg in Git:   Scott Chacon "Pro Git", Kap. 1-3 (evtl. 5)   René Preißel & Bjørn Stachmann "Git: Dezentrale Versionsverwaltung im Team - Grundlagen und Workflows", sehr gute und ansprechende Einführung (und darüber hinaus) - Einstieg in Scrum:   Ken Schwaber & Jeff Sutherland "Scrum Guide"

---

Organisatorisches

Anmeldung

Die Anmeldung erfolgt im KVV. Es gibt eine Warteliste, sodass Anmeldungen auch bei "0 freien Plätzen" möglich sind.

Mailingliste

Die Mailingliste dieser Veranstaltung ist se_p_agil at lists.spline.inf.fu-berlin.de. Jeder Teilnehmer muss sich auf dieser Mailingliste anmelden, und hat sicherzustellen, dass die Mails von dieser Mailingliste nicht in Junk/Spam/Bulk-Ordnern verschüttet gehen, da über diese Liste verbindliche Ankündigungen getätigt werden.

Erste Präsentation

Die erste Präsentation und reichlich Möglichkeiten zum Fragenstellen gab es am 10.4. -- die Folien stehen zum Download bereit.

FAQ

Sind die Voraussetzungen obligatorisch?
Die Vorlesung Softwaretechnik muss bestanden sein; die aufmerksame und (soweit möglich) aktive Lektüre der angegebenen Web-Literatur sollte zur Aneignung der Grundkenntnisse in Git und Scrum ausreichen. Die Anschaffung des Git-Buches ist ausdrücklich nicht erforderlich.

Wie nötig sind eigene Notebooks?
Die PC-Pool-Rechner können genutzt werden, aber nur in begrenztem Umfang an persönliche Vorlieben im Entwicklungsprozess angepasst werden. Die größte Flexibilität hat man mit eigener Hardware.

Wie wird die Anwesenheit geregelt?
Es wird von 40-Stunden-Wochen ausgegangen, was einem Tagespensum von 8 Stunden entspricht. In der Kernarbeitszeit von 10 - 15 Uhr müssen alle Teammitglieder anwesend sein (exkl. Mittagspause).

Meine Frage wurde nicht beantwortet!
Hier hilft eine Kontaktaufnahme mit Franz Zieris, z.B. per Mail: franz.zieris [at] fu-berlin.de.

---

Scrum

Product Backlog

Zum Product Backlog.

Allgemeine Festlegungen

• Das Daily Scrum findet Di-Fr um 12:00 Uhr statt.
• Montags findet zwischen 10 und 12 Uhr das Sprint Planning statt; ein Daily Scrum ist hier unnötig.
• Der Sprint Review und die Sprint Retrospektive werden am Freitag von 16 bis 17 bzw. 17 bis 18 Uhr stattfinden.

Spezielle Festlegungen

• Von Arbeitsbeginn bis zum Daily Scrum um 12 Uhr wird im Pair Programming im Promiscuous Mode (Taktung: 30 Minuten) gemacht. Dies ist zum intensiven Wissensaustausch als eine Art "Synchronisierungsphase" für den restlichen Arbeitstag verstanden.
  • Das Daily Scrum an sich ist daher auf eine Dauer von 5 Minuten beschränkt.
• Bis 16 Uhr jedes Tages muss 1 Commit integriert sein.
  • Die restliche Zeit ist nicht für weitere Funktionalität, sondern für Aufräumarbeiten wie z.B. Refactorings gedacht.

Sprint Goals und Backlogs

Sprint 1

Der Punkt NiceCursor wird in folgende Unterpunkte geteilt:

• NiceCursor-1: siehe Sprint Goal weiter unten
• NiceCursor-2: es wird ein echtes Fähnchen dargestellt, das auch den Namen des Buddys anzeigt. Es ist programmatisch konfigurierbar, unter welchen Bedingungen es angezeigt/ausgeblendet wird.

Spring Goal -- am Ende der KW 35:

• (NiceCursor-1) haben wir ein Saros, das zusätzlich für jeden Sitzungsteilnehmer einen strichförmigen Cursor plus farblicher Markierung anzeigt, sodass Positionen im Text (auch bei längeren Markierungen) eindeutig sind;
  • Als farbliche Markierung gilt jede Form (Rechteck, Ellipse, etc.) in der Farbe des jeweiligen Nutzers, in konstantem, nicht allzu großem Abstand vom senkrechten Cursor.
• (SelectionAnno) werden längere Text-Markierungen bei den anderen Sitzungsteilnehmern nicht zeilenweise hervorgehoben, sondern so wie lokale Markierungen dargestellt (siehe vergleichender Screenshot im Product Backlog).
• Außerdem sind Bug-782 und Bug-609 behoben.

Sprint Backlog -- um das Sprint Goal zu erreichen, sollte zum Stand-Up am Mittwoch das Folgende erreicht sein:

• Fix von Bug-609 mindestens in Spalte "Review"
• Punkt SelectionAnno mindestens in Spalte "Review"
• Strichförmiger Cursor für NiceCursor-1 mindestens in Spalte "Review"
• Restliche Arbeiten sind bis auf Task-Ebene runtergebrochen

Sprint Ergebnis -- Mängelliste

Sprint 2

Sprint Goal -- am Ende der KW 36:

• (NiceCursor-1) sind die entdeckten Mängel beim RemoteCursor behoben;
• (SelectionAnno) sind die entdeckten Mängel bei der SelectionAnnotation behoben;
• (NiceCursor-2) haben wir ein Saros mit Fähnchen an RemoteCursorn, das folgende Sonderfälle aushält:
  • Cursor am oberen Bildschirmrand
  • Cursor am rechten Bildschirmrand
  • Cursor des anderen außerhalb des sichtbaren Bereiches (Hinweis, falls rechts außerhalb. Nichts, falls oben oder unten außerhalb.)
  • Verdeckung des eigenen Cursors, falls möglich Falls weitere Sonderfälle entdeckt werden, müssen wir sie ebenfalls behandeln.
• (OwnCursor) kann der eigene Cursor wie die RemoteCursor mit einem Fähnchen versehen werden. In den Preferences kann dieses Verhalten ein- und ausgeschaltet werden.
• Bug-782 und Bug-609 sind behoben/geschlossen.
• (WbReintegrate-1) wissen wir so über den Reintegrierungsplan bescheid, dass wir beim nächsten Sprint Planning gut schätzen können. Außerdem sind die Aufwärmpatches (erster und zweiter) integriert.
• Gerrit #875 ist integriert.

Sprint Ergebnis -- Mängelliste

Sprint 3

Sprint Goal -- am Ende der KW 37:

• sind alle Mängel aus Sprint 2 behoben
• alle Patches von WbReintegrate sind integriert

Sprint Ergebnis -- Mängelliste

Sprint 4

Sprint Goal -- am Ende der KW 38:

• sind alle Mängel aus Sprint 3 behoben;
  • Das schließt die fehlenden 12 Patches von WbReintegrate ein. Defekte und Mängel an der internen Code-Qualität sind dabei entweder direkt zu beheben, oder im Quellcode-Code als solche zu kennzeichnen.
• (OwnCursor/RemoteCursor): es werden die Fähnchen in der Nähe des rechten Editor-Rands so umgedreht, dass sie immer zu lesen sind;
• (OwnCursor/RemoteCursor): es sind die Saros-Preferences so umstrukturiert, dass die ContributionAnnotation- und Fähnchen-Einstellungen auf einer Seite ("Appearances") konfiguriert werden können.
  • Dabei können eigene und fremde Fähnchen de-/aktiviert werden; eigene Fähnchen aber nicht ohne die fremden.
  • Letzteres Verhalten der GUI ist durch einen STF-Test abgesichert.
• Zusätzlich wird die interne Code-Qualität verbessert durch:
  • Gerrit #1033 "[REFACTOR] Add abstract class for annotation with need for the username"
  • Eine Dokumentation der verwendeten "Strategien" zum Zeichnen von Fähnchen (inkl. Cursor) und SelectionAnnotation.
  • Auslesen der helleren Farbwerte direkt aus der plugin.xml, anstelle einer Berechnung.

Sprint Backlog
Zur Strukturierung der Woche dienen die Whiteboard-Patches (= WB, je 5h) als "Konstanten", die restliche Zeit wird für die restlichen Aufgaben verwendet.
Hinweis: Chris arbeitet in dieser Woche nicht gleichmäßig, sondern (10, 10, 10, 8, 0) Stunden; sein Beitrag zum Sprint Review und Retrospektive bereitet er entsprechend vor, und sendet ihn am Donnerstag-Abend an Franz.

 Mo: 2x WB  (Rest: ( 6 + 6 +  8) - 2x5 = 10h)
 Di: 3x WB  ( "" : ( 8 + 8 + 10) - 3x5 = 11h)
 Mi: 3x WB  ( "" : ( 8 + 8 + 10) - 3x5 = 11h)
 Do: 3x WB  ( "" : ( 8 + 8 +  8) - 3x5 =  9h)
 Fr: 1x WB  ( "" : ( 6 + 6 +  0) - 1x5 =  7h)

Sprint 5

Sprint Goal -- am Ende der KW 39:

• Whiteboard:
  • sind alle aus Nutzerperspektive sichtbaren Probleme als Einträge im Bugtracker hinterlegt
  • sind wichtige Klassen refaktorisiert/aufgeräumt oder zumindest in Form von konstruktiven TODOs markiert
  • sind für wichtige Klassen mindestens 6 JTourBus-Toren angelegt
  • ist das Rauten-Verbindung-Problem entweder gelöst oder wenigstens als Bugtracker-Eintrag hinterlegt
• Release-Vorbereitung:
  • sind alle im Projekt implementierten Features in so zusammengefasst, dass ein flächendeckender Akzeptanz durchgeführt werden kann
  • sind alle seit Saros 13.3.22 aus Nutzerspektive sichtbaren Änderungen ebenso zusammengefasst und aufbereitet
• Fähnchen-Preferences
  • es gibt einen besseren STF-Test, der die Logik der beiden Einstellungensstufen testet (eigene und fremde Fähnchen)
  • das Häkchen für die Aktivierung des lokalen Fähnchens ist leicht eingerückt
  • die Änderungen an den Preferences werden nicht sofort, sondern erst nach Bestätigung (OK/Apply) sichtbar
• Fähnchen-Logik
  • im Umfeld eigenen Cursors werden fremde Fähnchen möglichst nur dann ausgeblendet, wenn sie tatsächlich stören (also nicht im Umfeld von drei kompletten Zeilen)
  • insbesondere sollen Fähnchen immer komplett oder gar nicht, nicht aber halb gezeichnet werden
  • sollte sich die verantwortliche Logik für das Halbe-Fähnchen-Versagen isolieren lassen, ist ein dafür ein Unit-Test zu schreiben
• Selection-Annotation:
  • Linker (alter) und rechter (neuer) Kamm einer Selektion werden immer in der gleichen Ebene gezeichnet, also weder durch lokale noch durch entfernte Selektionen getrennt
  • Auch bei eingeklappten Codestellen werden Selektionen immer wie lokal dargestellt, d.h. auch die letzte Zeile nicht bis zum Editorrand, sondern nur bis zum Selektionsende gezeichnet.
  • am rechten Editorrand
• Annotationen allgemein:
  • Die Editor-API ist refaktorisiert
  • Es gibt eine JTourBus-Tour die die verwendeten eigenen Zeichnungsstrategien erklärt, sodass zukünftige Anpassungen leichter vorzunehmen sind. In dieser Tour wird die Problematik des horizontalen Scrollens erläutert.

Nachtrag (2013-09-25): der Punkt YellowDot aus obigem Sprint-Goal wird nicht vom Projektteam selbst erarbeitet, somit trägt es auch keine Verantwortung für die Umsetzung dieses Punktes.

---

Material

Folien der Vorträge

• Vor-Vorstellung des Projekts (10.04.2013)

• Vorstellung des Projekts (19.08.2013)
• Vertiefung SWT und Projekthinweise (20.08.2013)
• Bugs zur Eingewöhnung (21.08.2013)

Vorlagen für Wochenbericht

• Microsoft Office Word-Vorlage
• OpenDocument-Vorlage
• PDF zum Ausdrucken

Bugs und Mini-Features zum Angewöhnen

ID	Area	Short Description	Priority	Status
Bug-782	Chat	Chatroom is not auto opened when receiving a message	high
ChatLink	Chat	Ability to follow links from the chat	high
Bug-609	User Interface	Wizards are not nicely displayed on Ubuntu	high
Bug-804	Awareness	„non-shared file open“ is shown but not true for no open file	medium
ChatOffline	Chat	Remove offline buddies from chat “ left the chat”	medium
Bug-803	Consistency	New untitled file causes inconsistencies	low
Bug-765	User Interface	SessionView Entries sometimes collapsed	low
Bug-719	User Interface	AutoComplete remains open even if according code was deleted underneath.	least