Über das Wie und Warum von Code kann viel diskutiert werden. In einem gewissen Rahmen ist das auch gut.
Aber darüber hinaus wollen Sie, dass Ihr Team sich einigt und sich dann alle an die Regeln halten.
Beispiele sind Formatierung, Einrückung, Namensgebung und Länge von Methoden, Funktionen und Dateien.
In den meisten Entwicklungsumgebungen können Sie Code-Standards erzwingen, beispielsweise mit Rubocop in Ruby on Rails – Projekten.
Ihr Team muss wissen, ob nach einer Änderung noch alles funktioniert. Das erreichen Sie nur durch eine hohe Test-Coverage. Und die Tests müssen nach jeder Änderung und vor jedem Deploy auch laufen.
Stellen Sie sicher, dass Sie ein CI – Setup haben und Ihr Team auch ausreichend Zeit und Liebe in Tests steckt.
Die Regel: If there is no test, it is broken.
Ja, Sie können auch alles selber machen. Und wenn Ihr Team groß und fähig genug ist, kann das eine gute Idee sein. Aber für kleinere und agile Teams lautet die Empfehlung: Benutzen Sie einen Cloud – Anbieter wie Heroku und verbringen Sie Ihre Zeit nicht mit dem Warten von Systemen
Paircoding ist so gesund wie Yoga und frische Luft. Es löst viele Probleme auf einmal:
Ihr Team kommt zusammen, mehr als eine Person kennt den Code, Fehler werden frühzeitig vermieden und das alles noch positiv aufgeladen.
Erlauben Sie Paircoding und sorgen Sie dafür, dass es auch gemacht wird.
Code Review ist notwendig!
Erstens macht jeder Fehler und zweitens jeder andere kann diese finden. Und zweitens ist es – nach dem Paircoding – der einzige Ort, wo alles nochmal aufeinander abgestimmt werden kann.
Sorgen Sie dafür, dass kein Code deployed wird, der nicht mindestens von einer Person und besser von mehreren gemeinsam gelesen wurde.
Code veraltet. Dadurch steigt die Komplexität, die Kosten, Entwicklungszeit und die Unzufriedenheit im Team.
Planen Sie Refactoring ein – und zwar von Anfang an. Einen Tag pro 2 Wochen beispielsweise. Oder wenn Sie mit Scrum arbeiten: Eine bestimmte Menge Storypoints pro Sprint.
Sorgen Sie dafür, dass Wissen augeschrieben wird. Das fängt mit der README an: Alles, was nötig ist , um die Anwendung zu betreiben muss dokumentiert werden. Etablieren Sie ein Developer-Blog und geben Sie dem Team Raum über Gelerntes zu sprechen.
Machen Sie sich nichts vor: Nur mit Druck und Terminen wird Software nicht entwickelt. Vereinbaren Sie Deadlines, das ist Gesund. Aber halten Sie diese weich und gestalten Sie Ihren Prozess so, dass Ihr Team weiß: Qualität und Funktionalität stehen im Vordergrund.
Zuerst: Schreiben Sie Ihre User Stories so gut und idiotensicher wie möglich auf.
Aber dann: Etablieren Sie in Ihrem Team die Erkenntnis, dass es keine perfekte Story gibt.
Sie können von Ihren Entwicklerinnen erwarten, dass diese eine unfertige oder fehlerhafte Aufgabenbeschreibung ergänzen und korrigieren.
Gestatten Sie Änderungen und sorgen Sie dafür, dass diese vom Team kommen.
Projektmanager lieben es, wenn jede Aufgabe einer Person zugewiesen ist. So können Sie immer jemanden fragen, was gerade der Status ist. Lassen Sie das. Fragen Sie das Team.
Und machen Sie dem Team klar, dass ALLE dafür verantwortlich sind, dass jeder Sprint oder jeder Release erfolgreich wird.
Dadurch werden Sie auch die meisten zwischenmenschlichen Probleme im Team in den Griff bekommen.