von Super User | März 21, 2017 | Agile Methoden
Agile Methode: Schätzen im agilen Umfeld
Im klassischen Projektmanagement ist das Schätzen für die Projektplanung von Bedeutung. Von vielen Menschen, die in Projekten arbeiten, wird das Schätzen von Dauer, Arbeitsstunden und Kosten als der aufwendigste und unangenehmste Teil des Planungsprozesses empfunden.
Da die Planung in agilen Methoden scheinbar keine so große Rolle spielt, entsteht hier schnell die Erwartung, „nicht mehr schätzen“ zum müssen. Diese Hoffnung deckt sich aber nicht mit der Realität. Auch hier müssen die Beteiligten und insbesondere die Menschen, die die Leistungen entwickeln, ständig schätzen.
Exaktheit vor Genauigkeit
Die wichtigste Schätzregel, wenn sie agil arbeiten:
Was bedeutet das?
Stellen sie sich vor, jemand schätzt und kommt zu folgender Aussage:
„Am ersten Dienstag im Februar des nächsten Jahres in Frankfurt wird es zwischen 17:00 und 17:15 genau 2 mm Niederschlag am Bahnhof geben.“
- Diese Aussage ist sehr genau.
- Wie viel Aufwand steckt in dieser Aussage: Der Schätzende hat die Wetterdaten des Frankfurter Bahnhofs über die letzten zehn Jahre in seine Analyse einfließen lassen. Er hat Wahrscheinlichkeiten für die Niederschlagswahrscheinlichkeit und Niederschlagsmenge berechnet. Er hat zusätzlich ein globales Langzeit Wettermodell bemüht uns außerdem die Temperaturkurve für Frankfurt in Kombination mit der Niederschlagswahrscheinlichkeit statistisch kombiniert. Er hat sich also alle Hilfsmittel, die ihm zur Verfügung standen, genutzt und alles getan, damit diese Schätzung so exakt wie möglich wird. Dafür hat er natürlich viel Arbeitszeit aufwenden müssen. Es hat sich gelohnt. Oder?
- Würden sie dieser Schätzung vertrauen? Würden sie sich darauf verlassen, dass dieses Ereignis genauso eintritt?
Nehmen wir im Vergleich ein andere Aussage:
„Im Frühjahr des nächsten Jahres wird es am Frankfurter Bahnhof regnen.“
- Diese Aussage ist sehr exakt.
- Der Aufwand, der hinter dieser Schätzung liegt, ist kaum messbar. Die Kausalität, die der Schätzende genutzt hat, war: Im Frühjahr innerhalb von drei Monaten irgendwann Regen => also auch am Frankfurter Bahnhof. Hat sich der Aufwand gelohnt?
- Würden Sie dieser Schätzung vertrauen? Würden Sie darauf vertrauen, dass dieses Ereignis eintritt?
Die erste Schätzung ist sehr genau. Das Eintreten ist sehr unwahrscheinlich. Der Aufwand sehr groß. Der Nutzen der Schätzung ist sehr gering.
Die zweite Schätzung ist sehr exakt. Das Eintreten der Schätzung extrem wahrscheinlich. Der Aufwand minimal. Aber der Nutzen der Schätzung ist nicht vorhanden.
Irgendwo zwischen diesen beiden Extremwerten liegt eine Schätzung, die einen guten Kompromiss zwischen den beiden Schätzungen darstellt. Diese gilt es zu finden.
Es gibt eine Reihe an Schätzverfahren, die in einem agilen Umfeld bevorzugt werden. Allerdings können auch alle anderen Schätzverfahren, die sich im Projektmanagement etabliert haben, eingesetzt werden. Umgekehrt gilt aber auch, dass alle Schätzverfahren die typisch für ein agiles Vorgehen sind, im klassischen Projektmanagement verwendet werden.
{article 245}[text] {/article}
von Super User | März 21, 2017 | Agile Methoden
Agile Methode: Weighted Shortest Job First (WSJF)
Diese Priorisierungstechnik entstammt dem Lean Production Development. Sie wird im Scaled Agile Framework vorgeschlagen.
Die Grundidee ist der Return of Investment (ROI) Rechnung ähnlich. Es erfolgt eine Erweiterung der Kriterien:
- Zeitkritikalität
- Risikoreduzierung, bzw. Chancenwahrnehmung.
Der WSJF wird dann so berechnet:
Je größer der WSJF Wert ist, umso größer ist die Priorität.
Zeitkritikalität:
Product Owner, Stakeholder und / oder das Entwicklerteam schätzen, wie dringend dieses Inkrement benötigt wird.
Risiko und Chance:
Product Owner, Stakeholder und / oder das Entwicklerteam schätzen, wie groß das Risiko ist, dass sich bei der Erstellung eines Inkrements ergibt und wie groß die Chancen sind, die sich daraus ergeben.
Bei allen hier genannten Variablen stellt sich die Problematik der Einheiten, in denen gemessen, bzw. geschätzt wird. Die Mathematik stellt gewisse Grundanforderungen, wie Berechnungen durchgeführt werden sollen, Insbesondere dürfen nicht Äpfel durch Birnen geteilt werden. Werden alle Faktoren in Euro berechnet ist das relativ unkritisch – aber hier ist die Umrechnung sehr zeitaufwendig.
{article 245}[text] {/article}
von Super User | März 21, 2017 | Agile Methoden
Agile Methode: Priorisierung nach dem Return of Investments (ROI)
Der Return of Investment ist ein klassisches Instrumentarium der Investitionsrechnung. In seiner einfachsten Form wird er in der folgenden Form berechnet:
Hier wird eine rein ökonomische Betrachtung zugrunde gelegt. Zunächst erscheint dieses Vorgehen recht einfach, weil Gewinn und investiertes Kapital objektiv leicht messbar sind. Bei der Priorisierung reden wir aber immer von erwartetem zukünftigen Gewinn und erwartetem zukünftig zu investierendem Kapital. Zukünftige monetäre Werte zu schätzen ist allerdings nicht nur sehr aufwendig, sondern auch von großen Unsicherheiten geprägt.
Eine am Nutzen des Auftraggebers oder des Nutzers oder anderer Stakeholder orientierte Perspektive des ROI errechnet sich nach der folgenden Formel:
Die Berechnung des ROI aus diesen Variablen ist allerdings noch schwierige, weil sowohl Nutzen, als auch Aufwand keine skalierbaren Dimensionen haben und häufig in verschiedenen Einheiten gemessen werden. Der Aufwand einer Funktionalität kann z.B. in den Personenstunden gemessen werden, die für seine Erstellung aufgewendet werden. Wenn keine Äpfel durch Birnen geteilt werden sollen, müsste der Nutzen auch in Personenstunden angegeben werden. Das ist aber nur in wenigen Fällen sinnvoll.
Behalten wir auch in Erinnerung, dass hier alle z.B. User Stories nach dem gleichen Kriterium priorisiert werden soll, dann wir muss die gleiche Skalierung für Nutzen und Aufwand in allen Userstories gleich sein. Das wird jedoch nur in wenigen Fällen möglich sein.
Außerdem sollten wir auch berücksichtigen, dass einer der Vorteile der bei der Verwendung von agilen Methoden darin besteht, dass mit einer Leistungsentwicklung ohne umfangreiche und lang dauernde Vorbereitungen begonnen werden kann. Wenn zur Priorisierung jeder einzelnen User Story umfangreiche Schätzungen und damit verbunden Planungsvorgänge verbunden sind, bevor klare Prioritäten festgelegt werden können, geht einer der Hauptvorteil des agilen Vorgehens bereits verloren, bevor das erste Inkrement entwickelt wird. Das leichtgewichtige agile wird zu einem schwergewichtigen analytischen Verfahren.
Aus kaufmännischer Sicht ist eine solche Form der RIO Berechnung eher minderwertig. Der Return of Investment wird hie meistens über mehre Perioden betrachtet, wobei erwarteter Gewinn in der Zukunft auf einen Gegenwartswert abgezinst wird. Eine Anwendbarkeit in der Priorisierung ist hier natürlich auch gegeben. Die oben bereits genannten Probleme vergrößern sich damit aber zusätzlich um die Prognose der zukünftigen Zinssätze.
{article 245}[text] {/article}
von Super User | März 21, 2017 | Agile Methoden
Agile Methode: User Story (User Story, Nutzergeschichte, User Storys)
User Storys werden in allen agilen Systemen verwendet. Wenn ein Unternehmen agil arbeitet, dann ist die Verwendung von User Storys schon fast eine Pflicht. Die Methode der User Story kann auch in vielen anderen Zusammenhängen genutzt werden, so z.B. in dem Anforderungsmanagement des klassischen Projektmanagements oder Produktmanagements.
Die Aussage, die sich im Zusammenhang mit Agilen Methoden ständig findet: „Anforderungen dürfen im klassischen Projektmanagement nicht geändert werden“, ist einfach falsch. In allen Projektmanagement Systemen gibt es ein Anforderungsmanagement. Teil dieses Anforderungsmanagements ist immer ein Änderungsmanagement, in dem ein Prozess für das Ändern von Anforderungen festgelegt wird. Im „klassischen Projektmanagement“ dürfen Anforderungen also durchaus geändert werden. Es besteht lediglich eine Notwendigkeit, diese Anforderungsänderungen von den Entscheidern genehmigen zu lassen. Das ist, wenn agil gearbeitet wird, aber nicht anders.
Anforderungen stellen in den Agilen Systemen einen Handlungsspielraum dar, der verändert werden kann, um geschäftliche Ziele zu erreichen. Wenn neue Erkenntnisse während der Entwicklung entstehen, die darauf hinweisen, dass das Kosten-Nutzen Verhältnis einer Anforderung ungünstiger ausfällt als ursprünglich gedacht, muss diese Anforderung angepasst werden. Genau diese Forderung findet sich auch in allen klassischen Projektmanagement Systemen.
Im Scrum muss am Anfang eines Leistungserstellungsprozesses nur ein geringer Aufwand betrieben werden, um die Anforderungen im Voraus zu entwickeln. Alternativ können auch Platzhalter im Product Backlog festgelegt werden, die erst im Verlauf des Projektes mit Inhalten gefüllt werden.
User Storys sind nur ein „Platzhalter“ in einem Product Backlog für Anforderungen. Diese Anforderungen sind für ein gemeinsames Verständnis zwischen Team und Stakeholdern über die zu erstellende Leistung notwendig. Dieses Verständnis entsteht durch die Kommunikation über die zu erstellende Leistung in einer Face to Face Kommunikation und häufige Feedback Schleifen in Form von Rückfragen und Reviews.
Hier liegt der große Unterschied zwischen dem „klassischen Umgang mit Anforderungen“ und einem agilen Vorgehen. Viele Anforderungen in „klassischen Projekten“ werden von Spezialisten in Zusammenarbeit mit den Stakeholdern geschrieben. Leider verändern diese sich mit der Zeit oder sind für Entwickler nicht zu verstehen. – Aber die Anforderer haben ihre Arbeit getan und wollen mit Rückfragen nicht mehr belästigt werden. Die Entwickler haben gefälligst das zu tun, mit dem sie beauftragt sind und die Anforderer nicht mehr zu stören. Immerhin haben die Anforderer viel Geld ausgegeben, um die Anforderungen von Beratern richtig formulieren zu lassen.
Wenn der Anforderer jetzt im Sinnes des Agilen Managements von den detaillierten Anforderungen zu leicht und schnell zu erstellenden User Storys wechselt, dann glaubt er, alles getan zu haben – und lehnt sich, seinen bisherigen Gewohnheiten entsprechend, zurück, in der Erwartung, das geliefert zu bekommen, was er glaubt bestellt zu haben. User Storys sind für ihn das ideale Mittel, um seinen eigenen Aufwand zu minimieren, denn User Storys sind wesentlich schneller und leichter erstellt als „klassische Anforderungsbeschreibungen“.
Durch den Einsatz agiler Methoden ist das Kommunikationsproblem von Entwickler und Anforderer eher größer geworden. Das Kommunikationsproblem, das bei Einsatz der „klassischen Methoden“ darin bestanden hat, dass der Anforderer nicht mit dem Kunden reden möchte und ihm die Teilnahme an einem Review viel zu kompliziert und eine Überarbeitung seiner Anforderungen zu aufwendig ist. Agil oder „klassisch“, keiner der Methoden ist das Problem – oder löst irgendein Problem. Das Problem liegt in der nicht vorhandenen Kommunikation zwischen Anforderer und Leistungsersteller – und es kann auch nur an dieser Stelle gelöst werden.
User Storys sind also Platzhalter, die Entwickler und Anforderer daran erinnern, dass sie über dieses Thema noch häufiger reden müssen und die durch genauere, spezifischer User Storys ersetzt werden, wenn über die Gespräche und die Erfahrungen aus diversen Reviews die Erkenntnisse über die zu erstellende Leistung im Verlauf des Leistungserstellungsprozesses besser geworden sind.
Der Zeitbedarf bei der Arbeit mit User Storys ist zumindest für die Seite der Anforderer nicht kleiner geworden. Im Gegenteil. Der Unterschied besteht lediglich darin, dass das Risiko geringer wird, das eine Leistung erstellt wird, die nachher nicht den Wünschen der Anforderer entspricht. – Ein Risiko, dass auch bei den klassischen Methoden erheblich reduziert werden würde, Anforderer und Leistungsersteller häufiger und klarer miteinander kommunizieren würden.
Ziel / Nutzen
User Storys werden zur Beschreibung der Anforderungen aus Perspektive eines Nutzers verwendet. Hierfür wird die Alltagssprache verwendet. Eine User Story beschreibt, was ein Benutzer mit einem Produkt erreichen will.
Hilfsmittel
User Storys sollten mündlich formuliert werden. Sie müssen anschließend schriftlich fixiert werden. Das geschieht zumeist in zwei Schritten:
- die schriftliche Ausformulierung in einer Langfassung.
- Kurzform, so dass sie auf eine Moderationskarte passt.
Die Kurzfassung wird in eine Product Backlog oder in einem Work breakdown Chart verwendet. Die „Langfassung“ ist eine notwendig Voraussetzung, damit mit einer User Story gearbeitet werden kann.
Wie geht es?
User Storys sollten vom Auftraggeber oder vom späteren Anwender formuliert werden. Eine Hilfslösung besteht darin, dass ein Spezialisten Team, welches die Zielgruppe sehr gut kennt, die User Storys formuliert.
Das Erstellen von User Storys ist ein interaktiver, mehrzyklischer Prozess. Zumeist entstehen „übergeordnete User Storys“ (Metaebene), aus denen dann untergeordnete User Storys entstehen, die zu kleineren „Problemlösungen“ führen. Es entstehen sehr schnell Strukturpläne aus User Storys. Das zeigte uns auch das INVEST-Kriterium
Eine der gerne gewählten Irrtümer besteht in der Annahme, dass der Aufwand der Umsetzung der Kundenwünsche in einem agilen Umfeld nicht geschätzt werden muss. Betrachten wir uns das INVEST-Kriterium ist das Gegenteil der Fall.
Die drei C´s der User Story:
Card (Karte)
User Storys können direkt auf Karteikarten oder Klebezettel (Post it) geschrieben werden. Dabei wird der unten beschriebene Satzbau verwendet.
Conversation (Gespräch)
In einem interaktiven Kommunikationsprozess von Feedback Schleifen wird zwischen den Beteiligten geklärt, wie die User Story zu verstehen ist. Natürlich dürfen dabei auch Dokumente verwendet und bei Bedarf erstellt werden. Ebenso selbstverständlich kann in der User Story auf andere Dokumente verwiesen werden.
Confirmation (Bestätigung, Akzeptanzbedingungen)
Zumeist auf der Rückseite der Karte werden die Akzeptanzkriterien aufgeführt. Das sind die Bedingungen, unter denen der Anforderer bereit ist, die User Story als erfüllt anzusehen. Häufig zeigt sich hier deutlicher als in der User Story, was genau der Anforderer haben möchte. Gleichzeitig legt sich der Anforderer damit fest. Wenn diese Kriterien erfüllt sind, dann hat das Team die Leistung im Sinne des Anforderers erstellt.
Dieser Ansatz wird auch als Spezikation nach Beispiel oder Acceptance-Test-driven Development (ATTD) bezeichnet.
Eine User Story kann auch eine längere Geschichte sein und sich über mehrere Textseiten ziehen. Wichtig ist nur, dass:
- Sie in einer kürzeren Form dem nachfolgendem Satzbau entsprechend umformuliert wird.
- Sie von der Entwicklerseite umfassend verstanden wird.
Satzbau
Eine User Story ist immer nach dem folgenden Schema aufgebaut:
Als <Rollen, die der Anforderer in der Story hat> will ich <Eigenschaft der Leistung>, damit < folgender Nutzen> entsteht.
Eine alternative Möglichkeit:
In meiner Rolle als <….>, ist mir folgendes passiert <….>. Dadurch sind folgende Probleme entstanden <…>. Eine Beseitigung dieser Probleme würde mir folgenden Nutzen generieren <…>.
Im ersten Fall, muss der Anwender die Eigenschaften einer Leistung, die er benötigt, bereits kennen. Im zweiten Fall, liegt es in der Verantwortung des Projektteams, eine Lösung zu entwickeln.
In beiden Fällen ist die Formulierung der Nutzenerwartung des Anderen wichtig. Nur dadurch ist es möglich, zu überprüfen, ob ein Wert für den Anwender geschaffen wurde.
Kriterien für eine gute User Story
INVEST-Kriterium
[I]ndependent
Eine gute User Story ist unabhängig von anderen User Storys. Die Entwicklung der Lösung für diese User Story sollte möglich sein, ohne dass zuerst andere User Storys umgesetzt werden müssen.
[N]egotiable
User Storys sollten im Verlauf der Entwicklung verhandelt werden können. Entwickler und Anfordere verhandeln diese User Storys im Verlauf der Entwicklung und können sie auf die jeweilige Situation und den jeweiligen Erkenntnisstand anpassen.
[V]aluable
Der Mehrwert der User Storys sollte für den Anforderer erkennbar sein. Am besten existiert ein skalierbares Kriterium für den Wert, der aus der Problemlösung entsteht. Ein skalierbares Kriterium kann in Geldeinheiten, aber auch in eingesparter Zeit, messbarer Zufriedenheitssteigerung oder ähnlichem bestehen.
[E]stimatabel
Der Arbeitsaufwand für jede User Story muss von dem Entwicklerteam schätzbar sein.
[S]mall
Die Umsetzung der Problemlösung sollte in möglichst kurzer Zeit möglich sein. Eine komplette Umsetzung sollte mindestens einen halben Personentag und maximal zehn Personentage erfordern. Auf jeden Fall sollten sie in einem Sprint abgeschlossen werden können. Das bedeutet auch, dass User Storys, die nur in größeren Arbeitseinheiten lösbar sind, in kleinere Einheiten herunter gebrochen werden.
[T]estable
Das Entwicklerteam muss anhand irgendwelcher vorher festgelegten Kriterien überprüfen können, dass die User Story erfolgreich abgeschlossen ist.
Zusätzlich zu jeder User Story müssen vom Anforderer die Akzeptanzkriterien formuliert werden, unter denen er die entwickelte Lösung der User Story als erfüllt ansieht.
Über die User Story hinausgehende Informationen
Oben wurde bereits gesagt, dass eine User Story ein Platzhalter ist. Auf dem Product Backlog ist auch kaum Platz für weitere Informationen.
An diese User Story können und sollen aber detaillierte technische Spezifikationen, etc. soweit bekannt „angehangen“ werden. Das bedeutet in der praktischen Umsetzung auch, dass es eine Vielzahl an Spezifikationsdokumenten geben kann, die zu einer User Story gehören, aber in einem entsprechenden Ordner abgelegt sind, die den Entwicklern ebenso zur Verfügung stehen müssen, wie den Anforderern.
Detailierungsgrad
Eine User Story unterliegt einer Geschichte, bis so detailliert ist, dass sie klein genug strukturiert ist, damit sie in einem Sprint abgearbeitet werden kann. User Stories werden im Verlauf des Leistungserstellungsprozesses immer weiter detailliert (siehe hierzu auch den Artikel Product Backlog). Die Verfeinerung der User Story erfolgt progressiv, also spätestens zu dem Zeitpunkt zu dem sie benötigt wird, in einem iterativen Prozess.
{article 245}[text] {/article}
von Super User | März 21, 2017 | Agile Methoden
Produkt Roadmap
Ziel / Nutzung
Entwicklung eines neuen Produktes.
Fragestellung: „Wohin soll die Entwicklung des Produktes gehen?“
Verwender: Product Owner, Stakeholder und alle Menschen die ein Produkt vor der Entwicklung durchdenken müssen.
Ein Instrument zur Diskussion und zur Analyse einer Produktentwicklung auf einer Abstrakten Ebene mit mehreren Personen.
Hilfsmittel
Ein oder mehrere große Whiteboard oder Pin Wände.
Wie geht es?
Erstellen Sie auf dem Whiteboard eine Tabelle.
In den Spalten werden die Etappen, Meilensteine, Releases, Sprints der Produktentwicklung aufgezeichnet. Meilenteine stellen Zwischenergebnisse zu einer vollständigen Produktentwicklung dar. Es sind Inkremente die am ende der Etappe von den Anwendern selbständig nutzbar sein müssen. Für den Anwender einen Wert haben.
Die Inhalte der Zeilen folgen dann folgendem Aufbau:
Ziel der Etappe -> Für Wen? -> Welche Bedürfnisse hat er? -> Was braucht er zur Bedürfnisbefriedigung? -> Wie können wir messen, dass wir das Ziel erreicht haben?
In den Zeilen werden folgende Fragestellungen beantwortet:
Ziel: „Wozu soll diese Phase dienen?“
- Was wollen wir in diese Etappe erreichen?
- Wozu machen wir diese Phase?
Jeder dieser Etappen muss einen Wert schaffen und mindestens ein Inkrement, das selbständig nutzbar, testbar und von den Anwendern bewertbar ist. Jedes Ziel sollte der Weiterentwicklung des Produktes hin zu einem größeren Wert aus Kundenperspektive führen. Aus diesem Ziel der Phase ergeben sich dann die anderen Zeilen.
Anwender: „Welche Anwender stehen in diesem Release im Mittelpunkt?“
- Für welche Anwender wird diese Teil des Produktes entwickelt?
- Welchen Menschen soll dieses Release einen Nutzen bringen?
- Wer soll mit diesem Produktteil arbeiten?
Der Anwender ist nicht zwangsweise der Endnutzer des Produktes sein. Bei einem Softwarprodukt kann es z.B. derjenige sein, der die Sofware wartet. Bei einem Haus der Hausmeister oder der Wartungsdienst für die Heizungsanlage. Die Zielgruppe des jeweiligen Release wird hier festgelegt. Ein guter Weg Anwender genauer zu beschreiben ist die Nutzung von Personas.
Bedürfnisse: „Welche Bedürfnisse haben die Anwender?“
- Welche Bedürfnisse der Anwender wollen wir befriedigen?
- Was schafft einen Wert für die Anwender?
- Welches Problem der Anwender wollen wir lösen?
Bei einer Neuentwicklung müssen hier nicht unbedingt bestehende Problem gelöst, bzw. Bedürnisse befriedigt werden. Es kann in der ersten Phasen einer Innovationentwicklung darum gehen, die in früheren Produkten bereits befriedigten Bedürfnisse ebensogut zu befriedigen, wie in der Vorversion. Ein gutes Mittel auf diese Ebene könnten die Nutzung von Userstorys zur Beschreibung der Problemstellungen sein.
Features: „Welche Funktionalitäten sollen entwickelt werden, damit diesen Bedürfnissen der Anwender entsprochen wird?“
- Was soll konkret entwickelt werden, damit den Bedürfnissen der Anwender entsprochen wird?
- Was brauchen die Anwender zur Befriedigung ihrer Bedürnisse?
Diese Zeile bringt die Entwickler von der Produkt Roadmap von der abstrakten auf die konkrete Ebene der Leistungsentwicklung. In diese frühen Phase der Produktentwicklung ist es noch nicht nötig, die genauen Eigenschaften der Features zu beschreiben. Viel mehr geht es um eine Sammlung von Features.
Am Beispiel eines Autos: Bremsen, Motor, ohne das beide „Features“ genauer beschrieben werden.
Messung: „Wie messen wir, dass die Features die Bedürfnisse der Anwender entsprechen?“
Weitere sinnvolle Spalten:
Name, Endtermin, etc.
Aufbau der Produkt Roadmap
Kombinierbar mit anderen Methoden
Phasenmodell mit Meilensteinen
User Story
Persona
Zielstrukturplan
Aufwandschätzung
