In den letzten Artikeln ging es darum, wie du durch eine Zieldefinition ( link ), eine Grobplanung ( link ) und einen Workshop ( link ) dir einen guten Überblick verschaffts, welche Aufgaben zu erledigen sind. In diesem Artikel geht es nun darum, wie du deine vielen Ideen zusammenfasst und in einen Detailplan bekommst.
Bevor wir in die Detailplanung gehen, möchten wir dir noch ein Konzept aus dem Lean Startup vorstellen, das MVP („Minimum Viable Product“) oder das gerade so nützliche Produkt. Damit ist ein Produkt gemeint, dass einen minimalen Funktionsumfang hat, dem Nutzer aber bereits einen Mehrwert bietet.
Es dient dazu die eigenen Ideen schnell zu realisieren und an den Nutzerbedürfnissen zu spiegeln. Behalte diesen Gedanken, einen minimalen Funktionsumfang zu realisieren, im Hinterkopf, wenn es im Folgenden nun um die Ableitung der Detailplanung geht.
Das was wir dir in diesem Artikel erzählen, ist unsere Herangehensweise und auch unsere Erfahrungen damit. Wir beginnen extra nicht mit den klassischen Methoden und der reinen Lehre, vielleicht dazu mehr in späteren Artikeln. Hier sollst du erfahren, was für uns gut funktioniert und im besten Fall, kannst du viele der Ansätze so für dich verwenden oder du passt sie auf deine Bedürfnisse an.
Was bedeutet Agil für uns?
Oft wird Agil fälschlicherweise damit gleichgesetzt, dass man nicht plant. Im Vergleich zum klassischen Wasserfall, mag das vielleicht auch so erscheinen. Das Zwiebelprinzip ( link ) ist aber nicht nur deswegen nicht mehr gültig, weil jemand jetzt Agil arbeitet. Für uns bedeutet Agil, sich an Veränderungen schnell anpassen zu können, viel zu Kommunizieren und das Erreichte selbstkritisch zu bewerten.
Was ist Wasserfall und kann ich damit nicht auch Agil sein?
Wasserfall im klassischen Sinn bedeutet, dass die Projektschritte linear, d.h. nacheinander durchgeführt werden. Analog zu einem Prozess, erst wenn der eine Schritt abgearbeitet ist, geht es zum nächsten. Eine Iteration ist nicht vorgesehen.
Der Projektplan wird somit einmal erstellt und nach einer gewissen Zeit sind alle Projektphasen durchlaufen und das Projekt beendet. Auf Änderungen wird erst am Ende reagiert, mit einem neuen Projektplan. Du kannst es dir vorstellen wie ein Zug, der auf einer Schiene dahinfährt. Nochmal, dass ist die klassische Sicht und es gibt natürlich Abwandlungen. Im Gegensatz dazu bedeutet Agil auf Änderungen zu reagieren. Nimmst du also nicht den Zug sondern das Auto, kannst du flexible deine Route anpassen und z.B. einen Stau umfahren im Gegensatz dazu der Zug, der bei einer blockierten Strecke nicht ausweichen kann.
Ganz klar, nein! Die verschiedenen Methoden sind Werkzeuge, um ein Problem zu lösen. So vielfältig die Probleme sein können, so vielfältige Lösungen braucht es auch. Wenn dein Ziel und dein Weg, um das Ziel zu erreichen unsicher sind, dann ist eine Agile Methode ggf. besser. Wenn du genau weißt, wer, was, wann zu tun hat und es darum geht, schnell und planbar das Projektziel zu erreichen, verwendest du vielleicht eine Methode, die sich am Wasserfall Prinzip anlehnt. Versuche die Methoden nicht streng zu teilen, sondern stelle dir vielmehr die Prinzipien zusammen, die auf deine Anforderungen passen. Jetzt aber zur Detailplanung.
Im letzten Arbeitsschritt hast du sowohl aus dem Brainstorming ( link ) als auch aus dem Eventstorming ( link ) viele mögliche und nützliche Features abgeleitet. Überlege dir nun, welche für deine Idee unbedingt notwendig sind. Um das zu realisieren ist es hilfreich dein Ziel so weit zu vereinfachen, dass der Kerngedanke gerade noch so erhalten bleibt. Wir zum Beispiel wollen es Menschen erleichtern open source Projekte schnell und unkompliziert zu finden. Der Kerngedanke ist das Suchen und Finden von open source Projekten. Im einfachsten Fall ist das eine Suchleiste auf einer Internetseite ( link ). Kategorisiere nun deine Features danach welche:
Klar ist, dass du Punkt 1 zuerst umsetzen musst, ohne das gibt es kein Produkt. Bei Punkt zwei ist es wichtig, dass du dir den einen Vorteil gegenüber anderen Produkten heraussuchst, der deiner Meinung nach den Nutzern am meisten Vorteil bringt. Schau dir dafür andere Produkte an, am besten nutze sie. Lies Nutzermeinungen und Forendiskussionen. Versuche ein recht genaues Bild davon zu bekommen, was deine zukünftigen Nutzer ansprechen könnte. Alles anderen Vorteile aus Punkt 2 kannst du in Punkt 3 packen und für später aufheben. Wenn du dich für das minimale Set an Funktionen entschieden hast, dann kannst du anfangen, diese Funktionen zu planen.
Wie würdest du vorgehen, wenn du mehrere Schränke von einem Raum in einen anderen bringen willst? Wenn du alleine bist wahrscheinlich, indem du die Schränke ausräumst, zerlegst, transportierst, aufbaust und wieder einräumst, ähnlich auch hier. Das große Problem, die Schränke, welche du nicht heben oder schieben kannst, in einem Stück in einen anderen Raum zu bewegen, ist aussichtslos. Du musst das Problem portionieren. Nimm dir eine Funktion aus dem vorgesehenen Funktionsumfang heraus und stelle dir die Frage, wie lange brauche ich, um diese Funktion zu entwickeln, zu testen und betriebsbereit zu bekommen. Und was denkst du? Wahrscheinlich kannst du noch keine gute Schätzung abgeben. Das zeigt dir, dass die Aufgabe noch zu groß ist. Überlege dir, welche Teilschritte du benötigst. Möchtest du beispielsweise ein Gartenhaus aufbauen, dann überlege, welche Schritte dafür notwendig sind. Du musst vielleicht eine Zeichnung erstellen, Material planen und einkaufen, ggf. musst du die Bretter zurechtsägen und so weiter. Bei jedem Arbeitsschritt versuchst du wieder den Aufwand zu schätzen. Fällt es dir leicht, dann hast du wahrscheinlich die richtige Planungstiefe erreicht. Der Sinn hinter dem Abschätzen des Aufwands ist es, dass du dir die Arbeit konkret vorstellen kannst. Um zu schätzen, wie lange eine Tätigkeit dauert musst du wissen, was dafür alles zu tun ist.
Wir bei WeValCo vereinfachen an dieser Stelle etwas. Anstelle einer genauen Zeitabschätzung bewerten wir den Aufwand nach vorher definierten Kriterien. Für uns haben sich die folgenden Zeiteinheiten gut bewährt: ein paar Stunden, ein paar Tage, mehr als eine Woche aber weniger als zwei Wochen (bei dir können diese Klassen aber auch ganz anders aussehen). Alles was über zwei Wochen hinaus geht, zerteilen wir in weitere Unteraufgaben. Wichtig ist auch, dass wir nicht den gesamten Funktionsumfang bereits zu beginn in Arbeitspakete aufteilen.
Im ersten Schritt bringen wir die einzelnen Funktionen in eine logische Reihenfolge, sofern es eine gibt. Als Beispiel, die Fenster einzusetzen, bevor eine Wand des Gartenhauses fertig gestellt wurde, ist nicht möglich. Also z.B. erst die Wand zusammenbauen, dann das Fenster fertigstellen und dann das Fenster in die Wand einbauen. Es muss diese logische Reihenfolge nicht immer geben und gerade in der Softwareentwicklung können viele Aufgaben parallel abgebarbeitet werden. Überlege dir aber auch, welche Bereiche sinnvollerweise vor anderen entwickelt werden sollten. Um z.B. Funktionalität für eine Website zu Entwicklungen, zu implementieren und zu testen, wäre es gut vorab eine Test-Website zu erstellen.
Im zweiten Schritt beginnen wir eine der Funktionen in Arbeitspakete zu zerlegen, so wie oben beschrieben. Lasten die entsprechenden Arbeitspakete uns bereits für die kommenden Wochen aus, so beenden wir die Planung. Wenn nicht, nehmen wir uns eine weiter Funktion und zerlegen diese. Für uns ist es ausreichend Arbeitspakete für die nächsten 4-6 Wochen zu erstellen. Bedenke, je weiter du in die Zukunft planst, desto wahrscheinlicher ist es, dass du die Planung wieder anpasst. Je weniger du planst, desto weniger Zusammenhänge zwischen den Arbeitspaketen fallen dir auf und du musst die Implementierung ggf. anpassen. Versuche für dich einen gut passenden Planungshorizont festzulegen, du kannst diesen individuell anpassen und jeder Zeit verändern.
Wenn du eine grobe Reihenfolge der Funktionen gefunden und genug Arbeitspakete erarbeitet hast, dann kannst du eigentlich anfangen. Es macht aber Sinn dir einen Zeitraum zu setzen, nach dessen Ende du zurückblickst und das geschaffte reflektierst. Wir machen das in sogenannten Sprints, welche eine Dauer von 2 Wochen haben. Zu Beginn eines Sprints legen wir fest, wer welche Arbeitspakete bearbeitet. Jedes Arbeitspaket ist in einer Aufwandsklasse und jede Aufwandsklasse hat Punkte. Wir haben für die Aufwandsklasse „ein paar Stunden“ einen Punkt vergeben, für „ein paar Tage“ 7 Punkte und für „zwischen 1 Woche und 2“ gibt es 20 Punkte. Pro 2 Wochen Sprint schaffen wir pro Person ca. 20 – 25 Punkte und dementsprechend viele Arbeitspakete nimmt sich jeder am Anfang eines Sprints. Diese Punkteangaben sind genau wie die Aufwandsklassen individuell und du kannst für dich ausprobieren, welche Abstufungen zu dir passen. Am Ende eines Sprints kannst du reflektieren, ob du deine gesteckten Ziele gut erfüllt hast oder nicht. Überlege dir auch, warum etwas gut oder weniger gut funktioniert hat. Sind die Arbeitspakete noch zu groß oder warst du zu optimistisch, wie viele Arbeitspakete du in deinem gesteckten Zeitraum schaffts? Iteriere dich an ein für dich passendes System. Die Reflektion am Ende eines Sprints ist dabei essenziell. Nur durch Reflektion wirst du besser in deiner Planung und effizienter in deiner Arbeitsweise. Frag dich immer: „Was lief gut und warum?“ und „Was lief schlecht und warum?“. Sei selbstkritisch aber sei auch stolz auf das, was du geschafft hast! Deine Erfahrungen mit dem aktuellen Sprint kannst du dann in die Planung des folgenden Sprints mit einfließen lassen. Hast du ein Arbeitspaket gut abschließen können, dann verwende für folgende Aufgaben mit ähnlichem Umfang einfach wieder die gleiche Aufwandsabschätzung. Hat es einmal nicht so gut funktioniert, dann passe deine Planung das nächste Mal an.
Am Ende jedes Sprints prüfen wir, ob noch genug Arbeitspakete geplant sind und planen ggf. Neue. Dann füllen wir den folgenden Sprint wieder mit Arbeitspaketen und der Zyklus beginnt von neuem.
Für die Nachverfolgung unserer Aufgaben verwenden wir Kanban. Auf einem Kanban Board siehst du z.B., welche Aufgaben du für den aktuellen Sprint geplant hast, an welchen gerade gearbeitet wird, welche fertig sind und ggf. noch mit Kollegen durchzusprechen sind und welche komplett abgeschlossen sind. Kostenfreie Kanban Lösungen findest du hier ( link ) in unserer Suche.
Den aktuellen Fortschritt der Aufgaben besprechen wir in kurzen, täglichen, Besprechungen von wenigen Minuten. So behält jeder den Überblick über die Aufgaben der anderen und kann sich schnell Rückmeldung bei Problemen holen. Beachte aber, dass es wirklich ein kurzer Austausch bleibt! Ausladente Diskussionen können im Nachgang und im kleineren Kreis geführt werden.
Auch Mia, Peter und Zou haben in den letzten Artikeln ( link ) Ideen zu ihrem Funktionsumfang erarbeitet. Zunächst möchten sie die wirklich notwendigen Funktionen beschreiben und sich auf ein besonderes Feature einigen. Für den Videochat braucht es auf jeden Fall eine Video- und Audioübertragung von mindestens zwei Teilnehmern. Einer der Teilnehmer muss die Möglichkeit haben, einen anderen einzuladen und der andere Teilnehmer muss die Möglichkeit haben die Einladung anzunehmen oder abzulehnen. Alle Arbeitspakete, die mit diesem grundlegenden Funktionsumfang zu tun haben, kategorisieren die drei mit „unbedingt notwendig“. Über die eine, herausragende Funktion, diskutieren die drei ausführlich. Zou findet eine Kontaktliste, aus der sie einen Teilnehmer auswählen kann, wichtig. Peter möchte eine Benachrichtigung auf das Handy bekommen, wenn er eingeladen wurde, um keine Einladung zu verpassen. Und Mia möchte Video-Chaträume, wo ein Thema vorgegeben werden kann und sich alle in Ihrer Gruppe zu einer bestimmten Zeit dazu austauschen können. Da die drei sich nicht sofort einig werden, lesen sie Foreneinträge und Fragen auch in ihrem Freundeskreis nach, welche Funktionen hilfreich wären und was in anderen Programmen ggf. noch fehlt. Dabei wird ihnen klar, dass sie bereits ein Alleinstellungsmerkmal haben, ihr Videochat ist open source und jeder kann diesen ganz einfach bei sich auf einem Server installieren und betreiben. Sie entscheiden sich daher alle drei Ideen für später aufzuheben und sich auf die notwendigen Funktionen zu fokussieren.
Durch das Eventstorming ( link ) haben die drei schon ein gutes Verständnis davon, wie ihr Videochat aussehen könnte. Sie spiegeln die Oberfläche an dem festgelegten Funktionsumfang und entfernen alle Interaktionsmöglichkeiten, die dafür nicht benötigt werden. Auch alle Events, die sie nicht brauchen, werden erstmal gestrichen. Die Funktionen bringen sie in eine logische Reihenfolge. Sie wollen mit Marketing und back-end Entwicklung zeitgleich beginnen. Für diese Bereiche beginnen sie die Dauer der Umsetzung abzuschätzen. Der Videochat soll als Webanwendung laufen. Dafür braucht es ein Grundgerüst der Weboberfläche, welche sie später erstellen werden. Um die Weboberfläche aufzusetzen, braucht es einen Testserver und entsprechende Möglichkeiten, Anwendungen zu starten. So denken sie sich Schritt für Schritt durch, bis sie bei planbaren Arbeitspakten für den back-end Bereich angekommen sind.
Für den Bereich Marketing will Zou mehr über ihre Zielgruppe in Erfahrung bringen. Sie möchte die Methode „Personas“ anwenden (dazu in einem späteren Artikel mehr) und dafür ist eine Recherche notwendig. Zou kann den Aufwand bereits abschätzen. In wenigen Tagen sollte sie genug Statistiken gesammelt und bewertet haben. Sie vergibt dem Arbeitspaket damit 7 Punkte. Die Methode anzuwenden braucht auch noch einmal ein paar Tage und sie vergibt wieder 7 Punkte. Das Ganze zu dokumentieren und mit den anderen Abzusprechen, schätzt sie mit einem Punkt ab.
In diesem Sinne arbeiten die drei sich durch die Bereiche back-end Entwicklung und Marketing durch. Für sie sind drei Dinge dabei immer wichtig:
Sie legen fest, was jeder in den kommenden zwei Wochen bearbeiten wird. Über den Arbeitsfortschritt möchten sie sich alle zwei Tage kurz austauschen. Damit beginnen die drei ihren ersten Sprint.
Im nächsten Artikel werden wir Zou über die Schulter schauen, wie sie die Methode der „Personas“ anwendet und was sie dabei herausfindet.
<< blogs