Eine flexible Entwicklungsmethode ist eine großartige Idee, die zu kompliziert ist. Agile Lite ist ein Versuch, die Situation zu vereinfachen. Sie benötigen keine Bücher oder Seminare, um Agile Lite zu erklären. Es wird nur ein kleiner Text mit wenigen Punkten benötigt. Hier ist der Text.

Agile Lite ist ziemlich einfach. Es kann auf jedes Projekt angewendet werden, vorausgesetzt, die Arbeit ist in kleinere Aufgaben unterteilt (Problem). Wie andere agile Methoden verwendet es kurze Entwicklungszyklen - Sprints. Im Gegensatz zu ihnen erkennt Agile Lite jedoch die Prävalenz von Burnout in der Softwareentwicklungsbranche deutlich und versucht, diese durch die Einführung eines dreiwöchigen Entwicklungs- / einwöchigen Ruhezyklus direkt zu mindern.

Grundregeln:

• In der ersten Woche jedes Zyklus bestimmen Projektmanager, Entwickler und andere Interessengruppen den bevorstehenden Sprint. Obwohl eine Woche vorgesehen ist, dauert die Sprintplanung nicht länger als zwei Stunden, und mit der richtigen Organisation dauert sie ungefähr 45 Minuten. Dies ist eine absichtlich einfache Woche: Viele können einfach Urlaub machen, um zu surfen, zu malen oder etwas anderes.
  
• Der Sprint läuft über die verbleibenden drei Wochen. Während dieser Zeit arbeiten die Ingenieure an den Aufgaben, die ihnen bei der Planung zugewiesen wurden. Da Mitarbeiter remote und über Zeitzonen verteilt sein können, sind Live-Meetings nicht häufig und der Großteil der Kommunikation erfolgt über einen Tracker (der schneller als E-Mail funktioniert). Ein gewöhnliches Kanban-Board wie Trello ist in Ordnung, und eine Tabellenkalkulation ist unwahrscheinlich. Tägliche Segelflugzeuge werden nicht empfohlen: Der Gesamtimpuls des Projekts wird vollständig durch Tracker-Updates verfolgt.
  
• Nach dem Start des Sprints können Sie dem Sprint keine Aufgaben hinzufügen, aber Sie können sie löschen. Dies reduziert die Kontextumschaltung, was gut ist.
  
• Unvollendete Aufgaben werden bei der nächsten Sprint-Planungssitzung berücksichtigt. Es wird beschlossen, die Aufgabe in den nächsten Sprint zu verschieben, sie wieder auf die Wunschliste zu setzen oder sie einem anderen Entwickler zuzuweisen.
  
• Jede Aufgabe steht entweder auf der Wunschliste oder im aktuellen Sprint. Jede Aufgabe sollte 4-8 Stunden dauern.
  
• Wie bereits erwähnt, wird Entwicklern empfohlen, sich während der Planungswoche auszuruhen, damit sich das Gehirn vom vorherigen Sprint erholt. Dies ist kein Kreuzzug. Entwickler arbeiten nicht am Wochenende. All dies hilft, Burnout zu vermeiden, was für alle nützlich ist.

Obwohl die Hauptarbeit im Sprint geplant werden kann, passiert manchmal etwas Unerwartetes. Diese unerwarteten Probleme werden als Support-Probleme bezeichnet.

Während der Sprintplanung empfehlen wir, Zeit für die Lösung von Supportaufgaben vorzusehen, die für die Planung nicht zugänglich sind. Beispiel: "Während des nächsten Sprints hat Dave 12 Stunden Zeit, um Support-Aufgaben zu lösen (Details dazu werden später festgelegt)." Es ist oft nützlich, die Rotation beizubehalten, wenn sich die Entwickler, die für Supportprobleme verantwortlich sind, bei jedem Sprint ändern.

Um die Genauigkeit der Prognose zu verbessern, wird bei jeder Sprint-Planungssitzung der Umfang der im vorherigen Sprint tatsächlich geleisteten Supportarbeit analysiert und entschieden, ob die Unterstützung des nächsten Sprints mehr oder weniger Zeit in Anspruch nimmt.

In der Praxis haben verschiedene Gruppen unterschiedliche Definitionen für Supportaufgaben. Vielleicht bedeutet dies Kunden- / Kundenunterstützung. Vielleicht die Unterstützung anderer Entwickler. Es liegt an Ihnen, zu entscheiden, welche Elemente dieser allgemeinen Methodik für Ihr Team am besten geeignet sind.

Durch die Beseitigung unnötiger Komplexität ist Agile Lite die beste und nachhaltigste Methode zur Entwicklung von Software. Es hilft bei der Entwicklung und gewährleistet gleichzeitig ein konstant hohes Produktivitätsniveau.

Agile Lite für Entwickler

Wenn Sie nicht neu in der Branche sind, haben Sie möglicherweise Burnout erlebt. Es hat viele Gründe, aber der einfachste Weg, Burnout zu beschreiben, ist das Ergebnis, wenn man zu lange unter zu viel Stress zu hart arbeitet.

