sprintDoc

• 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

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

• 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

• 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)

• 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

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

• 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 die für alle oder einige Projektpartner relevant sind, werden in der CosmoCode-Own-Cloud abgelegt
• Glossar
• Unternehmensarchitektur (Wissen über den Kunden)

• Neuer Eintrag: Speichern
• 2019/04/20 15:57 93.171.30.45: 3
• 2019/04/20 15:57 93.171.30.45: 3
• 2019/04/20 15:57 93.171.30.45: 3
• 2019/04/20 15:57 93.171.30.45: 3
• 2019/04/20 15:57 93.171.30.45: 3
• Vollständiges Log anzeigen

Hilfe