Missverständnisse über Collective Ownership in einem agilen Umfeld [geschlossen]

Nach meinem Verständnis wird kollektives Eigentum gemeinsame Probleme mit dem Antiquierten wie Qualität, Versagen aufgrund von Abwesenheit und Wissensaustausch lösen.

Es gibt jedoch einige Dinge, die ich nicht verstehe.

  1. Ist das Team eine Demokratie? Wenn ja, was ist, wenn die Mehrheit falsch liegt?
  2. Warum technische Korrektheit der "menschlichen Korrektheit" vorziehen? Das heißt, was technisch korrekt ist, ist möglicherweise nicht die motivierendste/angenehmste Wahl für die Personen, die an dem Projekt arbeiten. Ein unzufriedenes Team schafft eher schlechte Qualität als ein motiviertes Team.
  3. Was ist mit der Kreativität, dem Verständnis, der Erforschung und dem Experimentieren des Einzelnen? Diese werden wahrscheinlich vernachlässigt, wenn die einzigen Entscheidungen, die getroffen werden, auf einer gegenseitigen Vereinbarung beruhen.
  4. Wie wird mit betrügerischen Aktivitäten umgegangen? Wenn beispielsweise 99 % eines Projekts abgeschlossen sind und das gesamte Team bis auf eine Person am nächsten Tag in den Urlaub fährt, was hindert diese eine Person daran, Dinge zu ändern, die bereits während der Paarprogrammierungssitzungen vereinbart wurden, kurz bevor die letzten 1 % geliefert werden? ?
  5. Wird die Code-Produktionszeit nicht massiv erhöht? Wenn das gesamte Team den gesamten Code lernen muss , der produziert wird, kann technisch gesehen nur eine Sache gleichzeitig produziert werden.

Edit : Punkt 4 und 5 hinzugefügt.

Das sind mehrere Fragen. Auch wenn sie vage verwandt sein mögen, handelt es sich um eindeutig unterschiedliche Fragen, die separat gestellt werden müssen, um nicht zu weit gefasst zu sein. Darüber hinaus füllt das Thema funktionsübergreifendes Teaming vs. Individualismus bei Projekten ganze Bücher und ist eindeutig zu weit gefasst, wenn es nicht auf ein konkretes Problem eingegrenzt wird, mit dem Sie konfrontiert sind.
Die Kommentarthreads zu allen Antworten laufen aus dem Ruder. PMSE ist eine Q&A-Site, kein Diskussionsforum. Bitte verwenden Sie Kommentare nur, um Antworten zu klären oder zu verbessern; alles andere sollte in den Chat verschoben werden .

Antworten (3)

„Kollektives Eigentum am Code“ bedeutet nicht, dass jeder im Team bei jeder geschriebenen Codezeile mitreden kann. Der Code wird immer noch von Einzelpersonen geschrieben (es sei denn, Sie programmieren paarweise), und sie treffen die Entscheidungen, die sie zu diesem Zeitpunkt für die besten halten. Der Punkt ist, dass niemand einen Abschnitt des Codes „besitzt“.

Wenn John das Foo-Modul geschrieben hat und aus irgendeinem Grund während Johns Abwesenheit ein kritischer Fehler entdeckt wird, sollte nichts Sue daran hindern, einzuspringen und ihn zu beheben. Es ist nicht „Johns Code“, es sind die Teams.

Dann stellt sich also die Frage: "Wie repariert Sue den Code, wenn John ihn geschrieben hat?" und die Antwort ist nicht, dass Sue und der Rest des Teams jede Linie mit John entschieden haben, sondern dass John im Geiste der Teamarbeit und Zusammenarbeit und in dem Wissen, dass er nicht die einzige Person sein würde, die an dem Code arbeitet, nahm sich die Zeit, Tests zu schreiben und den Code zu dokumentieren, damit Sue daran arbeiten konnte.

Sue könnte auch einige Erfahrung mit dem Code aus Code-Reviews haben, die wiederum keine Chance für das Team sind, zu entscheiden, wie der Code hätte geschrieben werden sollen, sondern nur um sicherzustellen, dass er seinen Zweck erfüllt und allen Standards entspricht, denen das Team folgt .

Was Punkt 3 betrifft, so gehören Experimentieren, Erkunden usw. in Prototypen und persönliche Projekte, nicht in den Produktionscode.

