Wie bringt man ein Entwicklerteam dazu, TDD und CI zu verwenden?

Mit gutem Beispiel vorangehen. Sie können Menschen nicht dazu zwingen, etwas zu tun, woran sie nicht glauben, besonders nicht in Ihrer Rolle. Aber wenn du so arbeitest, wie du es für richtig hältst, und wenn du leise Ergebnisse zeigst, dann solltest du die Leute irgendwann für dich gewinnen. Zwingen Sie niemanden, arbeiten Sie einfach so, wie Sie es für richtig halten, erwähnen Sie Ihre positiven Ergebnisse und zeigen Sie ihnen bei Interesse mehr.

Ich erkannte zum ersten Mal die Leistungsfähigkeit von TDD, als einer aus meinem Team darauf bestand, es für seine eigene Arbeit zu tun. Ich dachte, er würde Zeit verschwenden, aber ich vertraute ihm genug, um ihn so arbeiten zu lassen, wie er es für richtig hielt. Dann zeigte er mir eines Tages Dutzende von Fehlern, die er in unserer Software gefunden und stillschweigend korrigiert hatte. Er hatte diese gefunden, weil er das Verhalten des Codes, mit dem er arbeitete, überprüfen wollte, Tests dafür geschrieben und Lücken gefunden hatte. Er hat in diesem Moment nicht das ganze Team bekehrt, aber er hat mich bekehrt. Ich bin mir sicher, dass er es auch für andere Leute getan hat ... nur leise.

Sehen Sie sich in diesem Zusammenhang dieses Video von Dan North und insbesondere Geschichte Nr. 3, The Coach, an. http://www.infoq.com/presentations/interactions-career

Meiner Erfahrung nach ist dies ein jahrelanger Prozess. Entwickler, die „Quality Build In“ nicht in ihrem täglichen Prozess praktizieren, werden dies als zusätzliche Arbeit empfinden. Sie programmieren lieber...

Qualität eingebaut

Lean-Manufacturing-Unternehmen werden Qualität so weit wie möglich in ihre Prozesse integrieren. Indem Sie Qualität in Ihren Prozess integrieren, vermeiden Sie unnötige Nacharbeit und Ausschuss. Das bedeutet, dass Ihre Maschinen Anomalien erkennen können (Jidoka) und Ihre Vorrichtungen fehlersicher sind, um Fehlmontagen zu vermeiden (Poka Yoke).

Verpflichtung des Managements

Aus meiner Sicht sollte dies die Vision des Managements sein, sie sollten diesen Teams vermitteln, dass dies von ihnen erwartet wird.

Denken Sie daran, dass automatisiertes Testen kurzfristig zusätzlichen Aufwand verursacht, während es auf lange Sicht wirklich agil und schlank ist. Die Entwicklerzeit verteilt sich zu 33 % auf Anforderungen, 33 % auf Programmierung und 33 % auf automatisierte Tests. Dies wird das Team verlangsamen und dies könnte ein Problem darstellen, wenn das Management nicht daran beteiligt ist.

• Erklären Sie, warum dies eine gute Praxis ist
• Geben Sie dem Team Zeit, damit zu experimentieren, automatisierte Tests zu schreiben und durchzuführen
• Legen Sie realistische Ziele für die Erhöhung der Codeabdeckung pro Release/Zyklus fest

Ein ergebnisorientierter Ansatz

Ich bin ein Softwareentwicklungsprogramm-Manager, der viele der Vorteile der testgetriebenen Entwicklung und der kontinuierlichen Integration erlebt hat. Aber einige der Entwicklerteams, mit denen ich zusammenarbeite, befolgen diese Praktiken nicht. Es steht mir nicht zu, ihnen zu sagen, wie sie ihre Arbeit machen sollen, aber wie kann ich sie ermutigen, diese Praktiken anzunehmen, ohne die Grenzen meiner Rolle zu überschreiten?

Auch wenn Sie möglicherweise nicht in der Lage sind, gute Arbeitspraktiken vorzuschreiben, sind Sie wahrscheinlich in der Lage, einen ergebnisorientierten Ansatz voranzutreiben. Im Allgemeinen sind TDD und CI Praktiken, die darauf abzielen, die Fehlerquote zu reduzieren, und darauf sollten Sie sich konzentrieren.

Als ein Beispiel könnten Sie ein Tortendiagramm erstellen, das zeigt, wie viel Zeit für die Behebung von Fehlern aufgewendet wird, anstatt neue Funktionen auf der grünen Wiese zu entwickeln. Indem Sie die Fehlerquoten zu sichtbaren Kosten für die Entwickler machen (die im Allgemeinen lieber an neuen Funktionen arbeiten als Fehler zu beheben), schaffen Sie einen Anreiz für die Entwickler, ihren Arbeitsablauf zu überprüfen und anzupassen.

Es geht hier nicht darum, „Menschen zur Rechenschaft zu ziehen“. Das Ziel besteht vielmehr darin, eine kausale Verbindung herzustellen, die den Entwicklern hilft, die natürlichen Konsequenzen ihrer aktuellen Entwicklungspraktiken zu erkennen. Dies ist möglicherweise alles, was erforderlich ist, um Veränderungen einzuladen.

Beachten Sie, dass es Ihnen am Ende des Tages wahrscheinlich egal sein sollte , ob sie Software mit TDD und CI schreiben oder Code auf Steintafeln mit Keilschrift schreiben. Was Ihnen wirklich wichtig ist, ist die Softwarequalität und die Effizienz der Bereitstellung, und Sie sollten auf jeden Fall vernünftige Ziele für diese beiden Dinge haben. Es liegt dann am Entwicklungsteam, ob es die Dinge einfach oder auf die harte Tour machen möchte; Sie können eine Anleitung geben, wenn sie es annehmen, aber Sie müssen einige Leute lernen lassen, indem sie ihre eigenen Fehler machen.

Konzentrieren Sie sich auf greifbare Ergebnisse (z. B. Fehlerquoten oder Durchlaufzeiten von Funktionen). Setzen Sie vernünftige Ziele für Ihre Projekte. Fordern Sie Ihre Teams auf, ihre Prozesse oder Toolchains zu verbessern, wenn sie die angemessenen Erwartungen nicht erfüllen. Sie können Menschen nicht vor sich selbst schützen, aber Sie können berufliches Wachstum fördern, insbesondere wenn Sie die Zeit, das Geld und die Ausrüstung bereitstellen, die für die Umsetzung echter Prozessänderungen erforderlich sind.