Buffl

L8-Denkmodelle im IT-Projektmanagement

PT
by Paul T.

Was ist das Manifest für agile SW Entwicklung?

  1. Herkunft:

    1. Das Manifest wurde von bekannten und erfahrenen SW Entwicklern gegründet als Antwort auf komplizierte SW Prozessmodelle, wie RUP oder das V-Modell.

    2. Die Kritik bezieht sich auf den Fokus der auf die Einhaltung von organisatorischen Regeln und Vorgaben basiert. Eine angemessene Reaktion auf Änderungen im Projekt wird verhindert.

  2. Werte der agilen SW Entwicklung:

    1. Vier agile Werte:

      1. Individuen und Interaktionen sind mehr als nur Prozesse und Werkzeuge.

        1. Werkzeuge und Prozesse sind wichtig, dürfen aber nicht über die Zusammenarbeit und Kommunikation der Stakeholder gestellt werden.

        2. Ein wohldefiniertes Prozessmodell und der Einsatz von Werkzeugen helfen, wirken aber erst, wenn alle beteiligten Menschen gut zusammenarbeiten.

      2. Eine funktionierende SW ist mehr als eine umfassende Dokumentation

        1. Der Kunde erwartet ein System, dass seine Anforderungen gut unterstützt. Eine gute Doku der Aktivitäten des SW Entwicklungsprozesses helfen nur, wenn das System auch funktioniert.

        2. Historische Prozessparadigmen, wie das Wasserfallmodell habne strenge Vorschriften bzgl Dokumentation eines Projekts. Damit werden viele Ressourcen gebunden, die nicht für Entwicklungsaktivitäten genutzt werden können.

      3. Zusammenarbeit mit dem Kunden ist mehr als nur eine Vertragsverhandlung.

        1. IT-Projekte sind i.d.R. größere Investitionen, die in Verträgen das organisationsübergreifende Entwicklungsprojekt zwischen Auftraggeber und Auftragnehmer regelt.

        2. Kunden müssen in der Planung aktiv mit einbezogen werden, damit fachliche und technische Unsicherheiten diesen nicht überfordern.

      4. Reagieren auf Veränderungen ist mehr als nur das Befolgen eines Plans.

        1. Eine ausgeprägte Anpassungsbereitschaft und Fähigkeit wird vorallem während des Projkts verlangt. Es muss kontinuierlich mit Änderungen an Anforderungen oder das System gerechnet werden, also auch mit dem Projektplan.

  3. Prinzipien der agilen SW Entwicklung:

    1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

    2. Heiße Anforderungsänderungen sind selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

    3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

    4. Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.

    5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.

    6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

    7. Funktionierende Software ist das wichtigste Fortschrittsmaß.

    8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

    9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

    10. Einfachheit – die Kunst, die Menge nicht erledigter Arbeit zu maximieren – ist essenziell.

    11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

    12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“

  4. Unterschied der Agilen Prinzipien zu klassischen Prozessparadigmen:

    1. Der Fokus der Projektorganisation liegt stark auf dem Produkt und der engen Zusammenarbeit der an der Erstellung beteiligten Personen.

    2. Das steht im Gegensatz zu vollständig geplanten Phasen, in denen nur bestimmte Aktivitäten ausgeführt werden dürfen.

    3. Scrum ist ein vollständig agiles Prozessmodell-Rahmenwerk

    4. RUP und V-Modell XT greifen agile Elemente auf.