Wenn es nicht zeilenweise gemacht wird, dann ist es Johns Lösung, wenn John am Code arbeitet. Wenn Sue an Johns Code arbeitet, ist es Sues Lösung, da sie den Code so ändern kann, dass er ihren Vorlieben am besten entspricht? In Ihrer Antwort auf Punkt 3 wird diese Art von Mentalität dazu führen, dass niemand jemals bereit ist, länger und härter zu arbeiten, da sein Job immer nur ein Opfer und keine aufregende Gelegenheit sein wird. Ich glaube nicht, dass dies zuverlässig oder effizient ist. Grundsätzlich glaube ich, dass Korrektheit bei Menschen liegen sollte, nicht bei Technik, da glückliche Menschen gute Technik machen und nicht umgekehrt.
Wenn John am Code arbeitet, ist es die Lösung des Teams, wenn Sue daran arbeitet, ist es auch die Lösung des Teams. Wenn Sue nicht zusammenhängende Änderungen nur aus persönlichen Vorlieben vornimmt, dann handelt sie egoistisch und gegen das beste Interesse des Teams.
Zu Punkt 3: Code kann morgens kreativ, experimentell und Teil eines Prototyps sein und abends ein gut dokumentierter, klar geschriebener Produktionscode sein. Der Punkt war eher, dass Sie kein Teamplayer sind, wenn Sie Code in die Produktion einbringen, mit dem niemand sonst arbeiten kann.
John und Sue können die Gedanken des anderen nicht lesen und müssen daher in Abwesenheit des anderen Vermutungen anstellen. Wenn es eine Wahl zwischen potenziell falschen Annahmen und Vorlieben ist, warum nicht Vorlieben wählen? Kreativität impliziert, dass andere lernen müssen, da es etwas Neues ist. Ich denke nicht, dass John oder Sue keine Teamplayer sind, ich denke, es bedeutet einfach, dass sie eine neue und effiziente Art erfunden haben, etwas zu tun, das das Team noch nicht verstanden hat. Warum Innovationen bestrafen?
@ThreaT: Zeile für Zeile kann es keine Annahmen geben. Der Computer kann weder Gedanken lesen noch Vermutungen anstellen. Auf der höheren Designebene kann man „unnötig schlau“ (was man vermeiden sollte) oder wirklich innovativ sein. Da John im letzteren Fall weiß, dass Sue möglicherweise auch am selben Code arbeitet, sollte John sein Design ordnungsgemäß dokumentieren, damit Sue es verstehen kann, ohne Vermutungen anzustellen. Es könnte ihm auch helfen, sich daran zu erinnern, welche cleveren Tricks er vor einem Jahr gemacht hat.
@BartvanIngenSchenau: Es scheint, als würde kollektives Eigentum immer dazu führen, dass in der Entwurfsphase der gemeinsame Ansatz gewählt wird, wodurch Kreativität niemals zugelassen wird.
@ThreaT "Designphase" schreit nach Wasserfall, nicht agil. Ich denke, Sie haben eine allzu drakonische Sichtweise auf das, was "kollektives Eigentum" bedeutet. Schreiben Sie einfach Code, wie Sie es normalerweise tun würden, aber denken Sie daran, dass andere daran arbeiten müssen (Kommentare, Sauberkeit usw.), ärgern Sie sich nicht, wenn jemand ihn bearbeitet, und haben Sie keine Angst davor, Code zu bearbeiten, der "nicht deine". Es geht darum, Egos beiseite zu legen und als Team zu arbeiten.
@MikeGossmann: Ich denke, es ist sehr demotivierend, wenn jemand keine Angst hat, Ihren Code so zu ändern, dass er "standardisierter" ist, während Sie gerade dabei sind, etwas Neues zu erstellen. Sicherlich muss es ein gewisses Timing, Grenzen und einen Alpha-Besitzer/ultimativen Entscheider geben, sonst ist es nur Anarchie und niemand ist am Ende glücklich und motiviert?
@ThreaT: Die Leute gehen nicht in den Code hinein, um ihn normaler zu machen, da normalerweise keine Zeit für solche "Leerarbeit" ist. Und es sollte eine Kommunikation zwischen den Entwicklern geben, um Konflikte zu vermeiden. Wenn ich an einer großen Änderung an den Klassen X, Y und Z arbeite und ein zweites Feature im Rückstand sehe, das eine dieser Klassen betrifft, dann würde ich das Team warnen, in Ruhe gelassen zu werden, bis ich mit meiner großen Änderung fertig bin. Nachdem ich fertig bin, steht es jedem frei, mit dieser anderen Funktion zu beginnen.
  1. Was ist, wenn die Mehrheit falsch liegt?

Es kann natürlich passieren. Ich würde erwarten, dass alle Probleme, die sich aus einer falschen Entscheidung ergeben, bei Retrospektiven angesprochen und diskutiert werden. Hoffentlich erkennt das Team dann den Fehler, den es gemacht hat, und passt es an.

  1. Warum die technische Korrektheit der menschlichen Korrektheit vorziehen

Warum eigentlich. Das Team sollte die Vor- und Nachteile der verschiedenen Ansätze diskutieren. Sie können entscheiden, dass eine technisch nicht optimale Lösung angemessener ist. Ein gesundes Team wird dies offen diskutieren und eine Entscheidung auf der Grundlage ihrer gemeinsamen Erfahrung treffen.

  1. Wird individuelles Talent vernachlässigt?