Alles beginnt mit einem Projekt. Jedes Projekt hat eine detaillierte Spezifikation und Frist. Wenn sich die Spezifikation ändert, ist die Frist nicht. Am Ende kommt die Frist und die Spezifikation hat sich zu etwas anderem entwickelt, als sie begonnen hat. Dies wird natürlich als Ihre Schuld angesehen, und Sie werden gebeten, bis spät zu bleiben oder „das Ziel zu strecken“. Infolgedessen arbeiten Sie jedes Wochenende, aber unabhängig von Ihren Bemühungen ist der Manager immer unzufrieden und das Projekt ist ständig „hinter dem Zeitplan“.

Wenn Sie Urlaub machen möchten, werden Sie wie ein Faulenzer erscheinen, der das Team nicht unterstützt. Möglicherweise arbeiten Sie in einem offenen Büro. Jeder weiß, wann jemand kommt und geht, und jeder unterschreibt einen unausgesprochenen Vertrag, um nicht weniger als andere zu arbeiten. Daher wissen die Leute, wie man beschäftigt aussieht. Wenn jemand fragt, wie es Ihnen geht, antworten Sie einfach: „Beschäftigt! Ich bin so beschäftigt! "

Aber am Ende passiert etwas. Sie können den Job wechseln, dies sind jedoch normalerweise andere Unternehmen in der Softwareindustrie. Vielleicht geben Sie Ihre ganze Kraft, um die Verwüstung zu vervollständigen, und dann lässt Sie das Unternehmen los, weil Sie bereits "nicht zur Kultur passen". Vielleicht beenden Sie den Handel mit Autos, weil das Programmieren zu frustrierend ist. Wie das Sprichwort sagt, wenn Sie das Vergnügen eines Hobbys verlieren möchten, versuchen Sie, Geld damit zu verdienen.

Ich biete eine Lösung an. Dies ist eine agile Form, die eindeutig darauf ausgelegt ist, Burnout zu vermeiden: Agile Lite. Es gibt keine Überstunden. Die technischen Arbeiten laufen auf Hochtouren, und die Entwickler haben genügend Zeit, um ihr Gehirn aufzuladen. Der Verwaltungsaufwand ist minimal.

Fast das gesamte System ist in den sechs obigen Punkten beschrieben. Es kann entsprechend Ihren Zielen geändert werden. Ich möchte jedoch eine Funktion von Agile Lite hervorheben. Hier sagen wir ausdrücklich: „Hey, flexible Teams brennen genauso aus wie bei anderen Entwicklungsmethoden. Es kann sich lohnen, explizite Regeln aufzuschreiben, um eine Überhitzung des Motors zu verhindern. Dies ist das Engineering-Team. “

Hören wir auf, die Motoren zu überhitzen. Wir haben viel Arbeit. In der Tat ist dies eine Grube ohne Boden. Aber das Leben ist zu kurz, um es vollständig für Arbeit, Stress und letztendlich Burnout auszugeben.

Agile Lite für Manager

Hatte Ihr Unternehmen Probleme mit Entwicklern? Haben Projekte oft Termine verpasst? Haben Sie mit Entwicklern zusammengearbeitet, die perfekt starten, sich dann langsam verschlechtern und dann verschwinden? Vielleicht ist dies ein talentierter Programmierer, der Burnout erlebt hat.

Burnout ist in der Softwareindustrie sehr verbreitet und ein Hauptgrund, warum viele Softwareprojekte fehlschlagen. Burnout kann am besten als Symptom einer posttraumatischen Belastungsstörung beschrieben werden, die mit einem bestimmten Projekt oder einer bestimmten Organisation verbunden ist. Zum Beispiel scheint sich das Gehirn auszuschalten und Sie verspüren extreme Angst bei der bloßen Erwähnung eines bestimmten Projekts. Das ist Burnout. Ein Entwickler in diesem Zustand kann höchstwahrscheinlich nicht weiter an diesem Projekt arbeiten, und in nachfolgenden Projekten kann er nicht mit voller Kraft arbeiten. Burnout kann eine Karriere lähmen.

Dies ähnelt dem Betrieb eines Automotors bei hohen Drehzahlen über einen sehr langen Zeitraum ohne Öl- oder Kraftstoffzusatz. Am Ende fällt dieser Motor aus und es wird schwierig sein, ihn wieder zusammenzubauen.

Die Grundprinzipien von Agile Lite sind oben beschrieben und können sich je nach Ihren Zielen ändern.

FAQ + typische Aussagen

Die einzige allgemeine Regel in der Welt der agilen Entwicklung ist, dass jeder es falsch macht. @fwip

Ingenieure haben also 12 Wochen pro Jahr frei zum Surfen und Malen? Wie wird dies in einer Welt funktionieren, in der die Arbeit von 9 bis 21 Uhr an sechs Tagen in der Woche zur Norm wird?

Ich denke, Ihre Entwickler sollten sich so viel ausruhen, wie sie brauchen.

Ich stelle fest, dass die 40-Stunden-Woche einst als radikale Idee galt. Google begann mit 80% der Arbeitszeit für Großprojekte, jetzt haben wir 75%. Ich möchte sie bis Ende der 2020er Jahre auf 10% (Ferris-Methode) reduzieren.

