Benutzer-Werkzeuge

Webseiten-Werkzeuge


softwaredevelopment:agil:start

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
softwaredevelopment:agil:start [2025/01/28 13:46] Martin Pabstsoftwaredevelopment:agil:start [2025/01/28 14:02] (aktuell) – [Agile Methoden] Martin Pabst
Zeile 29: Zeile 29:
 </WRAP> </WRAP>
  
-==== Agiles Modell für unser Projekt ==== +==== Agile Methoden ==== 
-Die nachfolgend beschriebene ([[https://subs.emis.de/LNI/Proceedings/Proceedings249/63.pdf|von P. Brichzin vorgeschlagene]]) Vorgehensweise orientiert sich an [[https://de.wikipedia.org/wiki/Scrum|Scrum]], jedoch wurde die Anzahl der Methoden, Rollen und Ereignisse deutlich reduziert und leicht adaptiert. Folgende Aspekte der Projektorganisation werden verwendet: +Die nachfolgend beschriebenen agilen Methoden ([[https://subs.emis.de/LNI/Proceedings/Proceedings249/63.pdf|siehe Paper von P. Brichzin]]) orientieren sich an [[https://de.wikipedia.org/wiki/Scrum|Scrum]], jedoch wurde die Anzahl der Methoden, Rollen und Ereignisse deutlich reduziert und leicht adaptiert.  
-=== Prototyping – iterativ inkrementelle Softwareentwicklung ===+=== Iterativ inkrementelle Softwareentwicklung ("Prototyping"===
 {{ :softwaredevelopment:agil:agil1.png?300}} {{ :softwaredevelopment:agil:agil1.png?300}}
 Regelmäßiger **Meilenstein (iterativer Prozess)** ist ein **lauffähiger und getesteter Prototyp**, der **mehr Funktionalitäten** bietet, **als der vorhergehende Prototyp Regelmäßiger **Meilenstein (iterativer Prozess)** ist ein **lauffähiger und getesteter Prototyp**, der **mehr Funktionalitäten** bietet, **als der vorhergehende Prototyp
 (inkrementell)**. Jedes **Inkrement umfasst dabei alle Schichten** (siehe Abb. rechts). Durch die Entwicklung "von Prototyp zu Prototyp" sehen wir nicht nur schrittweise unsere Software wachsen, sondern halten die Produktausrichtung und Reihenfolge der umzusetzenden Funktionalitäten flexibel. Weiterhin werden ungenaue Schnittstellenabsprachen zwischen Teilgruppen des Teams frühzeitig erkannt und können korrigiert werden. \\ \\  (inkrementell)**. Jedes **Inkrement umfasst dabei alle Schichten** (siehe Abb. rechts). Durch die Entwicklung "von Prototyp zu Prototyp" sehen wir nicht nur schrittweise unsere Software wachsen, sondern halten die Produktausrichtung und Reihenfolge der umzusetzenden Funktionalitäten flexibel. Weiterhin werden ungenaue Schnittstellenabsprachen zwischen Teilgruppen des Teams frühzeitig erkannt und können korrigiert werden. \\ \\ 
 +=== Sprint ===
 Das Zeitintervall, in dem ein Prototyp erstellt wird, wird **Sprint** genannt. Der Das Zeitintervall, in dem ein Prototyp erstellt wird, wird **Sprint** genannt. Der
 Sprint beginnt mit einer Planung, hat eine Implementierungsphase und schließt mit Sprint beginnt mit einer Planung, hat eine Implementierungsphase und schließt mit
 Tests ab. Ein Sprint soll sich sich in unseren Projekten über ca. 2 Wochen erstrecken. Tests ab. Ein Sprint soll sich sich in unseren Projekten über ca. 2 Wochen erstrecken.
 +
 +=== Retrospektive ===
 +Nach jedem Sprint treffen sich die Entwickler im Team zu einer 1 - 2-stündigen Besprechung, der **Retrospektive**. Sie reflektieren den Arbeitsprozess und haben Zeit, um außerhalb der täglichen Routine über vergangene Ereignisse und Verhaltensweisen nachzudenken. Das Team stellt sich beispielsweise folgende Fragen:
 +  * Was hat gut geklappt?
 +  * Was hat nicht gut geklappt?
 +  * Was wollen wir von nun an anders machen?
  
 === User Story === === User Story ===
Zeile 52: Zeile 59:
 Tasks sind elementare Aufgaben aus der Sicht der Entwicklerin/des Entwicklers, die durch die Unterteilung einer User Story entstehen. Tasks sind aufgeteilt in Titel und Beschreibung. Sie sind so kurz formuliert, dass sie auf ein „Post it“ passen. Sie sind Ergebnis einer Teambesprechung, testbar und in der Bearbeitung einem Paar zugeordnet. Tasks sind elementare Aufgaben aus der Sicht der Entwicklerin/des Entwicklers, die durch die Unterteilung einer User Story entstehen. Tasks sind aufgeteilt in Titel und Beschreibung. Sie sind so kurz formuliert, dass sie auf ein „Post it“ passen. Sie sind Ergebnis einer Teambesprechung, testbar und in der Bearbeitung einem Paar zugeordnet.
  
-=== Taskboard === +=== Project Board=== 
-Die gesamte Planung erfolgt über ein im Computerraum aufgehängtes Taskboard (s. Abb. rechts). Es dokumentiert über die **Spalten „to do“, „in progress“, „in test“ und „done“** zu Erledigendes und bereits Abgeschlossenes, sowie **wer aktuell an welchen Arbeitspaketen arbeitet**. Auch ist das **Sprintende** als nächster Meilenstein deutlich vermerkt. Bei den Arbeitspaketen, deren Reihenfolge durch die Priorisierung bestimmt wird, gibt es zwei unterschiedliche Granularitäten: User Stories und Tasks. Niedrig priorisierte müssen nicht von Anfang an als Tasks ausgearbeitet werden.+Die gesamte Planung erfolgt über ein im Computerraum aufgehängtes Project Board(s. Abb. rechts). Es dokumentiert über die **Spalten „to do“, „in progress“, „in test“ und „done“** zu Erledigendes und bereits Abgeschlossenes, sowie **wer aktuell an welchen Arbeitspaketen arbeitet**. Auch ist das **Sprintende** als nächster Meilenstein deutlich vermerkt. Bei den Arbeitspaketen, deren Reihenfolge durch die Priorisierung bestimmt wird, gibt es zwei unterschiedliche Granularitäten: User Stories und Tasks. Niedrig priorisierte müssen nicht von Anfang an als Tasks ausgearbeitet werden.
  
 {{ :softwaredevelopment:agil:projectboard.png?700 }} {{ :softwaredevelopment:agil:projectboard.png?700 }}
softwaredevelopment/agil/start.1738072018.txt.gz · Zuletzt geändert: 2025/01/28 13:46 von Martin Pabst

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki