Wie lässt sich Agile an verschiedene Unternehmen anpassen? Eine MBA-Thesis

Question

In meiner Masterarbeit möchte ich mich mit der Anwendung von Agile beschäftigen.

Es gibt eine ganze Reihe von Unternehmen, die agile Lösungen verkaufen - viele Unternehmensberater, die ihre Marke als die "beste" verkaufen.

Ich bin nicht daran interessiert, ob XP , Scrum , Kristallklar , Agile-CMMI , Sechs Sigma oder eine andere Marke/Variante ist am besten. Ich bin daran interessiert, was echte, aktive Entwickler (d.h. ihr) tatsächlich als agil anwenden.

Ich habe untersucht, wie man agile Methoden an die verschiedenen organisatorischen Anforderungen anpassen kann.

Aus der Untersuchung, wie verschiedene Organisationen agile Methoden anwenden, habe ich die folgenden Leitlinien entwickelt - ein Rezept dafür, welche agilen Varianten in welchen Situationen angewendet werden sollten:

• Größere und stärker verteilte oder flexiblere Teams brauchen strengere Kodierungs- und Teststandards, kleine Teams können (und sollten) weniger verwenden.
• Die Prozessdokumentation sollte minimal, zeitnah und aktuell sein.
• Detaillierte statistische Kontrollindikatoren sind ein unnötiger Mehraufwand: Die frühzeitige Freigabe unvollständiger Software ist ein besserer Indikator für den Fortschritt.
• Idealerweise sollten die Entwickler in der Nähe des Kunden sein und keine spezialisierten Zwischenrollen übernehmen. Zusätzliche Rollen sollten nur verwendet werden, wenn die Kunden so spezialisiert sind, dass Entwickler nicht gleichzeitig auch Benutzer sind.
• Iterationen sollten flexibel sein, es sei denn, die Koordination der Freigaben mit anderen Abteilungen oder anderen Prozessen wird dadurch begünstigt.
• Die Entwickler sollten in der Lage sein, einfach und regelmäßig miteinander zu kommunizieren, aber die Treffen sollten seltener sein (monatlich und wöchentlich, nicht täglich).
• Die Paarprogrammierung sollte nur für Schulungs- und Untersuchungsaufgaben eingesetzt werden.
• Diese Leitlinien sind nur ein Ausgangspunkt: Durch kontinuierliche Verbesserungen sollte die agile Variante weiter an die genauen Umstände angepasst werden.

Diese Faktoren ändern sich, wenn sie in einer Organisation mit bestehenden traditionellen (d.h. BDUF o Wasserfall ) Modelle, bei denen agile Teams entweder mit Teams, die nicht-agile Methoden anwenden, koexistieren oder von diesen angepasst werden müssen:

• Eine Prozessdokumentation mit Abzeichnung und strukturierten Schritten hilft anderen Teams, das Projekt zu verfolgen.
• Statistische Indikatoren (z. B. Geschwindigkeit) können nicht-agilen Teams die Gewissheit geben, dass der Prozess unter Kontrolle ist.
• Feste Iterationen erleichtern die Koordinierung zwischen den Teams.

Diese zusätzlichen Leitlinien werden die Koexistenz von agilen und traditionellen Modellen erleichtern, bringen aber auch zusätzlichen Aufwand und Einschränkungen mit sich.

Was ich wissen möchte, ist, was Sie - die Leute, die Software schreiben, nicht die agilen Berater - von diesem Rahmenwerk halten.

Was ist Ihrer Meinung nach richtig? Was ist Ihrer Meinung nach falsch? Was würden Sie ändern? Was habe ich übersehen?

Und vor allem: Warum?

---

Ich habe ein Kopfgeld ausgesetzt, um einen zusätzlichen Anreiz für die Beantwortung dieser recht langen Frage zu bieten. Die Prämie geht an denjenigen, der die meisten Stimmen aus der SO-Community erhält - mir ist klar, dass es keine einzig richtige Antwort gibt, aber ich bin daran interessiert, was dem Konsens der Community am nächsten kommt.

Answer 1

Eine noble Sache, viel Glück. Alle oben genannten Punkte sind ebenfalls gut. Ich würde nur hinzufügen:

Bei Agile geht es um die Prinzipien, nicht um den Prozess.

Siehe die Agiles Manifest .

Das Ziel ist es, das Verhalten des Unternehmens zu ändern und nicht ein bewährtes Verfahren zu ändern, um mit einer kaputten Organisation zu "arbeiten", also betonen Sie die Prinzipien hinter jeder Praxis. Und dann die Praktiken nicht ändern . Wenn die Grundsätze nicht anwendbar sind, dann lassen Sie die Praxis(en), die den Grundsatz widerspiegeln, fallen. Eine Änderung der Praxis gefährdet den Grundsatz und verfehlt seinen Zweck. Das Endergebnis solcher "Anpassungen" ist höchstwahrscheinlich dasselbe mangelhafte Verfahren, das bereits angewendet wird Der Begriff "Agilität" wird nun in eine agile Terminologie eingewickelt, aber es fehlen die Prinzipien, die sie ausmachen.

Prozessdokumentation ist Anti-Agil

"Process documentation with sign off and structured steps 
 will help other teams track the project"

Dazu muss ich ein dickes, fettes NEIN sagen. Die Dokumentation nimmt die Agilität aus dem Prozess (ganz zu schweigen von dem Leben und der Energie der Entwickler). Wenn Sie anderen Teams helfen wollen, das Projekt zu verfolgen, veröffentlichen Sie den Iterationsplan und die Geschwindigkeit im Intranet. Bitte verschwenden Sie nicht die Zeit der Entwickler - und das Geld der Kunden - mit dem Schreiben von Prozessdokumentationen, vor allem nicht für den angeblichen Nutzen von andere Personen, die keine Betroffenen sind und kein Risiko haben .

Und natürlich kommt kein MBA-Kandidat ohne mindestens eine Dilbert-Referenz aus einem Programmierer-Thread heraus:
_{(Quelle: <a href="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/50000/4000/500/54565/54565.strip.gif" rel="nofollow noreferrer">dilbert.de </a>)}

Answer 2

1. "Die Prozessdokumentation sollte minimal, zeitnah und aktuell sein."

Was meinen Sie mit "minimal"? Ist es im Sinne von, sagen wir, der Summe der Seitenzahl oder im Sinne des Umfangs (z.B. Standarddokumente, Konfigurationsmanagementhandbuch, Designdokumente).

Wenn man von einem Projekt ausgeht, bei dem es keine Fluktuation im Team gibt - und bei langen Projekten ist dies keine vernünftige Annahme -, braucht man einen effizienten Mechanismus für den Wissenstransfer, und der effizienteste Mechanismus für den Wissenstransfer ist die Dokumentation.

Ich habe Projekte gesehen, bei denen die Dokumentation minimal gehalten wurde (im Sinne der Seitenzahl), weil es zu mühsam war, die Dokumentation zu entwickeln. Wenn aber die Dokumentation von einem Projekt zum anderen ohne oder mit nur minimalen Änderungen wiederverwendet werden kann (was bei Dokumenten wie Programmierstandards und Konfigurationsmanagement-Handbüchern durchaus sinnvoll ist), dann ist die Entwicklung der Dokumentation nicht so aufwändig.

Die Prozessdokumentation sollte den gesamten Softwareentwicklungsprozess abdecken, da sonst die Gefahr besteht, dass Prozesse mit uneinheitlich ausgeführten Schritten entstehen. Agile Teams haben agile Softwareprozesse. Und mit Softwareentwicklungsprozessen meine ich klare Mechanismen für die Verwaltung von Code, die Kontrolle von Versionen, die Kontrolle von Überprüfungen, das Einchecken von Code, die Behebung von Fehlern usw.

Answer 3

• Größere und stärker verteilte oder flexiblere Teams brauchen strengere Kodierungs- und Teststandards, kleine Teams können (und sollten) weniger verwenden.

Kodierungs- und Teststandards sollten unabhängig von der Größe des Teams bestehen. Sie verbessern die Wartbarkeit des Codes und machen es einfacher, neue Ressourcen auf den neuesten Stand zu bringen.

• Die Prozessdokumentation sollte minimal, zeitnah und aktuell sein.

Einverstanden.

• Detaillierte statistische Kontrollindikatoren sind ein unnötiger Mehraufwand: Die frühzeitige Freigabe unvollständiger Software ist ein besserer Indikator für den Fortschritt.