Das System 996 (von 9 bis 21 Uhr an 6 Tagen in der Woche) ist der umgekehrte Ansatz, mit dem versucht wird, die 40-Stunden-Woche auf eine 72-Stunden-Woche zu verlängern. Ich sehe dies als eine Regression und ich denke, wir sollten aufhören, Überstunden zu fetischisieren. Tatsächlich erhöht es nicht die Produktivität.

Darüber hinaus entscheiden Sie selbst, was Sie während der "Ruhewoche" tun möchten: Urlaub machen, eine geringere Arbeitsbelastung zuweisen oder etwas anderes. Die Antwort kann von der jeweiligen Woche abhängen.

Vielleicht ist „einfache Woche“ für Menschen einfacher als „Woche der Ruhe“. Verwenden Sie, was für Sie bequemer ist.

Surfen und Malen sind keineswegs obligatorisch, sie dienen lediglich als Beispiele. Ich selbst surfe und male nicht einmal.

Werden den Personen Aufgaben zugewiesen oder sagen sie selbst voraus, was sie erhalten werden?

Sie sagen voraus. Es ist in Ordnung, wenn Ihre Schätzungen falsch sind. Dies ist Teil des Prozesses und alles in einem Team.

Könnte man es Iterationen anstelle von Sprints nennen?

Natürlich! Sprint ist richtig für mich.

Ist es möglich, eine gleitende Iteration im Kanban-Stil durchzuführen, bei der Start- und Enddatum variieren und von den Umständen abhängen?

Ich schätze das Konzept eines Arbeitszyklus mit bestimmten Start- und Enddaten, der durch einen Aufgabenblock definiert wird, sehr. Gleitende Iterationen, die nicht mit einer bestimmten Schleife synchronisiert sind, ruinieren diese.

Warum genau drei Wochen Sprints?

Weil Entwicklung plus Erholung in 13 Slots pro Jahr platziert wird. Wenn der Zyklus abgeschlossen ist, beginnt ein neuer. Eine Woche "Ruhe" ermöglicht es Ihnen, vor dem Start eines neuen Sprints neu zu starten. Es geht darum, eine Trittfrequenz und klare, konsistente Intervalle zu erreichen.

Bedeutet dies, dass das Start- und Enddatum von Sprints häufig in der Mitte des Kalendermonats liegt?

Ja

Sind Entwickler an der Sprintplanung beteiligt?

Ja Es ist ihnen nicht verboten, an dem Treffen teilzunehmen. Dies ist einfach nicht erforderlich, insbesondere wenn der Task-Tracker gut funktioniert und das Team einige der Punkte für den nächsten Sprint während des vorherigen Sprints besprochen hat.

Ich bin für weniger Treffen. Nur wenige Leute mögen sie. Wenn Sie einer von denen sind, dann zählen Sie nicht auf mich.

Dauert die Planung eines Sprints eine Woche?

Nein, das ist der Punkt. Dies ist eine einfache Woche.

Sind Stand-Ups wirklich ein Problem?

Nach meiner Erfahrung ja. Normalerweise steht jeder im Kreis und hört 20 Minuten lang einer Person zu. Natürlich ist dies der „falsche“ Ansatz, aber ich habe noch nie jemanden gesehen, der es richtig gemacht hat, und würde es vorziehen, die täglichen Segelflugzeuge ganz aufzugeben. Noch schwieriger (oder zumindest unpraktischer), wenn Ihr Team geografisch verteilt ist. Aber wenn sie für Sie sehr wertvoll sind, lassen Sie sich nicht von mir aufhalten.

Sollen wir es so machen?

Nein. Niemand zwingt dich zu irgendetwas. Dies sind Empfehlungen, keine Regeln.

Dies ist keine Religion.

Diese Regeln sind nur in dem Sinne politisch, in dem die Propaganda der 40-Stunden-Woche politisch war.

Was für Sie funktioniert, funktioniert möglicherweise nicht für andere. Weißt du davon?

Da bin ich mir sicher!

Häufige Ansprüche

Sie müssen keine Vorhersagen zum Zeitpunkt treffen, da Schätzungen nicht möglich sind.

Prognosen gelten als Prognosen, nicht als blutunterzeichnete Verträge. Wenn sie nicht eingehalten werden, ist dies daher normal. Machen Sie alle Anstrengungen und versuchen Sie, eine Prognose in Schritten von 4 Stunden zu erstellen.

Entwicklern kann man nicht vertrauen, und Sie müssen ihre gesamte Zeit im Auge behalten, denn so wird die Arbeit erledigt.

Ich bin wirklich anderer Meinung, kann aber nicht schnell erklären, warum. Wir haben grundlegende Unterschiede in der Weltanschauung.

Das ist nicht agil.

Natürlich Agile, er hat Recht im Titel.

Das ist nicht real.

Und doch funktioniert es.

Sie machen agil falsch.

Leider ist das Problem mit Agile, dass es nicht richtig gemacht werden kann.