Blog

  • Der Designprozess im agilen Kontext von Scrum

    Entwicklung nutzerzentrierter Produkte

    Die Entwicklung nutzerzentrierter Produkte erfordert einen strukturierten Designprozess. Im agilen Rahmenwerk von Scrum präsentiert sich dieser Prozess als iterativ und kollaborativ, wie die vorliegende Grafik veranschaulicht.

    Strategieentwicklung

    Der initiale Schritt umfasst die Strategieentwicklung und die Durchführung von Workshops und Interviews mit Stakeholdern. Diese Phase dient der Definition der Produktvision, der Ziele und der ersten User Stories, die in den Product Backlog einfließen. Sie entspricht der Product Backlog Verfeinerung und der Sprintplanung in Scrum.

    Wettbewerber- und Konzeptanalyse

    Anschließend erfolgt die Wettbewerber- und Konzeptanalyse. Diese dient der Informationsgewinnung und Ideengenerierung für erste Designansätze und kann in den frühen Sprints umgesetzt werden.

    Mockups und UX-Designs

    Die eigentliche Designarbeit innerhalb eines Sprints beginnt mit der Erstellung von Mockups und UX-Designs. Wireframes und Prototypen visualisieren die Benutzerführung und Interaktionen und werden im Sprint Review präsentiert.

    Grafik- und UI-Design

    Darauf aufbauend wird in weiteren Sprints das Grafik- und UI-Design entwickelt. Die Grafik zeigt, dass Korrekturen basierend auf Feedback zu Anpassungen in vorherigen Designphasen führen. Diese Iterationen sind ein zentrales Element des Scrum-Prozesses.

    Implementierung

    Parallel zur Designentwicklung erfolgt die Implementierung durch das Entwicklungsteam. Eine enge Abstimmung zwischen Design und Entwicklung ist für die erfolgreiche Umsetzung der Designspezifikationen entscheidend.

    Testing

    Nach der Implementierung erfolgt das Testing. Das Feedback aus Usability- und technischen Tests wird erfasst und fließt in den Product Backlog ein, um in zukünftigen Sprints adressiert zu werden.

    A/B-Testing

    Ein Instrument zur Optimierung des Designs ist das A/B-Testing, bei dem verschiedene Designvarianten mit Nutzern verglichen werden, um datenbasierte Entscheidungen für nachfolgende Sprints zu treffen.

    Launch

    Der Launch des Produkts markiert die Freigabe eines Inkrements. Der iterative Prozess setzt sich jedoch nach dem Launch durch kontinuierliches Testing und A/B-Testing fort.

    Zusammenfassend lässt sich festhalten: Der Designprozess im Scrum-Umfeld ist durch Iteration, frühes Feedback und die enge Zusammenarbeit des Teams gekennzeichnet. Anstelle eines linearen Vorgehens ermöglicht dieser agile Ansatz eine flexible und nutzerzentrierte Produktentwicklung, bei der Designentscheidungen kontinuierlich überprüft und angepasst werden.

  • UI/UX-Design: Agentur vs. Konzern

    Mal Agentur-Hektik, mal Konzern-Regeln

    User Interface (UI) und User Experience (UX) Design – ein echt spannendes Feld. Aber ob du da in einer quirligen Agentur sitzt oder in einem großen Konzern, das ist schon ein Unterschied wie Tag und Nacht.

    Die Agentur: Viel Abwechslung

    In einer Agentur? Da purzeln die Projekte nur so rein, für die unterschiedlichsten Auftraggeber. Heißt konkret:

    • Fexibilität und Neugier: Jeden Tag eine neue Branche, ein neues Produkt, eine neue Herausforderung. Da wird’s echt nicht langweilig.
    • Schnelligkeit ist keine Hexerei: Vom ersten Konzept bis zum Launch, das kann ganz schön schnell gehen.
    • Direkt am Ohr des Kunden: Du redest viel mit dem Kunden, kriegst direktes Feedback. Deine Designs müssen deren Wünsche treffen, das ist super wichtig.
    • Backend? Eher Nebensache: Um das „was unter der Haube steckt“ kümmern sich meistens die Entwickler. Dein Fokus liegt klar auf dem, was der Nutzer sieht und erlebt.

    Der Konzern: Langfristig und nachhaltig

    Im Konzern ticken die Uhren oft anders:

    • Experte werden: Du arbeitest meistens an größeren, langfristigen Sachen oder entwickelst bestehende Produkte weiter. Da kannst du richtig tief in die Materie eintauchen.
    • Alles hat seine Ordnung: Prozesse sind meistens klar geregelt, es gibt Designsysteme und Richtlinien, damit alles einheitlich aussieht.
    • Der „Kunde“ sitzt im Haus: Dein Auftraggeber ist oft intern – Produktmanager, Marketing-Leute usw. Deine Aufgabe ist es, die Bedürfnisse der Endnutzer zu vertreten, aber eben im Rahmen der Unternehmensziele.
    • Backend wird wichtig: Gerade bei komplexeren Systemen spielt das Backend eine größere Rolle. Du arbeitest eng mit den Backend-Entwicklern zusammen, damit am Ende alles reibungslos funktioniert.

    Das Backend: Mehr als nur Datenspeicher

    Egal wo du bist, das Backend-Design ist super wichtig, auch wenn man es nicht direkt sieht. Es geht darum, wie die Daten organisiert sind und wie sie für die Benutzeroberfläche bereitgestellt werden. Ein gutes Backend sorgt dafür, dass alles flüssig läuft und auch bei vielen Nutzern nicht zusammenbricht. Als UI/UX-Designer musst du zumindest eine Ahnung davon haben, was im Hintergrund möglich ist (und was nicht), damit deine Designs auch funktionieren.

    Die Verantwortung: Für den Nutzer, klar!

    Ob Agentur oder Konzern, am Ende designst du für Menschen. Es geht darum, deren Probleme zu lösen und ihnen eine gute Erfahrung zu bieten. Das heißt, du musst dich in die Nutzer hineinversetzen, gut kommunizieren können und deine Designentscheidungen auch mal erklären und verteidigen.

    Unterm Strich

    UI/UX-Design ist in beiden Welten – Agentur und Konzern – total spannend und bietet viele Möglichkeiten. In der Agentur ist es oft bunter und schneller, im Konzern dafür vielleicht etwas ruhiger und spezialisierter. Aber am Ende zählt immer: Das Design muss passen, das Backend muss laufen und die Nutzer müssen zufrieden sein!

  • Das Project Management Office – PMO – in IT Projekten

    Das Project Management Office – PMO umfasst sowohl

    • die Definition von Methoden und Prozessen für ein durchgängiges einheitliches Projektvorgehen,
    • die einheitliche Steuerung und
    • das Reporting,
    • als auch die operative Unterstützung des Projektmanagements.

    In größeren Unternehmen besteht das PMO aus einer eigenen Abteilung, die eine zentralisierte Rolle im Unternehmen hat. In kleineren Unternehmen besteht ein PMO häufig aus einer Einzelperson oder einem kleinen Team. Das PMO ist dann meist nur für einzelne Projekte zuständig und sorgt für die Entlastung der Projektleitung. In diesem Fall handelt es sich hier eher um Project Office (Projektbüro) als um PMO. Das Projekt Office besteht so lange wie das Projekt selbst, d. h., es besteht nicht auf Unternehmens-, sondern auf Projektebene.

    Beide Rollen bzw. Einheiten können gleichzeitig bestehen, es gibt doch Unterschiede bezüglich der Einsatzdauer und des Aufgabenbereichs. Grundsätzlich können PMO als allgemeiner Koordinator und PO als spezifische Einheit betrachtet werden.

    Das Project Office (Projektbüro) arbeitet als operative Unterstützung des Projektleiters direkt in den Projekten und wird oftmals ad hoc, während das Projekt bereits läuft berufen. Pos sind für die Projektdokumentation, das Projektreporting, sowie für administrative Aufgaben innerhalb des Projektteams zuständig.

    Das PMO arbeitet an Standards, Richtlinien, Prozessen und Methoden für den Einsatz in Projekten. Das PMO ist generell projektübergreifend tätig, kann aber bei Bedarf auch einzelne Projekte direkt unterstützen.

    Der Einsatz des PMO verbessert die Zielerreichung einzelner Projekte, und optimiert gleichzeitig die Prozesse für einheitliches Projektportfoliomanagement.

    Der Einsatz des Project Office führt zu einer Entlastung des Projektmanagers und des Projektteams, was wiederum zur Erhöhung der Effektivität in der Projektarbeit führt.

    Beide Rollen bzw. Einheiten können gleichzeitig bestehen, es gibt doch Unterschiede bezüglich der Einsatzdauer und des Aufgabenbereichs. Grundsätzlich können das PMO als allgemeiner Koordinator und das PO als spezifische Einheit betrachtet werden. Beide können helfen, ein Projekt kontinuierlich am Laufen zu halten, und dadurch Nutzen stiften, dass Projekte schneller umgesetzt werden, geringere Kosten entstehen und durch Prozesssicherheit höhere Qualität erzielt wird.

    Ist in einem Unternehmen ein PMO vorhanden, so wird dieses Vorgehensmodelle für Projekte erarbeiten. Solche Vorgehensmodelle beschreiben die beispielsweise die Art und Frequenz des Berichtswesens, die Projektdokumentation und eine einheitliche Projektstruktur. Die Projektleiter in solchen Unternehmen sind gehalten, diese Regeln anzuwenden, auch wenn projektbezogene Ausnahmen im Rahmen pragmatischer Arbeit immer erlaubt sein müssen.

    Anders verhält es sich in Unternehmen ohne PMO: hier wird das Vorgehensmodell üblicherweise innerhalb des Projekts erarbeitet und festgelegt. Der Projektleiter ist damit letztlich für das Vorgehensmodell verantwortlich, während der PO es lediglich anwendet und bestenfalls optimiert.

    Aufgaben des Project Office (Projektbüro) in IT Projekten

    • Erstellen von Standards und Templates für
      • die Projektdokumentation
      • das Reporting
    • Unterstützung des operativen Projektmanagements bei
      • der Planung,
      • dem Reporting und
      • dem Controlling.
    • Unterstützung des Projektteams bei administrativen Aufgaben: In einem Projekt fallen zahlreiche administrative Tätigkeiten – wie z. B. Dokumentation-, Berichts- und Bestellwesen – an. Ein PO kann diese Aufgaben vom Produktivteam fernhalten. So kann das PO des Teams von administrativen Aufgaben entlasten, was wiederum zur Erhöhung der Effektivität der Projektarbeit führt.

    Aufgaben des Projekt Management Office – PMO

    In IT Projekten hat das PMO, zusätzlich zu den eben beschriebenen Aktivitäten desProject Office (Projektbüro) folgende Aufgaben:

    • Definition einer unternehmensweiten Projektmanagement Kultur mit
      • geeigneten Tools und
      • Infrastruktur-Unterstützung, um das Wissen aus und in den Projekten transparent zur Verfügung zu stellen.
    • Sicherstellen des Einklangs der Projekte mit der Unternehmensstrategie: Das PMO sorgt dafür, dass die durchgeführten Projekte an der Unternehmensstrategie ausgerichtet sind. Diese Aufgabe beinhaltet unter anderem die Vorbereitung von Entscheidungsgrundlagen zur Projektauswahl und zur Priorisierung von Projekten.
    • Erstellen von projekteinheitlichen Regeln für
      • Projektmanagementmethoden,
      • Prozesse und Workflows für Projektkalkulation, Risiko- und Problemkontrolle, Anforderungskontrolle.
    • Unterstützung bei der Multi-Projektplanung mit
      • Koordination der unterschiedlichen Projekte und
      • Priorisierung.

    Das Project Management Office – PMO nach PMI

    Nach der Definition im Project Management Body of Knowledge (PMBOK Guide) des Project Management Institute (PMI), das PMO ist eine organisatorische Einheit, die das Management von Projekten, die zu seinem Bereich gehören, zentralisiert und koordiniert. Ein PMO wird auch als ‚Programm Management Office‘, ‚Projektoffice‘, oder ‚Programmoffice‘ bezeichnet.“

  • Risikomanagement in IT und Software-Projekten

    Das Risikomanagement in IT und Software-Projekten ist der wichtigste Faktor für die Absicherung, die Schadenminimierung und schließlich für den erfolgreichen Abschluss der Projekte. Unter Risikomanagement werden alle erforderlichen Aufgaben und Maßnahmen zur Risikobekämpfung zusammengefasst.

    IT und Software Projekte erweisen in ihr Laufzeit eine Vielzahl von Risiken. Die Risikohöhe nimmt mit der Größe und Komplexität der geplanten Software und mit der Anzahl der Schnittstellen zu anderen Systemen überproportional zu. Deshalb ist es wichtig, dass alle Risikofaktoren in die Vorphase und in die Planung und Überwachung des Projekts mit einbezogen werden.

    Zu den Risikofaktoren eines IT Projekts zählen sowohl Allgemeine als auch Spezielle Risikofaktoren.

    Allgemeine Risikofaktoren, relevant für das Risikomanagement in IT und Software-Projekten

    • unzureichende Unterstützung durch die Geschäftsführung
    • Spannungen und Konflikte im Projektteam
    • Fehlende Motivation im Projektteam
    • Fehlende Benutzerakzeptanz
    • mangelhafte Informations- und Kommunikationsstrategie
    • unzureichende Fachkompetenz der Teammitglieder

    Spezielle Risikofaktoren(fachliche und methodische Risiken)

    • fehlende und unklare Zielsetzung des Projekts
    • unrealistische Terminvorgaben
    • fehlende Planung, Termin- und Kostenüberwachung
    • mangelhafter Überblick des Projektstands und Fortschritts
    • Schnittstellenprobleme (Fehlende Dokumentation, Inkompatibilitätsprobleme)
    • unzureichende Tests und fehlende Qualitätskontrolle

    Das Vorgehen beim Risikomanagement in IT und Software-Projekten besteht aus folgenden Schritten

    • Identifikation der Ursachen
    • Analyse
    • Risikobewertung
    • Priorisierung anhand der Auswirkungen und der Eintrittswahrscheinlichkeit
    • Einleitung von Maßnahmen
    • Konsequente Verfolgung der Risiken (Monitoring)

     Risikobewertung

    Die Risikobewertung dient der Priorisierung und anschließend der kontinuierlichen Überwachung. Sie ist die Grundvoraussetzung für eine gezielte Steuerung und Behebung oder Minimierung des Risikos durch Maßnahmen. Die Risiken werden hinsichtlich ihrer Eintrittswahrscheinlichkeit und Auswirkung bewertet und priorisiert.

    1. Niedrige Priorität: Das Risiko ist definitiv nicht Projektgefährdend, muss doch überwacht werden.

    2. Mittlere Priorität: Das Risiko ist wahrscheinlich nicht Projektgefährdend, muss doch intensiv überwacht werden.

    3. Hohe Priorität: Das Risiko gefährdet das Projekt. Die Maßnahmen zur schrittweisen Behebung oder Reduzierung des Risikos, müssen geplant und Zeitnah eingeleitet werden.

    4. Höchste Priorität: Sofortige Maßnahmen müssen in diesem Fall eingeleitet werden. Das Risiko kann große Projekt- oder sogar Unternehmensweite Schaden verursachen.

    Voraussetzungen für erfolgreiches Risikomanagement in IT und Software Projekte

    Kontinuität

    Die Risiken müssen identifiziert und intensiv verfolgt werden. Potenzielle neue Risiken müssen immer wieder überprüft und erkannt werden.

    Offene Kommunikationskultur

    Im Unternehmen muss eine offene Kommunikationskultur gelebt werden, damit im Rahmen des Risikomanagements die Maßnahmen in unterschiedlichen Bereichen des Unternehmens ausweiten zu können. In diesem Zusammenhang jemand, der Risiken meldet, darf auf keinem Fall vor beruflichen Konsequenzen fürchten.

    Vollständige Integration im Entwicklungsprozess

    In der gesamten Laufzeit eines Projekts muss Risikomanagement fester Bestandteil der Prozesse sein.

  • Tester und Testmanager in Scrum

    Tester und Testmanager gibt es zwar als Rollen in Scrum Prozess nicht, allerdings ist Scrum nur ein Softwareentwicklung-Framework, das keine technischen Praktiken diktiert. Nun, da Scrum Teams übergreifende Teams sind, gehören Tester bzw. Testmanager dazu.  So wird beim agilen Prozess die Unabhängigkeit zwischen Entwicklungs- und Testmannschaft, die bei den klassischen Methoden die Regel ist, aufgegeben.
    Tester und Testmanager sind hier Teile des Scrum Teams. Statt auf freigegebene Anforderungs- und Designdokumente zu warten, sind sie im agilen Team zu Kommunikation, Interaktion und aktiver Mitarbeit aufgerufen. Auch wenn sie keinen Code schreiben, müssen Tester bei der Automatisierung von Regressionstests und anderen Automatisierungstests sehr eng mit den Programmierern zusammenarbeiten.

    Sobald ein Programmierer eine User Story implementiert, sollte der Tester bereits die Testfälle anhand der Akzeptanzkriterien vorbereitet haben, um mit den Tests der Story beginnen zu können.

    Erst wenn alle User Stories implementiert und die Tests erfolgreich abgeschlossen sind, kann ein Sprint als erfolgreich abgeschlossen betrachtet werden. Hier ist natürlich die Continuous Integration Umgebung sehr wichtig, um die Änderungen der Entwicklung sofort dem Testing zur Verfügung zu stellen.

    Aufgaben der Tester und Testmanager in einem Scrum Team

    • Analysieren der User Stories auf ihre Qualität und Vollständigkeit
    • Mitdefinieren der Akzeptanzkriterien
    • Prüfen der Akzeptanzkriterien auf Testbarkeit
    • Sicherstellen von Testdaten
    • Sicherstellen der Rückverfolgung zwischen User Story und Test
    • Beteiligung an der Sprint-Planung und den Daily Scrum Meetings
    • Funktionales Testen der User Stories
    • Usability Tests
    • Explorarives Testing
    • Mitarbeit mit den Programmierern bei der Implementierung von Unittests
    • Ausführung einer Kombination von Unitests und explorativen Tests. So werden schnell Fehler gefunden, die allen von Unitests nicht gefunden werden können.
    • Performance und Security Tests

    Damit die Sprints erfolgreich getestet werden, ist der Betrieb einer Continuous Integration Umgebung, in der automatisierte Unit-, Integrations- und Systemtests die Implementierung der User Stories begleiten, notwendig.

    Die Implementierung von den Unit-, Integrations- und Systemtests übernehmen die Entwickler, Tester arbeiten mit. Um diese Tätigkeiten qualitativ auszuführen bedarf es  guter Kommunikation, analytischer Kenntnisse und methodisches Vorgehen.

    Und selbstverständig … Agiles Testen, Tester und Testmanager folgen den Prinzipien des agilen Manifests und wenden die agilen Prinzipien auf das Testen an.

    Siehe das Agile Manifest.

  • Scrum oder Kanban

    Beide Projektmanagement-Frameworks dienen dem agilen Softwareentwicklungsprozess und unterstützen die Philosophie, dass sich Prozesse und Tools den Individuen und deren Interaktionen unterordnen müssen.

    Es sind beides Frameworks zur Ablaufplanung, die auf dem “Just-in-Time”-Prinzip aus der Lagerverwaltung des Leankonzepts basieren. Das Team als zentrale Instanz sagt, wann und wie viel Arbeit in einem bestimmten Zeitraum zu schaffen ist und verpflichtet sich auf die Fertigung. Die Teammitglieder “ziehen” Arbeit heran, wenn sie bereit sind, und bekommen sie nicht von außen „zugeschoben“, wie bei den klassischen Methoden.

    Der kontinuierliche und erfahrungsgestützte Verbesserungsprozess, wie es das Kaizen-Prinzip aus dem Leankonzept vorgibt, ist ein wichtiger Bestandteil beider Frameworks.

    Scrum oder Kanban?

    Scrum hat seine Vorzüge dort, wo es darum geht, sehr flexibel und agil auf geänderte Anforderungen einzugehen.

    Kanban stellt das Ziel in den Vordergrund, Probleme im Projekt transparent zu machen und zeitnah effizient zu lösen.

    Ähnlichkeiten von Scrum und Kanban

    • beide Frameworks haben ihre Wurzeln in dem Leankonzept und sind agil
    • Beide haben als Basis das Pull-Prinzip (Hol-Prinzip): Die anfallende Arbeit verteilt nicht ein „Supervisor“, sondern die Teammitglieder holen sich ihre Arbeit, um den Produktionsfluss möglichst fließend zu halten
    • Im Brennpunkt stehen bei beiden Flexibilität und maximaler Kundennutzen: schnell und oft ausführbare Software liefern
    • Beide bemühen sich auf kontinuierliche Prozessverbesserung durch Transparenz
    • Die Teams sind selbstorganisierte Teams

    Unterschiede

    • Bei Scrum gibt es 3 Rollen(Product-Owner/Scrum Master/Team), und Spielregeln(Dailyscrum, Sprints, Produktbacklog). Kanban Schreibt keine Rollen vor
    • Während es bei Scrum Iterationen mit festem Zeitschema, die sogenannten Sprints gibt, sind bei Kanban die Iterationen mit festem Zeitschema optional
    • Der Prozess ist bei Scrum zeitgetrieben, während es bei Kanban ereignisgetrieben ist
    • Das Team gibt bei Scrum, in der Sprintplanung, sein Commmitment für die Abarbeitung eines bestimmten Arbeitpakets innerlalb des Sprints, während bei Kanban keine bestimmte Arbeitspaketgröße vorgeschrieben ist und das Commitment optional ist
    • Das Schätzen des Aufwands ist bei Scrum vorgeschrieben, während bei Kanban das Schätzen optional ist
    • Bei Scrum gibt es ein priorisiertes Produktbacklog, bei Kanban ist die Priorisierung der Tasks optional
    • In Scrum gehört das Sprintbacklog einem bestimmten Team, ein Kanbanboard kann von mehreren Teams bearbeitet werden
    • Ein Scrumboard wird für jeden Sprint neu eingesetzt, ein Kanbanboard bleibt durchgehend bestehen

    Ein Beispiel des KanbanBoards

     

    Kanban entstammt dem Japanischen. Dort heißt かんばん (看板) so viel wie „Karte“, „Tafel“ oder „Beleg“. Alternative Namen für Kanban sind Hol-, Zuruf- oder Pull-Prinzip. Quelle: Wikipedia

  • Klassisches Projektmanagement und Scrum

    Klassisches Projektmanagement basiert sich auf Wasserfall Methoden und die Rolle „Projektmanager“ trägt die Verantwortung für den Erfolg des Projekts. Der klassische Projektmanager ist derjenige, der ein Projekt inhaltlich und zeitlich plant und vorantreibt, das Projektbudget verwaltet, die Umsetzung leitet, mit den Stakeholdern kommuniziert und alle erfolgsrelevanten Rahmenbedienungen des Projekts berücksichtigt.

    Rollen bei Scrum

    Bei Scrum gibt es die Rolle „Projektmanager“ nicht mehr. Dafür gibt es die Rollen „Product Owner“ und „Scrum Master“. Die Aufgaben des klassischen Projektmanagers werden auf diese beiden Rollen verteilt.

    Der „Product Owner“ ist für die Vision, die inhaltliche Beschreibung der Anforderungen, die Planung in enger Zusammenarbeit mit dem Team, die Steuerung der Umsetzung und das Budget verantwortlich.

    Der „Scrum Master“ sorgt für optimale Arbeitsbedienungen, räumt Hindernisse und Störer aus dem Weg und unterstützt das Team bei fachlichen Problemen.

    Die Rolle „Team“ ist bei Scrum sehr wichtig, da es für die Einhaltung der Planung und die Umsetzung, durch das Commitement verantwortlich ist.

    Die Verantwortung für den Erfolg eines Projekts tragen bei Scrum alle drei Rollen zussammen.

    Der klassische Projektmanager ist durch seine Kenntnisse fähig, beide Rollen zu erfüllen. Man sollte hier prüfen, welcher Teil der Rollen einem am besten liegt:

    Treibt man ein Projekt gerne inhaltlich voran, hat kreative Ideen für neue Produkte und kann gut die Budgets verwalten, dann sollte man die „Product Owner“-Rolle wählen. Ist man hingegen eher der „Kümmerer“ und versteht die Technik gut, dann sollte man am besten die „Scrum Master“-Rolle einnehmen.

    Es gibt jedoch größere Projekte, die zusätzlich zu den Rollen „Product Owner“ und „Scrum Master“ auf klassisches Projektmanagement angewiesen sind. Ein Projektmanager ist bei größeren Vorhaben eine Notwendigkeit, da es hier nicht nur um die Umsetzung eines Produkts, sondern mehrerer Produkte mit mehreren Schnittstellen geht.

    Diese Person sollte dann die Gesamtplanung des Projekts verantworten, die Stakeholder steuern, die Schnittstellen zu anderen Produkten oder Projekten berücksichtigen, Maßnahmen zur Infrastruktur und den erfolgreichen Betriebsübergang treffen, um das Projekt erfolgreich abschließen zu können.

  • Scrum oder klassische Methoden für das Projektmanagement?

    Scrum oder klassische Methoden für das Projektmanagement? In vielen Unternehmen wird über den Einsatz Agiler Methoden in IT-Projekten nachgedacht.

    Klassische Methoden

    Die klassischen Methoden der Softwareentwicklung basieren auf einer sequenziellen, schrittweisen Entwicklung, die in mehrere Phasen unterteilt ist. Die Phasen bauen in einer festgelegten Reihenfolge aufeinander auf.

    Das bekannteste Modell ist hier das Wasserfallmodell.

    Die typischen Phasen des Wasserfallmodells sind:

    • die Konzeption (Anforderungsanalyse und -spezifikation),
    • das Design (Systemdesign und -spezifikation),
    • die technische Umsetzung (Programmierung und Modultests),
    • die Integrationstests (Integrations- und Systemtest) und
    • der Roll-out und Support (Auslieferung, Einsatz und Wartung).

    Die klassische Methoden verlangen die konsequente Durchführung der vorher geplanten Phasen. Dadurch können große und umfangreiche Projekte präzise und mit hoher Planungssicherheit durchgeführt werden.

    Der größte Vorteil des Wasserfallmodells ist die hohe Planungssicherheit. Durch die geordnete Struktur können auch umfangreiche Projekte präzise geplant und zuverlässig durchgeführt werden. (Steht schon so im Absatz hier drüber)

    Allerdings können Entscheidungen in einer abgeschlossenen Phase – ohne einen aufwändigen Change Request-Prozess – nicht mehr geändert werden. Das wiederum kann zu Gefährdung der Planung (des Projektes?) führen.

    Der Fokus bei den klassischen Methoden liegt auf Strukturen, langfristige Planung und detaillierte Spezifikation.

    Bezogen auf das Dreieck des Projektmanagements sind die Kosten und der Umfang des Projekts festgelegt, während die Dauer in Gefahr ist.

    Agil

    Bei den agilen Methoden liegt der Focus auf Werte und Prinzipien. Der Mensch und das Team haben hier eine sehr hohe Bedeutung. Es wird ein produktives Arbeitsumfeld mit Wert auf schnelle Veränderungen, Kommunikation und Eigenverantwortlichkeit gefordert/geschaffen?.

    Das agile Manifest legt die wesentlichen Prioritäten fest:

    „Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.

    Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

    • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
    • Funktionierende Software mehr als umfassende Dokumentation
    • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
    • Reagieren auf Veränderung mehr als das Befolgen eines Plans

    Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein“

    Bezogen wiederum auf das Dreieck des Projektmanagements sind bei Scrum die Kosten und die Dauer des Projekts festgelegt, während der Umfang flexibel und veränderbar ist.

    Ziel der Entwicklung bei Scrum ist es, eine lauffähige und akzeptable Software zu entwickeln.

    Dafür wird die komplexe und umfangreiche Entwicklung in kleine Teilprojekte zerteilt. Diese werden nacheinander in sog. Sprints, die in der Regel zwei bis vier Wochen dauern, umgesetzt. Das Ziel jedes Sprints ist die Auslieferung von funktionsfähiger und qualitativ hochwertiger Software.

    Im Verlauf der Entwicklung können sich die Anforderungen und Randbedingungen ändern. Auf diese Änderungen muss das Team schnell reagieren können. Änderungswünsche werden während der Entwicklung aufgenommen und nach Priorität im nächsten Sprint realisiert.

    Allerdings läuft man Gefahr – durch den schnellen Änderungsprozess – nur kurzfristige (und fehleranfällige?) Lösungen zu schaffen. Durch die Teilung in Sprints kann man den Überblick über das Ganze verlieren.

    Fazit Scrum oder klassische Methoden:

    Scrum ist bei Entwicklungsprojekten mit hohem Termindruck geeignet, bei dem die Anforderungen an das zu entwickelnde Produkt zu Beginn des Projekts noch unklar sind.

    Scrum erfordert jedoch häufig einen Wandel des existierenden Verständnisses von Führung und Verantwortungsbereichen, um die für agile Projekte maßgeblichen Freiräume für Selbstorganisation, Selbstverantwortung und Entscheidungskompetenz der operativen Teams zu schaffen.

    Die Auswahl der Methodik sollte sich immer zwingend an der Unternehmenskultur und an der aktuellen Situation orientieren. Sowohl Scrum als auch klassische Methoden haben ihre Vor- und Nachteile. Jedoch beide Verfahren fordern die richtigen Rahmenbedinungen, um ein Projekt zum Erfolg zu bringen.

    Zu diesen Rahmenbedienungen zählen neben der Bereitstellung der notwendigen Ressourcen, sowohl die Wertschätzung des Teams, als auch die richtige Planung, Motivation und Kommunikationsstrategie.

    Sogenannte hybride Ansätze kombinieren klassische und agile Methoden miteinander. Je nach Projektphase oder Vorgang kann auch nach dem Werkzeugkastenprinzip der jeweils geeignete Ansatz gewählt werden.

     

  • Wer findet das kreativste Konsensmodell?

    Die Suche nach dem einfallsreichsten Konsensmodell geht weiter…

    Auch wenn Proof-of-Work, über das wir  in unserem ersten Beitrag zu Proof-Modellen (hier) berichtet haben, nachwievor das bekannteste und meistverwendetste Konsensmodell ist, gibt es allerlei Abwandlungen und Mischformen . Nichts ist in Stein gemeißelt und die Suche nach energieschonenderen und sicheren Lösungen ist noch lange nicht vorbei. Neben Lösungen, die die Blockchain als Web-of-Trust durch Vertrauenspersonen (wie auch schon hier dargestellt), gibt es hier einige andere innovative Ansätze:

    Tangle

    IOTA verwendet keine Blockchain, hat aber technisch ein ähnliches System (hier das Whitepaper). Jeder User, der eine Transaktion durchführen will, muss zwei andere Transaktionen bestätigen. Dadurch können zugleich verschiedene Transaktionen an verschiedenen Stellen bestätigt werden und das System soll mit steigender Teilnehmerzahl schneller statt langsamer werden. Das System ist besonders geeignet für Gegenden, in denen es Internetprobleme gibt, weil die Geräte auch mit Bluetooth oder anderen Systemen miteinander verbunden werden können und damit Transaktionen dennoch ausgeführt werden können.

    Proof-of-Membership (PoM)

    Das Proof-of-Membership Konsensmodell schränkt im Vergleich zu PoW oder PoS die Gruppe derer, die bestätigen, dass eine Transaktion so stattgefunden hat, wie behauptet, auf eine offene Gruppe von Mitgliedern oder sogar eine geschlossene Gruppe von vertrauenswürdigen Mitgliedern aus.

    Dieses Modell wird derzeit noch nicht verwendet, befindet sich aber in Diskussion.

    Proof-of-Importance (PoI)

    Der Proof-of-Importance wurde von NEM erfunden um zu verhindern, dass jene belohnt werden, die das beste Equipment haben oder am meisten Coins. Der PoI belohnt jene, die am meisten für die Community tun. Es basiert darauf, wie viele Transaktionen ein User hat und mit wem. Ziel ist es, den Reichtum an jene auszuschütten, die in der Community am meisten aktiv sind. Harvesting ist das Wort das anstelle von Mining verwendet wird und die Importance eine Users wird durch einen “trust Score” bewertet, der sich daraus berechnet, wie viel der User das Netzwerk benutzt. Harvesting kann jeder betreiben, der 10.000 Xem besitz, die als angestammt angesehen (vested) werden. Egal welche Summe von Token gekauft wird, wird immer 10% pro Tag als angestammtes Kapital angesehen, sodass nach 10 Tagen die gesamte Summe dazu zählt.

    Proof-of-Play (PoP)

    Bisher wird Proof-of-Play erst von einem einzigen Coin als Konsensmodell verwendet – MotoCoin (hier das Whitepaper). Anstelle der komplizierten Rechenaufgabe, die ein Computer zu lösen hat, wird gemined indem eine 2D-Motorrad-Simulation manuell gespielt wird. Es ist keine spezielle Hardware erforderlich, der Energieverbrauch ist deutlich geringer als beim klassischen minen und eine Attacke durch 51% gilt als unmöglich, weil es sehr teuer wäre genug erfahrene Spieler zu gewinnen und diese den Coin dann wohl lieber minen als zerstören wollen würden.

    Proof-of-Elapsed-Time (PoET)

    Intel hat vor einigen Jahren den Algorithmus für Proof-of-Elapsed Time entwickelt. Dieser basiert darauf, dass eine vertrauenswürdige Laufzeitumgebung gibt, in der ein Zufallsgenerator oder ein Lotterie-basiertes System entscheidet, wer den nächsten Block finalisiert. Dafür wird eine zufällig verteilte Leader Wahl unter allen verfügbaren Teilnehmern durchgeführt, für die alle Beteiligten verifizieren können, ob diese Wahl manipulationsfrei gelaufen ist. Die Wahl funktioniert so, dass jeder Validierer bei der Software um eine Wartezeit anfragt und jener, der die kürzeste Wartezeit bekommt, die Lotterie gewinnt und der Leader wird. Wenn ein Validierer behauptet, der Leader zu sein und den Block erstellt, wird damit auch ein Beweis erstellt, den die anderen einfach verifizieren können. Dieser Beweis enthält auch die Information, dass dem Validierer tatsächlich die kürzeste zugewiesen war und dass er die vom Protokoll vorgeschriebene Zeit gewartet hat, bevor er den nächsten Block gemined hat. Dadurch, dass der Zufall die Wartezeiten generiert, wird sichergestellt, dass die Rolle des Leader zufällig auf die Teilnehmer verteilt wird.

  • Proof-Alternativen für die Blockchain-Technologie

    Proof-Alternativen: Byzantinisches Problem, Delegierte und vertrauensvolle Systeme

    Neben Proof-of-Work und Proof-of-Stake (die wir schon in unserem vorherigen Artikel behandelt haben) gibt es allerlei Abwandlungen und Mischformen. Die folgenden beiden Modelle versuchen über Delegierte, Zeugen und Sprecher vertrauensvolle Systeme zu erstellen:

    Proof-Verfahren: Delegated Byzantine Fault Tolerance

    Dieser von NEO verwendete Algorithmus kombiniert die Vorteile von Proof-of-Stake und den Lösungen des byzantinischen Problems. Es wird eine Anzahl von Delegierten definiert, die einen Konsens über eine Order des Speakers erreichen müssen. Obwohl sowohl die Delegierten als auch die Speaker unehrlich sein können, wird mit einer Konsensrate von 66,66% abgesichert, dass die Buchungen korrekt sind. Innerhalb einer festgesetzten Zeit sendet ein Consensus Node eine Transaktion mit den Signaturen des Senders an das gesamte Netzwerk. Der erste Speaker sieht sich die Buchung an und sendet seinen Vorschlag; dieser Vorschlag wird wiederum von den Delegierten validiert. Wenn die Delegierten zustimmen und den Bock signieren, wird der Block in die Blockchain gehängt. Wenn der Prozess die festgesetzte Zeit überschreitet, wird eine neue Konsensrunde gestartet.

    Das byzantinische Problem

    Warum reicht eine Konsensrate von 66,66%? Die Basis dafür ist das sogenannte byzantinische Problem.

    Der Legende nach hatten osmanische Generäle im Jahr 1453 n. Chr. bei der Belagerung von Konstantinopel (Byzanz) ein Kommunikationsproblem. Während sie an verschiedenen Stellen um die Stadt lagerten und nur mit Boten kommunizieren konnten, wussten sie bei der Planung ihres Angriffs, dass einige der Generäle Verräter waren und bewusst die Planung torpedieren würden.

    Im Jahre 1982 veröffentlichten Lamport, Shostak und Pease – entspannte 500 Jahre später –  Lösungen für dieses Problem (hier ihre Publikation).

    Grundannahmen dieser Lösung sind die Folgenden: Der Befehlshaber schickt allen Generälen den selben Befehl und die loyalen Generäle befolgen jeweils den Befehl, den sie erhalten. Alle schicken untereinander jeweils ebenfalls die Befehle, wobei bekannt ist, dass die illoyalen diese Befehle verfälschen und die loyalen nicht. Damit können die Leutnants die eingehenden Befehle als Wahl behandeln, also jenen Befehl ausführen, der ihnen am öftesten zugetragen wird.

    Eine Lösung besagt, dass solange der Anteil der verräterischen Generäle kleiner als ein Drittel ist, die Lösung tolerant ist gegen den Byzantinischen Fehler.

    Die zweite Lösung benötigt nicht fälschbare Signaturen; diese erhält Fehlertoleranz bei beliebiger Anzahl verräterischer Generäle.

    Auf Basis diese Lösung reicht also eine Zustimmung von zwei Drittel der Speaker und Delegierten, die nicht fälschbaren Signaturen erhöhen die Fehlertoleranz.

    Delegated Proof-of-Stake (DPoS)

    DPoS versucht die Nachteile des Proof-of-Work und des Proof-of-Stake auszugleichen, indem ein Layer technologischer Demokratie eingezogen wird. Die Echtheit von Transaktionen wird von auserwählten Zeugen bestätigt. Diese Zeugen werden von den Eigentümern der Coins bestimmt. Es kann eine unbeschränkte Anzahl von Zeugen bestimmt werden, solange zumindest 50 % der Mitglieder der Meinung sind, dass mit den gewählten Zeugen ausreichend Dezentralisierung gewährleistet ist.

    Zusätzlich werden auf die gleiche Art Delegierte gewählt, die dafür verantwortlich sind das Netzwerk zu erhalten und sogar Änderungen am Netzwerk vorschlagen können.

    Damit soll nicht nur aktuelle Funktionalität und Sicherheit gewährleistet werden, sollten Änderungen notwendig werden, so können diese ebenfalls einfach abgestimmt werden.

galaniprojects GmbH
Datenschutz-Übersicht

Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.