Es gibt nicht viele statistische Kontrollindikatoren für die Softwareentwicklung, die durchgängig aussagekräftig sind. Ich würde nach der Abweichung von Zeit und Budget, der Fehlerrate bei Tests und in der Produktion und der Abweichung von den Schätzungen suchen.

• Idealerweise sollten die Entwickler nahe am Kunden sein und keine spezialisierten Zwischenrollen einnehmen. Zusätzliche Rollen sollten nur dann verwendet werden, wenn die Kunden so spezialisiert sind, dass die Entwickler nicht gleichzeitig auch Benutzer sind.

Das ist oft unpraktisch oder unmöglich. Die Kunden haben beruflich so viel zu tun, dass sie selten die Zeit haben, sich intensiv mit den Entwicklern zu befassen. Business-Analysten verfügen über die notwendigen Fähigkeiten, um geschäftliche Fragen zu konsolidieren und klare Antworten zu erhalten, und das in viel kürzerer Zeit. Wenn Ihre Veröffentlichungszyklen kurz genug sind, haben die Kunden reichlich Gelegenheit für ein Feedback.

• Iterationen sollten flexibel sein, es sei denn, die Koordination der Freigaben mit anderen Abteilungen oder anderen Prozessen wird dadurch begünstigt.

Es sollte eine gewisse Flexibilität geben, aber nicht viel. Einer der Vorteile eines agilen Ansatzes besteht darin, dass er das Team zwingt, den Umfang auf die wichtigsten Anforderungen zu beschränken. Wenn man den Iterationszeitplan flexibler gestaltet, erhöht sich das Risiko, dass sich der Umfang vergrößert.

• Die Entwickler sollten in der Lage sein, einfach und regelmäßig miteinander zu kommunizieren, aber die Treffen sollten seltener sein (monatlich und wöchentlich, nicht täglich).

Tägliche Besprechungen sind bei größeren Teams effektiv. Sie halten die Teilnehmer auf Kurs und fördern die Zusammenarbeit. Sie verhindern, dass Teammitglieder bei einem Problem steckenbleiben, ohne um Hilfe zu bitten. Sie helfen auch, die Kontrolle über die Iteration zu behalten, was angesichts des Mangels an anderen Kontrollmöglichkeiten sehr nützlich ist.

• Die Paarprogrammierung sollte nur für Schulungs- und Untersuchungsaufgaben eingesetzt werden.

Zu diesem Thema habe ich nicht viel zu sagen.

• Diese Leitlinien sind nur ein Ausgangspunkt: Durch kontinuierliche Verbesserung sollte die agile Variante weiter an die genauen Umstände angepasst werden.**

EXAKT! Agilität ist dazu da, sich den Bedürfnissen der Organisation anzupassen. Ständige Anpassungen sind für die Perfektionierung des Prozesses unerlässlich.

Ich wünsche Ihnen viel Glück für Ihre Dissertation.

Answer 4

• Größere und stärker verteilte oder flexiblere Teams brauchen strengere Kodierungs- und Teststandards, kleine Teams können (und sollten) weniger verwenden.

Kontinuierliche Tests sind unabhängig von der Teamgröße von unschätzbarem Wert. Was variieren sollte, ist der Umfang der Tests je nach Projektreife und Kritikalität der Komponenten.

Bei neuen Produkten sind regelmäßige Vorführungen gut für die Arbeitsmoral und geeignet, um der Geschäftsleitung ein Gefühl für den Fortschritt zu vermitteln.

Bei ausgereiften und bereits ausgelieferten Produkten werden zumindest regelmäßige Abnahmetests der wichtigsten Funktionen durchgeführt, um die Freigabebereitschaft des Produkts zu überprüfen.

Für wichtige Systemschnittstellen sind Unit-Tests anschaulich und helfen, Überraschungen zu vermeiden. Bei der Arbeit mit beauftragten Teilprojekten sind Unit-Tests besser als Dokumentation und entscheidend, um Verzögerungen durch Schuldzuweisungen zu vermeiden.

Test-first-Entwicklung ist ein lohnenswertes Experiment für die schwergewichtigen Teile des Codes. Wenn Ihr wertvollstes Gut Ihre Technologie ist, sollte sie extrem gründlich getestet werden.

