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