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