• Detaillierte statistische Kontrollindikatoren sind ein unnötiger Mehraufwand: Die frühzeitige Freigabe unvollständiger Software ist ein besserer Indikator für den Fortschritt.

Statistische Kontrollindikatoren sind für die frühzeitige Erkennung von Projektüberschreitungen unerlässlich, sollten aber am besten in den Händen des "Agile Coach" oder "Scrum Master" verbleiben, entweder dauerhaft oder bis das gesamte Team diszipliniert genug ist, um genaue Berichte über Fortschritte und Verzögerungen zu erstellen.

Bei effektiver Anwendung agiler Entwicklungspraktiken sollten Stories und Aufgaben so klein sein, dass sie innerhalb von Stunden bis Tagen abgeschlossen werden können. Ein effektives Management des "Planungsspiels" und des Feedbacks, das zu einer Überschreitung einzelner Aufgaben führt, kann den Aufwand für die Schätzung und Erfassung von Fortschrittsdaten minimieren.

Schließlich wird eine historische Aufzeichnung von Kunden- (und/oder Management-) Entscheidungen und eine Buchführung darüber, wie viel Zeit (Tage) tatsächlich für die Reaktion auf diese Entscheidungen aufgewendet wurde, den Weg zur Verbesserung sowohl der technischen als auch der geschäftlichen Prozesse weisen. Ein "Swim Lane"- oder "Gantt"-Diagramm der blockierten Entwicklung und der aufgewendeten Zeit wird zeigen, dass "aber wir sind agil" keine Entschuldigung für unüberlegte Geschäftsentscheidungen ist.

• Idealerweise sollten die Entwickler in der Nähe des Kunden sein und keine spezialisierten Zwischenrollen übernehmen. Zusätzliche Rollen sollten nur dann verwendet werden, wenn die Kunden so spezialisiert sind, dass die Entwickler nicht gleichzeitig auch Benutzer sind.

Ausnahmsweise stimme ich zu! Getrennte Entwicklungs- und Managementsitzungen sind gut geeignet, um Anliegen zu trennen.

• Iterationen sollten flexibel sein, es sei denn, die Koordination der Freigaben mit anderen Abteilungen oder anderen Prozessen wird dadurch begünstigt.

Agile Iterationen sind ein wertvoller Entwicklungsrhythmus für die Erstellung eines kontinuierlich freizugebenden Produkts. Am Ende der Iterationen können Entscheidungen über Funktionen umgesetzt und Änderungen an der Versionskontrolle vorgenommen werden, um Funktionen abzuzweigen, die das Ziel nicht erreichen werden.

Diese Praxis kann sich jedoch für Teams als schwierig erweisen, wenn die Iterationen nicht mit den Geschäftsanforderungen übereinstimmen. Iterationen sollten um geschäftliche Anforderungen wie Demos und Werbeaktionen herum geplant werden.

• Die Entwickler sollten in der Lage sein, einfach und regelmäßig miteinander zu kommunizieren, aber die Treffen sollten seltener sein (monatlich und wöchentlich, nicht täglich).

Montag/Donnerstag sind Standup-Meetings eine gute Idee. Sie müssen jedoch auf 15-30 Minuten begrenzt werden. Teilen Sie die Besprechung nach Bedarf auf, um die Zeit zu verkürzen. Trennen Sie die Anliegen, um die Zeit der Entwickler nicht zu verschwenden.

Ein Bürohund kann dazu beitragen, die Aufmerksamkeit der Mitarbeiter in Sitzungen aufrechtzuerhalten. Ein paar Bellen ist besser, als wenn jemand einnickt oder eine SMS schreibt.

• Die Paarprogrammierung sollte nur für Schulungs- und Untersuchungsaufgaben eingesetzt werden.

Pair Programming, Unit Testing, gnadenloses Refactoring und testgetriebene Praktiken gehören zu den schwierigsten agilen Fähigkeiten, die sich Teams aneignen müssen. Die Vorteile der Paarprogrammierung bestehen darin, das Bewusstsein und das Wissen zu erhöhen und zu verhindern, dass die Arbeit isoliert durchgeführt wird, wo schlechte Entscheidungen und Annahmen verweilen und kaskadieren können.