Was ist Value-Based Software Engineering?

  1. Zweck:

    1. Alle Entscheidungen und Aktivitäten der SW Entwicklung orientieren sich konsequent an dem maximal zu erzielenden Nutzen der Stakeholder am Projekt

  2. Ausgangspunkt:

    1. SW Engeneering wird i.d.R. Wertneutral betrieben. Wie die Anforderungen der Stakeholder technisch am besten in das SW System umgesetzt werden können.

    2. Problem:

      1. Anforderungen sind gleichgewichtig.

      2. Controlling achtet nur auf Zeit und Kosten

      3. Zuständigkeit der Softwareentwickler wird nur auf die Übersetzung Anforderungen in den Programmcode reduziert.

    3. SW Systeme und SW Entwicklungsprogramme bestizten essentiellen Einfluss auf Erfolg von Wertschöpfungsketten und Geschäftsmodellen. Der tatsächliche Wertbeitrag für die organisation sollte im Mittelpunkt stehen.

  3. Kerngedanke und Hauptelemente:

    1. VBSE ist ein Rahmenwerk, dass die Berücksichtigung von tatsächlich für de Stakeholder geschaffenen Werten in alle Techniken und Methoden des SW Engeneerigs aktiv einbezieht.

    2. Es handelt sich um das Zusammenfassen von Techniken und Prinzipien, die den Fokus von IT-Projektteams auf die für die Stakeholder tatsächlichen geschaffenen Werte legt.

    3. Hauptelemente:

      1. Analyse der tatsächlichen Vorteile

        1. Welches Ergebnis kann tatsächlich erzielt werden.

        2. Die Ergebnisse helfen bei Fokussierung und der Kommunikation im Projekt.

        3. Nur wenn jeder im Team weiß, was im Projekt erreicht werden soll, ist es möglich, Entscheidungen Wertorientiert zu treffen.

        4. Darüberhinaus können Maßnahmen außerhalb des Projekts identifiziert werden, die den Einsatz der SW maximieren.

      2. Ausarbeitung und Schlichtung von Stakeholder-Interessen

        1. Im Projektverlauf sind konkurrierende und überschneidende Ziele zwischen relevanten Stakeholdern unvermeidbar.

        2. Interessen sind möglicherweise nicht vergleichbar und erschweren die Abwägung einer Lösungsstrategie.

        3. Eine gute Zusammenarbeit ist wichtig. kritische Erfolgsfaktoren müssen dargestellt werden und verhandelt werden. Es gilt Zielkonflikte übersichtlich darzustellen.

        4. Win-Win Vereinbarungen sollten zwischen konfliktparteien gefunden und dokumentiert werden.

      3. Business Case Analyse

        1. Wirtschaftlichkeitsanalyse mittels ROI.

        2. Anwendung bei Projektinitialisierung und Entscheidungen im Verlauf des Projekts.

        3. Unter Einbezug wirtschaftlicher Alternativen, Unsicherheiten, Risiken und nicht qualifizierbaren Nutzen bei Entscheidungsfindung.

        4. Techniken sind die multikriterielle Entscheidungsanalyse oder Nutzenfunktion.

      4. Kontinuierliches Management von Risiken und Alternativen

        1. Dient der Entscheidungshilfe während des SW Lebenszyklus hinweg.

        2. Die Wahrnehmung und Einschätzung von Risiken ist sehr unterschiedlich. Das reagieren auf die individuelle Nutzenfunktion der Stakeholder ist ein wichtiges Werkzeug zur Risikominimierung.

        3. Ermittlung des Gefährdungspotenzials verschiedener Handlungsoptionen. Risikowahrscheinlichkeit R und der Schaden S ermitteln das Gefährdungspotenzial G = R * S

      5. Gleichzeitiges System- und SW Engeneering

        1. Eine schnelle Reaktionszeit der IT auf geänderte Anforderungen ist besonders für UN relevant, deren Wertschöpfung eng mit IT-Systemen verbunden sind und bei denen eine schnelle Time-to-Market Wettbewerbsvorteile sichert.

        2. IT muss so organisiert sein, dass sie auf schnelle Anpassungen reagieren kann. Insbesondere das Prozessparadigma der evolutionären Entwicklung unterstützt die Entwicklung von kurzen Zeitabständen, welches z.B. das Wassferfallmodell niht zulässt.

      6. Wertebasierte Projektüberwachung und -Steuerung

        1. Das Projektcontrolling wird typischerweise durch das Earned Value Management dgf.

        2. Es wird überprüft wie viele Kosten das Projekt bereits verursacht hat und wie der aktuelle Bearbeitungsstand der Arbeitspakete im Vergleich zum ursprünglichen Plan ist.

        3. Bei häufigen Planänderungen ist diese Aussagekraft begrenzt. In der SW Entwicklung sollten zur Projektüberwachung und- Steuerung die tatsächlichen erzielten Beiträge und Ergebnisse berücksichtigt werden.

        4. Prüfung, ob die Beiträge des Systems realisiert wurden und ob die ursprünglichen Annahmen und Randbedingungen zur Erreichung des Ergebnisses noch zutreffen. Dann wurde ein Stakeholderrelevanter Wert geschaffen.

        5. In Verbindung mit der Business Case Analyse kann geprüft werden, wie die aktuellen Ausgaben im Verhältnis zu den erzielten Werten stehen.

      7. Veränderung als Chance

        1. Die Fähigkeit zur Veränderung und Anpassung ist ein Wettbewerbsvorteil.

        2. Dazu muss ein wirtschaftlich sinnvoller Grad an Veränderungsfähigkeit einzelner Systeme und der Systemlandschaft hergestellt werden.

        3. Die Technologische Anpassungsfähigkeit ist mit Investitionen verbunden.

        4. Eine mögliche Strategie ist die Sammlung vermutlich zukünftiger Änderungswünsche und die sofortige oder spätere Berechung der Kosten für deren Umsetzung. Real-Options-Theorie


Author

Paul T.

Information

Last changed