Ein gutes Team sucht nach Wegen, um gute Arbeit zu leisten. Sie tun dies sowohl durch Zusammenarbeit als auch durch die Stärkung der Stärken von Einzelpersonen im Team.

  1. Wie wird mit Rogue-Aktivitäten umgegangen?

Wenn Schurkenverhalten Probleme verursacht, werden diese bei Retrospektiven angesprochen und diskutiert. Gruppenzwang reicht normalerweise aus, um den Schurken dazu zu ermutigen, produktiver zu arbeiten, insbesondere wenn die negativen Auswirkungen nachgewiesen werden können.

Gute Antwort. Ich möchte Sie jedoch bitten, Punkt 3 zu erweitern, bevor Sie ihn als richtig akzeptieren. Ich verstehe immer noch nicht wirklich, wie individuelles Wachstum durch kollektives Eigentum gefördert wird.
Viel wird von der Persönlichkeit der Teammitglieder abhängen. Wenn sie aufgeschlossen und nicht konfrontativ sind, werden sie das Potenzial des Einzelnen erkennen und es fördern. Der Schlüssel ist ein schneller Ansatz und keine Vorwürfe, wenn etwas schlecht läuft. Die Retrospektiven geben Feedback über Dinge, die gut gelaufen sind, und Dinge, die schlecht gelaufen sind. Wenn die Person Dinge tut, die wirklich helfen, sollten sie in den Retrospektiven erwähnt werden. Ein positives Team wird versuchen, diesen Erfolg zu unterstützen.
@BarnbyGolden: Meiner Erfahrung nach hat das Sprintboard jedes Mal Vorrang vor der Retrospektive. Selbst wenn Sie etwas im Nachhinein erwähnen, ist es höchst unwahrscheinlich, dass Sie die Chance erhalten, neue Dinge auf eigene Faust kreativ zu machen, anstatt Dinge in kollektiver Eigenverantwortung zu tun.
Kontinuierliche Verbesserung ist das Herzstück des Scrum-Prozesses. Wenn es Einzelpersonen schwer fällt, Maßnahmen zu vorgeschlagenen Verbesserungen zu ergreifen, kann es ein Problem mit der Art und Weise geben, wie die Retrospektiven durchgeführt werden. Aber wenn Einzelpersonen Änderungen vorschlagen, ist es wichtig, dass sie auch beschreiben, wie die Änderung die Dinge verbessern wird, und ebenso wichtig, wie sie diese Änderung messen können. Mit einem begründeten Argument und einem definierten Erfolgsmaß wird das Team normalerweise eine Änderung zulassen. Wenn das Team nicht bereit ist, es zu versuchen, deutet dies auf mangelndes Vertrauen hin und darauf, dass es die Vorteile von Agile verpasst.
Es ist nicht immer möglich, Ratschläge zu geben, wie eine Erkundung die Dinge notwendigerweise verbessern wird, weil Sie es nicht wissen, bis Sie es versucht haben. Die Erforschung neuer Ideen kann scheitern, aber es kann sich auch als wirklich vorteilhaft erweisen. Auch wenn Sie im Nachhinein mangelnde Kreativität ansprechen, bei höher priorisierten Aufgaben, die ständig anfallen, wird Kreativität immer auf der Strecke bleiben. Eine Möglichkeit besteht darin, Entwickler hin und wieder etwas alleine machen zu lassen, aber dies steht offensichtlich im Widerspruch zu kollektivem Eigentum.
Gute Antworten. Kollektives Eigentum bedeutet, dass Teammitglieder sich gegenseitig unterstützen und in der Lage sind, ihr Produkt zu unterstützen, auch wenn Menschen fehlen. 1, 2 und 4 sind Fragen der Gruppendynamik, die zutreffen, unabhängig davon, ob Sie sich in einer agilen Umgebung befinden. Für Nr. 3 sollte eine agile Umgebung eine Kultur des Lernens und des kontrollierten Experimentierens fördern. Dies sollte Gelegenheiten schaffen, Optionen zu erkunden. Natürlich ist es denkbar, dass die Organisationsdynamik das Team dazu zwingt, Abstriche zu machen und unabhängig von der Qualität den ersten plausiblen Weg einzuschlagen, aber das wäre eine schlechte agile Umsetzung.
  1. Was ist, wenn die Mehrheit falsch liegt?

Es ist in Ordnung, wenn dies passiert! Die Idee ist, „schnell zu scheitern“, sich anzupassen, Ihren Plan zu aktualisieren und weiterzumachen und etwas anderes auszuprobieren. Das „fail fast“-Konzept ist nur eine weitere Möglichkeit, die wissenschaftliche Methode auf Ihre Arbeit anzuwenden.

Ich beantworte nur die erste Frage, jetzt bin ich auf dem Handy.

Missverständnisse über Collective Ownership in einem agilen Umfeld [geschlossen]
AntwortenHierDatenschutz-Bestimmungen1y, 0v