News

    Holisticon auf Twitter folgen

     

    Agiles Glossar

    Unser Agiles Glossar entzaubert und erklärt die vielen Fachbegriffe wie beispielsweise DSDM Atern, ScrumMaster, Velocity, Planungs-Poker, Lean etc., die durch alle möglichen eZines und Printmedien geistern, und erklärt, was hinter den Begrifflichkeiten steckt.

    Wenn Sie Begriffe vermissen, die Ihrer Meinung nach erklärt gehören oder falls Sie Fragen haben, mailen Sie uns doch einfach unter

    Index

    A⋅B⋅C⋅D⋅E⋅F⋅G⋅H⋅I⋅J⋅K⋅L⋅M⋅N⋅O⋅P⋅Q⋅R⋅S⋅T⋅U⋅V⋅W⋅X⋅Y⋅Z⋅Alle


    A     nach oben
    Agile Manifesto Im Februar 2001 trafen sich die agilen Köpfe dieser Welt, um darüber zu diskutieren, welches denn der wahre agile Prozess sei. Es handelte sich z.B. um Ken Schwaber und Jeff Sutherland aus dem Scrum-Lager, Kent Beck von XP, Alistair Cockburn von der Crystal Family und viele andere Vorreiter der agilen Bewegung. Erwartungsgemäß konnten sie sich nicht auf die einzig wahre Methode einigen, sie verfassten aber das Agile Manifest, sozusagen der Kleinste Gemeinsame Nenner aller agilen Methoden.

    Diese besagen:

    • Menschen und Zusammenarbeit sind wichtiger als Prozesse und Werkzeuge
    • Funktionierende Software ist wichtiger als verständliche Dokumentation
    • Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen
    • Reagieren auf Veränderungen ist wichtiger als einem Plan zu folgen.

    Obwohl die Dinge auf der rechten Seite ihren Wert haben, werten wir die Dinge auf der linken Seite doch höher.

    Dies wird gemeinhin als das agile Wertesystem bezeichnet, also die Prinzipien, die allen agilen Methoden gemeinsam ist.

    Näheres unter http://agilemanifesto.org/

    Agiles Planen Gemeinhin sind agile Vorgehensweisen dafür berüchtigt, keine Planungsanteile zu besitzen, sondern chaotisch zu sein. Dies ist falsch, wie man an der Grafik sehen kann.

    Bei Scrum gibt es in den Sprints vier explizite Planungs-Meetings:

    • Sprint Planning 1, in dem aus dem Product Backlog die Stories für den aktuellen Sprint ausgewählt werden
    • Sprint Plannung 2, in dem aus den ausgewählten Stories Tasks gemacht werden
    • Review, in dem die Ergebnisse des Sprints den Stakeholdern vorgeführt werden
    • Retrospective, in der die Erlebnisse des Sprints diskutiert und bewertet werden und evtl. Konsequenzen gezogen werden, die als neue Stories in den nächsten Sprint eingehen.

    Dazu kommen nebenläufige Planungstätigkeiten, die bei Bedarf durchgeführt werden:

    • Releaseplanung vor dem ersten Sprint (und immer mal zwischendrin)
    • Estimation Meetings, in denen das Team neu ins Backlog kommende Stories schätzt
    • Architektur Meetings, in denen das Team über die Architektur der Applikation diskutiert
    Agiles Schätzen Schätzungen werden in agilen Projekten nicht im stillen Kämmerlein vorgenommen, sondern in einer gemeinsamen Teamrunde, damit alle das Thema kennen und eine Zahl entsteht, die von allen mitgetragen wird. Näheres siehe unter Planning Poker.
    Anforderungen Anforderungen sind die Eigenschaften, von denen der Auftraggeber möchte, dass das neue Produkt sie erfüllt.

    Hierbei ergeben sich zwei Probleme:

    • Erstens ist es extrem schwierig, Anforderungen so zu formulieren, dass sie ohne Missverständnisse beim Realisierer ankommen
    • Zweitens ist es bei Projekten, die über mehr als ein paar Wochen laufen, so gut wie sicher, dass sich die Anforderungen im Laufe des Projektes ändern werden, z.B. weil der Kunde eine frühe Version sieht und weitere tolle Ideen hat

    Aus diesem Grund werden in agilen Projekten keine Lastenhefte geschrieben, auf die dann der Auftragnehmer mit einem Pflichtenheft antwortet (wie krank ist das denn? Ich schreibe auf, was ich glaube, verstanden zu haben? Wie wäre es mal mit reden?), sondern alle Anforderungen werden in Form von User Stories formuliert und in das Product Backlog geschrieben. Diese Anforderungen sind dann so formuliert, dass man im engen Dialog herausfinden muss, was genau gemeint ist und genügend Spielraum hat, um Implementierungsdetails selbst zu bestimmen.


    B     nach oben
    Backlog Ein Backlog ist einfach eine Liste von Dingen, die noch erledigt werden müssen. In Scrum werden Anforderungen in ein Backlog geschrieben.

    Man unterscheidet zwischen

    Berichte Berichte im herkömmlichen Sinne gibt es in der agilen Welt nicht mehr. An deren Stelle gibt es ein Daily Scrum, das öffentlich ist und wo sich jeder über den aktuellen Stand des Projektes informieren kann und mindestens ein Burn Down Chart, an dem der Fortschritt im aktuellen Sprint abgelesen werden kann.
    Burn Down Chart Am Anfang eines Sprints wird festgelegt, welche User Stories im Sprint umgesetzt werden. Jede einzelne Story ist vorab in ihrer Größe (in Story Points) geschätzt worden.

    Der Anfang eines Burn Down Charts ist die Summe der Story Points, die in diesem Sprint abgearbeitet werden sollen (Y-Achse). Auf der X-Achse sind die Tage des Sprints aufgezeichnet. Nach der Abarbeitung jeder Story wird am Tag der Erledigung die entsprechende Punktzahl abgezogen, so dass im Laufe des Sprints die Kurve absteigend gegen Null läuft. Wichtig ist hier, dass nur 100% fertige Stories abgetragen werden, 80% erledigt z.B. wird noch als null gewertet.

    Beispiel eines Burn Down Charts:

    Business Value Neudeutsch für Geschäftswert. Dies ist in der agilen Welt der zentrale Begriff, an dem sich jeder Realisierungsaufwand messen muss. Jede User Story muss vom Product Owner nach Business Value bewertet und in der Priorität eingestuft werden. Danach wird die Größe der Story in Story Points bewertet. Über die Velocity und die Größe des Teams kann letztendlich auf den Preis für die Story rückgerechnet werden. Nur wenn der Business Value größer ist als der Preis für die Realisierung, sollte die Story umgesetzt werden.

    Außerdem gilt die Grundregel, dass jede Story einen Business Value besitzen muss. Rein technische Stories, die keinen Mehrwert für den Auftraggeber besitzen, gibt es nicht. Technische Details, die sicher wichtig sind, werden nur im Zusammenhang mit einer Story umgesetzt, die einen echten Business Value besitzt.


    C     nach oben
    Certified ScrumMaster Wie bei vielen anderen Ausbildungen auch gibt es im Bereich Scrum eine Reihe von Zertifizierungen, die in diesem Fall von der Scrum Alliance vorgenommen werden. Die Eingangsstufe hierbei ist der CSM, bei dem seit Neuestem auch durch eine Prüfung nachgewiesen werden muss, dass man verstanden hat, was Scrum bedeutet.

    Holisticon hat übrigens alle seine Mitarbeiter zum Certified ScrumMaster ausbilden lassen, wir sind also “100% agil”.

    Die nächste Stufe ist der Certified Scrum Practitioner, dann folgen der Scrum Coach und der Scrum Trainer.

    CMMI Capability Maturity Model Integration. Ist ein Messmodell für den Reifegrad von Prozessen. Man unterscheidet 5 Reifegrade:
    • Initial: Es gibt keinen Prozess. Dies ist der Mindestwert, der für jedes Unternehmen zutrifft
    • Geführt: Die Prozesse werden zielgerichtet geführt. Vergleichbare Projekte werden vergleichbar durchgeführt.
    • Definiert: Der Prozess ist beschrieben. es gibt einen Stadardprozess, nach dem gleichartige Projekte durchgeführt werden.
    • Qualitativ geführt: der Anwendung des Standardprozesses wird überwacht.
    • Optimiert: Die Ergebnisse der Überwachung des Standardprozesses führt zu Verbesserungen des Prozesses.

    Nach dieser Definition ist Scrum dann also CMMI Level 5, da mit dem Prinzip Inspect-And-Adapt die Überwachung des Prozesses und das Einfließen der Verbesserungen in die nächsten Iterationen garantiert ist.

    Commitment das englische Wort für Verpflichtung. Ein Commitment wird vom Entwicklungsteam abgegeben zum (selbstgewählten) Lieferumfang am Ende des Sprints. Im agilen Zusammenhang ist dies aber weit mehr als eine Willenserklärung zu Planungszwecken, sondern das Team erklärt damit den unbedingten Willen, das Ziel zu erreichen und zwar mit allen ihnen zur Verfügung stehenden Mitteln.

    Wichtig hierbei ist insbesondere der freiwillige Charakter. Somit wird die Erreichung der Ziele zur “Ehrensache”, da man sich die Ziele ja selbst gesteckt hat.

    Continuous Integration = ständige Integration. Ein Mittel aus dem eXtreme Programming (XP). Hierbei wird jeder abgeschlossene Entwicklungsschritt kurzfristig (alle paar Minuten) in das zentrale Source Code Repository eingecheckt, wo ständig (mindestens aber einmal täglich) der neue Code gebaut, integriert, auf ein Testsystem deployed und dort getestet wird. Hiermit wird zum Einen vermieden, dass Entwickler gegen eine möglicherweise veraltete Version einer anderen Klasse entwickeln, zum Anderen wird sichergestellt, dass noch alle Module fehlerfrei arbeiten, und das auch noch zusammen.
    Crystal Crystal ist eine Familie von Methodiken für agile Softwareentwicklung. Entwickelt von Alistair Cockburn besteht sie aus sieben verschiedenen Varianten, die sich in der Teamgröße und der Kritikalität unterscheiden.

    Crystal Clear ist der “kleinste” Vertreter, gedacht für Teams bis zu 8 Personen. Eine Beschreibung in einem Satz stammt von Alistair selbst:
    “Der Chefarchitekt und zwei bis sieben andere Entwickler,
    in einem großen oder mehreren angrenzenden Räumen,
    mit Informationsmedien wie Whiteboards und Flipcharts ausgestattet,
    mit einfachem Zugriff auf Experten,
    von Störungen abgeschirmt,
    entwickeln lauffähigen, getesteten, benutzbaren Code für den Benutzer
    jeden oder jeden zweiten Monat (schlimmstenfalls vierteljährlich),
    ständig ihre Arbeitsweise überprüfend und anpassend.”
    Crystal bezeichnet sich selbst als “nicht eifersüchtig”, was bedeutet, dass es sich selbst als undogmatisch empfindet und die Vermischung mit anderen Methoden und Techniken befürwortet. Crystal Clear beinhaltet keine allgemeingültigen Richtlinien für alle Entwickler (wie z.B. XP), sondern muss immer auf ein konkretes Projekt angepasst werden. Mehr zum Thema findet man hier.

    Cycle Time = In Kanban die Durchlaufzeit einer Aufgabenkarte durch den Prozess. Das Ziel von Kanban ist die Durchlaufzeit und damit die Time-To-Market zu minimieren und die Ergebnisse der Arbeit schnellst möglich sichtbar zu machen.


    D     nach oben
    Daily Scrum Ein tägliches, immer zur gleichen Zeit stattfindendes Teammeeting. Es dient zur taktischen Planung des Projekts, nämlich der Planung des aktuellen (bestenfalls des nächsten) Tages.

    Das Daily Scrum ist öffentlich, allerdings dürfen nur die Teammitglieder und der ScrumMaster etwas sagen (Chicken und Pigs). Das Meeting sollte maximal 15 Minuten dauern, im Stehen stattfinden und im Kern daraus bestehen, dass jedes Teammitglied drei Fragen beantwortet:

    • Was habe ich seit dem letzten Meeting an meinen Aufgaben geleistet?
    • Was habe ich mir bis zum nächsten Meeting vorgenommen?
    • Was hindert mich momentan daran, meine Aufgabe zu beenden?

    Es geht also im Wesentlichen darum, die anderen Teammitglieder von den aktuell bearbeiteten Aufgaben und Problemen zu unterrichten. Jeder weiß also über die Lage des Projektes jederzeit Bescheid. Diskussionen über einzelne Themen sollten nicht während des Meetings, sondern im Anschluss in einem ggf. kleineren Kreis besprochen werden.

    Definition of Done Aufgaben (z.B. in Form von User Stories) werden nur dann im Review gezeigt und am Ende des Sprints als fertig gewertet, wenn sie der eigenen Definition von Done entsprechen. Halbfertiges wird nicht betrachtet, sondern in die nächste Iteration verschoben. Die Definition of Done muss von jedem Team selbst erstellt werden, sie kann durchaus je Team unterschiedlich sein.
    Delphi Schätzmethode Die Delphi-Methode stammt aus den 60er Jahren des letzten Jahrhunderts. Es geht dabei um getrennte Expertenbefragungen mit Rückkopplungsrunden. Eine Frage wird mehreren Experten unabhängig voneinander gestellt und sie müssen darauf antworten. Diese Antworten werden dann ausgewertet und teilweise allen Experten wieder zur Verfügung gestellt (z.B. nur besonders kontroverse Aspekte). Die Experten können dann anhand dieser für sie neuen Argument ihre eigene Einschätzung überprüfen und korrigieren. Dieses Verfahren kann über mehrere Runden angewendet werden, bis ein Konsens erreicht wurde.

    Vorteil dieser Methode ist, dass Meinungsführerschaft eliminiert wird (da getrennte Befragung), trotzdem aber Rückkopplung zwischen den Experten stattfindet. Die agile Variante dieser Methode ist das Planning Poker.

    Done Features in Scrum dürfen nur dann im Sprint Review gezeigt werden und in das Iterationsergebnis eingehen, wenn sie Done sind. Was das genau bedeutet, ist von Team zu Team unterschiedlich, da das Team selbst für das Ergebnis verantwortlich ist. Üblicherweise gehört jedoch dazu: Der Code
    • ist eingecheckt
    • ist “sauber”
    • ist (Unit-)getestet
    • läuft fehlerfei durch den Build
    • ist dokumentiert (inline, Wiki)
    • ist getestet (Akzeptanztests, Performancetests,…)

    Diese Punkte werden nicht explizit vom Product Owner überprüft. Das Team sollte genügend Eigenanspruch an die Qualität haben, dass es die Einhaltung selbst überprüft. Ist dies nicht der Fall, bleiben ja Restarbeiten für den nächsten Sprint, was dann dort wieder die Velocity senkt und mittelfristig das Projekt gefährdet.

    DSDM Atern DSDM Atern ist ein weiterer Vertreter der agilen Methoden. Am besten informieren kann man sich eigentlich hier auf der Webseite unter Atern.


    E     nach oben
    Epic Epics sind Riesenstories, die eigentlich nur als Platzhalter für große, später zu realisierende Features stehen.

    In einem Product Backlog stehen die User Stories in unterschiedlicher Granularität, je nachdem, wann die Umsetzung des Features geplant ist:
    • Die Features des aktuellen Sprints sind fertig geschätzte und ausformulierte User Stories, an denen das Team gerade arbeitet. Diese sind unantastbar.
    • Die Features für die nächsten 2–3 Sprints sind gerade in Verfeinerung durch den Product Owner. Sie sind wahrscheinlich noch nicht geschätzt und müssen möglicherweise noch in kleinere Stories zerhackt werden. Auch sind vielleicht noch nicht alle Details dazu bekannt.
    • Für die Features, die noch einige Sprints von ihrer Realisierung entfernt sind, gilt: Es ist noch nicht allzu viel darüber bekannt, außer, dass es sie geben wird. Beispiele hierfür sind Benutzverwaltung, Rechnungsdruck oder Sollstellung. Gemäß der agilen Denkweise, dass sich die genauen Umstände ohnehin noch ändern werden, wäre es Verschwendung, sich jetzt schon im Detail mit diesen Features zu befassen.
    Extreme Programming , auch verkürzt XP genannt, ist eine agile Software-Entwicklungsmethode, die im Wesentlichen von Kent Beck entwickelt wurde. Sie basiert auf Werten, Prinzipien und Praktiken. Die enthaltenen Werte sind: Kommunikation, Einfachheit, Feedback, Mut und Respekt. Beispiele der verwendeten Praktiken (insgesamt 14) sind: Pair Programming, Continuous Integration, Testgetriebene Entwicklung, Refaktorisierungen usw.

    XP stellt keine Konkurrenz zu Scrum dar, sondern eine hervorragende Ergänzung, da Scrum sich mehr um den Managementansatz der Entwicklung kümmert und nicht so sehr um die technischen Aspekte, die wiederum bei XP im Vordergrund stehen.


    F     nach oben
    Flow Zum Begriff Flow gibt es zwei Bedeutungen:


    1. Flow ist ein Zustand, in den ein Team geraten kann, wenn es durch eine Mischung von Perfektion, Kreativität, Leidenschaft, Können und Willen in eine Arbeitsweise verfällt, die Glückseligkeit enthält, aber auch außerordentliche Leistungen erbringt.

      Man spricht auch von einem hyperproduktiven Zustand, in dem die Teamleistung um ein Vielfaches mehr ist als die Summe der Einzelleistungen der Teammitglieder.

      Dieser Zustand ist selbst von einem optimalen Scrumteam erst nach etlichen Sprints erreichbar und leider nicht erzwingbar. Er entwickelt sich von selbst - oder auch nicht. Voraussetzung ist aber auf jeden Fall ein motiviertes, selbstorganisiertes und kreatives Team.
    2. Die zweite Bedeutung des Begriffs Flow bezieht sich auf den Rhythmus, den ein Scrum-Projekt im Laufe eines Sprints durchläuft. Das geht von der Vision über die verschiedenen Meetings des Sprint Planning über die täglichen Daily Scrums bis hin zum Review und zu Retrospektive. Nachfolgend ein Bild, das diesen Flow verdeulicht.


    G     nach oben
    Gantt Chart Ein Gantt-Chart ist ein Planungsinstrument aus dem klassischen Projektmanagement. Der größte Nachteil aus agiler Sicht ist, dass es eine Planbarkeit und Planungssicherheit suggeriert, die in der Realität meistens nicht gegeben ist. Während agile Methoden Änderungen erwarten, muss im klassischen PM ein schwerfälliges Change Management eingesetzt werden, um den Plan ständig der Realität anzupassen.

    Agiles Planen funktioniert mit Planning Poker und Release-Plan.

    Geschäftswert Geschäftswert ist nur das deutsche Wort für Business Value, das auch dort erklärt wird.
    Größe Features, am besten in Form von User Stories, werden im agilen Umfeld immer nach Größe geschätzt und nie nach Aufwand. Der Grund dafür ist, dass eine Aufgabe zwar immer gleich groß ist, die Dauer für die Abarbeitung aber hochgradig abhängig ist von der Anzahl der Personen, die daran arbeiten, von den individuellen Fähigkeiten dieser Personen und den Werkzeugen, die sie dafür verwenden.

    Die Maßeinheit ist abstrakt und nennt sich Story Points. Anhand der Anzahl der Story Points, die ein Team pro Sprint abarbeitet, kann die Velocity des Teams berechnet werden.


    H     nach oben


    I     nach oben
    Impediment Ein Impediment ist ein Hindernis, das das Team daran hindert, seine Arbeit optimal zu verrichten. Die Eliminierung dieser Hindernisse ist die Hauptaufgabe des ScrumMasters.

    Beispiele sind fehlende Whiteboards, schlechte Anforderungen, Nichterreichbarkeit des Product Owners usw.

    Impediment Backlog Das Impediment Backlog ist eine öffentlich im Teamraum aushängende Liste, auf der, natürlich nach Dringlichkeit priorisiert, die Impediments hängen. Sie stellt sozusagen die Aufgabenliste für den ScrumMaster dar und wird tagesaktuell gehalten.
    Inspect and adapt Eine der mächtigsten agilen Techniken überhaupt. Zurückgehend auf den Deming-Zyklus (Plan-Do-Check-Act) wird die eigene Arbeit in regelmäßigen Abständen überprüft und in der nächsten Iteration angepasst. Inspect and Adapt findet auf mehreren Ebenen statt: auf Tagesbasis durch Pair Programming und Daily Scrum, nach außen zum Kunden im Sprint Review und nach innen in der Retrospektive.


    J     nach oben


    K     nach oben
    Kaizen Wird in Deutschland auch gerne Kontinuerlicher Verbesserungsprozess oder KVP genannt.

    Gemeint ist damit eine Unternehmenskultur, die darauf ausgerichtet ist, durch ständige kleine Verbesserungen das Produkt nahezu perfekt zu machen und damit maximale Kundenzufriedenheit zu erzielen, die sich hoffentlich dann auch im Umsatz und Gewinn des Unternehmens bemerkbar macht.

    Dazu zählen u.a. ein betriebliches Vorschlagswesen für die Mitarbeiter, ständige Weiterbildungen und ein sinnvolles Qualitätsmanagement.

    Kanban Kanban ist eine weitere agile Vorgehensweise, die sich allerdings ein wenig von Scrum unterscheidet.

    Alle Aktivitäten innerhalb eines Workflows werden als Spalten in einem sog. Kanban-Board eingetragen. Die einzelnen Aufgaben wandern dann als Tickets von links nach rechts durch das Board, bis sie abgearbeitet sind.

    Hierbei wird für jede Aktivität (z.B. Anforderungsaufnahme, Entwicklung, Test, Inbetriebnahme) eine Obergrenze festgelegt für die Anzahl, die sich gleichzeitig in diesem Stadium befinden darf, das sog. WiP-Limit (WiP = Work in Progress).

    Hierdurch wird das Pull-Prinzip implementiert, das besagt, dass sich z.B. Entwickler dann eine neue Aufgabe nehmen, wenn sie dazu bereit sind und nicht, wenn die Anforderungen dafür fertig sind. Schwachstellen im Prozess können so entdeckt und behoben werden.

    Im Unterschied zu Scrum gibt es keine festen Iterationen, es kann ausgeliefert werden, wann immer es sinnvoll ist. Oft findet man beide Varianten parallel im Projekt: Scrum für die reine Entwicklung (wg. der besseren mittel- und langfristigen Planbarkeit) und Kanban für die Fehlerbehebung und Wartung (wg. der besseren Statuskontrolle und schnellen Liefermöglichkeit).

    Kunde Der Kunde ist derjenige, der bestimmt, was das Endprodukt leisten soll. In der agilen Welt ist der Kunde nicht ein reiner Auftraggeber, der einmalig ein Lastenheft erstellt, den Auftrag erteilt und am Ende die Abnahme vornimmt, sondern ein aktiver Teil des Entwicklungsprozesses.

    Im Sprint Review muss der Kunde regelmäßig die bis dahin geleistete Arbeit begutachten und kommentieren, aber auch zwischendurch muss er damit rechnen, dass das Team Fragen geklärt haben möchte. Dies führt auf der einen Seite zu einer besseren Akzeptanz des Produkts, auf der anderen Seite auch zu höherer Qualität.

    Der Product Owner ist der Kundenvertreter während der Entwicklung, falls dieser nicht ständig anwesend sein kann. Er hält engen Kontakt zum Kunden und trifft für ihn die täglich anfallenden Entscheidungen.


    L     nach oben
    Lean Lean ist ein Management-Ansatz, der sich auf die wertschöpfenden Schritte einer Fertigung konzentriert. Alles, was nicht direkt zur Wertschöpfung beiträgt, wird als Verschwendung (Waste) bezeichnet und konsequent eliminiert. Lean wurde durch das Toyota Production System bekannt.
    Lean Software Development Im Buch Lean Development beschreiben Mary und Tom Poppendieck sieben schlanke Prinzipien für erfolgreiche Softwareentwicklung und leiten daraus 22 Werkzeuge ab, die Lean Development ausmachen.

    Die Schlüsselfaktoren sind

    • Vermeide Verschwendung. Verschwendung ist z.B. teilweise getane Arbeit, die nicht benötigt wird, Wartezeiten, Wechsel zwischen Aufgaben, Fehler, zusätzliche Features, zusätzliche Prozesse usw. Die volle Konzentration soll der eigentlichen Aufgabe gelten.
    • Lernen verstärken. Nutze jede Möglichkeit zum Feedback, um aus dem Feedback lernen zu können.
    • Entscheide so spät wie möglich
    • Möglichst schnell ausliefern. Nur ein Stück Software, welches der Kunde sehen und nutzen kann, ist dazu geeignet zu prüfen, ob das eigentliche Ziel erreicht werden kann. Außerdem kann durch die schnellstmöglich Auslieferung an den Kunden ein schnellerer ROI erreicht werden.
    • Verantwortung an das Team geben
    • Integrität einbauen
    • Das Ganze sehen


    M     nach oben
    Management Das Management scheint in der agilen Welt nur noch eine untergeordnete Rolle zu spielen, da die Teams ja selbstorganisiert sind. Dies ist ein Trugschluss. Zunächst kann das Management den Weg zu einem agilen Unternehmen massiv behindern, so dass man gut daran tut, das Management in alle Prozesse mit einzubeziehen. Außerdem bleiben selbstverständlich genügend Aufgaben für das Management übrig: Entwicklung und Überwachung der Firmenstrategie, Personalführung, Organisation der gesamten Firma inklusive der Entwicklung und nicht zuletzt müssen sie die Gelder verwalten und genehmigen, die das Entwicklungsteam dazu bewegen, die perfekte Software zu bauen.
    Mindmap Eine Mindmap ist ein kreatives und agiles Verfahren, brainstorming-artig Ideen zu einem Thema zu organisieren. Hierzu werden ausgehend vom speziellen Thema zunächst Hauptknoten mit den wichtigsten Oberbegriffen gebildet und anschließend werden in Unterknoten diese Begriffe beliebig weiter verfeinert.

    Man kann Mindmaps wahlweise händisch (siehe Bild) oder mit speziellen Programmen erstellen, z.B. mit dem Open Source Tool XMind.

    Minimal Marketable Feature ein Begriff aus dem Buch “Software by Numbers”, der sehr griffig die kleinste “verkaufbare” Einheit bei der Entwicklung eines Systems beschreibt.
    MoSCoW-Priorisierung MoSCoW-Priorisierung ist ein Verfahren, Features während der Entwicklung zu priorisieren. Die einzelnen Buchstaben stehen dafür für die verschiedenen Prioritäten:
    • Must have: Unverzichtbares Feature, ohne das die Software nicht benutzbar wäre
    • Should have: Sollte eigentlich in dieser Iteration enthalten sein, es gibt aber einen kurzfristigen Workaround, so dass die Funktionalität nicht vollständig wegfällt
    • Could have: Features, die man gerne dabei hätte. Sollte man es allerdings nicht schaffen, sind dies Kandidaten für Features, die weggelassen werden können
    • Won’t have: Features, die in dieser Iteration ganz sicher nicht umgesetzt werden

    Insbesondere in DSDM Atern, wo Zeit und Kosten fix sind und der Lieferumfang über die Features geregelt wird, findet dies Prinzip Einsatz, aber auch in Scrum ist dies Verfahren ein Mittel, die Releaseplanung sinnvoll zu gestalten.


    N     nach oben


    O     nach oben


    P     nach oben
    Pair Programming Eine Technik, die aus dem Extreme Programming stammt. Zwei Entwickler sitzen nebeneinander an einem Arbeitsplatz und implementieren ein Feature gemeinsam. Der Entwickler an der Tastatur erklärt dabei laufend, was er tut und warum er es tut und der andere hinterfragt ständig, was getan wird. Nach einer Weile wechseln dann die Rollen.

    Positive Nebeneffekte: Der Code ist bereits während der Erstellung gereviewed, es wird nur entwickelt, was tatsächlich sinnvoll und notwendig ist und es gibt sofort 2 Personen, die den Code kennen.

    Die Tatsache, dass zwei Personen an einem Feature arbeiten, scheint die Kosten zu verdoppeln. Das Gegenteil ist allerdings der Fall: die Entwicklungskosten werden sich mittelfristig verringern, da nur das entwickelt wird, was wirklich notwendig ist (Vermeidung von Verschwendung) und man schon im ersten Durchlauf sauberen Code produziert (durch das ständige Review) und sich damit teure Nacharbeiten spart.

    Planungs- Poker Planungs-Poker ist agiles Schätzverfahren, bei dem das Entwicklungsteam die zu entwickelnden Features selbst schätzt. Besonderen Wert wird dabei darauf gelegt, dass die Größe eines Features geschätzt wird und nicht der Aufwand.
    Planung Agile Methoden sind entgegen ihrem Ruf sehr selten chaotisch (und wenn, dann sind sie falsch implementiert ;-)). Selbstverständlich wird kaum ein Kunde ein Projekt genehmigen, ohne wissen zu wollen, wann es fertig sein wird und die Marketing-Abteilungen sind natürlich sehr interessiert an einer Releaseplanung, um einzelne Features rechtzeitig bewerben zu können.

    Agile Methoden gehen allerdings davon aus, dass sich bei komplexen Projekten die Faktenlage ohnehin während des Projektes ändern wird, so dass es reine Verschwendung wäre, das gesamte Projekt komplett durchzuplanen. Vielmehr wird die Planung umso grobgranularer, je weiter weg der beplante Zeitpunkt noch ist. Mann muss also unterscheiden zwischen strategischer und taktischer Planung.

    Planung, strategisch Zur strategischen Planung in Scrum zählen die Vision (Wohin will ich mit meinem Produkt?), natürlich das Product Backlog (Was benötige ich alles, um die Vision zu erfüllen?), und die Releaseplanung (Wann bekomme ich die einzelnen Features von meinem Team geliefert?).

    Die Kosten werden nicht explizit beplant, sie ergeben sich aus der Größe der Features, der Velocity des Teams und natürlich den Kosten der einzelnen Entwickler und Infrastruktur.

    Die Strategische Planung ist also recht grobgranular, die Einzelheiten werden erst in der taktischen Planung festgelegt.

    Planung, taktisch Bei der taktischen Planung werden die Dinge gelant, die im kommenden bzw. laufenden Sprint zur Realisierung anstehen. Im Sprint Planning wird festgelegt, welche Stories (Features) im gerade begonnenen Sprint umgesetzt werden sollen.

    Auf Tagesebene gibt es noch zusätzlich das Daily Scrum, das sozusagen das tägliche Planungsmeeting darstellt. Hier wird besprochen, was an diesem Tag bis zum nächsten Daily Scrum anliegt.

    Die taktische Planung ist schon sehr detailliert und an dieser Stelle auch keine Verschwendung, weil wir sicher sind, dass das, was hier geplant wird, auch tatsächlich umgesetzt wird. Und dass die einzelnen Aufgaben geplant werden müssen, ist doch auch mit Scrum selbstverständlich, oder?

    Priorisierung In Scrum versuchen wir, das Wichtigste zuerst umzusetzen. Zum Einen, um schnell erkennen zu können, ob das Produkt hält, was wir uns davon versprechen, zum Anderen gibt es den charmanten Nebeneffekt, dass im Falle einer Geldknappheit oder Dienstleisterinsolvenz der Löwenanteil schon geleistet und deshalb der wirtschaftliche Schaden gering ist. So ist es beispielsweise eine der Hauptaufgaben des Product Owners, den ROI zu maximieren. Wenn die Kosten für die Umsetzung eines Features den Business Value übersteigen, sollte es nicht umgesetzt werden. Das gilt natürlich auch auf Projektebene. Ist der “Wert” des Rests der noch geplanten Features geringer als die für die Realisierung notwendigen Kosten, sollte das Projekt beendet werden. Dies funktioniert natürlich nur, wenn die Features im Product Backlog nach Business Value priorisiert sind. Wobei Priorisierung in diesem Fall nicht ein dreistufiger Wert hoch-mittel-niedrig ist, sondern eine Reihenfolge in der Liste. Steht ein Feature weiter oben in der Liste, ist es höher priorisiert und muss eher umgesetzt werden. So gesehen ist die Priorisierung ein mächtiges Planungsinstrument, das über die Reihenfolge der Umsetzung entscheidet und damit auch über den Lieferzeitpunkt der einzelnen Features.
    Product Backlog Das Product Backlog ist die Liste aller Features, die im laufenden Projekt umgesetzt werden sollen. Die einzelnen Features sind priorisiert und als User Story formuliert.

    Um Verschwendung zu vermeiden, sind die Stories in unterschiedlicher Granularität formuliert. Näheres findet sich unter dem Stichwort Epic.

    Product Owner Der Product Owner ist derjenige, der für den wirtschaftlichen Erfolg des Projektes zuständig ist. Seine Aufgaben umfassen:
    • Aufnahme der fachlichen Anforderungen vom Kunden
    • Erstellung von User Stories aus diesen Anforderungen
    • Priorisieren der einzelnen Anforderungen nach Business Value
    • Pflege dieser Anforderungen im Product Backlog
    • Erstellung eines Releaseplans
    • Teilnahme an Schätzklausuren des Teams (Planungs-Poker)
    • Teilnahme am Sprint Planning
    • Beantworten aller Fragen des Teams während der Entwicklung
    • Abnahme der Features beim Sprint Review
    • …

    mit anderen Worten: er ist dafür zuständig, dem Team zu erklären, WAS im Projekt umgesetzt werden soll und das Team in die Lage zu versetzen zu entscheiden, WIE das Ganze umgesetzt werden soll.

    Pull Prinzip Kreativität und Freude an der Arbeit entsteht meist bei solchen Teams, die nicht fremdgesteuert sind. Wer ständig gesagt bekommt, was er zu tun hat, hört auf, selbstständig zu denken (Micromanagement). Deshalb hat sich das Pull-Prinzip als gut herausgestellt. To pull bedeutet ziehen und das bedeutet in diesem Zusammenhang, dass das Team nicht gesagt bekommt, was es bis wann abzuliefern hat, sondern dass das Team selbst bestimmt, wieviel es im nächsten Sprint abliefern wird. Weiterhin nimmt sich (auf Tagesebene betrachtet) jeder Entwickler beim Daily Scrum seinen nächsten Task selbst statt einer Zuweisung durch einen Projektleiter. So kann jeder seinen Arbeitsdurchsatz selbst steuern, der äußere Druck wird nicht höher, als man selbst will und das Ergebnis wird insgesamt besser.


    Q     nach oben


    R     nach oben
    Refactoring Refactoring, auf deutsch auch Refaktorisierung genannt, ist eine Technik, die ursprünglich aus dem Extreme Programming stammt. Hierbei geht es darum, eine “Pflege” des Codes zu betreiben. Auskommentierte Stellen werden tatsächlich auch aus dem Code entfernt (setzt ein Repository voraus!), die Algorithmen werden auf Lesbarkeit und Eleganz geprüft, bis hin zum Check, ob Methoden- und Variablennamen gut benannt sind. Insgesamt gilt: nur 20% der Zeit, die man mit einer Codezeile verbringt, wird bei der Ersterstellung verbraucht. Die restlichen 80% sind spätere Änderungen oder Erweiterungen. Diese werden sicher nicht in allen Fällen vom “Ersttäter” vorgenommen. Deshalb ist es enorm wichtig, die “Wartbarkeit” und Änderungsmöglichkeit des Codes zu erhalten.
    Referenz Story Die Referenzstory ist die “Erdung” des Planning Poker. Bei dieser agilen Schätzmethode werden die einzelnen Stories des Product Backlog ja relativ zueinander geschätzt. Die Bezugsgröße hierbei stellt die Referenzstory dar. Es sollte eine kleine, technisch gut bekannte Story sein, ein Durchstich durch alle Applikationsschichten ist ebenfalls hilfreich. Beim Pokern werden dann alle Stories im Verhältnis zu dieser Referenz geschätzt.

    Mehr zum Thema unter http://www.holisticon.de/PlanningPoker.

    Release-Plan Kein Kunde, weder extern noch intern, wird ernsthaft ein Projekt genehmigen und viel Geld ausgeben, ohne eine Aussage darüber zu bekommen, wann er welches Feature bekommt. Aus diesem Grund gibt es natürlich auch bei Scrum einen Releaseplan, der über die Planung eines einzelnen Sprint hinausgeht.

    Wir wissen, dass die Velocity eines Teams über die Zeit konstant ist. Mit anderen Worten ist die Anzahl der Story Points, die ein Team je Sprint abarbeiten kann, in jedem Sprint ungefähr gleich. Wenn wir weiterhin davon ausgehen, dass das Product Backlog vom Team durchgeschätzt ist, kann man recht einfach bestimmen, welche Features in welchem Sprint realisiert sein werden. Gemeinsam mit dem Kunden kann man dann daraus mögliche Releases schneiden.

    Retrospektive Inspect and Adapt ist eine der wichtigsten Techniken in allen agilen Verfahren. Das Feedback von außen, also vom Kunden und möglicherweise vom Management, holt man sich im Review, das Feedback von innen, also vom Team für das Team passiert in der Retrospektive.

    Voraussetzung hierfür ist eine geschützte, vertrauensvolle Umgebung. Man sollte sich also am besten in einen entlegenen Besprechungsraum zurückziehen, wo man nicht gestört wird. In dieser Athmosphäre ist es dann besser möglich, auch über unangenehme Dinge zu sprechen. Hier darf kein Finger-Pointing in Richtung einzelner Personen stattfinden, sondern man sollte vorwärtsgerichtet konstruktiv versuchen, Missstände zu beseitigen, und zwar gemeinsam als Team. Hierzu fragt man sich zur Einstimmung zunächst, was im letzten Sprint passiert ist, nur Fakten, ohne Wertung. Wichtig ist, dass jeder sich eigenständig Gedanken macht, damit alle Meinungen des Teams einfließen. Man gibt also fünf Minuten Zeit, seine eigenen Ideen auf Post-Its zu schreiben, die dann anschließend (ohne Kommentare anderer) mit einer kurzen Erklärung auf einen Zeitstrahl des Sprints geklebt werden. Danach wird die Frage gestellt: “Was lief gut im letzten Sprint?”. Wieder fünf Minuten Zeit und dann eine kurze Erklärung. Dieses Flipchart kann man übrigens gut im Teamraum hängen lassen, zur Aufbesserung der Stimmung in “schlechten Zeiten”. Die letzte Frage ist dann “Was kann verbessert werden?”. Dies ist natürlich die wichtigste Frage, weil hier das Verbesserungspotenzial steckt. Die gefundenen Schwachpunkte werden dann anschließend noch aufgeteilt in die Bereiche, die das Team selbst beeinflussen kann und die, die von der Organisation gelöst werden müssen. Der erste Teil wandert mit ins nächste Sprint Planning Meeting, da der Product Owner ja Geld (wg. der Zeit, in der das Team keine Features implementieren kann) dafür zur Verfügung stellen muss. Der zweite Teil geht in das sogenannte Impediment Backlog, die Arbeitsliste des Scrum Master.

    Review Im Sprint Review zeigt das Team, was es im vergangenen Sprint erreicht hat. Wichtig ist, dass eine Vorführung in einer produktionsnahen Umgebung stattfindet und nicht auf einem Entwicklungsrechner. Es soll ja potenziell auslieferbar sein, also je nach der Definition of Done des Teams eingecheckt, getestet und integriert. Alle Features des Sprints werden vorgestellt und diskutiert. Dieser Diskussionsprozess ist extrem wichtig, da hier das externe Feedback zu der Lieferung des Teams kommt. Ist es positiv, gibt das einen weiteren Motivationsschub. Der Kunde hat möglicherweise sofort neue Ideen, wie man das Produkt noch weiter verbessern kann. Ist das Feedback negativ, ist der Effekt noch stärker: man läuft einfach nicht so lange in die falsche Richtung, sondern erkennt Fehler frühzeitig, was letztendlich massive Geldverschwendung vermeidet. Nicht zuletzt führt der Product Owner bzw. der Kunde eine Abnahme der Sprintergebnisse durch. Das ist zwar noch keine Endabnahme, aber die bereits fertigen Teile sind zunächst mal aus dem Fokus und man kann sich voll auf die nächsten Features konzentrieren.
    ROI Der Return on Investment (ROI) wird errechnet aus dem Quotienten aus Gewinn zu Kapitaleinsatz. Der Product Owner ist innerhalb eines Scrum Projektes verantwortlich für die Maximierung des ROI des Projektes. Dies hat im Wesentlichen zwei Auswirkungen: Das Product Backlog ist sortiert nach dem Business Value, damit das Team die wertvollsten Features zuerst implementiert. Da der Kapitaleinsatz mit Projektdauer wächst, sinkt der ROI für ein einzelnes Feature, je später es umgesetzt wird. Auf der anderen Seite hat der Product Owner auf diese Art und Weise die Möglichkeit, ein Projekt abzubrechen, sobald der Kapitaleinsatz für einen weiteren Sprint die Gewinnerwartung übersteigt. Diese Möglichkeit hat man im klassischen Projektmanagement nicht, da ein Großteil der Features erst am Ende der Projektlaufzeit vollständig integriert und damit benutzbar sind.
    Rollen

    Es gibt drei Kernrollen in einem Scrum Team, den ScrumMaster, den Product Owner und das Teammitglied. In aller Kürze kann man folgende Definitionen abgeben: Der Product Owner ist zuständig für das “Was”. Er sorgt für die Anforderungen, priorisiert sie und steht dem Team für alle Nachfragen zur Verfügung. Das Teammitglied ist gemeinsam mit den anderen Teammitgliedern zuständig für das “Wie”. Die fachlichen Vorgaben des Product Owners müssen in (technische) Tasks heruntergebrochen und implementiert werden. In Selbstorganisation und mit viel Kreativität tut das Teammitglied alles dafür, dass die zugesagten Ziele des Sprints erreicht werden. Der ScrumMaster schließlich sorgt für die Einhaltung des Scrum-Prozesses und beseitigt alle Hindernisse (Impediments), die das Team daran hindern, ihre Aufgaben optimal zu erfüllen. Nähere Erklärungen finden sich unter den jeweiligen Rolleneinträgen.

    RUP Der Rational Unified Process ist eine weitere Softwareentwicklungsmethode, die den Anspruch erhebt, agil zu sein. Man muss wohl ehrlicherweise sagen: agil sein zu können. Ein ausgeprägtes Phasenkonzept und definierte Meilensteine kommen nicht grade agil daher. Die einzelnen Phasen sind allerdings wiederum in Iterationen eingeteilt, so dass RUP durchaus als iterativ-inkrementell angesehen werden kann. Wenn man, wie in jedem Modell möglich, die weniger agilen Teile weglässt (customized), kann durchaus ein agiles Vorgehen daraus erwachsen. In der (nicht-IBM-)Literatur wird RUP allerdings nach wie vor als eher unagil bewertet.


    S     nach oben
    Schätzen Anforderungen zu einem Software-Projekt müssen in jedem Fall geschätzt werden. Bei klassischen Verfahren wird dies vom Projektleiter, vielleicht (hoffentlich!) gemeinsam mit dem Chefentwickler vorgenommen. Bei Verwendung von agilen Verfahren schätzen diejenigen, die später auch das Produkt entwicklen sollen, nämlich die Entwickler. So wissen wir mit einer größeren Sicherheit, wie lange es vermutlich dauern wird. Außerdem kann hinterher kein Entwickler sagen: “Das ist ja ohnehin völlig unrealistisch, da muss ich mich ja gar nicht anstrengen.” Näheres zu einem möglichen Verfahren siehe unter Planning Poker.
    Schneiden von User Stories User Stories sind eine mögliche Form der Notation für Anforderungen in einem agilen Projekt. Epics sind zu groß für die Implementierung, sie müssen zunächst in kleine User Stories geschnitten werden. Dabei ist es üblicherweise keine gute Idee, eine Story nach Komponenten zu zerteilen, also Frontend, Mittelschicht und Datenbank. Sinnvoller ist es, sie in funktionale Teile zu zerlegen. Wenn ich also eine Stammdatenverwaltung entwickeln soll, kann man die Anzeige von bereits gespeicherten Datensätzen durchaus von der Neuanlage oder der Änderung trennen.

    Als Faustregel sollte gelten: Die Story muss klein genug sein, um in einen Sprint zu passen und muss noch gut schätzbar sein. Mehr als 20 Story Points sind ein sicherer Kandidat für eine notwendige Teilung. Außerdem muss die Story groß genug sein, um einen funktionalen Mehrwert zu bieten und schätzbar sein.

    Schwaber, Ken Ken Schwaber ist einer der “Erfinder” von Scrum und Autor diverser Bücher zum Thema. Gemeinsam mit Jeff Sutherland entwickelte er das Konzept von Scrum. Sein charismatisches Auftreten als Rampensau hat sicher zur erfolgreichen Verbreitung von Scrum beigetragen. Inzwischen sieht er bei der Scrum Alliance zuwenig Agilität und hat seine eigene Sicht von Scrum veröffentlicht (siehe hier).
    Scrum Scrum ist die weltweit verbreitetste agile Methode. Scrum basiert auf der Erkenntnis, dass komplexe Projekte ab einer gewissen Größenordnung nicht mehr vorab vollständig planbar sind und es deshalb Verschwendung wäre, es trotzdem zu tun. Kurze Feedbackzyklen, intern (Retrospektive) sowie extern (Review) sorgen für gleichbleibend hohe Qualität und ein selbstorganisiertes Team entscheidet kreativ über die technische Umsetzung der fachlichen Vorgaben aus dem Product Backlog und zwar nur die mit Planning Poker selbst geschätzten Aufgaben, die nach dem Pull Prinzip ausgewählt wurden. Am Ende jedes Sprints steht dabei ein Produktinkrement, das so fertig ist, dass es theoretisch auslieferbar wäre und an dem sich wunderbar mit dem Kunden diskutieren lässt.
    Scrum of Scrums In skalierten Umgebungen, d.h. in Projekten mit mehr als einem Team, sind einige zusätzliche Kommunikationsmaßnahmen notwendig, um Scrum durchzuführen.

    Die klassischen Meetings sind solche innerhalb des Teams und solche mit dem Product Owner. Gemäß den Grundlagen der Transparenz müssen sich allerdings auch Teams untereinander synchronisieren, insbesondere dann, wenn funktionale Abhängigkeiten zwischen den Liefergegenständen der Teams bestehen. Also treffen sich regelmäßig (bei vierwöchigen Sprints z.B. einmal pro Woche) Vertreter der Teams zu einem Scrum of Scrums, das eigentlich genauso abläuft wie ein Daily Scrum innerhalb eines Teams. Wichtig ist dabei, dass hier besonderer Wert auf die Schnittstellen zwischen den Teams geachtet wird. Es sollte niemals der ScrumMaster der eine Vertreter des Teams sein und es hat sich auch als hilfreich herausgestellt, dass nicht immer das gleiche Teammitglied als Abgesandter fungiert. Ansonsten schleift sich eine Routine ein, die nicht mehr förderlich für das Ergebnis ist. Eine gute Idee ist oft, den Realisierer der wichtigsten Tasks der Woche zu dem Meeting zu schicken, da dieser auch am besten Auskunft erteilen kann.

    ScrumMaster Der ScrumMaster ist eine der drei Kernrollen in Scrum. Er ist KEIN Projektleiter im klassischen Sinne, sondern wacht darüber, dass die Regeln von Scrum eingehalten werden. Obwohl das Team selbstorganisiert ist, kann dazu auch gehören, dem Team entsprechende Fragen zu stellen, um es dazu zu drängen, Alternativen zu erwägen oder Prioritäten sinnvoll zu setzen. Die eigentlich Aufgabenliste des ScrumMaster ist das Impediment Backlog, auf dem die Dinge verzeichnet sind, die das Team davon abhalten, optimal zu arbeiten. ScrumMaster ist ein Fulltimejob, es ist meist keine gute Idee, ihn auch als Entwickler im Team einzusetzen, da die Zielkonflikte dazu führen könnten, dass beide Teilaufgaben nicht ordentlich erfüllt werden. Als ScrumMaster darf man kein ängstlicher Mensch sein, da man sich des Öfteren mit dem Management streiten muss und dies unter Umständen zur eigenen Entlassung führen kann. Es kann außerdem eine recht frustrierende Aufgabe sein, da man (als externer SM) von Anfang versucht, sich selbst überflüssig zu machen und immer genau dann gehen muss, wenn es gerade anfängt, perfekt zu laufen und man in eine Wohlfühlphase geraten könnte.
    Selbstorganisation Teams werden motivierter und kreativer und produzieren somit bessere Software in kürzerer Zeit, wenn sie selbstorganisiert arbeiten. Das Gegenteil davon ist das leider allzu übliche Mikromanagement, bei dem jedes Teammitglied gesagt bekommt, wann es was wie zu erledigen hat. Frust und schlechte Arbeitsleistung sind oft die Folge. Bei Scrum gibt es Selbstorganisation auf verschiedenen Ebenen: Bereits beim Schätzen ist das Team dabei (siehe Planning Poker), die Auswahl der im kommenden Sprint zu erledigenden Stories werden vom Team selbst ausgewählt als Selected Product Backlog, die Tasks zur Erfüllung der Stories werden selbstständig erdacht und schließlich die Reihenfolge und die personelle Bestückung der einzelnen Tasks ist ebenfalls komplett selbstbestimmt. All das sind Ingredenzien für erfolgreiche, weil motivierte Softwareentwicklung.
    Selected Product Backlog Im Sprint Planning 1 wählt das Team die Stories aus, die im kommenden Sprint zu erledigen sind. Wichtig hierbei: die Stories werden aus einem priorisierten Backlog entnommen und zwar von oben. So ist sichergestellt, dass die wichtigsten Funktionalitäten als Erstes abgearbeitet werden. Dieses Selected Product Backlog ist ein sehr flüchtiges Artefakt in Scrum, wird es doch im Sprint Planning 2 vom Team in einzelne Tasks zerhackt, die dann das Sprint Backlog bilden.
    Sprint Ein Sprint ist das Wort in Scrum für eine Iteration. Das ist ein (über die Zeit konstanter) Zeitraum, innerhalb dessen das Team Funktionalität erstellt, am Ende fertig hat (siehe Definition of Done) und dann dem Kunden zum Review vorführen kann, um daran zu diskutieren, wie die Entwicklung in den nächsten Sprints weitergehen kann. Da die Velocity eines Teams konstant ist, kann über diese Velocity und die Anzahl der Sprints ein Releaseplan erstellt werden.
    Sprint Backlog Als Sprint Backlog bezeichnet man die einzelnen Tasks, die zur Erfüllung der Stories aus dem Selected Product Backlog identifiziert wurden. Zu jedem Task wird außerdem der Status am Taskboard festgehalten, meist in den Ausprägungen To do, In Progress und Done. Den Abarbeitungsgrad des Sprint Backlog kann man recht gut im Burndown Chart visualisieren und hat damit auf einen Blick einen optimalen Blick auf den Status des Teams innerhalb des Sprints.
    Sprint Goal Das Sprint Goal ist das Ziel für diesen Sprint. Aus den ausgewählten Stories lässt sich meist recht gut ein Ziel identifizieren, auf das hingearbeitet wird. Sollten trotz redlicher Bemühungen nicht alle Stories fertig werden, kann man möglicherweise einige Tasks so umarbeiten, dass sie nicht ganz so aufwändig sind, aber trotzdem noch das Sprint Goal erreichen lassen. Sieht man schon während des Sprints, dass das Sprint Goal nicht mehr erreichbar ist, sollte der Product Owner den Sprint abbrechen und die Planung erneut überdenken.
    Sprint Planning Das Sprint Planning besteht aus zwei Teilen, dem Sprint Planning 1 und dem Sprint Planning 2. Beide Meetings finden am ersten Tag eines Sprints statt, bei einem vierwöchigen Sprint das erste am Vormittag und das zweite am Nachmittag, jeweils maximal vier Stunden lang. Bei kürzeren Sprints werden die Meetings entsprechend gekürzt.

    Im ersten Teil schaut sich das Team gemeinsam mit dem Product Owner die User Stories aus dem Product Backlog an und wählt von oben diejenigen aus, die es im Laufe des nächsten Sprints meint, abarbeiten zu können. Hier wird also geklärt, WAS umgesetzt werden soll. Im zweiten Teil wird geklärt, WIE die Stories umgesetzt werden sollen. Hier werden Designs und Architekturen entworfen und die Stories in einzelne Tasks zerlegt. Am Ende des Sprint Plannings steht ein Taskboard, auf dem alle konkreten Aufgaben für den nächsten Sprint hängen und nach und nach abgearbeitet werden (Sprint Backlog).

    Stakeholder Stakeholder sind Interessensvertreter, also alle, die vom Projekt betroffen oder direkt daran beteiligt sind. Dazu können zählen: Management, Auftraggeber, User, Kunde, Mitarbeiter, Kollegen, möglicherweise sogar Banken und Betriebsräte. Wichtig ist, dass die Interessen der Stakeholder während der Projektdurchführung mindestens bekannt sind, wenn nicht sogar bei der Realisierung berücksichtigt werden. Beim Sprint Review ist es eine gute Idee, möglichst viele der Stakeholder der Demonstration des fertigen Teilprodukts einzuladen, nicht zuletzt, um bereits frühzeitig die Akzeptanz zu erhöhen oder im positiven Fall gute Ideen für die weitere Umsetzung einzusammeln und in das Product Backlog einfließen zu lassen.
    Story Card Während eines Sprints arbeitet das Team an Stories, die aus dem Product Backlog kommen und dort in aller Regel elektronisch verwaltet werden. Im täglichen Doing allerdings ist das Taskboard das hauptsächliche Arbeitsmittel. Was wir also brauchen, ist eine visuelle Repräsentation der einzelnen Stories. Und genau das ist eine Story Card. Auf ihr steht auf der Vorderseite der Text der Story und idealerweise ebenfalls der Business Value und die Story Points. Auf der Rückseite finden dann noch Details wie z.B. Abnahmekriterien, Teststrategien usw. Platz. Damit hat man dann alle Informationen an der Hand, um vollständig unelektronisch am Taskboard arbeiten zu können.
    Story Points Um eine sinnvolle Sprint- und Releaseplanung vornehmen zu können, brauchen wir die Größe einer Story. Diese wird in sogenannten Estimation Meetings mit der Technik Planning Poker bestimmt. Wichtig ist auf der einen Seite, dass nicht die Dauer der Umsetzung, sondern Größe der Story geschätzt wird, da die Umsetzungsdauer massiv von der Anzahl der Leute und ihrer Fähigkeiten sowie den verwendeten Tools abhängt. Um also eine Rückrechnung auf die Zeit möglichst zu erschweren, führt man diese abstrakte Messgröße Story Point ein, die nur im Vergleich zu anderen Stories Sinn ergibt, nicht aber als allein stehende Zahl.
    Sutherland, Jeff Jeff Sutherland hat gemeinsam mit Ken Schwaber Scrum in seiner heutigen Form “erfunden”. Eigentlich handelt es sich um eine Sammlung bereits lange bekannter Techniken aus verschiedensten Gebieten, wie z.B. Deming-Cycle, Iterativ-Inkrementelle Softwareentwicklung, viel Kommunikation usw. Diesen beiden gebührt aber sicher der Verdienst, diese Techniken aufeinander abgestimmt und ein schlüssiges Gesamtkonzept daraus entwickelt zu haben. Die Tatsache, dass das Konzept kurz, knapp und in sich abgeschlossen ist, hat sicher zur schnellen Verbreitung und Popularität beigetragen.


    T     nach oben
    Task Ein Task ist ein Arbeitsschritt, der gemeinsam mit anderen Tasks der Erfüllung einer User Story dient. Features (in Form von User Stories) werden vom Product Owner vorgegeben und im Sprint Planning 1 vom Team für den kommenden Sprint ausgewählt. Im Sprint Planning 2 werden diese Stories dann vom Team in einzelne Tasks zerteilt. Diese stellen die technischen Schritte dar, um das fachliche Feature umzusetzen. Jede Task sollte nicht länger als einen Tag zur Umsetzung benötigen, damit man jeden Tag den Fortschritt messen kann. Während die Anzahl der Stories im Laufe eines Sprint konstant bleibt, kann sich die Anzahl der Tasks ändern, z.B. wenn das Team erkennt, dass ein weiterer Schritt nötig ist, um eine Story fertig zu stellen.
    Taskboard Das Taskboard ist das wichtigste Arbeitsmittel des Teams. Hier stehen in der linken Spalte alles Stories des aktuellen Sprints und daneben die zugehörigen Tasks im jeweiligen Status. Das Daily Scrum findet am Taskboard statt und jedes Teammitglied verschiebt “sein” Task in die entsprechende Spalte. Gemeinsam mit dem Burndown Chart ist das Taskboard völlig ausreichend, um einen ziemlich guten Überblick über den momentanen Stand des Projekts zu bekommen.
    Team Das Team ist eine der drei Kernrollen in Scrum. Das Team ist selbstorganisiert und entscheidet völlig selbstständig, wieviele Tasks im jeweiligen Sprint abgearbeitet werden und wie die technische Umsetzung dafür aussieht. Kein Teammitglied bekommt Aufgaben zugewiesen, sondern nimmt sich einen Task, den es bearbeiten will (Pull-Prinzip). Das Team gibt am Anfang ein Commitment über den Lieferumfang des Sprints an den Product Owner und versucht mirt allen sinnvollen Mitteln, dieses Ziel auch zu erreichen. Sollten Probleme auftauchen, werden diese an den ScrumMaster übergeben, der dann dafür sorgt, dass sie aus dem Weg geräumt werden.
    Timebox Die Timebox ist ein festes, geschlossenes Zeitfenster, das unbedingt eingehalten werden muss. Jedes Meeting und jede Zeitangabe in Scrum (z.B. Sprintlänge) hat eine definierte Timebox. So darf z.B. ein Daily Scrum nicht länger als 15 Minuten sein. Der Grund für diese Timeboxes ist die Vermeidung von Verschwendung und die Fokussierung auf die wirklich wichtigen Dinge im Sprint. Eine Erzählung über das 10-jährige Dienstjubiläum von gestern Nachmittag gehört in die Pause und nicht in das Daily Scrum. Sollte am Ende der geplanten Timebox das Thema nicht hinreichend diskutiert sein, wird eben ein Folgemeeting einberufen, bei dem dann aber nur genau der Personenkreis eingeladen wird, der auch betroffen ist.
    Toyota Production System Auch wenn Scrum lt. Ken Schwaber seine Wurzeln nicht im TPS hat, sind doch viele der Ideen von Scrum bereits im TPS enthalten, das seit den vierziger Jahren des letzten Jahrhunderts von Toyota für seine Fahrzeugproduktion eingesetzt wird. Einige ausgewählte Prinzipien sind Verschwendung vermeiden, z.B. durch die sogenannte Just-In-Time-Produktion, die Lagerkosten vermeidet. Ein kontinuierlicher Verbesserungsprozess wird eingesetzt, indem die einzelnen Arbeiter einen roten Notaus-Knopf haben, mit dem sie ein Fließband anhalten können, wenn sie einen Fehler im Produktionsprozess erkennen. Schließlich sind sie die Experten, da sie selbst die Tätigkeiten jeden Tag durchführen und nicht die Manager. Eine logische Konsequenz daraus ist die Übertragung der Verantwortung für die Qualität an das Team, diese dann verbunden mit der Erlaubnis/Verpflichtung zur Selbstorganisation innerhalb des Teams.


    U     nach oben
    User Als User bezeichnet man den Benutzer eines Softwareproduktes. Dass das Wort an sich bereits einen negativen Beigeschmack hat, liegt an der klassischen Sichtweise, dass der Kunde ohnehin nicht weiß, was er will und der User einfach nicht versteht, welch geniales System er vor sich hat. In agilen Methoden hingegen wird der User nicht als Gegner, sondern als Partner gesehen, der mithelfen kann und muss, ein besseres Produkt zu bauen. Durch frühes Vorweisen der bereits realisierten Teilfunktionalitäten im Review kann zum Einen jeder nützliche Hinweise des Users mit in das Produkt einfließen, was sicherlich zur Verbesserung mindestens der Bedienbarkeit führen wird. Zum Anderen wird natürlich auch die Akzeptanz beim User erhöht, da er nicht vom Ergebnis überrascht wird, sondern sich frühzeitig daran gewöhnen kann. Er kann mit dem System arbeiten und Verbesserungsvorschläge vorbringen.
    User Story Eine User Story ist eine mögliche Form der Notation für Product Backlog Items. Sie gehorcht einer speziellen Syntax: “Als <Rolle> möchte ich <Feature>, weil <Motivation>”. Also z.B.: “Als Administrator möchte ich das Passwort eines Benutzers zurücksetzen können, weil dieser sonst bei vergessenem Passwort keine Möglichkeit mehr hat, in das System zu gelangen”. Diese Beschreibung ist bewusst kurz gehalten, um zu erzwingen, dass eine Diskussion zwischen dem Team und dem Product Owner über das Feature entsteht. Außerdem ist rein fachlich gehalten, die Entscheidung über die technische Umsetzung obliegt ja dem Team.

    Die Kunst des Product Owners besteht darin, diese Stories in genau der richtigen Größe bereitzustellen (siehe Schneiden von User Stories). Während der Arbeit an den Stories im Sprint werden sie auf Story Cards geschrieben und an das Taskboard gehängt.


    V     nach oben
    Velocity Als Velocity bezeichnet man die Geschwindigkeit eines agilen Entwicklungsteams. Sie wird gemessen in Story Points pro Sprint. Es werden nur die Story Points der wirklich fertigen Stories aufsummiert. Interessanterweise ist die Velocity eines Teams nach einer Einschwingphase von 3–5 Sprints konstant. Dies führt dazu, dass die Velocity ein sehr gutes Planungsmittel für die Releaseplanung darstellt.
    Vision Die Vision wird vom Product Owner erstellt und stellt die Richtlinie dar, an der alle Features des Produktes gemessen werden müssen. Eine Vision muss erreichbar sein, ein übergeordnetes Gesamtbild des Projektes bilden und enthält idealerweise auch bereits 3–5 der wichtigsten Features des späteren Produktes. Teile der Vision können als Sprint Goal fungieren.


    W     nach oben
    Workshop In agilen Umgebungen betrachten wir Kommunikation und Teamarbeit als sehr wichtig. Taucht ein Thema oder ein Problem auf, das nicht von einer Person bearbeitet werden kann oder sollte, ist ein Workshop möglicherweise die richtige Methode, sich dem Thema zu nähern. In einem Workshop können dann mehrere Teilnehmer, möglicherweise unter Hinzuziehung projektexterner Experten das Thema diskutieren und zur Umsetzung vorbereiten. Um einen guten Erfolg eines Workshops zu gewährleisten, sollte dieser vorbereitet sein, moderiert werden und zeitlich begrenzt sein (Timebox).
    Work in Progress (WiP) Bei agilen Ansätzen bezeichnet Work in Progress die Aufgaben in Bearbeitung. Meisten Methoden versuchen die Verschwendung zu minimieren die aufgrund einer nicht-bedarfsorierntierten Abarbeitung entseht in dem WiP minimiert wird.


    X     nach oben
    XP XP ist die Abkürzung für Extreme Programming, einer agilen Software-Entwicklungsmethodik


    Y     nach oben
    Yesterday’s weather Hierbei handelt es sich um eine Methode zur Bestimmung der Velocity eines Teams in einem neuen Projekt. Sie basiert auf der Annahme, dass die Velocity vermutlich ähnlich sein wird wie beim letzten Projekt des gleichen Teams. Dies gilt natürlich nur bei ähnlichen Projekten und nur dann, wenn keine besseren Informationen zur Verfügung stehen. Obwohl in Wirklichkeit geraten (man hat ja noch keine Informationen), ist diese Annahme möglicherweise besser als ganz einfach ins Blaue zu raten, denn üblicherweise benötigt der Product Owner irgendeine Zahl, um die Realeaseplanung vorzunehmen.


    Z     nach oben


    Copyright © 2009–2010 Holisticon AG

    Dieses Glossar darf in vollständiger Form und unverändert jederzeit kopiert und kostenlos weitergegeben werden. Der Hinweis auf die Originalquelle http://www.holisticon.de/cms/AgileGlossar/Startseite muss ebenso wie dieser Copyright-Hinweis stets angegeben werden. Es ist nicht zulässig, das Glossar kommerziell zu vertreiben, gegen Entgelt weiterzugeben oder Inhalte zu verändern. Im Rahmen nicht-kommerzieller Verwendungen, beispielsweise Diplomarbeiten, darf das Glossar gerne übernommen werden. Die Verwendung in kommerziellen Zusammenhängen, beispielsweise in öffentlichen oder internen Schulungen, firmeninternen Netzwerken, Publikationen, Produkten etc. ist prinzipiell gestattet, wenn eine entsprechende Meldung an gesendet wird. Die Weitergabe ist sowohl in elektronischer als auch gedruckter Form zulässig. Im Internet zugängliche Kopien sind ebenfalls zu melden.

    Hinweis zu den Urhebern der dargestellten Abbildungen: Alle hier wiedergegebenen Grafiken wurden von uns erstellt und sind NICHT von Dritten bezogen!

    Nehmen Sie Kontakt mit uns auf!

    Ihre Ansprechpartner:

    Holger Koschek Carsten Sahling
    Telefon: +49 40 5074 2722