Aufrufe
vor 2 Jahren

02 | 2016 NEWS

  • Text
  • Anforderungen
  • Risiken
  • Planung
  • Msggillardon
  • Institute
  • Unternehmenssteuerung
  • Scrum
  • Risikomanagement
  • Banken
  • Vertriebsplanung
Wohin? - Aufsichtsrecht und Meldewesen

u

u Informationstechnologie Stakeholder Sprint Retro Daily Scrum Produktvision Team Scrum Master Sprint Sprintreview Shippable Product € Productowner Productbacklog Sprintbacklog Abbildung 1: Scrum-Ereignisse Scrum-Ereignisse Scrum bietet dem Projektleiter, dem Product Owner und dem Team vier wesentliche Eingriffspunkte für das Risikomanagement: das Sprint Planning, das Daily Scrum, den Sprint Review und die Sprint-Retrospektive. Im Sprint Planning werden die beiden Fragen „Was wird im nächsten Sprint getan?“ und „Wie erreichen wir das Ziel?“ beantwortet. Im Rahmen der Planerstellung für den nächsten Sprint werden hier Ressourcenverfügbarkeiten berücksichtigt und ein gemeinsames Verständnis des zu erreichenden Ziels erarbeitet. Risiken werden durch das Team direkt im Forecast für den nächsten Sprint berücksichtigt. Durch diese Selbstorganisation im Team erhöht sich das Verantwortungsbewusstsein und damit auch die gelieferte Qualität. Das Daily Scrum bietet dem Team die Möglichkeit, den Fortschritt auf einer täglichen Basis abzuschätzen und zu beobachten, um frühzeitig steuernd einzugreifen. Das Team synchronisiert hier seine Tätigkeiten für die nächsten 24 Stunden und gibt eine Prognose ab, welche Arbeiten bis zum nächsten Daily Scrum erledigt sein werden. Risiken können so während der Entwicklung erkannt und entweder direkt im Team oder in Zusammenarbeit mit dem Product Owner und dem Scrum Master gelöst werden. Der Sprint Review gibt den Projektstakeholdern die Möglichkeit, die geleistete Arbeit zu sichten und hinsichtlich ihres Nutzens zu bewerten. Dies erlaubt es, frühzeitig festzustellen, ob das Projekt auf dem richtigen Kurs ist. Dabei gilt: Je größer die Begeisterung für das Produkt ist, desto größer wird auch die Motivation des Entwicklungsteams. Umgekehrt zeigt eine negative Kundenreaktion, dass das Projekt auf dem falschen Weg ist, und versetzt den Projektleiter und den Product Owner in die Lage, korrigierend einzugreifen. Im Extremfall kann das Projekt frühzeitig abgebrochen werden, beispielsweise wenn erkannt wird, dass der Business Value nicht mehr erbracht werden kann. 30 I NEWS 02/2016

Informationstechnologie t Insgesamt bringt der Review durch den Austausch von Entwicklern und Stakeholdern ein gesteigertes gegenseitiges Verständnis, indem alle Diskussionen auf dem erlebbaren Produkt aufsetzen. Dadurch können neue Erkenntnisse darüber gewonnen werden, wie das Produkt weiter verbessert werden kann. In der Sprint-Retrospektive rekapituliert das Team den letzten Sprint und identifiziert Verbesserungspotenziale. Dazu werden die Umsetzung und Wirksamkeit der Maßnahmen aus dem letzten Meeting analysiert und neue Maßnahmen definiert. Ziel ist es, den Entwicklungsprozess und die Teamzusammenarbeit zu verbessern und effektiver zu gestalten. Im Rahmen dieses Meetings können aufgetretene Risiken des letzten Sprints analysiert und Lösungen für den zukünftigen Umgang mit diesen erarbeitet werden. Insgesamt zeichnen sich zwei Ansatzpunkte für das Risikomanagement durch die Scrum-Ereignisse ab: Einerseits wird das Team stärker in die Verantwortung genommen und aktiv in das Risikomanagement eingebunden. Andererseits bieten sich durch die definierten Abläufe vielfältige Möglichkeiten sowohl zur Identifikation von Risiken als auch zur Definition von Maßnahmen und damit zur Risikosteuerung. Transparenz Durch die kurzen Sprintzyklen und die Sprint Reviews wird der aktuelle Projektstand regelmäßig dem Team und den Stakeholdern transparent gemacht. Dies verhindert Missverständnisse im Reporting und führt dazu, dass Risiken sowohl durch das Team als auch durch die Stakeholder bereits frühzeitig identifiziert werden und somit frühzeitig Maßnahmen zur Steuerung ergriffen werden können. Dies führt zum einen dazu, dass Risiken früher erkannt werden, und ermöglicht zum anderen, ein Chancenmanagement zu etablieren. Die Entscheidung, welche Stakeholder aktiv am Review teilnehmen, wird im Zuge der Stakeholderanalyse getroffen. Impediment Backlog Das Impediment Backlog zeigt alle vom Team identifizierten Hindernisse mit ihrem aktuellen Status. Es liefert einen Überblick, welche Risiken im Projektverlauf in der Praxis tatsächlich auftreten und wie man ihnen begegnen kann. Diese Erkenntnisse können in andere Projekte einfließen und ermöglichen es, das Risikomanagement stetig weiter zu verbessern. User Stories User Stories dienen zwei großen Zielen: Einerseits wird die Komplexität in beherrschbare Teile aufgeteilt, andererseits zeigen sie immer auch den Nutzen für einen Personenkreis auf: Damit möchte ich als folgende . Dadurch wird verhindert, dass Funktionen implementiert werden, deren Nutzen nicht nachgewiesen ist. Die Entwickler verstehen so, zu welchem Zweck die Funktion verwendet werden soll, und werden auf diese Weise dazu befähigt, aktiv Verbesserungen einzubringen. Das Format der User Stories fördert die Diskussion zwischen allen Beteiligten auf einer nutzenbasierten Ebene. Das Ziel der User Stories kann leichter nachvollzogen werden, um so gemeinsam zu einer bestmöglichen Lösung zu kommen. Durch die Verwendung von User Stories zur Anforderungserfassung wird aktiv das Risiko von Missverständnissen minimiert, sodass der Kunde das bekommt, was er benötigt, auch wenn er es nicht detailliert spezifiziert hat. Schätzungen und das Product Backlog Alle Einträge im Product Backlog müssen geschätzt sein. Diese Forderung führt dazu, dass zu große oder komplexe Einträge identifiziert und weiter detailliert werden können. Auch wird während des Schätzens erkannt, ob alle Beteiligten das gleiche Verständnis der Aufgabe haben. User Stories, die zu unspezifisch oder zu groß sind, werden so frühzeitig erkannt und müssen vom Product Owner in Zusammenarbeit mit dem Team verkleinert werden. Hierdurch werden Risiken, die sich aus mangelnder Detaillierung oder fehlendem Verständnis ergeben, angegangen und entschärft. NEWS 02/2016 I 31

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2016 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum