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