Wie sieht eine gute „Definition von erledigt“ für ein reifes Team aus?

Wenn Sie sich Beispiele für Definitionen ansehen, die in verschiedenen Quellen erstellt wurden, enthalten sie normalerweise Punkte wie

• Code abgeschlossen
• Unit-Tests laufen
• Code Peer-Review oder gepaart
• Code eingecheckt
• Dokumentation aktualisiert
• …

In unserem Team haben wir eine ähnliche Liste, aber niemand sieht sie sich jemals an, weil diese Punkte so offensichtlich erscheinen, dass es niemandem einfällt, einen dieser Schritte zu überspringen. Wir haben uns also gefragt, ob dies hauptsächlich ein Werkzeug für Teams ist, die zu einem agilen Prozess übergehen, und ob wir ihn nicht einfach loswerden sollten.

Auf der anderen Seite wird in vielen Literaturstellen behauptet, dass alle leistungsstarken Teams eine starke Definition von erledigt haben. Diese Art von Hinweisen, dass wir möglicherweise eine Gelegenheit verpassen, uns hier zu verbessern.

Also, was sind Beispiele für starke Definitionen von getan von einem reifen Team? Welche Art von Punkten enthalten sie normalerweise?

Die Richtlinien sind für alle da. In einem reifen Team, wie Sie bereits erwähnt haben, tun es alle, was nicht bedeutet, dass es keinen Platz dafür gibt. Angenommen, ein neues Mitglied tritt bei, das zuvor noch nicht mit dieser Methode vertraut war. Die Struktur zu haben, wäre für ihn von entscheidender Bedeutung. Er würde andere Mitglieder nicht belästigen müssen oder ein Ergebnis nicht "vergessen".

Meiner Meinung nach alles auflisten, auch das Offensichtliche. Vielleicht haben Sie eine "kurze Cheat-Liste" für nicht offensichtliche, wenn es denen hilft, die eine kürzere Liste wollen, aber den Fall neuer Mitglieder in Betracht ziehen.

Es ist ein iterativer Prozess. Jedes Mal, wenn Sie etwas sehen, das Sie verbessern können, fügen Sie es in die Definition von erledigt ein. Im Laufe der Zeit erstellen Sie eine Liste, die für Ihr Unternehmen relevant ist. Anann hat bereits einige erwähnt, die sich lohnen.

Nur weil die Punkte offensichtlich sind, heißt das nicht, dass die Leute sie immer ausführen werden. Nehmen wir zwei weitere Beispiele - Piloten und Chirurgen. Ein Cockpit eines Verkehrsflugzeugs oder eines Operationssaals hat mehrere Personen mit viel Ausbildung und Erfahrung. Es geht jedoch immer noch schief - Schritte werden nicht in der richtigen Reihenfolge ausgeführt, etwas wird vergessen, etwas wird falsch ausgeführt. Ich habe eine Reihe von Quellen gesehen, auf denen eine große Anzahl (bis zu 70%) von Flugzeugvorfällen, die auf Pilotenfehler zurückzuführen sind, mit einer Checkliste hätte verhindert werden können . In der medizinischen Welt hätten laut Forschern bis zu 29% der Rechtsstreitigkeiten in den Niederlanden durch die Verwendung einer Checkliste verhindert werden können. Obwohl diese Leute geschult wurden und im Nachhinein wahrscheinlich leicht erkennen würden, was sie falsch gemacht haben, passierte etwas, das sie zum Erlöschen brachte. Ich habe es noch nicht gelesen, aber das Checklisten-Manifest soll relevant sein. Es wurde von einem medizinischen Beruf geschrieben, aber die Vorteile, eine Checkliste oder ein Flussdiagramm sichtbar zu machen, um daran zu erinnern, was zu tun ist, gelten für jeden Beruf.

Schritt eins wäre also, eine Liste von Dingen zu erstellen, die Teil Ihrer Definition von erledigt sind, und sie sichtbar zu machen. Es spielt keine Rolle, wie offensichtlich diese Aufgabe ist. Wenn sie abgeschlossen sein muss, damit die Geschichte als erledigt betrachtet werden kann, muss sie auf dieser Liste stehen. Die Liste muss für das Team sichtbar sein. Beachten Sie, dass es nichts Besonderes oder Formales sein muss - vielleicht nur eine Reihe von Fragen, die sich jeder stellen muss, bevor eine Geschichte als erledigt bezeichnet werden kann.

Schritt zwei besteht darin, zu entscheiden, was auf dieser Checkliste für Ihre Definition von erledigt steht. Alles, was Sie tun müssen, um eine Aufgabe zu erledigen, sollte spezifisch, eindeutig, akzeptabel und realistisch sein. Es muss sich auch in einem zeitlichen Kontext befinden, in dem überlegt wird, was getan werden soll. Zum Beispiel müssen Sie nicht "Code ändern" oder "Design ändern" in eine Definition von "erledigt" aufnehmen. Wenn Sie kein Arbeitsprodukt ändern mussten, war die Story nicht erforderlich.

Ich würde vermuten, dass eine gute Checkliste, die als Grundlage für eine Definition von erledigt dient, wäre:

• Wurden alle zugehörigen Einheiten-, Integrations-, System- und Abnahmetests aktualisiert?
• Wurde das Arbeitsprodukt in seine lösbare Form gebracht? Zum Beispiel Code erstellt, Dokumentation im exportierbaren Dateiformat usw.
• Wurden alle zugehörigen Arbeitsprodukte einer Peer-Review unterzogen? Beispiele für Arbeitsprodukte sind Quellcode (Produktion und Test), Kommentare, Konstruktionsdokumente, Testverfahren und Benutzerhandbücher.
• Wurden alle zugehörigen Tests (auf allen Testebenen) ausgeführt und bestanden?
• Wurde der Code in das Integrations-Repository eingefügt?

Natürlich müssen Sie eine gute Definition von erledigt finden, die alle anderen Aktivitäten umfasst, die Ihr Team und Ihr Kunde als Mehrwert empfinden. Wenn es auf der Checkliste steht, sollte es etwas sein, das getan werden muss, um jemandem (dem Team, dem Kunden, dem Benutzer) einen Mehrwert zu bieten. Indem Sie klar auflisten, was Sie tun, können Sie auch fremde Aktivitäten identifizieren und eliminieren, um den Prozess zu verbessern.

Das klingt tatsächlich so, als wären Sie ein Glückspilz:

In unserem Team haben wir eine ähnliche Liste, aber niemand sieht sie sich jemals an, weil diese Punkte so offensichtlich erscheinen

Dein Team ist schon "ausgereift" ;-). Aber es gibt immer Raum für Verbesserungen!

Zu Ihrer Frage:

Also, was sind Beispiele für starke Definitionen von getan von einem reifen Team? Welche Art von Punkten enthalten sie normalerweise?

Oben auf Ihrer Liste können Sie Folgendes hinzufügen:

Verschiedene Codequalitätsmetriken: - Instabilität, Abstraktion - LOC vs DLOC (dokumentiert) - etc ...

Die Faustregel könnte sein, dass die Metrik mit Ihrem Commit nicht schlechter werden sollte. Darüber hinaus könnten Sie ein "done: withExcellence" formulieren, wenn jemand die Metriken tatsächlich verbessert. Obwohl dies (Metriken werden besser) normalerweise nicht Teil der Entwicklungsphasen (neue Funktionen), sondern der Refactoring-Phasen ist.

In einem meiner früheren Unternehmen hatten wir eine Definition von "erledigt", die besagte, dass Ihre Metriken unter bestimmten Schwellenwerten bleiben müssen. Wenn Sie darüber hinausgehen, sind Sie noch nicht fertig. (Die zyklomatische Komplexität sollte niemals über 15 hinausgehen, es sei denn, Sie haben eine sehr, sehr gute Entschuldigung, wie komplizierte Berechnungen.)

Gleiches gilt für Verstöße vom Typ Checkstyle, insbesondere wenn Sie über einen benutzerdefinierten Regelsatz verfügen, mit dem Sie den Codestil Ihres Teams überprüfen können. Wenn Sie gegen den Kodierungsstandard verstoßen, sind Sie noch nicht fertig.

Dann könnten Sie nicht nur UnitTest ausführen, sondern auch die Codeabdeckung messen. Wenn nicht mindestens 50% gedeckt sind, sind Sie noch nicht fertig. Obwohl dies eine Art flockige Definition von erledigt ist, sollten Sie Tests für die Kern- / Haupt- / kritischen Methoden durchführen und nicht unbedingt für 100% Ihrer Codebasis.

Oh ja ... und wenn Sie einen CI-Server mit automatisierter Zweigstellenintegration haben (sollten), sind Sie nur fertig, wenn Ihr Commit im DEV-Zweig mit dem aktuellen LIVE-Zweig zusammengeführt wurde und auch keine Fehler verursacht. (Unit Tests usw.)

hmmm ... das ist alles, woran ich mich erinnern kann, was ich aus früheren Unternehmen / Projekten weiß, was in Ihrer Liste nicht erwähnt wurde.

Ich hoffe das hat dir ein paar Ideen gegeben ;-)

Prost,

anann

In einer TDD / BDD-Umgebung ist die Definition von "erledigt" (technisch "Code abgeschlossen", da Matt Ss Definition von "wirklich erledigt" korrekt ist) ziemlich einfach:

• Alle automatisierten Tests bestehen (diese automatisierten Tests sollten neue Tests enthalten, die für die betreffende Story geschrieben wurden, um zu überprüfen, ob die erforderliche Funktionalität oder das erforderliche Verhalten vorhanden ist und funktioniert).
• Codeüberprüfung bestanden (mindestens ein leitender Entwickler im Team ist zufrieden damit, dass Ihre Arbeit Teil der Codebasis wird und dass Sie sich nicht durch die Geschichte "betrogen" oder "gehackt" haben).
• Commit erfolgreich (einschließlich des Build-Bots, der alle automatisierten Tests, Code-Coverage-Metriken, Style-Cop-Prüfungen usw. besteht)

An diesem Punkt können Sie fortfahren. Diese drei Punkte sind kritisch, aber sie sind alles, womit sich der durchschnittliche Teamcodierer befassen muss. Geschrieben oder ungeschrieben sind sie in einer TDD-Umgebung unverletzlich. Die Dokumentation ist ein zusätzlicher Punkt, wenn die Codierer die Dokumentation durchführen. In meinem letzten Agile-Team wurde die Dokumentation von den BAs / QAs bearbeitet. Sie wussten, was der Client wollte, hatten die UATs ausgeführt und waren daher am besten in der Lage, die neue Funktion auf eine für den Client sinnvolle Weise zu dokumentieren, sodass die Dokumentation nicht Teil der Definition des Codierers für "erledigt" war, obwohl sie Teil war der Teamdefinition.