Hausarbeit im Rahmen des Lernportfolios im Master-Modul ‚Management von IT Projekten‘. Dokumentation und Reflexion des Gelernten.
In der Produkt- und Softwareentwicklung werden häufig Projekte beauftragt, bei denen die Anforderungen vor Projektbeginn nicht vollständig definiert werden können. Es gibt Unsicherheiten, die den Umfang oder die Detaillierung betreffen. Zusätzlich ändern sich auch während des Projektes die Anforderungen. Daraus entstehen zusätzlich zu den normalen Projektrisiken weitere unvorhersehbare Risiken in Hinsicht auf die Skalierung und Umsetzung. Durch die unterschiedlichen Detaillierungsgrade kann es vorkommen, dass das beauftragte Produkt an einigen Stellen „besser“ entwickelt wurde als an anderen. Um ein gänzlich zufriedenstellendes und detailliertes Produkt entwickeln zu können, wird das agile Vorgehensmodell des Projektmanagements durch Nutzung von Scrum eingesetzt. Bei Einsatz dieses Vorgehensmodells werden mit dem Auftraggeber häufig Rahmenverträge geschlossen, damit die Vergütung des gesamten Projektes im inkrementellen Vorgehen abgesichert ist. Für jeden Projektabschnitt werden dann gesondert Werkverträge geschlossen, die dem jeweiligen Aufwand angepasst sind.
Inhaltsverzeichnis
1. SCRUM
1.1 Inventur
1.2 Inhalte
1.2.1 Ausgangsproblem
1.2.2 Methode, Lösung bzw. Vorgehen
1.3 Reflexion
2. KANBAN
2.1 Inventur
2.2 Inhalte
2.2.1 Ausgangsproblem
2.2.2 Methode, Lösung bzw. Vorgehen
2.3 Reflexion
3. Requirement Engineering
3.1 Inventur
3.1.1 Ausgangsproblem
3.1.2 Methode, Lösung bzw. Vorgehen
3.2 Reflexion
4. Multiprojektmanagement
4.1 Inventur
4.1.1 Ausgangsproblem
4.1.2 Methode, Lösung bzw. Vorgehen
4.2 Reflexion
Literaturverzeichnis
1. SCRUM
1.1 Inventur
- Persönlich: Kenntnisse aus Vorlesungen, sollte im Unternehmen eingesetzt werden, aber Einführung hat sich verzögert
- Agiles Projektmanagement
- Häufig in Unternehmen zur Softwareentwicklung genutzt
- Unterteilung in verschiedenen Phasen, die „Sprints“ genannt werden
- Unterschiedliche Rollen innerhalb eines Teams
- Scrum Master
- Product Owner
- Scrum Entwicklungsteam
- Verschiedene Rollen: Entwickler, Tester, …
- Basiert auf PDAC (Plan – Do – Act – Check) Zyklus
- Product Backlog Items (PBIs), die die zu erledigenden Aufgaben aufführen
- PBIs werden priorisiert nach Eigenschaften = wichtigstes zuerst, dann nebensächliches
- Häufige Rücksprache und Abstimmung über Ergebnisse und offene Aufgaben innerhalb des Teams (Meetings, die täglich, wöchentlich oder am Ende einer Phase stattfinden)
1.2 Inhalte
1.2.1 Ausgangsproblem
In der Produkt- und Softwareentwicklung werden häufig Projekte beauftragt, bei denen die Anforderungen vor Projektbeginn nicht vollständig definiert werden können. Es gibt Unsicherheiten, die den Umfang oder die Detaillierung betreffen. Zusätzlich ändern sich auch während des Projektes die Anforderungen. Daraus entstehen zusätzlich zu den normalen Projektrisiken weitere unvorhersehbare Risiken in Hinsicht auf die Skalierung und Umsetzung. Durch die unterschiedlichen Detaillierungsgrade kann es vorkommen, dass das beauftragte Produkt an einigen Stellen „besser“ entwickelt wurde als an anderen. Um ein gänzlich zufriedenstellendes und detailliertes Produkt entwickeln zu können, wird das agile Vorgehensmodell des Projektmanagements durch Nutzung von Scrum eingesetzt. Bei Einsatz dieses Vorgehensmodells werden mit dem Auftraggeber häufig Rahmenverträge geschlossen, damit die Vergütung des gesamten Projektes im inkrementellen Vorgehen abgesichert ist. Für jeden Projektabschnitt werden dann gesondert Werkverträge geschlossen, die dem jeweiligen Aufwand angepasst sind.
1.2.2 Methode, Lösung bzw. Vorgehen
Scrum ist ein Framework, mithilfe dessen durch zyklisches Planen und Umsetzen einzelner Anforderungsteile letztendlich ein den Anforderungen des Auftraggebers entsprechendes Produkt geliefert werden kann. Durch das zyklische Planen werden Entscheidungen teilweise erzwungen, da der vorgegebene Zeitrahmen nicht überschritten werden darf.
Das Projekt wird in sogenannte Sprints unterteilt. Diese dauern maximal einen Kalendermonat bzw. 30 Tage. Es ist jedoch möglich diese Zeit auf beispielsweise 15 Tage zu verringern. Aus dem Anforderungskatalog (Product Backlog, im Folgenden genauer beschrieben) werden einzelne Anforderungen herausgezogen, im Sprint Backlog (ebenfalls im Folgenden genauer beschrieben) festgesetzt und anschließend umgesetzt. Hieraus resultiert, dass jeder Sprint ein potenziell lauffähiges Produktinkrement liefert. Dieses wird dem Auftraggeber vorgestellt, der dadurch Zwischenergebnisse erhält und anhand dieser seine Anforderungen ggf. spezifizieren oder ändern kann. Durch das Vorgehen kann der Nutzen des Produktes im Projektverlauf maximiert werden. Damit das Sprintergebnis nutzbar ist, muss ein Sprint alle Bereiche der Entwicklung abdecken (Analyse, Design, Umsetzung, Implementierung, Test, …). Kann eine Anforderung nicht vollständig umgesetzt werden, wird sie in einem späteren Sprint fortgesetzt und der aktuelle Sprint dennoch zum festgelegten Termin beendet.
Das bereits erwähnte Product Backlog ist der Anforderungskatalog, in welchem alle Anforderungen des Projektes aufgeführt werden. Jede Anforderung wird als P roduct B acklog I tem (PBI) aufgeführt und erhält eine Priorität, die anhand der Wichtigkeit für das Projekt gemessen wird. Nur Anforderungen, die auch im Product Backlog stehen, existieren und werden umgesetzt. PBIs definieren sich dadurch, dass sie unabhängig voneinander, verhandelbar hinsichtlich Priorität und Sinnhaftigkeit, wertbeitragend, zeitlich klar schätzbar, klein und testbar sind. Der Product Owner, dessen Rolle im Folgenden noch beschrieben wird, definiert und priorisiert die PBIs anhand von Wert, Risiko und Verzögerungskosten. Durch die Beschreibung der PBIs durch Epics (Prozesse) und User Stories (Prozessausschnitte bzw. Tätigkeitsschritte) können die PBIs genau definiert und getestet werden. Ist eine erfolgreiche Abbildung möglich, kann definiert werden, dass der entsprechende PBI als „abgeschlossen“ markiert werden kann.
Im sogenannten Sprint Backlog werden die PBIs aufgeführt, die für den aktuellen Sprint ausgewählt wurden. Diese werden wiederum in feinere Aufgaben (Tasks) unterteilt, die, entsprechend der verschiedenen Funktionen der Teammitglieder, ein Enddatum, einen Status (nicht begonnen, in Bearbeitung, vollständig), eine zugewiesene Person und eine genaue Aufgabenbeschreibung enthalten (z.B. testen, programmieren der Schnittstelle XY, …). Für den erfolgreichen Abschluss eines Sprints werden Test driven development (TDD), fortlaufende Versionierung, Regressionstests, peer programming und weitere Techniken genutzt. Bevor ein PBI in das Sprint Backlog übernommen wird, muss das gesamte Team bestätigen, dass dieses PBI innerhalb des Sprints machbar ist. Dieser Schritt erfolgt im „Sprint Planning Meeting“, das später genauer beschrieben wird.
Bevor auf die verschiedenen Meetings eingegangen werden kann, die den Ablauf eines Sprints strukturieren, müssen zunächst die Rollen der verschiedenen Mitglieder innerhalb des Scrum-Teams vorgestellt werden: Der Scrum Master, der Product Owner und das Entwicklungsteam.
Ziel des Scrum Masters ist, dass Scrum erfolgreich im Projekt eingesetzt wird. Er besitzt umfassende Kenntnisse über die Technik. Er hilft bei der Einführung von Scrum und unterstützt das Team, insbesondere den Product Owner in methodischen Fragen. Er moderiert die Meetings, leitet durch das Projekt, trainiert das Entwicklungsteam in der Selbstorganisation und beseitigt Hemmnisse. Er ist allerdings kein Projektleiter und trägt dadurch auch keine Verantwortung für die Ergebnisse. Eine weitere wichtige Aufgabe ist, dass er das Team vor Störungen von außen schützt.
Der Product Owner hat als Ziel, dass der Produktnutzen maximiert wird, indem die Produkteigenschaften priorisiert werden. Er verwaltet und pflegt die einzelnen PBIs, formuliert diese für jeden verständlich und transparent und priorisiert diese anschließend. Dabei definiert er klar, woran als nächstes gearbeitet werden soll. Als Schnittstelle zum Auftraggeber vertritt er dessen Interessen. Dementsprechend besitzt er quasi eine Leitungsfunktion, allerdings keine Weisungsbefugnisse gegenüber dem Entwicklungsteam.
Das Entwicklungsteam hat als oberstes Ziel die Erstellung eines erfolgreichen und wartbaren Produktes. Da wie bereits zuvor erwähnt alle Bereiche der Entwicklung abgedeckt werden müssen, ist das Team funktionsübergreifend und besitzt alle für die Produkterstellung notwendigen Fähigkeiten. Es ist selbstorganisiert und die einzelnen Personen arbeiten gemeinsam an einer Lösung. Das Entwicklungsteam unterstützt den Product Owner in der Detaillierung der einzelnen Anforderungen, muss allerdings widersprechen, wenn der Umfang eines einzelnen Sprints zu groß wird.
Gemeinsames Ziel des gesamten Scrum-Teams ist also die Erstellung eines erfolgreichen und wertvollen Produktes. Innerhalb des Teams gibt es keine Arbeitgeber-Arbeitnehmer-Beziehung zwischen Product Owner und Entwicklungsteam und jedes Scrum-Team ist unabhängig von anderen Teams. Da es keinen offiziellen Projektleiter gibt, verteilen sich dessen Aufgaben innerhalb des Teams durch die Selbstorganisation und verschiedenen Meetings. Es ist vorgegeben, dass das Team zwischen 4-9 Personen umfasst. Dadurch wird automatisch in der Projektgröße eingeschränkt. Größere Projekte werden durch Large Scale Scrum (LeSS) abgebildet. Dafür wird Scrum durch Regeln ergänzt und die Aufgaben des Product Owners und Scrum Masters in Umfang und Aufwand erweitert. Die Teams werden auf bis zu acht erhöht. Auch die Meetings werden hinsichtlich der Struktur verändert. Darauf soll in dieser Arbeit allerdings nicht detaillierter eingegangen werden.
Innerhalb von Scrum gibt es fünf verschiedene Meetings, die zu verschiedenen Zeitpunkten eines Sprints stattfinden. Im Folgenden sollen die einzelnen Meetings kurz beschrieben werden.
Vor Beginn eines jeden Sprints finden das sogenannte Backlog Refinement Meeting, auch Backlog Grooming genannt, und das Sprint Planning Meeting statt.
Das Backlog Refinement Meeting ist ein Meeting, welches nicht zwingend durchgeführt werden muss, jedoch zur Vorbereitung des Sprint Planning Meetings und als Unterstützung für den Product Owner dient. Jegliche PBIs werden innerhalb von vier Stunden, bei einem Sprint von 15 Tagen innerhalb von zwei Stunden, im Team besprochen. Es werden Prioritäten für die einzelnen PBIs festgelegt und Aufwände geschätzt. Ein weiterer wichtiger Aspekt sind hierbei die Abnahmekriterien für die einzelnen PBIs, die definitiv erfüllt werden müssen, damit ein PBI als erfolgreich umgesetzt gilt. Durch User Stories werden die PBIs dabei sinnvoll in umsetzbare Umfänge verkleinert, sodass sie innerhalb eines Sprints erfolgreich umgesetzt werden können.
Am darauf folgenden Sprint Planning Meeting nimmt ebenfalls das gesamte Team teil. Es ist zeitlich auf maximal acht Stunden bei einem Sprint von 30 Tagen und auf vier Stunden bei einem Sprint von 15 Tagen begrenzt. Einzelne PBIs werden betrachtet und aus diesen Tasks abgeleitet. Ist ein PBI ausreichend definiert, d.h. ca. 60% der Tasks wurden definiert und weitere ergeben sich im Verlauf des Sprints, wird dieser in das Sprint Backlog übernommen und für den kommenden Sprint als Ziel gesetzt. Wichtig ist dabei, dass alle Teammitglieder zustimmen, dass der PBI innerhalb eines Sprints erledigt werden kann. Ist dieses nicht der Fall, muss der PBI verkleinert bzw. verfeinert werden, denn oberstes Ziel bleibt, dass am Ende eines jeden Sprints ein potenziell auslieferbares Produkt erstellt wurde. Es werden noch keine Zuweisungen der Tasks an einzelne Teammitglieder gemacht, diese Zuweisungen erfolgen erst im Daily Scrum Meeting.
Das Daily Scrum Meeting findet täglich zur gleichen Zeit, am selben Ort, für fünf bis 15 Minuten statt und wird auf der Basis von drei Fragen durchgeführt: Was habe ich gestern gemacht? Was mache ich heute? Was hat mich behindert? Am Meeting nehmen der Scrum Master und das Entwicklungsteam teil. Es ist dem Team selbst überlassen, ob der Product Owner ebenfalls teilnimmt. Das Team kann durch Beantwortung der drei Fragen offene Punkte und Probleme diskutieren und sich gegenseitig unterstützen. Außerdem werden die offenen Tasks untereinander verteilt und somit die sich in Ausführung befindliche Arbeit (Work in Progress) immer weiter minimiert. Fallen den Mitgliedern weitere noch nicht aufgeführte Tasks auf, die ebenfalls erledigt werden müssen, wird das Sprint Backlog ergänzt. Als Hilfsmittel für das Meeting gibt es das sogenannte Taskboard, an dem alle Tasks mit dem jeweiligen Zustand (neu, in Bearbeitung, abgeschlossen) aufgeführt. Es schafft einen Überblick über alle Aufgaben. Das Sprint Burndown Chart ist ein Diagramm, welches im Verhältnis von Zeit und Aufwand einen Überblick über den verbleibenden Aufwand gewährt. Innerhalb des Diagramms gibt es eine optimale Kurve. Liegt das Team oberhalb oder unterhalb dieser Kurve kann schnell erkannt werden, ob das Team zeitlich im Rahmen liegt oder, ob es schneller arbeiten muss. Große Diskrepanzen zwischen Zeit und Aufwand werden dadurch ebenfalls zeitnah aufgedeckt.
Nachdem ein Sprint beendet wurde findet das Sprint Review Meeting statt. Zu diesem Meeting erscheinen das gesamte Team und die Stakeholder. Das Meeting ist in vier Abschnitte unterteilt. Zunächst wird der aktuelle Stand vorgestellt und das Sprintinkrement in einer Livedemonstration gezeigt. Anschließend wird anhand der PBIs erläutert, welche Aspekte erledigt wurden und welche nicht.
Im dritten Abschnitt geben die Stakeholder und der Product Owner Feedback zum Sprintinkrement und können auf Basis dieses Inkrementes ihre Anforderungen spezifizieren oder ändern. Im vierten und letzten Abschnitt des Meetings werden die neuen bzw. geänderten Anforderungen und nächsten Schritte diskutiert und schriftlich fixiert.
Da das Ziel von Scrum ist, dass es auch als Lernplattform für alle Beteiligten dient, gibt es ein weiteres Meeting nach Beendigung eines jeden Sprints. Das Retrospective Meeting dient dem Scrum Team dazu die eigenen Fähigkeiten zu verbessern. Der vergangene Sprint wird dazu von allen Mitgliedern bewertet und es wird herausgearbeitet was gut und was schlecht lief.
Auf Basis der erarbeiteten Ergebnisse, werden Maßnahmen für zukünftige Sprints geplant. Dadurch können die Zusammenarbeit im Team und auch die Fähigkeiten der einzelnen Mitglieder verbessert werden. Für die Bewertung des Sprints können viele verschiedene Techniken gewählt werden. Einige Beispiele dafür sind der Safety Check, bei dem die Mitglieder anonym auf einer Skala bewerten wie sicher sie sich in dem Sprint gefühlt haben, die timeline retrospective, bei der die Teammitglieder an einem Zeitstrahl Ereignisse aufführen und diskutieren und die klassische Scrum Retrospective, bei der festgehalten wird, was gut und schlecht lief, was gelernt wurde und was sie nach wie vor beschäftigt.
Zusammenfassend ist Scrum ein Rahmenwerk, welches strikte Prinzipientreue erfordert. Durch das agile Vorgehen kann ein Produkt entwickelt werden, welches genauestens den Kundenwünschen entspricht. Dadurch eignet sich Scrum besonders in den Bereichen der Hard- und Softwareentwicklung und der Dienstleisungsbranche, aber auch für alle anderen Bereiche, in denen die Anforderungen nicht von vorn herein klar definiert werden können. Bei der Arbeit im Team können die eigenen Fähigkeiten, der Teamgedanke und die Selbstorganisation verbessert werden. Scrum ist zwar zunächst schwer zu erlernen und fordert viel Disziplin von allen Beteiligten in der Ein- und Durchführung, allerdings kann es dann zu einem erheblichen Mehrwert in der kundenorientierten Entwicklung beitragen.
1.3 Reflexion
Wo sind noch Lücken in meinen Handlungskompetenzen?
- Umgang mit Problemen im Team (ggf. Details welche Probleme in der Praxis häufig auftauchen und wie damit umgegangen werden kann)
- Ausführliches Beispiel für ein Projekt mit mehreren Sprints
Wie könnte ich bzw. der Dozent den Stoff besser erlernen / vermitteln?
- Informationen in der Veranstaltung bzw. der Vorlesungsunterlagen waren häufig identisch zu denen aus dem Video à weitergehende Informationen durch den Dozenten
2. KANBAN
2.1 Inventur
- Persönlich: Benutzung im Unternehmen für Softwareentwicklung
- Tafel mit verschiedenen Spalten, die Prozessschritte darstellen
- Aufgaben stehen auf kleinen Kärtchen
- Aufgaben werden in verschiedenen Spalten einsortiert
- Jedes Mitglied „holt sich die Aufgaben“
2.2 Inhalte
2.2.1 Ausgangsproblem
Im Arbeitsalltag in der IT fallen unterschiedlichste Aufgaben an. Einige dieser Aufgaben müssen sofort erledigt werden, andere können später erledigt werden und wieder andere weisen einen so großen Umfang auf, dass kontinuierlich über einen langen Zeitraum an ihnen gearbeitet werden muss. Dabei ist das Priorisieren der Aufgaben nicht immer einfach und häufig wird, auf Drängen der Projektleiter hin, dessen Aufgabe gelöst, der betont, dass seine Aufgabe die Wichtigste sei. Durch diesen Umstand finden an einem Arbeitstag häufige Aufgabenwechsel statt, damit jede Aufgabe zumindest teilweise bearbeitet werden kann. Das senkt die Produktivität aufgrund der Rüstzeiten, die durch jeweils erneutes Einfinden in die andere Aufgabe entstehen und es kommt zu Zeitproblemen und Überforderung der Mitarbeiter.
2.2.2 Methode, Lösung bzw. Vorgehen
Das bereits in Kapitel 1 vorgestellte Vorgehensmodell „Scrum“ kann nicht als Lösung für die Problematik genutzt werden, da es auf die Organisation genau eines einzigen Projektes ausgerichtet ist und nicht auf das IT Change-Management abzielt, bei dem mehrere Aufgaben und Projekte gleichzeitig bearbeitet werden. Sobald mehrere Aufgaben gleichzeitig bearbeitet werden, muss also eine andere Technik genutzt werden. Eine Möglichkeit ist die Nutzung der Technik „Kanban“ (japanisch: Signalkarte). Sie entspringt der genutzten Technik im Produktionssystem von Toyota. Dort sollte ein kontinuierlicher und gleichmäßiger Arbeitsfluss in der Produktion entstehen. Im Jahr 2007 stellte David Anderson, der als Begründer von Kanban in der IT gilt, die abgewandelte Technik vor. Sie zielt ebenfalls durch ein einfaches Konzept darauf ab, einen kontinuierlichen Arbeitsfluss zu visualisieren und generieren und dennoch keinen Mitarbeiter zu überlasten.
Für den Einsatz von Kanban sind nur wenige Hilfsmittel notwendig: ein Kanban-Board (z.B. ein großes Whiteboard), Post-It’s, Sticker (rot, grün, Namen der Mitarbeiter) und Stifte. Zu Beginn wird jeder einzelne Prozessschritt als Spalte auf das Kanban-Board geschrieben (z.B. nicht begonnen, Analyse, Programmierung, Testen, abgeschlossen). Dadurch sind die einzelnen notwendigen Arbeitsschritte der Reihenfolge nach notiert und für jeden Mitarbeiter klar ersichtlich in welcher Reihenfolge die Aufgaben abgearbeitet werden. Diese werden bei Eintreffen jeweils auf ein Post-It geschrieben.
[...]
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X.