Kollaborative Entscheidungsfindung<\/strong><\/a><\/p>\n[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=“1″ _builder_version=“4.4.1″ custom_padding=“|||0px||“ locked=“off“][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“8vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“1.7em“ header_3_font_size=“1.4em“ header_4_font=“||||||||“ header_4_font_size=“1.1em“ header_4_line_height=“1.5em“ header_5_font_size=“1.12em“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
1. Grundlagen der Agile-Methode<\/h2>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Warum Agile?<\/h3>\n
Der gesch\u00e4ftliche Schwerpunkt hat sich von der Herstellung von Waren hin zu Informationen und Daten verlagert. In den letzten Jahrzehnten haben Unternehmen ihren Schwerpunkt vermehrt von der Herstellung von G\u00fctern auf Informationen und Daten gesetzt. Sie legen Wert auf den Besitz von Informationen und Daten und die F\u00e4higkeit, diese zur Gestaltung\/Optimierung von Waren und Dienstleistungen zu nutzen.<\/p>\n
Die mit IT-Projekten verbundene Arbeit ist weniger eindeutig und klar definierbar als die Arbeit in herk\u00f6mmlichen, industriellen Projekten. Aus diesem Grund f\u00fchrt die Anwendung traditioneller Managementtechniken und Planungen bei IT-Projekten h\u00e4ufiger zu Misserfolgen und Frustration.<\/p>\n
Klassische Managementtechniken und Planungsmethoden lassen sich bei vielen IT-Projekten nicht zufriedenstellend umsetzen. Agile ist eine Sammlung jener Methoden und Strukturen, die beim Aufbau von IT-Produkten am effektivsten sind.<\/p>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ hover_enabled=“0″ border_color_left=“#ff6317″]<\/p>\n
Die 4 Grundprinzipien von Agile<\/h3>\n
Mit Agile zu arbeiten funktioniert am besten mit einer agilen Herangehensweise, die Priorit\u00e4ten neu ordnet:<\/p>\n
Individuen und Interaktionen gehen vor Prozesse und Werkzeuge.<\/strong> Ja, wir brauchen Prozesse und Werkzeuge – sie sind logisch und vorhersehbar, und es ist schwer, ein Projekt ohne sie abzuschlie\u00dfen. Andererseits sind sie lediglich statisch und mehr f\u00fcr die L\u00f6sung alter und sich wiederholender Probleme und Aufgaben geeignet. Im Gegensatz dazu sind es die Menschen und ihre Interaktion, die neue Probleme l\u00f6sen und in der Lage sind, innovativ zu sein und die Dinge voranzubringen.<\/p>\nFunktionierende Software geht vor umfassender Dokumentation.<\/strong> Software ohne angemessene Dokumentation ist schwer zu betreuen und zu warten. Aber eine umfassende Dokumentation ohne funktionierende Software ist nutzlos. Deshalb sollte die Dokumentation gerade rechtzeitig fertig und gerade umfassend genug sein, ohne dabei zum Hauptthema zu werden.<\/p>\nZusammenarbeit mit dem Kunden geht vor Vertragsverhandlungen.<\/strong> Verwenden Sie einen flexiblen Vertrag, der eine vertiefte Zusammenarbeit mit dem Kunden erm\u00f6glicht. Das ist eine der besten M\u00f6glichkeiten, den Aufwand von T\u00e4tigkeiten mit geringem Wert (z.B. Besprechung, was zu tun ist, wenn sich der Projektumfang \u00e4ndert) auf Ihre produktivste Arbeit zu verlagern.<\/p>\nWir sind uns der traditionellen Change-Management-Prozesse bewusst, deren Vereinbarung viel Zeit und M\u00fche erfordert. Sie neigen eher dazu, Change-Suppression-Prozesse zu bewirken, was das Gegenteil von Agile ist. Daher empfehlen wir, nicht zu viel Zeit und Aufmerksamkeit in Change-Management-Klauseln zu investieren.<\/p>\n
Auf Ver\u00e4nderungen zu reagieren geht vor Umsetzung nach Plan.<\/strong> Das bedeutet nicht, dass wir die Planung aufgeben sollten – wir brauchen immer noch Pl\u00e4ne, aber wir m\u00fcssen akzeptieren, dass sie aufgestellt wurden, als wir am wenigsten \u00fcber das Projekt wussten. Anstatt das Projekt wieder an den urspr\u00fcnglichen Plan anzugleichen, sollten wir die Pl\u00e4ne \u00f6fter aktualisieren, damit wir uns an unvermeidliche Ver\u00e4nderungen anpassen k\u00f6nnen.[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\nFlexible Denkweise: Invertiertes magisches Dreieck<\/h3>\n
Ein Projekt wird durch drei Hauptbedingungen definiert: Eigenschaften, Zeit und Kosten. Beim traditionellen Projektmanagement beschr\u00e4nken wir uns zun\u00e4chst auf die Eigenschaften: Wir verbringen zu Beginn viel Zeit mit einer detaillierten Definition der Anforderungen und gehen davon aus, dass wir 100 % liefern werden.<\/p>\n
Auf der Grundlage dieser Anforderungen sch\u00e4tzen wir den Zeit- und Kostenaufwand und fahren fort. Aber keine Sch\u00e4tzung ist 100 % perfekt, wenn man mit der Realit\u00e4t konfrontiert ist, daher m\u00fcssten Zeit und Kosten flexibel sein, um 100 % der Projektfunktionalit\u00e4t zu liefern.<\/p>\n
In Agile stellen wir die Einschr\u00e4nkungen auf den Kopf. Zu Beginn schr\u00e4nken wir die Zeit und die Kosten ein und akzeptieren, dass Umfang und Eigenschaften flexibel sind. Indem wir die Eigenschaften auf der Grundlage ihres Gesch\u00e4ftswerts priorisieren, ist die Zuweisung von Zeit und Kosten relevanter. Auch wenn sich die urspr\u00fcngliche Sch\u00e4tzung \u00e4ndert, werden die wichtigsten Funktionen bereits geliefert – innerhalb der vereinbarten Zeit und zu den vereinbarten Kosten.<\/p>\n
Wir sehen daher zwei Hauptvorteile von Agile gegen\u00fcber der traditionellen Planung:<\/p>\n
\n- Die (Fix-)Kosten und der Zeitrahmen sind Ihnen bekannt.<\/li>\n
- Sie k\u00f6nnen sich darauf konzentrieren, (etwa) 75 Prozent der Funktionalit\u00e4t zu liefern, die 95 Prozent des Gesch\u00e4ftswerts des Projekts abdecken.<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-inverted-triangle-of-constraints.jpg“ alt=“Berg Software – Agile stakeholder engagement – inverted triangle of constraints“ title_text=“Berg Software – Agile stakeholder engagement – inverted triangle of constraints“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Wie Agile funktioniert und warum Sie sich damit besch\u00e4ftigen sollten<\/h3>\n
Das traditionelle Modell wird Wasserfallmodell genannt, weil es eben wie einer aussieht: Es ist eine lineare Abfolge von Schritten, die Sie zum gro\u00dfen, endg\u00fcltigen Ergebnis f\u00fchren.<\/p>\n
Die festgelegten Arbeitsschritte sind:<\/p>\n
\n- Anforderungen definieren<\/li>\n
- technische Architektur entwerfen<\/li>\n
- die eigentliche Entwicklung des Produkts abschlie\u00dfen<\/li>\n
- das Produkt testen<\/li>\n
- bereitstellen<\/li>\n<\/ul>\n
Agile folgt mehr oder weniger den gleichen Schritten, aber in kleinerem Umfang und durch mehrere Iterationen, d.h. schrittweises Erreichen eines zufriedenstellenden Ergebnisses.<\/p>\n
Weitere Vorteile ergeben sich aus den wiederholten, schrittweisen Lieferungen:<\/p>\n
\n- mehr Gesch\u00e4ftswert<\/li>\n
- weniger Risiko<\/li>\n
- bessere Sichtbarkeit<\/li>\n
- mehr Anpassungsf\u00e4higkeit<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-waterfall-versus-Agile.jpg“ alt=“Berg Software – Agile stakeholder engagement – waterfall versus Agile“ title_text=“Berg Software – Agile stakeholder engagement – waterfall versus Agile“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=“1″ _builder_version=“4.4.1″ custom_padding=“|||0px||“ locked=“off“][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“8vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
2. Grundlagen des Stakeholder-Engagements<\/h2>\n\n- Wer sind die Stakeholder?<\/li>\n
- Wie w\u00e4hlt man die richtigen Stakeholder aus?<\/li>\n
- Wie kann man Stakeholder kontinuierlich einbinden?<\/li>\n
- Was passiert, wenn man es nicht tut?<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Wer sind die Stakeholder?<\/h3>\n
Die Stakeholder sind alle Personen oder Personengruppen, die vom Projekt betroffen sind oder einen Einfluss auf das Projekt haben werden. Dazu k\u00f6nnen geh\u00f6ren:<\/p>\n
\n- Kunden<\/li>\n
- Unternehmensberater<\/li>\n
- Endbenutzer<\/li>\n
- F\u00fchrungskr\u00e4fte<\/li>\n
- H\u00e4ndler<\/li>\n
- Lieferanten<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Wie w\u00e4hlt man die richtigen Stakeholder aus?<\/h3>\n
Es ist entscheidend, die richtigen Stakeholder zu finden \u2013 und Sie sollten sich darum bem\u00fchen. Je mehr von diesen drei Eigenschaften in einem Stakeholder vertreten sind, desto besser:<\/p>\n
\n- Der Stakeholder hat das richtige Wissen.<\/li>\n
- Der Stakeholder kann Entscheidungen treffen.<\/li>\n
- Der Stakeholder hat Autorit\u00e4t.<\/li>\n<\/ul>\n
Hier finden Sie, wonach Sie suchen m\u00fcssen: Wissen: Personen, die die Anforderungen, Merkmale, technischen Aspekte, bestimmte Regeln oder rechtliche Zw\u00e4nge des Projekts abdecken.<\/p>\n
Wissen<\/strong>: Personen, die die Anforderungen, Merkmale, technischen Aspekte, bestimmte Regeln oder rechtliche Zw\u00e4nge des Projekts abdecken. Achten Sie darauf, dass sie auch effektiv erkl\u00e4ren k\u00f6nnen – das wird dem Entwicklungsteam helfen, Ihren Kontext und Ihre Anforderungen schneller zu verstehen. Typische Personen: Endbenutzer, Unternehmensberater, Technologie-\/Fachexperten.<\/p>\nEntscheidungstr\u00e4ger<\/strong>: Jemand, der die notwendigen Schritte unternehmen kann, um die Dinge voranzubringen. Sie sind entweder Vertreter einer Gruppe von Personen (d.h. sie k\u00f6nnen Entscheidungen in ihrem Namen treffen) oder sie k\u00f6nnen den Entscheidungsprozess erleichtern und diese Entscheidung dem Team mitteilen. Typische Rolle: Produktmanager.<\/p>\nAutorit\u00e4t<\/strong>: Jemand mit der entsprechenden Position und Macht, an den Sie Fragen f\u00fcr eine schnellere L\u00f6sung eskalieren k\u00f6nnen. Typische Rollen: Abteilungsleiter, Sponsor. Es w\u00e4re gro\u00dfartig, Personen mit all diesen Eigenschaften zu finden. Aber in der Praxis geschieht dies nicht, so dass wir eine Gruppe von Interessensvertretern brauchen. Denken Sie daran, dass die besten Leute auch die flei\u00dfigsten sind, was es noch schwieriger macht, sie ins Boot zu holen.<\/p>\nEs w\u00e4re gro\u00dfartig, Personen mit all diesen Eigenschaften zu finden. Aber in der Praxis geschieht dies nicht, so dass wir eine Gruppe von Interessensvertretern brauchen. Denken Sie daran, dass die besten Leute auch die flei\u00dfigsten sind, was es noch schwieriger macht, sie ins Boot zu holen.[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Wie kann man Stakeholder kontinuierlich einbinden?<\/h3>\n\n- Zeigen Sie ihnen, woran Sie arbeiten.<\/li>\n
- Besprechen Sie Kalkulationen und Prognosen.<\/li>\n
- Finden Sie deren pers\u00f6nliches Interesse heraus und bedienen Sie es.<\/li>\n
- Hinweis: Seien Sie sich bewusst, dass manche Stakeholder zur Belastung werden k\u00f6nnen.<\/li>\n<\/ul>\n
F\u00fcr die Stakeholder ist Ihr Projekt vielleicht nicht der Hauptschwerpunkt, sondern nur eine Nebenaktivit\u00e4t unter (vielen) anderen. Erschwerend kommt hinzu, dass Stakeholder \u00fcber verschiedene Organisationen verteilt sein und sich Ihrem unmittelbaren Einfluss entziehen k\u00f6nnen.<\/p>\n
Die Stakeholder erwarten normalerweise, dass sie nur in der Planungsphase einbezogen werden \u2013 was es f\u00fcr Sie umso wichtiger macht, sie so lange wie m\u00f6glich am Projekt zu beteiligen. Hier sind einige Hinweise, wie Sie dies tun k\u00f6nnen:<\/p>\n
Zeigen Sie ihnen h\u00e4ufig, was im Zuge des Projekts bereits gebaut wurde<\/strong>, damit diese sehen k\u00f6nnen, wie die Dinge sich entwickeln und das Interesse nicht verlieren. Au\u00dferdem hilft es Ihnen, sich auf das Wesentliche zu konzentrieren und nicht zu viel Arbeit in das Bauen falscher Features zu investieren.<\/p>\nZeigen Sie ihnen den tats\u00e4chlichen Fortschritt<\/strong>; besprechen Sie Kalkulationen und Prognosen. Die schlechte Nachricht: Manchmal entspricht das tats\u00e4chliche Fortschrittstempo nicht dem, was der Kunde\/die Stakeholder erwarten. Die gute Nachricht: Transparente Informationen, die bei Verf\u00fcgbarkeit sofort geliefert werden, sind unbezahlbar. Durch das Besprechen der gelieferten Features im Vergleich zu den \u00fcbrigen Features k\u00f6nnen Ihr Team und der Kunde auf der Grundlage solider Daten Kompromissentscheidungen treffen.<\/p>\nF\u00fcgen Sie „Goodies“ hinzu<\/strong>, um die Stakeholder einzubeziehen:<\/p>\n\n- Stellen Sie sicher, dass deren Beteiligung sichtbar ist und begleitet wird; betonen Sie gegen\u00fcber den Stakeholdern die Vorteile ihres Engagements.<\/li>\n
- Schenken Sie den Stakeholdern Anerkennung f\u00fcr ihr Engagement und belohnen Sie sie daf\u00fcr, indem Sie z.B. gemeinsam den Projekterfolg feiern.<\/li>\n
- Sprechen Sie mit den Vorgesetzen der Stakeholder dar\u00fcber, wie deren Beitr\u00e4ge am besten gew\u00fcrdigt werden k\u00f6nnen, z.B. indem diese Beitr\u00e4ge in deren Leistungsbewertungen miteinbezogen werden.<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Was passiert, wenn die Stakeholder nicht eingebunden werden:
\nKluft der Auswertung<\/h3>\n
Wenn die Stakeholder nicht eingebunden werden, wird das Projekt wahrscheinlich der „Kluft der Auswertung“ zum Opfer fallen und aufgrund der Widerspr\u00fcche zwischen dem,<\/p>\n
\n- was der Kunde braucht,<\/li>\n
- wie der Kunde beschreibt, was er braucht,<\/li>\n
- wie das Entwicklungsteam diese Beschreibung versteht,<\/li>\n
- was das Team tats\u00e4chlich umsetzt, schlussendlich nicht erfolgreich sein.<\/li>\n<\/ul>\n
So entstehen viele Diskrepanzen. Wenn diese zu lange unbeachtet bleiben, f\u00fchren sie zu kostspieligen Nachbesserungen oder sogar zum Scheitern des Projekts. Versuchen Sie daher, statt mehrerer unterschiedlicher Bilder Ihres Produkts ein einziges Bild zu erstellen, das von allen Beteiligten gemeinsam genutzt wird: „die gemeinsame Vision des Produkts“.[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-gulf-of-evaluation.jpg“ alt=“Berg Software – Agile stakeholder engagement – gulf of evaluation“ title_text=“Berg Software – Agile stakeholder engagement – gulf of evaluation“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=“1″ _builder_version=“4.4.1″ custom_padding=“|||0px||“ locked=“off“][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“8vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
3. Eine gemeinsame Vision des Produkts schaffen<\/h2>\n
Praktische Beispiele f\u00fcr die Schaffung einer gemeinsamen Vision:<\/p>\n
\n- Projektcharta<\/li>\n
- Kurzpr\u00e4sentation des Projekts<\/li>\n
- Definition von „erledigt“<\/li>\n
- Modellbildung mit Agile<\/li>\n
- Wireframes<\/li>\n
- Personas<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Die Projektcharta (W5H)<\/h3>\n
ist eines der ersten Dokumente, die im Rahmen eines Projekts erstellt werden. Sie enth\u00e4lt die Zustimmung des Geldgebers fortzufahren, sowie wichtige Bausteine wie:<\/p>\n
\n- W<\/strong>orum es bei diesem Projekt geht: eine Metabeschreibung der Vision, des Auftrags, der Ziele und Vorgaben des Projekts.<\/li>\n
- W<\/strong>arum das Projekt durchgef\u00fchrt wird: der Gesch\u00e4ftszweck des Projekts.<\/li>\n
- W<\/strong>er die Beteiligten sind: eine Liste der Projektteilnehmer und beteiligten Stakeholder.<\/li>\n
- W<\/strong>ann das Projekt beginnen und enden wird: angestrebte Start-\/Endzeitpunkte und Zeitplan f\u00fcr partielle Releases.<\/li>\n
- W<\/strong>o das Projekt stattfinden wird: Informationen \u00fcber die verschiedenen Arbeitsorte (z.B. wo die gemeinsamen Treffen stattfinden), Anforderungen an die Bereitstellung usw.<\/li>\n
- W<\/strong>ie das Projekt durchgef\u00fchrt wird: eine Beschreibung des Ansatzes, der Methoden und des zu verwendenden Rahmens. Dies kann auch als Mitteilung an die Stakeholder dienen, um ihre verst\u00e4rkte Beteiligung am Agile-Projekt einzufordern.<\/li>\n<\/ul>\n
Bitte beachten Sie: Wenn wir davon ausgehen, dass der Umfang des Projektes nicht absolut festgelegt ist, und dass einige Projektteile zu Beginn sogar unbekannt sein k\u00f6nnten, dann besteht keine Notwendigkeit, den Umfang vollst\u00e4ndig zu spezifizieren.<\/p>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Die Kurzpr\u00e4sentation des Projekts<\/h3>\n
ist die konzentrierteste, glanzvollste Beschreibung eines Projekts. Stellen Sie sich vor, Sie befinden sich in einem Aufzug mit jemandem, der Ihr Projekt unterst\u00fctzen\/finanzieren kann: Sie haben h\u00f6chstens 20-30 Sekunden Zeit, um es zu beschreiben, also muss es kurz und \u00fcberzeugend sein und beim Adressaten „h\u00e4ngen bleiben“.<\/p>\n
Im Folfenden schlagen wir eine m\u00f6gliche Struktur (anhand eines erfundenen Beispiels) vor:<\/p>\n
\n- F\u00fcr | Zielkunden<\/strong> | Diana Travis ist eine Marketingspezialistin bei InnerWorks, die…<\/li>\n
- Wer | Bedarf \/ Gelegenheit \/ Problem<\/strong> | …kann nicht mit der Erstellung aller ben\u00f6tigten Berichte fertig werden.<\/li>\n
- Das Produkt \/ die Dienstleistung<\/strong> | AntwortASAP ist…<\/li>\n
- Die Kategorie<\/strong> | …ein Berichtsgenerator-Werkzeug, das…<\/li>\n
- Hauptvorteile<\/strong> | …hilft, jede marktrelevante Frage fast sofort zu beantworten.<\/li>\n
- Im Gegensatz zu \/ konkurrierende Alternativen<\/strong> | Die Erstellung eines Berichts dauert jetzt 30 Minuten…<\/li>\n
- Wir \/ Differentiator<\/strong> | …aber wir k\u00f6nnen den Bericht in 4 Minuten erstellen.<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Definition von „erledigt“:<\/h3>\n
Erstaunlicherweise kann „erledigt“ f\u00fcr verschiedene Menschen unterschiedliche Dinge bedeuten. Wenn man eine Liste mit allem hat, was erledigt werden muss, werden alle Beteiligten dasselbe Verst\u00e4ndnis haben:<\/p>\n
\n- Codiert: Ist der gesamte Code geschrieben worden?<\/li>\n
- Gestaltet: Entspricht die Gestaltung des Codes den vereinbarten technischen Standards?<\/li>\n
- Getestet: Sind alle Tests abgeschlossen?<\/li>\n
- Integriert: Funktioniert das Feature von Anfang bis Ende?<\/li>\n
- Installiert: Wird die Anwendung auf den erwarteten Servern installiert?<\/li>\n
- \u00dcberpr\u00fcft: Haben Kunden das Feature \u00fcberpr\u00fcft und best\u00e4tigt, dass es ihren Erwartungen entspricht?<\/li>\n
- Genehmigt: Haben die Kunden diese Funktionalit\u00e4t genehmigt?<\/li>\n
- Repariert?<\/li>\n
- Migriert?<\/li>\n
- Vorschriftsgem\u00e4\u00df?<\/li>\n<\/ul>\n
Ohne eine gemeinsame Definition riskieren Sie h\u00e4ufige Diskrepanzen.<\/p>\n
Das Entwicklungsteam konzentriert sich beispielsweise in der Regel auf die ersten Themen (Design, Codierung und Testen) und will sie erledigen, bevor es zur n\u00e4chsten Sache \u00fcbergeht. In einer separaten Darstellung betrachtet der Kunde einen anderen Satz von Kriterien, wie z.B. Integration, Genehmigung oder Konformit\u00e4t. Wie zu erwarten ist, wird das Zusammenf\u00fcgen der beiden Kriterienkataloge ohne vorherige Abstimmung und gemeinsames Verst\u00e4ndnis definitiv zu Problemen f\u00fchren.<\/p>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Agile Modellierung<\/h3>\n
kann mit Use-Case-Diagrammen, Datenmodellen und Screendesigns durchgef\u00fchrt werden:<\/p>\n
\n- Die Use-Case-Diagramme beziehen sich in der Regel auf Akteure und Handlungen (z.B. die Endnutzer und die Prozesse hinter ihren Handlungen).<\/li>\n
- Datenmodelle beziehen sich auf Datenentit\u00e4ten und ihre Verkn\u00fcpfung untereinander.<\/li>\n
- Screendesigns zeigen, wie das Produkt auf einer Webseite, einem Desktop oder einem mobilen Ger\u00e4t aussehen soll.<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-agile-modelling.jpg“ alt=“Berg Software – Agile stakeholder engagement – agile modelling“ title_text=“Berg Software – Agile stakeholder engagement – agile modelling“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Wireframes<\/h3>\n
sind vor allem bei der Erstellung von Mock-ups eines Produkts n\u00fctzlich. Es handelt sich dabei um eine Reihe von Screendesigns, die einen Prototyp eines bestimmten Teils des Produkts oder eines bestimmten Arbeitsablaufs mit einem Minimum an ben\u00f6tigter Funktionalit\u00e4t darstellen (z.B. nur das Verschieben von einer Seite auf eine andere). Wireframes sind zu Beginn sehr n\u00fctzlich, da sie eine schnelle und kosteng\u00fcnstige M\u00f6glichkeit darstellen, um Feedback zu einer vorgeschlagenen Funktionalit\u00e4t zu erhalten.[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-wireframes.jpg“ alt=“Berg Software – Agile stakeholder engagement – wireframes“ title_text=“Berg Software – Agile stakeholder engagement – wireframes“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Personas<\/h3>\n
sind Kurzanleitungen und Erinnerungen an die Endbenutzer und ihre Anwendungsf\u00e4lle. Sie sind ein weiteres Werkzeug f\u00fcr das Entwicklungsteam, um seine Arbeit zu priorisieren und sich auf das Wesentliche zu konzentrieren. Personas ersetzen die Anforderungen nicht, sondern erweitern sie vielmehr.<\/p>\n
\n- Stellen Sie eine Beschreibung eines repr\u00e4sentativen Benutzers zur Verf\u00fcgung<\/li>\n
- Verklieren Sie nicht den Zugang zur Realit\u00e4t<\/li>\n
- Seien Sie zielorientiert und spezifisch<\/li>\n
- Seien Sie fokussiert<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-personas.jpg“ alt=“Berg Software – Agile stakeholder engagement – personas“ title_text=“Berg Software – Agile stakeholder engagement – personas“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=“1″ _builder_version=“4.4.1″ custom_padding=“|||0px||“ locked=“off“][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“8vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
4. Stakeholder-Kommunikation<\/h2>\n
Wenn die Erarbeitung einer gemeinsamen Vision der erste Schritt zur Vermeidung der „Kluft der Auswertung“ ist, dann ist der zweite Schritt die richtige Kommunikation mit den Beteiligten. Im Zusammenhang mit dem agilen Stakeholder-Engagement sind folgende M\u00f6glichkeiten zielf\u00fchrend:<\/p>\n
\n- Pers\u00f6nliche Kommunikation<\/li>\n
- Wissensaustausch<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Die pers\u00f6nliche Kommunikation<\/h3>\n
kann entweder in einem Dispatching-Modell oder in einem Kooperationsmodell erfolgen.<\/p>\n
Das Dispatching-Modell folgt normalerweise der hierarchischen Struktur einer Organisation, die von oben nach unten verl\u00e4uft, vom Produktmanager zum Teamleiter und dann zu denjenigen, die die Arbeit tats\u00e4chlich ausf\u00fchren: den Teammitgliedern. Dieser Befehls- und Steuerungsansatz mag f\u00fcr denjenigen, der den Arbeitsauftrag erteilt, einfacher sein, aber er ist in Softwareprojekten nicht effektiv.<\/p>\n
Der kollaborative Weg (d.h. Zwei-Wege-Kommunikation) baut auf direkten Mitteilungen auf, gefolgt von Feedback und Validierung, wie z.B:<\/p>\n
\n- Entwicklungsteam zum Kunden: „Hier ist das, was Sie unserer Meinung nach gefordert haben, und hier ist, was wir aufgebaut haben. Bitte best\u00e4tigen Sie uns, dass wir auf dem richtigen Weg sind“.<\/li>\n
- Kunde an Entwicklungsteam: „Mir gefallen diese beiden Teile, aber Sie haben den dritten falsch verstanden. Oh, und das erinnert mich daran, dass wir etwas brauchen, f\u00fcr das wir eine neue Anfrage stellen m\u00fcssen.“
Aus offensichtlichen Gr\u00fcnden ist der kollaborative Weg der effektivste und wird daher bei agilen Software-Projekten bevorzugt.<\/li>\n<\/ul>\n[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-personnal-communications.jpg“ alt=“Berg Software – Agile stakeholder engagement – personnal communications“ title_text=“Berg Software – Agile stakeholder engagement – personnal communications“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Wissensaustausch<\/h3>\n
Informationssender sind gut sichtbare Informationsanzeigen, wie z.B. gro\u00dfe Diagramme, einfache Grafiken und Zusammenfassungen von Projektdaten. Die Informationen sollten in stark frequentierten B\u00fcrobereichen oder online in einfachen und schnellen Wiki-Seiten angezeigt werden. Dies steht im Gegensatz zu Informationsspeichern, in denen Projektinformationen in komplizierten Dokumenten, Berichten und KPI-Bl\u00e4ttern aufbewahrt werden – was bedeutet, dass niemand wei\u00df, was vor sich geht.<\/p>\n
\n- Bidirektionale Informationsfl\u00fcsse sind entscheidend.<\/li>\n
- Von den Stakeholdern zum Entwicklungsteam: die gemeinsame Vision \u00fcber das Projekt und die Ergebnisse.<\/li>\n
- Vom Entwicklungsteam zu den Stakeholdern:<\/li>\n
- Feature-Map<\/li>\n
- Wer arbeitet woran (Kanban-Tafel)<\/li>\n
- die aus der aktuellen Iteration ausgew\u00e4hlten Merkmale<\/li>\n
- Geschwindigkeitsdiagramm<\/li>\n
- Defektmetriken<\/li>\n
- Liste der Risiken und Probleme<\/li>\n
- Burn-Down-Diagramme<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Die Feature-Map<\/strong> (auch Story-Mapping genannt) ist eine M\u00f6glichkeit, die Features so anzuordnen, dass eine bessere \u00dcbersicht dar\u00fcber entsteht, wie sie sich in der gesamten Benutzererfahrung verhalten.<\/p>\nIn diesem Beispiel einer Map mit den Features eines Webstores enth\u00e4lt die erste Zeile die grundlegenden Schritte dieser Reise , die das „R\u00fcckgrat“ der Map bilden.<\/p>\n
Die rote Linie zeigt die Benutzerreise (wie der Benutzer das Produkt benutzen wird).<\/p>\n
Die einzelnen Features werden entlang der Hauptphasen der Reise verteilt, mit schrittweisen Releases (R1, R2, R3).<\/p>\n
Unten sehen Sie den Nachholbedarf, um die Features ohne klares Ver\u00f6ffentlichungsdatum einzubeziehen.<\/p>\n
Die Vorteile einer Feature-Map:<\/p>\n
\n- Sie zeigt das Gesamtbild der Nutzung des Produkts;<\/li>\n
- Ist ein ausgezeichnetes Werkzeug zur Visualisierung der Priorit\u00e4ten und des Zeitplans f\u00fcr die Freigabe von Funktionen.<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-features-map.jpg“ alt=“Berg Software – Agile stakeholder engagement – features map“ title_text=“Berg Software – Agile stakeholder engagement – features map“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Die Kanban-Tafel<\/strong> erhielt ihren Namen vom japanischen Wort „Kanban“, was w\u00f6rtlich \u00fcbersetzt „eine Tafel mit Zeichen darauf“ bedeutet.<\/p>\nDie Spalten zeigen die Phasen eines Prozesses, w\u00e4hrend die einzelnen Karten Arbeitsauftr\u00e4ge\/Aufgaben darstellen. Der Fortschritt wird visualisiert, indem die Karten von links nach rechts verschoben werden, was die Teamkoordination vereinfacht. Bei Bedarf kann die Tafel weiter in separate Zeilen aufgeteilt werden, um verschiedene Arbeitsbereiche oder verschiedene Teams anzuzeigen.<\/p>\n
Sie k\u00f6nnen die verbleibenden Tage f\u00fcr bestimmte Aufgaben z\u00e4hlen, um R\u00fcckst\u00e4nde zu erkennen und m\u00f6gliche Probleme hervorzuheben.<\/p>\n
Kanban-Tafeln sind in verschiedenen Softwarepaketen enthalten – aber eine physische wei\u00dfe Tafel, auf die Sie zeichnen und Notizen kleben k\u00f6nnen, l\u00e4sst Sie besser vorausplanen und die Aufgaben strets vor Augen haben.<\/p>\n
Auch wenn die Stakeholder hier nicht die eigentliche Arbeit verrichten, ist es f\u00fcr sie dennoch n\u00fctzlich, durch das Kanban zu sehen, wie sich die Dinge entwickeln. Wenn sie zum Beispiel die Implementierung bestimmter Funktionen verfolgen wollen, zeigt das Brett an, wer daran arbeitet.<\/p>\n
[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-kanban-board.jpg“ alt=“Berg Software – Agile stakeholder engagement – kanban board“ title_text=“Berg Software – Agile stakeholder engagement – kanban board“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Das Geschwindigkeitsdiagramm<\/strong> zeigt die Geschichte der abgeschlossenen Projekte im Vergleich zur gesch\u00e4tzen Dauer.<\/p>\nIdealerweise sollte der graue Balken mit dem gr\u00fcnen Balken \u00fcbereinstimmen. In der Praxis wird das in der Regel nicht der Fall sein – und wenn es keine gr\u00f6\u00dferen Probleme gibt, ist das auch in Ordnung.<\/p>\n
Ein Szenario ist, dass der graue Balken st\u00e4ndig vor dem gr\u00fcnen Balken liegt (d.h. gesch\u00e4tzt > abgeschlossen): Das bedeutet, dass das Team seine Kapazit\u00e4t \u00fcbersch\u00e4tzt, d.h. es glaubt, dass es mehr tun kann, als es tats\u00e4chlich tut.<\/p>\n
Umgekehrt, wenn der graue Balken st\u00e4ndig unter dem gr\u00fcnen Balken liegt (d.h. gesch\u00e4tzt < abgeschlossen), untersch\u00e4tzt das Entwicklungsteam seine Kapazit\u00e4t, m\u00f6glicherweise weil es nicht zu viel versprechen will.<\/p>\n
Wie dem auch sei, dies ist eine wertvolle Information bei der Planung: Sie hilft bei der Einsch\u00e4tzung\/Entscheidung, wie viel Arbeit in einem bestimmten Zeitrahmen zu leisten ist.<\/p>\n
[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-velocity-chart.jpg“ alt=“Berg Software – Agile stakeholder engagement – velocity chart“ title_text=“Berg Software – Agile stakeholder engagement – velocity chart“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row column_structure=“1_2,1_2″ use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Das Burn-Down-Diagramm<\/strong> ist ein weiteres Hilfsmittel, um den Fortschritt Ihrer aktuellen Iteration zu visualisieren und schnell zu verstehen, ob ein Team im Zeitplan ist oder nicht.<\/p>\n[\/et_pb_text][\/et_pb_column][et_pb_column type=“1_2″ _builder_version=“4.4.6″][et_pb_image src=“\/\/cdn.berg-software.com\/wp-content\/uploads\/Berg-Software-Agile-stakeholder-engagement-burndown-chart.jpg“ alt=“Berg Software – Agile stakeholder engagement – burndown chart“ title_text=“Berg Software – Agile stakeholder engagement – burndown chart“ _builder_version=“4.4.6″][\/et_pb_image][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=“1″ _builder_version=“4.4.1″ custom_padding=“|||0px||“ locked=“off“][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“8vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
5. Kollaboratives Arbeiten<\/h2>\n
Wenn Sie die gemeinsame Vision einmal festgelegt und kommuniziert haben, k\u00f6nnen Sie sie auf gemeinschaftliche Art und Weise aufbauen durch:<\/p>\n
\n- Workshops und Brainstorming-Sitzungen<\/li>\n
- Spiele zur Zusammenarbeit<\/li>\n
- Spiele zur Entscheidungsfindung<\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row use_custom_gutter=“on“ gutter_width=“3″ _builder_version=“4.4.6″ custom_margin=“||||false|false“ custom_padding=“3vh||||false|false“ border_color_left=“rgba(0,0,0,0)“][et_pb_column type=“4_4″ _builder_version=“4.4.6″][et_pb_text _builder_version=“4.4.6″ text_font=“|300|||||||“ text_font_size=“1.12em“ text_line_height=“1.55em“ quote_font=“|700|||||||“ quote_text_align=“left“ quote_font_size=“16px“ header_2_text_color=“#ff6317″ header_2_font_size=“30px“ header_3_font_size=“23px“ header_4_font=“||||||||“ header_4_font_size=“16px“ header_4_line_height=“1.5em“ header_5_font_size=“14px“ custom_margin=“||||false|false“ custom_padding=“||||false|false“ border_color_left=“#ff6317″]<\/p>\n
Wissensaustausch<\/h3>\n
kann man auf zweierlei Arten durchf\u00fchren: \u00fcber Workshops und bei Brainstormings. Die Workshops sind am effektivsten, wenn ein paar einfache Regeln befolgt werden:<\/p>\n