Schlagwort: Scrum

  • Der Designprozess im agilen Kontext von Scrum

    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.

  • Scrum oder Kanban

    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 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?

    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.

     

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.