Grundregeln für die Erstellung von Entwicklungsteams

    Die EDISON oft drehen Ingenieure wollen Mitarbeiter zum Team hinzuzufügen. Ich möchte "das Rätsel schnell lösen" und dabei ein Dutzend zusätzlicher Entwickler ausnutzen. Funktioniert dieser Ansatz? Leider nicht immer. In der Programmierung gibt es wie in der Physik Gesetze.


    Ein intelligentes Team zusammenzustellen ist eine echte Kunst

    Brooks Law


    Ohne dieses Prinzip findet keine Diskussion der Entwicklungsteams statt:

    „Durch das Hinzufügen von Personal verzögern wir das Ende eines Softwareprojekts“ (Brooks, 1975).

    Unzählige Entwicklungsteams haben das Postulat bestätigt. Die Gesetze von Brooks und Conway bilden die Basis.

    Beim Beitritt zu einer neuen Person bemüht sich das Team um eine Einführung in den Ablauf der Dinge, um die Erklärung der verwendeten Tricks und Geräte. Die Teilnehmer verbringen Zeit damit, sich mit einem Neuling zu informieren und zu synchronisieren, Teamarbeit zu lernen und Wissen zu übertragen. Die Arbeit verlangsamt sich.

    Frisches Personal braucht nicht nur in der ersten Woche Hilfe. Einige Autoren (zum Beispiel Koplien und Harrison) gehen von einem einjährigen Intervall aus, bevor sie vom Anfänger die Produktivität erhalten. Geben Sie der Aussage aufgrund des Einflusses verschiedener Faktoren keine zu große Bedeutung. Es ist davon auszugehen, dass einige Mitarbeiter in den ersten drei Monaten ohne Hilfe auskommen werden.

    Ein Team kann Dinge verlangsamen, lange bevor eine neue Person eintrifft. Ein Mitarbeiter passiert nicht einfach so. Manchmal handeln HR-Manager im privaten Interesse und fordern mehr Ressourcen an. Stellenbeschreibungen müssen verfasst, geprüft, veröffentlicht, an die Personalabteilung weitergeleitet und an Personalagenturen gesendet werden. Es wird einige Zeit dauern, um die Prozesse zu genehmigen.

    Der Lebenslauf sollte berücksichtigt und entweder als Absage oder als Aufforderung zum Vorstellungsgespräch verfasst werden. Wenn der Kandidat genehmigt wird, wird ein Vertrag erstellt und ein Vorschlag für die Aufnahme in das Team gesendet.

    Verfahren vergehen, bis eine Person das Recht erhält, eine Codezeile zu schreiben. Auch wenn die Personalabteilung die meisten Prozesse leitet, werden Teamleiter und normale Mitglieder abgelenkt. Die Zeit für echte Arbeit und Entwicklung wird reduziert.

    Das Brooks-Gesetz bedeutet keine völlige Ablehnung der Erweiterung von Teams. Das Anwachsen der Vereinigung geschieht jedoch selten schnell. Wenn sich das Team für eine Erweiterung entscheidet, wird ein Teil der Leistung für den Kapazitätsaufbau verwendet.

    Richard Sheridan machte eine kühne Aussage:

    Ich freue mich, Ihnen mitteilen zu können, dass möglicherweise gegen das Brooks-Gesetz verstoßen wird. Alle unsere Aktivitäten konzentrieren sich darauf, die Aussage zu brechen. Das Teilen von Personen in Paare, das Wechseln zwischen Paaren, die Testautomatisierung, das Code-Management, die Rekrutierung ohne Helden, laufende Verhandlungen, ein offenes Arbeitsumfeld und sichtbare Artefakte widerlegen die Aussage von Brooks (Sheridan, 2013).

    In dem Buch stellt der Autor eine Software-Entwicklungsumgebung vor, die sich von der tatsächlichen für die meisten Entwickler und Manager unterscheidet. Menlo spart nicht daran, seine eigene Kultur und Gemeinschaft aufzubauen, sich daran zu beteiligen und sie zu stärken. Bis Unternehmen den Ansatz in der Praxis ausprobieren, gibt es nicht genügend Beispiele, um zu studieren. Es ist schwierig zu sagen, ob es sich lohnt, Sheridans Proben zu kopieren.

    Die vom Autor beschriebenen Methoden sind glaubwürdig. Nun, wenn das Brooksche Gesetz verletzt wird.

    Conway Gesetz


    Organisationen, die Systeme entwerfen ... erzeugen sie, indem sie die Kommunikationsstrukturen kopieren, die sich in diesen Organisationen entwickelt haben
    - Conway, 1968

    Menschen und ihre Organisation spielen eine wichtige Rolle bei der Festlegung der von Entwicklern verwendeten Softwarearchitektur.

    Stellen Sie sich die Schaffung eines neuen Sozialversicherungssystems durch die Regierung vor. Es werden Datenbanken, Schnittstellen und Geschäftslogik benötigt. Entwickler und Tester, kostspieliges Management, das Festlegen von Anforderungen und mehr sind erforderlich.

    Das Ergebnis nimmt eine sichtbare Form an: Benutzerrollen, Workflow, Datenformulare, Berichte werden definiert. An dieser Stelle müssen Sie zustimmen, dass die Schaffung eines kleineren oder grundlegend anderen Systems bereits unmöglich ist.

    Schauen Sie sich das System nach 10 Betriebsjahren an. Das umgekehrte Gesetz von Conway wird eingehalten:

    Unternehmen, die Softwaresysteme einsetzen, beschränken sich auf Kommunikationsstrukturen, die dieses System nachbilden.

    Das Gesetz von Conway berichtet über das mögliche Kopieren von Unternehmensproblemen in einer Schnittstelle: in Ebenen, in der APL, in Modulen oder anderswo.

    Das Conway-Gesetz muss bei der Organisation von Teams und Softwaresystemen berücksichtigt werden. Versuche, das Prinzip wissentlich oder unwissentlich zu brechen, werden Kräfte schaffen, die sich dem Projekt widersetzen. Es sieht aus wie ein Wunsch, Holz über die Fasern zu spalten. Es ist klüger, das Gesetz von Conway zu respektieren und anzuwenden.

    Dunbar Nummer. Naturdenkmäler


    „Die Extrapolation von Menschen unter Affen gibt eine Vorstellung von der Größe sozialer Gruppen. Über 150 Personen - die Grenze der menschlichen sozialen Beziehungen. Die Nummer wurde mit dem Namen "Dunbar Numbers" ausgezeichnet,
    - Dunbar, 2010

    Eine häufig gestellte Frage von Entwicklungsgruppen lautet: „Wie groß sollte das Team sein?“ Die Arbeit des Anthropologen Robin Dunbar liefert interessante Ideen für die Beantwortung einer Frage.

    Der Autor liefert überzeugende Argumente, dass 150 die Obergrenze für die Organisation von Menschen ist. Dunbar notierte die angegebene Anzahl in militärischen Formationen seit dem alten Rom, in neolithischen Siedlungen, in amischen Gemeinden und in modernen Forschungsgruppen.

    Gemeinschaften mit mehr als 150 Mitgliedern sind weniger kohärent und erfordern eine stärkere Kontrolle über Verhalten und Hierarchie. Forschung und Analyse betonen die Hauptpunkte bei der Bildung von Gruppen. Es ist besser, den Parameter "Dunbar Numbers" aufzurufen. Die Merkmale gelten für verschiedene Gruppen, die in großen Formationen enthalten sind. Kleinere Teams sind stärker und stützen sich
    vermutlich auf Zahlen mit dem Faktor 3. Nach der These haben die meisten Leute enge Freunde von 3 bis 5 Leuten. Die nächste Stufe der Freunde von 10 bis 13-15 Personen (mit etwas Mühe). Die nächste Gruppe enthält 30 bis 50 - ein typischer Kampfzug. Mit 150 Einwohnern ist dies der kleinste unabhängige Block in einer Militärfirma und der Ort, an dem separate Unternehmensgruppen gegründet werden.

    Dunbar schlägt die Existenz einer Formation von 500 und 1.500 vor. Der Autor unterstützt Platon bei der Bestimmung der idealen Größe für Demokratie in 5300 Einheiten. Interessante Parallelen lassen sich zwischen der Größe der Militäreinheiten ziehen.

    OrganisationGröße
    Feuerwehr4 oder weniger Personen
    Sektion / Kader8-12 Teilnehmer (mehrere Feuerwehren)
    Zug15–30 Mitarbeiter (2 Kader)
    Gesellschaft80–250 Soldaten (mehrere Züge)
    Bataillon300-800 Kämpfer

    Die Liste ist nicht endlich. Vergessen Sie nicht die Unterschiede zwischen den Ländern. Auch über die Eigenschaften der Flanken einer militärischen Organisation. Im weiteren Sinne folgen die Blockgrößen jedoch Dunbars Erkenntnissen.

    Miller's Magic Seven (Miller's Wallet)


    Es wird als eine kluge Wahl angesehen, die der Größe eines Teams von 7 Personen (± 2) entspricht. Die Aussage hat keinen praktischen Sinn. Es gibt keine Belege für eine These über die optimale Anzahl der Teammitglieder von 5 bis 9 Personen.

    Befürworter der Größe finden in Millers berühmtem Artikel von 1956, The Magic Number Seven Plus Minus Two: Einige Einschränkungen unserer Fähigkeit zur Informationsverarbeitung. In der Praxis werden die meisten Zitierarbeiten nicht gelesen.

    In dem Artikel argumentiert Miller, dass 7 eine kritische Zahl für die Beschreibung der Leistungsfähigkeit der Verarbeitungsfähigkeiten des menschlichen Gehirns ist. Die ausgewählte Zahl bestimmt die maximale Anzahl von "Informationsstücken" für die gleichzeitige Verarbeitung durch das Gedankenzentrum. Der Autor kommt zu dem Schluss, dass die Interpretation der häufigen Wiederholung der Zahl 7 nicht eindeutig ist:

    „Im Moment dränge ich darauf, keine eindeutigen Urteile zu fällen. Vielleicht liegt in den Tiefen dieser Siebenen etwas Wichtiges, das entdeckt werden muss. Aber ich vermute, dass alles nur ein katastrophaler Zufall in Pythagoras sein kann. “

    Die Bedeutung von 7 Magie ist zweifelhaft.

    Abschließend sagt der Autor: "Ich bin der Meinung, dass meine Geschichte hier aufhören sollte, weil sie bereits ziemlich interessant geworden ist." Mehr als 50 Jahre sind seit der Veröffentlichung von Millers Artikel vergangen. Ein Team von 5 bis 9 Mitarbeitern ist in jedem Fall für die Bewältigung von Veränderungen ausreichend. Am Ende des Intervalls ist die Notwendigkeit, die Anforderungen an ein Team von Spezialisten zu prüfen und zu erfüllen, gerechtfertigt. Am oberen Ende des Bereichs ist es schwierig, das System vollständig zu steuern. Daher ist die Anzahl der Mitarbeiter von 5 bis 9 Personen sinnvoll.

    Der beschriebene Betrag schließt die Existenz größerer Teams je nach den Umständen nicht aus.

    Teamgröße in der Scrum-Methodik


    Wie ist Millers Artikel über den Umfang der Informationsverarbeitung durch das menschliche Gehirn anzuwenden, um die Größe eines Softwareentwicklungsteams zu bestimmen? Wenden wir uns der Scrum-Methodik zu. Im Lehrbuch heißt es: „Das Team bei Scrum muss aus sieben plus oder minus zwei Personen bestehen“ (Dimer et al., 2008). Gleichzeitig heißt es im Scrum Guide 2011: „Teams mit mehr als neun Mitgliedern verursachen zu viele Koordinationsprobleme. Große Entwicklungsteams erschweren den gesamten Prozess erheblich “(Sutherland und Schwaber, 2013).

    Der Studienführer lautet:

    Die Rollen des Produktbesitzers und des Leiters des Scrum-Teams werden nicht in die Berechnung einbezogen, es sei denn, sie fließen in die Arbeiten zur Reduzierung des Rückstands im nächsten Sprint ein
    - Sutherland und Schwaber, 2013

    Gleichzeitig deutet die Einführung des Scrum-Teamleiters darauf hin, dass sich der Product Owner außerhalb des Teams befindet.

    Andere Quellen geben verschiedene Empfehlungen zur Identifizierung von Gruppenmitgliedern und zur „gerechten Teilnahme“.

    Teams im Bereich von 4-8 Personen sind überall sichtbar. Millers Artikel begründet rational die Wahl der Gruppengrößen von 7 ± 2. Die Erfahrung bestätigt die optimale Anzahlgrenze. Die Menge kann höher sein als in den Quellen für Scrum angegeben.

    Parkinson-Gesetz und Hofstadter-Gesetz


    Die für die Umsetzung vorgesehene Zeit ist voll
    - das Parkinson-Gesetz

    Es wird immer länger dauern als erwartet, auch wenn Sie das Hofstadter-
    Gesetz kennen - das Hofstadter-Gesetz von 1980

    Versuchen wir die Frage zu beantworten: „Erinnerst du dich an ein Studium an einer Universität? Wann haben die Aufgaben stattgefunden? “Die meisten Leser haben die Arbeit einige Tage vor Ablauf der Frist erledigt. Der Teil war in der Nacht vor der Kapitulation mit dem Projekt beschäftigt.

    Und die überwiegende Mehrheit passte in die Frist.

    Wissenschaftler bestätigen, dass Menschen die für die Fertigstellung der Arbeit erforderliche Zeit nicht gut einschätzen können, es ihnen jedoch gelingt, ein Problem zu einem klar vereinbarten Zeitpunkt zu lösen (z. B. Bühler, Griffin und Peetz, 2010).

    Liegt ein Zeitüberschuss für das Projekt vor, kommt es zu einer übermäßigen Ausweitung des Arbeitsumfangs durch den Auftragnehmer.

    Die Entwicklung von Software unterliegt den Gesetzen von Parkinson und Hofstadter. Wenn Sie einen Stichtag auswählen, wird die erforderliche Zeit zwangsläufig unterschätzt. Infolgedessen werden sich die Arbeitsbedingungen und der Arbeitsumfang erhöhen. Eine Studie (Bühler, Griffin und Pitz, 2010) legt nahe, dass Optimismus in Bezug auf das Datum, an dem die Aufgabe erledigt wurde, es ermöglicht, die Arbeit früher als mit einer pessimistischen Schätzung des Zeitrahmens auszuführen. Die gesamte Projektvorlaufzeit des Optimisten wird jedoch länger sein als die des Pessimisten. Die Frist könnte wichtiger sein als die voraussichtliche Projektabschlusszeit (Arily und Wertenbroch, 2002).

    Goll'sches Gesetz. Parnassus und Alexander


    Ein komplexes Arbeitssystem leitet sich ausnahmslos von einem einfachen Arbeitssystem ab. Ein ausgeklügeltes System, das von Grund auf neu entwickelt wurde, funktioniert nie. Und keine Verbesserungen bringen es zum Laufen. Sie sollten mit einem einfachen Arbeitssystem beginnen
    - Goll's Law, 1986

    Das Gesetz gibt die Worte von David Parnassus wieder:

    „In der Regel funktionieren Softwaresysteme erst dann gut, wenn sie unter„ Kampfbedingungen “mehrmals verwendet wurden.“

    Die Autoren betonen verschiedene Aspekte eines Phänomens, das Christopher Alexander als "organisches Wachstum" bezeichnet.

    Es wird empfohlen, beim Erstellen von Software mithilfe einer Technik, die als "Laufskelett" bezeichnet wird, ein einfaches, grundlegendes Codeteil zu erstellen. Das Skelett treibt, obwohl mit einem gewissen Risiko, das System voran. Nachdem das Team die Basis erstellt hat, fügt es "Fleisch" hinzu - eine Ebene der Funktionalität.

    Das Prinzip kann auf Gruppen, auf Software angewendet werden:

    „Ein effektives, komplexes Team entsteht immer aus einem einfachen, produktiven Gegenstück. Ein komplexes Team, das von Grund auf neu zusammengestellt wurde, kann nicht effektiv funktionieren. Und ohne Änderungen wird es funktionieren. Es lohnt sich, mit einem bereits erarbeiteten Team zu beginnen. "

    Sie können eine Parallele zwischen einem komplexen und einem großen Team ziehen. Das Gesetz weist auf eine Möglichkeit hin, große Gruppen zu bilden, eine flexible Methode zur Skalierung von Assoziationen.

    Der Zusammenhang mit Conways Gesetz ist offensichtlich: Die Konstruktion des „Laufskeletts“ basiert auf dem Rückgrat des Teams. Um eine große und komplexe Formation zu erzeugen, wird ein äquivalentes Skelett-Skelett verwendet.

    Bei der Konstruktion einer anfänglich großen Struktur sagt Conway Law eine große und komplexe Architektur voraus. Golls Gesetz spricht vom Auftreten eines funktionsunfähigen Systems und rät dem Team, mit weniger zu beginnen, um die Fristen einzuhalten.

    Kellys Gesetze


    Ein paar nützliche Postulate des Autors des Artikels sollten hinzugefügt werden.

    Die Skalierung der Software wird immer proportional zu den verfügbaren Ressourcen zunehmen
    - Kellys erstes Gesetz

    Innerhalb jedes großen Entwicklungsprojekts gibt es ein kleines Nebenprojekt außerhalb der Hauptaufgabe
    - Kellys zweites Gesetz

    Ein übergroßes Team, um seine eigene Größe zu rechtfertigen, wird mehr Arbeitskraft, schwerfällige Lösungen und eine ausgefeilte Architektur hervorbringen. Einfacher hinzuzufügen als gegen den Willen eines Gruppenmitglieds zu entfernen.

    Wenn die Teamgröße bereits in der Anfangsphase klein gehalten wird, wird wahrscheinlich eine einfache und prägnante Lösung gefunden. Beginnend mit einem großen Team wird eine umständliche Implementierung garantiert.

    Fazit


    Dunbar-Zahlen bestimmen die Größenbeschränkung eines effektiven Teams. Basierend auf dem Gesetz von Conway können wir über die potenzielle Grenze des Systems sprechen. Der einzige Weg, um das Axiom zu umgehen, besteht darin, das große System in kompakte Gruppen zu unterteilen. Teams werden nicht vollständig gebildet und effektiv geboren. Das Gesetz von Conway arbeitet in Verbindung mit der These von Goll. Gruppen müssen allmählich wachsen. Brooks Postulat impliziert, dass Teams nicht zu schnell expandieren können. Unter Parkinson-Gesetz versteht man die Beschäftigung von übergroßen Teams, die ihre eigene Existenz aufrechterhalten.

    Kellys zweites Postulat schlägt eine Lösung vor: Vermeide das Große, konzentriere dich auf das Kleine.

    Es ist besser, sich nicht den Gesetzen zu widersetzen, sondern einen Ansatz zu finden und mit den Bestimmungen zu arbeiten. Der Versuch, mit Gesetzen umzugehen, kann wirtschaftlich rentabel sein, wenn Sie sie zumindest verwenden, um Entscheidungen zu rechtfertigen, die gegenüber höheren Behörden getroffen werden.

    Der Artikel ist ein Auszug aus Allan Kellys neuem Buch Xanpan Book 2: A Tool of Production. Wird Ende 2015 verfügbar sein.


    Jetzt auch beliebt: