sprintDoc

project_pattern
ProjektstatusLaufend
Teammitgliederdhue, agoh, mgro, voigt
Projektstart2015-03-01
Projektende2017-05-31
Projektbudget in Euro209 000
KundeBMBF/DLR
Produkt(e)sprintdoc

Team / Projektrollen

Team Name (Link auf Profil) Telefon Mail Aufgabenbereich
Kunde
Kunde
Intern
Intern

Beschreibung

  • Im sprintDoc Projekt wollen wir ein zentrales Problem in agilen Softwareprojekten lösen: den Mangel an brauchbarer Dokumentation. In agilen Prozessen steht die Bereitstellung von releasefähigen Software-Artefakten im Fokus; Dokumentation ist nachrangig. Dokumentation ist ohnehin das ungeliebte Kind von Softwareentwicklern. Mit dem sprintDoc Forschungsprojekt wollen wir dieses Problem angehen und untersuchen, welche Dokumentationsarten benötigt werden, welche Relevanz diese haben, und wie die Dokumentation sich in der agilen Projektmethodik integrieren lässt.
  • Ziel ist die Entwicklung eines Methoden- und Werkzeugsets für die Dokumentation in agilen Softwareprojekten und dessen prototypische Umsetzung und Evaluierung bei zwei Pilotanwendern
  • Der Werkzeugprototyp setzt dabei auf dem DokuWiki auf

Dokumentationsziele

  • Wissen/Erfahrungen sichern (Teammitglieder nicht mehr verfügbar)
  • Nachvollziehbarkeit von (Design-) Entscheidungen ermöglichen
  • Entwicklung, Verstehen und Festhalten eines Gesamtbildes der Anwendung

Risiken

  • Technische Risiken:
    • Integration mit agilen Projektmanagement-Werkzeugen
      • Schnittstellen zu JIRA in den Varianten „hosted“ und „server“
      • Übertragbarkeit des Ansatzes auf GitHub und GitLab
    • Überführung in ein marktfähiges Produkt nach Projektende (hoher Entwicklungsaufwand)
  • Organisatorische Risiken:
    • Abstimmungsaufwand mit Pilotanwendern und mögliche Verzögerungen
    • Gedeckeltes Budget durch Projektantrag und Zuwendungsbescheid
    • Abwägung von wissenschaftlich sinnvollen Anforderungen und wirtschaftlich machbaren Feature-Umsetzungen

Liefergegenstände / Lieferumfang

  • Zum Projektende müssen folgende Dinge vorliegen:
    • Analyseergebnisse (Verantwortung: OVGU)
    • Technisches Konzept Werkzeug (Verantwortung: CC)
    • Methodenkonzept (Verantwortung: OVGU)
    • sprintDoc-Prototyp (Verantwortung: CC)
    • Evaluierungsbericht (Verantwortung: OVGU)

Meilensteinplanung

  • Dezember 2015: Prototyp Alpha mit Fokus initialer MagicMatcher (JIRA-Anbindung)
  • März 2016: Prototyp Beta mit Fokus initialem Struct und initialem Farming
  • Juni 2016: Prototyp Gamma mit Fokus stabilem Struct, Farming und Multi-Projekt-MagicMatcher
  • Oktober 2016: Prototyp Delta mit Fokus Abrundung bestehender Komponenten und GitHub-Anbindung
  • Januar 2017: Prototyp Epsilon mit Fokus Usability-Verbesserungen (Frontend)
  • Mai 2017: Finaler Prototyp

Kosten /Aufstellung der Aufwände

  • ca. A Personentage Projektmanagement (inkl. Konzeption und Evaluierung)
  • ca. B Personentage Administration
  • ca. X Personentage Backend
  • ca. Y Personentage Frontend

Abnahme Spezifikationen/Kriterien

  • Folgende Stufen sind zu beachten:
    • in Status Documentation schieben, wenn Feature/Bugfix ist aus Sicht Entwickler gelöst und ausgetestet
    • in Status Acceptance schieben, wenn Feature dokumentiert ist
    • in Status Done schieben, wenn im Sprint-Review/Sprint-Planning durch Product-Owner (Detlef) abgenommen
  • Change-Requests bzw. Bug-Reports können durch Pilotanwender, Product-Owner und Forschungspartner (Stefan) beim Evaluieren und Testen entstehen und werden im JIRA aufgenommen und spätestens im folgenden Sprint-Planning besprochen

Dokumente

Logbuch

  • 2016/09/22 09:17 Stefan Voigt: Struct ist mit Bureaucracy integriert
  • 2016/09/22 09:16 Stefan Voigt: MagicMatcher ist jetzt multiprojektfähig
  • 2016/09/22 09:16 Stefan Voigt: Erste Evaluierungsergebnisse der Pilotanwender liegen vor
  • 2016/09/22 09:16 Stefan Voigt: Farmer-Plugin und Farmsync-Plugin kann jetzt getestet werden
  • 2016/09/22 09:15 Stefan Voigt: Erstes Release vom Struct Plugin

Zugehörige Dokumentationspatterns

Hilfe

Zugehörige Change Requests

Zur Anlage eines neuen Change-Requests bitte dessen Namen hier eingeben:

Zugehörige Features

Nichts gefunden

Zur Anlage eines neuen Features bitte dessen Namen hier eingeben:

Zugehörige Komponenten

Nichts gefunden

Zur Anlage eines neuen Features bitte dessen Namen hier eingeben:

Zugehörige Learnings

Zur Anlage eines neuen Learnings bitte dessen Namen hier eingeben:

Zugehörige Meetings

SeiteMeeting topicDate of meetingProject(s)ParticipantsRequirements
2015-04-16_kick-offOffizieller Kickoff2016/09/22sprintDocdhue, agoh, voigt
2016-02-25_telko_evaluierungRückmeldungen zur Evaluierung bei Pilotanwendern2016/09/25sprintDocdhue, voigt
2016-08-30_planung_sprint_12Sprintmeeting2016/08/30sprintDocvoigt, dhue, mgro, agohGithub-Support als Repo, GitHub-Support als Issue-Tracker (JIRA-Ersatz)
wemeet2019/06/25sprintDocmgro, kkos
CSV-Export

Zur Anlage eines neuen Meetings bitte dessen Namen hier eingeben (Vorschlag: YYYY-MM-DD Meetingthema):

Zugehörige Requirements


Zugehörige Dokumentationspatterns

Hilfe

Zugehörige Change Requests

Zur Anlage eines neuen Change-Requests bitte dessen Namen hier eingeben:

Zugehörige Learnings

Zur Anlage eines neuen Learnings bitte dessen Namen hier eingeben:

Zugehörige Meetings

SeiteMeeting topicDate of meetingProject(s)ParticipantsRequirements
2015-04-16_kick-offOffizieller Kickoff2016/09/22sprintDocdhue, agoh, voigt
2016-02-25_telko_evaluierungRückmeldungen zur Evaluierung bei Pilotanwendern2016/09/25sprintDocdhue, voigt
2016-08-30_planung_sprint_12Sprintmeeting2016/08/30sprintDocvoigt, dhue, mgro, agohGithub-Support als Repo, GitHub-Support als Issue-Tracker (JIRA-Ersatz)
wemeet2019/06/25sprintDocmgro, kkos
CSV-Export

Zur Anlage eines neuen Meetings bitte dessen Namen hier eingeben (Vorschlag: YYYY-MM-DD Meetingthema):

Zugehörige Requirements

Impressum und Datenschutzerklärung