- Projektschätzungen oder Delegation beginnen damit, große Anfragen wie „das hier bauen“ in eine klare Aufgabenliste zu überführen; jeder Eintrag sollte die gewünschte Veränderung und den Abschlusszustand sichtbar machen
- Der Zerlegungsprozess besteht darin, ausgehend von Ideen, Skizzen oder einer ersten Liste die nötigen Schritte aufzuschreiben und jeden Eintrag rekursiv weiter zu unterteilen, bis er ausreichend definiert ist
- Das Beispiel eines Streak Trackers für Outdoor-Aktivitäten wird schrittweise in Datenmodell, Kalenderansicht, Aktivitätsaufzeichnung, Streak-Berechnung und Streak Freeze zerlegt und macht dabei auch unklare Punkte sichtbar
- Eine „ausreichend definierte Aufgabe“ ist ein Zustand, in dem man alle Fragen zu gewünschter Veränderung, fertigem Ergebnis, allen Schritten bis zum Abschluss und den für den sofortigen Start nötigen Informationen mit Ja beantworten kann
- Aufgabenzerlegung ist eine Fähigkeit, die erfahrungsbasiertes Pattern Matching erfordert; unerfahrene Teams brauchen daher sichere Übungsmöglichkeiten, um Planung zu versuchen und Feedback zu erhalten
Große Projekte in Aufgabenlisten verwandeln
- Frühere Diskussionen über Projektschätzungen gingen davon aus, dass bereits eine klare Aufgabenliste vorliegt; in der Praxis kann jedoch zunächst der vorgelagerte Schritt der Aufgabenzerlegung nötig sein
- Aufgabenzerlegung ist der Prozess, ein großes Projekt in seine Bestandteile aufzuteilen; für Schätzung oder Delegation braucht man feinere Einheiten als eine einzelne Aufgabe wie „dieses Bild bauen“
- Bei einem allein umgesetzten persönlichen Projekt kann eine Skizze ausreichen, aber wenn man etwas an andere übergeben oder die Dauer schätzen will, muss die Detailtiefe höher sein
Beispiel: persönlicher Streak Tracker
- Als Beispiel dient ein persönlicher Streak Tracker, der Tage mit Outdoor-Aktivitäten verfolgt
- Gewünscht ist etwas Ähnliches wie die App Streaks
- Es sollen Optionen für Outdoor-Aktivitäten wie Laufen, Radfahren und Skifahren enthalten sein
- Auch die Streak-Freeze-Funktion von Duolingo soll integriert werden
-
1. Durchgang: mit einer Skizze beginnen
- Ein visuelles Mockup ist ein guter Ausgangspunkt, um die zu bauenden Funktionen verständlich zu machen
- Bei einem Projekt, das man allein baut, könnte eine solche Skizze schon ausreichen, um direkt Code zu schreiben
- Wenn das Ziel Schätzung oder Delegation ist, braucht man eine feiner unterteilte Aufgabenliste als „dieses Bild bauen“
-
2. Durchgang: in große Funktionsbereiche aufteilen
- Bei der ersten Zerlegung wird das Projekt grob in Komponenten aufgeteilt
- Datenmodellierung
- Kalenderansicht, die die Daten der aktuellen Woche zeigt
- Interaktiver Kalender, in dem man durch Klick auf ein Icon eine Aktivität erfasst und den entsprechenden Tag für die Streak-Verfolgung als erledigt markiert
- Berechnung und Anzeige der aktuellen Streak-Länge
- Implementierung von Streak Freeze
- Um das Beispiel zu vereinfachen, werden operative Aufgaben wie Deployment und Datenbankeinrichtung ausgelassen
- In einem echten Projekt, insbesondere mit mehreren Beteiligten, wäre es sinnvoller, Deployment-, Frontend- und Backend-Arbeiten als eigene Punkte aufzuteilen
- Schon auf dieser Ebene ist eine gewisse Schätzung möglich, aber es bleiben Unsicherheiten etwa zur Anhäufung und Nachverfolgung von Freezes, zu historischen Einträgen sowie zum Hinzufügen und Löschen von Aktivitätstypen
-
3. Durchgang: weiter aufteilen, damit Abschlusskriterien sichtbar werden
- Das Datenmodell wird in Aktivitätstypen, aufgezeichnete Aktivitäten, Freezes und Streaks aufgeteilt
- Für Aktivitätstypen reicht eine hartcodierte Liste wie run/bike/ski/climb
- Aufgezeichnete Aktivitäten haben ein Datum und einen Typ
- Freezes haben ein Erwerbsdatum und ein Nutzungsdatum
- Streaks haben ein Startdatum, ein Enddatum und aggregierte Informationen je Aktivitätstyp
- Die statische Kalenderansicht wird in Wochenansicht, Startbildschirm, Monatsansicht, Navigation und Eingabe zum Wechseln des Datums aufgeteilt
- Für den Datumswechsel kann ein HTML5-Date-Widget verwendet werden, ohne komplexe Fuzzy-Date-Eingaben
- Der dynamische Wochenkalender fügt der Monatsansicht keine dynamische Eingabe hinzu, sondern erfasst einen Abschluss durch Klick auf einen Aktivitätstyp an einem bestimmten Datum
- Berechnung und Anzeige von Streaks durchlaufen die Aktivitätsaufzeichnungen, berechnen den Streak, zeigen den aktuellen Streak in der UI an und berechnen ihn erneut, wenn in der UI eine Aktivität erfasst wird
- Streak Freeze umfasst das Ansammeln, das Verhindern doppelter Ansammlung sowie die Nutzung und Anzeige der verbleibenden Anzahl in der UI
- Die X Tage als Kriterium zum Erwerb eines Freeze können zunächst hartcodiert werden
- Freezes können in den nächsten Streak übertragen werden
- Wenn vergangene Aktivitäten geändert und Streaks neu berechnet werden, muss eine doppelte Ansammlung von erneut erhaltenen Freezes verhindert werden
Ein wiederholt anzuwendender Zerlegungsprozess
- Aufgabenzerlegung ist kein Entwurf, der in einem Durchgang abgeschlossen ist, sondern ein iterativer Prozess
- Man beginnt mit einer Aufgabenliste oder einem einzelnen großen Projekt
- Man überlegt und notiert die Schritte, die nötig sind, um diese Aufgabe abzuschließen
- Man prüft, ob jeder Schritt ausreichend definiert ist
- Wenn nicht, zerlegt man diesen Eintrag erneut
- Jede Iteration muss nicht vollständig oder exakt sein; es reicht, wenn sie die vorherige Liste zumindest ein wenig erweitert
- Derselbe Prozess wird wiederholt, bis alle Aufgaben ausreichend definiert sind
Kriterien für „Aufgabe“ und „ausreichend definiert“
- In Softwareentwicklung und Projektschätzung ist eine Aufgabe eine ausreichend definierte, vollständige Arbeitseinheit, die eine Veränderung liefert
- „An Zeug arbeiten“ ist keine Aufgabe, weil es keinen Umriss der Anforderungen gibt
- „Einen Baum fällen“ ist keine vollständige Aufgabe, wenn man nur die Kettensäge mitgebracht hat
- Im Arbeitskontext ist eine Aufgabe nur sinnvoll, wenn nach ihrer Ausführung etwas anders ist
- Ob eine Aufgabe ausreichend definiert ist, beurteilt man danach, ob die ausführende Person alle folgenden Fragen mit „Ja“ beantworten kann
- Verstehe ich, welche Veränderung gewünscht ist?
- Verstehe ich, wie „fertig“ aussieht?
- Kann ich alle Schritte definieren, die bis zum Abschluss nötig sind?
- Habe ich, sofern es keine Blocker oder Abhängigkeiten gibt, alle Informationen, die ich brauche, um sofort zu beginnen?
- Je nach organisatorischem Kontext müssen möglicherweise auch Beobachter wie Projektmanager, wichtige Stakeholder oder Auditoren diese Fragen mit „Ja“ beantworten können
- Es gibt auch Aufgaben mit Unbekannten, die sich kaum weiter unterteilen lassen, etwa Bugfixes
- In solchen Fällen kann man Techniken wie Timeboxing verwenden
Ein Zerlegungsgefühl, das durch Erfahrung entsteht
- Aufgabenzerlegung ist eine Fähigkeit, die Übung erfordert, und es ist normal, dass sie sich am Anfang nicht leicht anfühlt
- Dass im Beispiel die Datenmodellierung zuerst kommt, ist kein klarer Algorithmus, sondern eine erfahrungsbasierte Intuition
- Es gibt die Erfahrung, dass ähnliche Tools besser gelingen, wenn man zuerst das Datenmodell festlegt
- Django bietet Affordances, die besser zu einem Modell-Daten-zuerst-Ablauf passen
- Wenn man noch nicht viele Projekte gesehen oder umgesetzt hat, kann es schwer sein, den Ausgangspunkt zu bestimmen
- Damit ein Team diese Fähigkeit entwickeln kann, braucht es einen sicheren Rahmen, in dem es Projektpläne erstellen, sie zerlegen und Feedback erhalten kann
- Wenn frühe Pläne stark danebenliegen, aber nicht bestraft werden, werden diese Fehler zu Erfahrungsdaten, die beim nächsten Pattern Matching genutzt werden
Schätzergebnis des Beispielprojekts
- In der Bonus-Schätzung werden nach der Zerlegung der Aufgaben Komplexität, Unsicherheit, erwartete Tage und Tage im Worst Case ergänzt
- Die Gesamtschätzung wird mit 15,5 Tagen, der Worst Case mit 23,5 Tagen berechnet
- Unter den wichtigen Punkten haben Streak-Berechnung und Freeze-Ansammlung jeweils mittlere Komplexität und moderate Unsicherheit, mit einer Schätzung von je 3 Tagen und 4,5 Tagen im Worst Case
- Die Verhinderung doppelter Freeze-Ansammlung hat geringe Komplexität, aber extreme Unsicherheit und wird mit 1 Tag erwartet sowie 5 Tagen im Worst Case angesetzt
- Tatsächlich wurde das Projekt in etwa zwölf Abenden und einem langen Flug fertiggestellt, allerdings wurde das Design stark ausgelassen, und im Freeze-Algorithmus könnten Bugs stecken, die erst später auftauchen
1 Kommentare
Hacker-News-Kommentare
Erstens habe ich die tatsächlichen Schritte fast nie wie geplant bis zum Ende ausgeführt. Schon nach ein paar Schritten erkennt man etwas Neues, entdeckt etwas Übersehenes oder sieht einen einfacheren Weg, und dann folgt man dem Plan nicht mehr.
Zweitens habe ich das Gefühl, dass sich die gesamte kreative Anstrengung, darüber nachzudenken, wie man etwas baut, an den Anfang verlagert, und deshalb arbeite ich ungern so. Der Rest ist immer noch der Großteil der Arbeit, aber übrig bleibt nur der langweiligste Teil; es ist interessanter, Kreativität und Langeweile gleichmäßiger zu mischen, dadurch geht es schneller und das Ergebnis wird besser.
Beides hängt vermutlich zusammen, und ausgeschlossen ist auch nicht, dass ich ADHS habe.
Wenn man ein eigenes Projekt erkundet oder baut und es keine besondere Verantwortungsstruktur gibt, muss man nicht so weit planen, es sei denn, man mag Planung an sich.
Aber sobald der Chef fragt: „Wie lange dauert das? Wer macht was? Wo fangen wir an?“, braucht man irgendeinen Rahmen.
Ich hasse es auch, mich an willkürliche oder übermäßig starre Systeme anzupassen, aber Systeme sollten einfach und flexibel sein, und Produktivitätssysteme sind dafür da, Menschen zu helfen.
Ich glaube nicht, dass der Autor das als detailliertes Kochrezept gemeint hat, sondern eher seinen Ansatz zeigen wollte, damit andere daraus eigene Ideen entwickeln können.
Manchmal ist es sogar schlimmer als „Der Plan wird nie genau befolgt“. Wenn man während der Umsetzung ständig Aufgaben hinzufügt, bleibt am Ende nur eine unübersichtliche Liste unerledigter Aufgaben übrig, die mit den beim Planen erstellten Aufgaben vermischt ist und nicht mehr gebraucht wird.
Denn solche Aufgaben wurden ohne den Gesamtkontext erstellt, der erst während der Umsetzung entsteht.
Der Reiz des Programmierens liegt darin, dass es eine flexible, fließende, kreative Tätigkeit ist. Man gestaltet sie im Vorangehen und erlebt sie organisch.
Im Arbeitsumfeld wird diese organische Qualität meist entfernt, weil Überwachung und Verantwortlichkeit nötig sind.
Wenn man das nächste Mal dieselbe oder eine ähnliche Arbeit plant, wird der künftige Plan besser.
Auch Projektmanager haben den Leitspruch: „Wer an der Planung scheitert, plant das Scheitern.“
Denn ich merke oft, dass ich unter den vielen Dingen, an die ich denken muss, einiges übersehe.
Ein Plan ist nur eine Möglichkeit, meinem zukünftigen Ich das ideale Ergebnis in Erinnerung zu rufen, das mein früheres Ich im Sinn hatte — statt endlos den Plan zu ändern und Glühwürmchen hinterherzujagen.
„Arbeit aufteilen“ ist ein so großes Thema, dass es ein eigenes Buchgenre oder Podcast-Genre sein könnte. In Büchern über Selbstverbesserung oder Organisation wird die Tätigkeit, Arbeit aufzuteilen, oft so behandelt, als sei sie eine ursprüngliche menschliche Fähigkeit, die Leser bereits besitzen.
Nach meiner Erfahrung und dem, was ich in Gruppensitzungen gehört habe, ist das Aufteilen von Arbeit jedoch sehr schwierig und kann Vermeidungsgefühle oder Verzweiflung auslösen.
Der am breitesten anwendbare Rat, den ich gesehen habe, lautet: Teile die Aufgabe immer weiter auf, bis du 90 % sicher bist, dass du sie erfolgreich abschließen kannst. Dieses Sicherheitsniveau hängt vom Selbstvertrauen und der Risikobereitschaft ab; manche Menschen teilen vielleicht nur bis zu einer Erfolgswahrscheinlichkeit von etwa 70 % auf.
Pro Tag hat man ungefähr 6 Stunden nutzbare Zeit, und wenn jemand selbstbewusst sagt, es dauere „einen halben Tag“, und man darauf hinweist, dass das etwa 3 Stunden sind, wird er plötzlich viel weniger sicher oder verärgert. Und drei Tage später arbeitet er immer noch daran.
Diese Methode war bei Zeitschätzungen überraschend genau, allerdings in der Summe; einzelne Schätzungen lagen deutlich daneben.
Letztlich ist es eine Wahrscheinlichkeitsschätzung. Über viele Ereignisse hinweg konvergiert sie zum Durchschnitt.
Das Problem, das die meisten nicht kennen, ist, dass Softwareentwicklung vor allem einer kreativen Tätigkeit ähnelt. Natürlich gibt es ernsthafte technische Aspekte, aber weil das Problem selbst virtuell ist und nicht wie im Bauingenieurwesen an reale Beschränkungen gebunden ist, gibt es nicht die eine optimale Lösung.
Wenn man versucht, die Lösung zu definieren, bevor man das Problem richtig untersucht hat, beschränkt man nur das Endergebnis. Der Großteil der Erkundung geschieht tatsächlich erst, nachdem man mit dem Coden begonnen hat.
In Software ist es nicht so wichtig, dass Endergebnis und Zeit nicht klar definiert sind, weil es keine Kosten pro Einheit gibt. Manager ohne Hintergrund in Software Engineering verstehen das oft nicht.
Ein allgemein nutzbares Produkt kann ohne zusätzliche Entwicklungskosten an mehrere Kunden verkauft werden.
Weil die meisten Unternehmen jedoch wie Fabriken geführt werden, erzeugen alle Prozesse am Ende ein sehr eingeschränktes Produkt für einen bestimmten Kunden. Genau das haben die großen Tech-Unternehmen vermieden.
Die ganze Branche scheint dieses Muster übernommen zu haben.
Aber ehrlich gesagt glaube ich, dass die meisten von uns eher dadurch blockiert werden, dass uns die Fähigkeit fehlt, genau das nicht zu tun. Wenn man etwas bauen will, sollte man nicht alle Teile planen, sondern einfach das kleinste Ding bauen, das potenziell Wert hat.
Im Beispiel würde man mit dem „Heute“-Bildschirm und vier Buttons anfangen. Man könnte heute eine Ansicht bauen, die vier Trainingsbuttons zeigt, die man jeden Tag drücken kann. Streaks, Freezes und Kalenderansicht braucht man nicht.
Diese Ideen sind alle gut und kommen später dran, aber zuerst braucht man Schwung. Ein paar Tage später entscheidet man vielleicht, dass einem diese Kalenderansicht gar nicht gefällt.
Mehr Projekte brauchen dieses Drängen im Sinne von „mach es einfach, selbst wenn es nur klein ist“. Bring es heute fertig und schau an diesem Punkt, was die nächste Aufgabe ist. Es ist sehr wahrscheinlich, dass sie sich von dem unterscheidet, was man in der Planungsphase gedacht hatte.
Natürlich ist auch das nicht einfach. Das Kleinste zu finden und sich fest vorzunehmen, es ohne Ablenkung zu veröffentlichen, erfordert Nachdenken und Disziplin. Trotzdem lohnt es sich, das zu üben.
Es ist das Prinzip, sich angesichts von Unsicherheit auf „das nächste Richtige, das zu tun ist“ zu konzentrieren [0].
Das soll nicht abwertend gemeint sein. Herauszufinden, was als Nächstes das Richtige ist, ist schwierig und aus meiner Sicht der wertvollste Teil der Planung.
0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
Zum Beispiel erstellt eine Person eine Vergleichsmethode für Tests, eine andere probiert einen Ansatz aus, eine weitere einen anderen Ansatz und eine dritte noch einen weiteren; nach einem festgelegten Zeitraum wird alles bewertet.
Natürlich ergibt das nur Sinn, wenn es nicht bereits einen bevorzugten oder offensichtlich überlegenen Ansatz gibt.
In der tatsächlichen Entwicklung kann Modularisierung eine Methode der Parallelisierung sein. Etwa so, dass jede Person oder jedes Team eine Komponente übernimmt.
In meiner Arbeit wechsle ich besonders dann, wenn ich die Richtung noch auslote, gern zwischen den menschenzugewandten Teilen und dem technischen Innenleben. Wenn man nur die Technik entwickelt, ohne die Nutzung zu kennen, wird die nutzbare Form in eine bestimmte Richtung gezwungen; aber auch ein Interface zu entwerfen, ohne die Technik zu kennen, hat seine Fallen.
Aber bei Aufgaben, die wie Forschung kreative Experimente und einen Proof of Concept erfordern, um etwas im Voraus Unbekanntes zu prüfen, bricht die Arbeitszerlegung selbst zusammen.
Deshalb habe ich mir angewöhnt, den Großteil meiner Proof-of-Concept-Arbeit nicht öffentlich zu machen und niemandem davon zu erzählen.
Wenn es klappt, kann man es veröffentlichen; wenn nicht, kann man es verwerfen und weitermachen, ohne das Gesicht zu verlieren oder gesagt zu bekommen, man solle es irgendwie zum Laufen bringen, obwohl bereits klar ist, dass man nicht weitermachen sollte.
Man sagt einfach: „Wir verwenden 3 Stunden auf die Untersuchung von X, 3 Stunden auf Y und 3 Stunden auf Z und machen danach ein Planungsmeeting, was als Nächstes zu tun ist.“
Es gibt vier Ergebnisse: Das erste löst es, das zweite löst es, das dritte löst es, oder keines löst es.
Wenn es ein Problem ist, das sich mit etwas Aufwand lösen lässt, liegt die Wahrscheinlichkeit, es beim zweiten Versuch, also innerhalb von 6 Stunden, zu lösen, bei 50 %.
Und irgendwann muss man es einfach tun.
Arbeitszerlegung und Schätzung sind fast dasselbe. Wenn die Zerlegung erledigt ist, haben Menschen mit ein paar Jahren Erfahrung Standardschätzungen für kleine Aufgaben, sodass es nur ein paar Minuten dauert, jedem Teil eine Schätzung zuzuweisen.
In meinem Fall zerlege ich Arbeit in Einheiten, die ich schätzen kann, und hole mir für die Teile, die ich nicht schätzen kann, die Meinung anderer ein.
Allerdings glaube ich nicht, dass der eigentliche Weg zur Meisterschaft in der Arbeitszerlegung liegt. Jede und jeder kann eine schlechte Zerlegung erstellen.
Die eigentliche Meisterschaft liegt darin, zu erkennen, wann die Evidenz zeigt, dass diese Arbeitszerlegung so falsch ist, dass sie Probleme verursacht, und das zu kommunizieren oder neu zu schätzen [0].
Wichtig ist außerdem, gelassen zu akzeptieren, dass so etwas passieren wird, und sich nicht davon stressen zu lassen, von Anfang an einen Zeitplan vorzulegen, der sich wahrscheinlich ändern wird.
Manager wollen normalerweise von Anfang an eine genaue Roadmap, aber damit verlangen sie etwas Unmögliches. Gutes Management liegt aus meiner Sicht in Flexibilität und darin, zu verstehen, dass sich die Natur der erwarteten Arbeit im Lauf der Zeit verändert, während Entwickler dazulernen.
Auch das kleine Beispiel am Ende des Textes ist bedenkenswert. Selbst wenn jemand eine genaue Schätzung abgegeben hätte, nämlich „das ist nach ein paar Abendessen während Flugreisen erledigt“, hätte er es als zu riskant abgelehnt.
Das zeigt, dass Schätzung nicht nur eine Frage der Genauigkeit ist. Es gibt dabei viele Faktoren, die sich mit Begriffen wie Risikomanagement, Erwartungsmanagement und Vertrautheit mit der Aufgabe nicht vollständig ausdrücken lassen.
[0] https://jacobian.org/2021/jun/8/incorrect-estimates/ – dazu gibt es auch einen Beitrag.
Das sind gute neue Software-Fachkräfte, aber manchmal ist der Bereich für sie neu und sie wissen wirklich nicht, wie man grundlegende Funktionen aufbaut. Meiner Erfahrung nach wollen sie Aufgaben, an denen sie lernen und die sie gut bewältigen können, und genau das führt zu Wachstum.
Man muss unbedingt im Kopf behalten, dass Prozesskosten ein Kontinuum sind, das an das Team angepasst wird. NBA-Spieler lernen während des Spiels nicht im Huddle, wie man den Ball wirft, aber Drittklässler tun das.
Beide Arten von Planung und Coaching sind dann angemessen, wenn sie zum jeweiligen Team passen.
Vielleicht ist genau das die zentrale Wahrheit der Softwaretechnik. Vielleicht gibt es bereits eine Open-Source-Version der Streak-App, die der Autor bauen will, und er erfindet das Rad neu.
Das Gehirn scheint keine Aufgabenlisten zu mögen. Listen zu erstellen kann Spaß machen, aber der Großteil von Gründen oder Programmieren ist Exploration.
Und Aufgabenlisten verhindern Exploration.
Wenn nicht: Was ist bei Softwareentwicklung anders, sodass „weiß ich nicht“ in unserem Beruf eine vernünftige Antwort ist?
Manchmal ist das richtig, manchmal nicht. „Die Karte ist nicht das Gelände“.
Um Arbeit in kleinere Aufgaben zu zerlegen, muss man doppelte Arbeit leisten, und der Trick besteht darin, sie zu minimieren.
Wenn man überhaupt keine unnötige Arbeit machen will, muss man am Ende alles auf einmal erledigen.
Nehmen wir zum Beispiel an, man refaktoriert ein Programm mit den Modulen A und B, wobei B von A abhängt. Der Weg mit der geringsten Verschwendung ist, beide Module gemeinsam zu refaktorieren. Aber das ist auch der riskanteste und am schwersten zu schätzende Weg.
Die Aufteilung bestand darin, A zu refaktorieren und B so anzupassen, dass es mit dem refaktorierten A funktioniert. Wenn man danach A erneut refaktoriert, besteht die Gefahr, dass die zuvor geleistete Anpassungsarbeit schnell weggeworfen wird
Wenn man vermeiden will, dass Wegwerfarbeit entsteht, lässt sich Arbeit oft nicht aufteilen. Selbst mit 20 Jahren Erfahrung zögere ich noch immer häufig, temporäre Arbeit zu machen, die später verworfen wird, nur um Arbeit aufzuteilen
Stattdessen läuft es oft darauf hinaus, dass ich an einer mehrwöchigen Aufgabe arbeite und dabei alle Yak-Haare abrasiere, ohne ein einziges übrig zu lassen
Es ist sinnvoll, vor dem Start über das zu lösende Problem nachzudenken, und grobe Meilensteine sind ebenfalls wichtig. Aber meistens gibt es so viele unbekannte Unbekannte, dass eine vollständige Aufteilung völlig nutzlos oder unmöglich ist
Ich habe das Gefühl, dass es viel schneller gegangen wäre, wenn man die Zeit, die für die Aufteilung eines Projekts draufgeht, einfach darauf verwendet hätte, eine Lösung zu finden oder zu bauen. Zumindest fühlt es sich so an
Ich gehe meistens anders heran. Es geht darum, den Aufwand abzuschätzen, um überhaupt zu entscheiden, ob man etwas bauen sollte oder nicht. Anders gesagt: Der erste Grund ist, bei einer Kosten-Nutzen-Abwägung zu helfen
Auch für das Team kann das sehr nützlich sein. Besonders wenn man mit weniger erfahrenen Leuten arbeitet, kann man Arbeit stark aufteilen und parallelisieren
Jacob hat bei der Implementierung seiner Streak-App vermutlich auch nicht so stark zerlegt, und deshalb scheint er zur Erklärung rekursiv Beispiele angeführt zu haben
In solchen Fällen war es nützlich, es in kleinere Aufgaben zu zerlegen und sie nacheinander abzuschließen. So entsteht selbst dann Fortschritt, wenn man feststeckt oder keine Lust zu arbeiten hat, und dieser Fortschritt erzeugt Schub, um weiterzumachen
Es hat eindeutig auch Wert, wenn Manager die Geschwindigkeit abschätzen können. Das Problem ist nur, dass sie, sobald sie auf den Geschmack gekommen sind, wirklich nicht mehr verstehen, was „unsicher“ bedeutet
Ich bin selbst Berater, und selbst wenn wir „agil“ arbeiten, ist es sehr wichtig sagen zu können: „Wir liefern das innerhalb dieser Zeit.“