Wir praktizieren Agilität in einem großen Unternehmen mit hoch integrierter Software und festgelegten Windows-Zeitpunkten, zu denen Software auf gemeinsam genutzten Hardware-Umgebungen in die Produktion überführt werden kann.
Wir haben eine Reihe von agilen Praktiken entwickelt, die sich aus SCRUM (Projektmanagement) und XP (Technik) zusammensetzen. Viele der Systeme, die wir einsetzen, nutzen traditionelle Wasserfallverfahren
Was Ihren Rahmen betrifft, so werde ich auf jeden einzelnen Punkt eingehen:
"Größere und stärker verteilte oder flexiblere Teams brauchen strengere Kodierungs- und Teststandards, kleine Teams können (und sollten) weniger verwenden."
Wenn Sie mit Kodierungs- und Teststandards technische Praktiken (XP) wie kontinuierliche Integration, Paarprogrammierung, testgetriebene Entwicklung, automatisierte Funktions- und Leistungstests usw. meinen, dann arbeiten wir unabhängig von der Größe des Teams oder des Projekts mit denselben Praktiken. Infolgedessen geben wir oft Software frei, bei der während des User Acceptance Test keine Fehler gefunden werden. Die Freigabe von qualitativ hochwertiger Software (mit wenigen Fehlern), die formbar bleibt, um eine kontinuierliche Entwicklung in einem nachhaltigen Tempo zu ermöglichen, ist ausschlaggebend für den Bedarf an technischen Verfahren, nicht die Größe des Unternehmens.
"Die Prozessdokumentation sollte minimal, zeitnah und aktuell sein."
Wenn Sie mit Prozessdokumentation die agile Prozessdokumentation meinen, dann passt alles von uns an eine Wand. Wir zeigen das Manifest, die Zuordnung zu den 12 Prinzipien und schließlich die 21 Praktiken, die wir als Mitarbeiter anwenden. Die Tatsache, dass sie an die Wand passen und gut sichtbar sind, ermöglicht es dem Team, sie zu verstehen und, was noch wichtiger ist, sie tatsächlich in die Praxis umzusetzen.
"Detaillierte statistische Kontrollindikatoren sind ein unnötiger Mehraufwand: Eine frühzeitige Freigabe unvollständiger Software ist ein besserer Indikator für den Fortschritt."
Prozentuale Abschlüsse bei traditionellen Arbeitsmitteln haben wenig Wert. Der beste Indikator für den Fortschritt ist die Vorführung funktionierender Software für unseren Produktinhaber/Geschäftspartner alle zwei Wochen. Die Verfolgung der tatsächlichen Geschwindigkeit (Einheiten der fertiggestellten Story Cards) und der Fehlerraten und die Darstellung der Daten in großen, sichtbaren Diagrammen ist sehr hilfreich. Bei der Einführung bestimmter Praktiken in einem Team ist es nützlich, den Fortschritt aufzuzeigen. Zum Beispiel die Anzahl der Einheitstests, die vor dem Code geschrieben werden, wenn TDD gelernt wird.
"Idealerweise sollten die Entwickler nahe am Kunden sein und keine spezialisierten Zwischenrollen einnehmen. Zusätzliche Rollen sollten nur verwendet werden, wenn die Kunden so spezialisiert sind, dass die Entwickler nicht gleichzeitig auch Benutzer sind."
Wenn möglich, sollten die Benutzer mit dem Team im offenen Arbeitsbereich arbeiten. Wenn es dem Benutzer nicht möglich ist, mit dem Team zusammenzuarbeiten, ist ein Benutzerstellvertreter die nächstbeste Person, die an der Leitung sein sollte. Niemand kann ein besseres Feedback geben als die Personen, die die Software tatsächlich für ihre Arbeit nutzen.
"Iterationen sollten flexibel sein, es sei denn, die Koordination von Releases mit anderen Abteilungen oder anderen Prozessen wird dadurch begünstigt."
Noch wichtiger ist, dass die Veröffentlichungstermine teamübergreifend abgestimmt werden sollten. Iterationen sind am besten, wenn sie von gleichbleibender Dauer sind (wir verwenden alle 2 Wochen). Eine gleichbleibende Iterationsdauer entspricht dem Time Boxing und der Berechnung der Geschwindigkeit, die für die Festlegung der Story Cards für die nächste Iteration verwendet wird.
"Die Entwickler sollten in der Lage sein, einfach und regelmäßig zu kommunizieren, aber die Treffen sollten seltener sein (monatlich und wöchentlich, nicht täglich)."
Das Team sollte am täglichen Stand-up-Meeting und bei jeder Iteration am Iterationsplanungsmeeting, dem Show & Tell-Meeting, dem Planungspoker-Meeting und dem Retrospektiv-Meeting teilnehmen. Bei jedem Release nimmt das Team an der Release-Planungsbesprechung teil. Da der Benutzer/Geschäftspartner mit der Linie zusammenarbeitet, können täglich Gespräche über die zu erledigende Arbeit stattfinden.
"Pair Programming sollte nur für Ausbildungs- und Forschungszwecke eingesetzt werden."
Der erste Grund für den Einsatz von Pair Programming ist die Beseitigung von Fehlern. Ich habe eine Reihe von Antworten zum Thema Pair Programming geschrieben. Zusammenfassend lässt sich sagen, dass Paare weniger wahrscheinlich blockiert werden, weniger wahrscheinlich E-Mail- oder Web-Urlaub nehmen, einen Mechanismus zum Transfer von Fähigkeiten aus dem Geschäfts- und Anwendungsbereich sowie der technischen Praxis bieten, Wissenssilos beseitigen (wichtig in größeren Organisationen) usw.
"Diese Leitlinien sind nur ein Ausgangspunkt: Durch kontinuierliche Verbesserungen sollte die agile Variante weiter an die genauen Umstände angepasst werden."
Retrospektiven, die bei jeder Iteration oder bei Auftreten eines Ereignisses, das eine Retrospektive erforderlich macht, geplant werden, und eine Null-Fehler-Mentalität fördern die kontinuierliche Verbesserung. Durch die Anwendung der XP-Entwicklungspraktiken kann das Team den Code gesund halten, so dass neue Funktionen auf unbestimmte Zeit hinzugefügt werden können. Wir behandeln die Ergebnisse von Wasserfallprojekten als Einschränkungen. Um mit diesen Einschränkungen umzugehen, fordern wir die Arbeit dieser Teams lange im Voraus an und verwenden technische Techniken wie Mocking, um die Story Cards zu testen, die in diese Ergebnisse integriert werden.
"Diese Faktoren ändern sich, wenn sie in einer Organisation mit bestehenden traditionellen (d.h. BDUF- oder Wasserfall-) Modellen angewendet werden, wo agile Teams entweder mit Teams, die nicht-agile Methoden verwenden, koexistieren oder von ihnen angepasst werden müssen:"
Wir haben agile Teams, die in einer Wasserfallwelt leben. Wir laden die Wasserfallprojekte zu unseren Release- und Iterationsplanungssitzungen (und Retrospektiven) ein. Der Erfolg, den wir haben und weiterhin haben werden, bringt neue Bekehrte zu den agilen Praktiken innerhalb des Unternehmens.
"Eine Prozessdokumentation mit Abzeichnung und strukturierten Schritten hilft anderen Teams, das Projekt zu verfolgen."
Uneinig. Die Story-Card-Wand, der Iterationsplan und der Release-Plan sind alles, was von den Teammitgliedern und Externen benötigt wird.
"Statistische Indikatoren (wie die Geschwindigkeit) können nicht-agilen Teams die Gewissheit geben, dass der Prozess unter Kontrolle ist.
Einverstanden. Agile Teams werden die Geschwindigkeit und die Fehlerraten sichtbar machen. Die Budgets werden innerhalb von 1 oder 2 Prozent liegen, und die Releases werden termingerecht erfolgen, da sie in Time Boxes verpackt sind.
"Feste Iterationen werden die Koordination zwischen den Teams erleichtern.
Wird in hoch integrierten und großen Umgebungen benötigt. Hilft dem Team auch bei der Erstellung von Iterations- und Release-Plänen auf der Grundlage der Entwicklungsgeschwindigkeit.
