Tipps & Tricks zum Homeoffice: Teil 2

COVID-19: Entwickler müssen sich für die Zusammenarbeit in einer All-Remote-Welt entscheiden
Keine Kommentare

Wir Software-Entwickler arbeiten nicht genug zusammen. Dieser Artikel geht der Frage auf den Grund, was die Leistung von Entwicklerteams verbessert und warum unsere Arbeitskultur aus Wettbewerbsgründen gegen einen stärker kollaborativen Ansatz resistent war.

Einführung

Im ersten Teil dieser Serie haben wir darüber gesprochen, wie wir persönliche und menschliche Aspekte unseres Lebens im Homeoffice berücksichtigen müssen, die nicht nur mit dem Geschäft oder unserer Karriere zu tun haben. Wir wiesen auch darauf hin, dass es ein Privileg ist, ein Software-Entwickler zu sein, und wir die Möglichkeit haben, einen Beitrag zur Gesellschaft zu leisten, während wir von zu Hause aus arbeiten. Herausfordernde Zeiten sind oft der richtige Zeitpunkt, um das, was wir für selbstverständlich halten, neu zu überdenken. Wir glauben, dass es Raum für Verbesserungen in unseren Software-Entwicklungsprozessen gibt. Jetzt ist ein guter Zeitpunkt, damit zu beginnen.

In diesem Artikel werden wir uns damit befassen, was die Leistung von Entwicklerteams verbessern kann und wie unsere Kultur sich gegen einen stärker kooperativen Ansatz gewehrt hat. Wir werden darauf eingehen, wie wir bei CodeStream gelernt haben, diese Probleme anzugehen, und die Auswirkungen, die wir als Ergebnis unseres Ansatzes sehen.

Wir arbeiten nicht genügend zusammen

In den vergangenen zwei Jahren haben wir mit etwa 2.000 Software-Entwicklungsteams gesprochen, um zu verstehen, wie ihr Toolset, ihr Workflow und die Möglichkeiten zur Leistungsverbesserung aussehen. Wenn Sie wie über 80% der Teams sind, mit denen wir Kontakt hatten, dann sehen Ihr Toolset und Ihr Workflow so aus:

  • Das Team plant den Sprint an einem Montag, und die Entwickler konzentrieren sich meist bis zum Ende des Sprints auf Ihre Aufgaben. In der Regel ist das eine Woche mit relativ wenig Zusammenarbeit, bis der Code fertig ist.
  • Sie stellen ad-hoc Fragen, manchmal an den Entwickler, der neben Ihnen sitzt, manchmal über Slack oder Microsoft Teams. Meistens versuchen Sie jedoch einfach, es selbst herauszufinden. Es gibt keine Anreize zur Zusammenarbeit, außer zur Codeüberprüfung.
  • Sie verwenden GitHub, GitLab oder Bitbucket für die Versionskontrolle und die Codeüberprüfung.
  • Sie weisen die Aufgaben über Jira, Trello, Asana oder ähnlichen Tools zu. Meistens beginnen alle Zuweisungen in Ihrem Aufgabenverwaltungssystem, sie erledigen Ihre Arbeit weitgehend ohne Zusammenarbeit mit ihren Kollegen.
  • Insgesamt haben Sie nur wenig Einblick in die Arbeit Ihrer Teamkollegen.

Wir sind an die Abläufe gewöhnt und sehen sie als sinnvoll an. Welche Teile des Prozesses können in einer ganz anderen Denkweise und in einem anderen Kontext verbessert werden? Wie oft überprüfen Sie mit Ihrem Team oder Ihrem Rezensenten, ob das Feature, mit dem Sie beginnen, auf dem richtigen Weg ist? Wie oft schlagen Sie einem Teamkollegen eine Änderung vor, um die Codequalität zu verbessern?

Wenn eine Antwort nur selten oder sogar nur ein- oder zweimal am Tag erfolgt, handelt es sich nicht um einen optimalen Arbeitsprozess. Insbesondere dann, wenn Sie es gewohnt sind, Probleme durch einfaches Klopfen auf die Schulter oder durch lautes Fragen in einem Raum neben Ihren Teamkollegen zu lösen. In diesem Falle ist ein neuer Ansatz erforderlich. Lassen Sie uns jeden der oben genannten Punkte aus einem mehr kollaborativen Blickwinkel betrachten.

International JavaScript Conference

Effective Microservices Architecture In Node.js

by Tamar Stern (Palto Alto Networks)

React Components And How To Style Them

by Jemima Abu (Telesoftas)

Angular Camp 2020

Als Online- oder Präsenztraining!

Das 360°-Intensivtraining mit Angular-Koryphäe Manfred Steyer
Präsentiert von Entwickler Akademie

Rückfragen sind keine Schande

Die meisten Entwickler sind stolz darauf, Probleme selbstständig zu lösen. Vielleicht ist es eine Ehrenmedaille. Vielleicht ist es angesichts der Tatsache, dass wir in einem kompetitiven Umfeld leben, auch das Gefühl, dass Nachfragen eine gewisse Schwäche offenbaren. Als Team haben wir bei CodeStream Anreize geschaffen, öfter Fragen zu stellen. So belohnen wir diese Art des Austauschs in der Öffentlichkeit, indem wir über die Teilnahme an unseren wöchentlichen All-Hands-Reports berichten. Ein Kunde von uns plant, einen Teil des Bonus der Entwickler an gelungene Kommunikation zu binden, sei es durch das Stellen einer Frage oder durch die Bereitstellung einer Antwort. Sie sollten sich überlegen, wie Ihre Organisation mehr Offenheit in der Code-Diskussion fördern und Anreize dafür schaffen kann.

In einer dezentralen Arbeitsumgebung sind die heute üblichen Werkzeuge für die Code-Reviews besonders suboptimal. Die Verwendung von Slack oder MS-Teams führt zu einem flüchtigen Austausch, der nicht zum kollektiven Wissen beiträgt und erhebliche Anstrengungen erfordert, um den Kontext bereitzustellen, der durch Kopieren eines Code-Blocks und Einfügen in einen Chatstream entfernt wurde. Da die Frage selbst schnell vom Bildschirm verschwindet und nie wiedergesehen wird, bieten diese Lösungen nicht die Persistenz und Zugänglichkeit, die in einer asynchronen, Remote-Welt erforderlich sind.

Wir haben CodeStream entwickelt, um dieses Problem zu lösen, indem wir Fragen und Antworten an den/die Code-Block(e) anhängen, auf den/die sie sich beziehen, und dann den gesamten Kontext in Slack, MS Teams oder E-Mail freigeben, um Ihre vorhandenen Kommunikationswerkzeuge zu nutzen. CodeStream ist die In-Editor-Brücke, die diese Diskussionen häufiger und nützlicher für das gesamte Team macht.

Die Pull-Anfrage ist großartig. Bei Code-Reviews können wir es besser machen.

Praktisch jedes moderne Entwicklungsteam, mit dem wir seit 2019 gesprochen haben, führt Code-Reviews mit den integrierten Tools von GitHub, GitLab und BitBucket durch. Große Organisationen wie Google und Microsoft haben ihre eigenen Tools zur Durchführung von Code-Reviews entwickelt, die nicht auf PR basieren. Bei Google hat man ein einheitliches Toolset standardisiert, wobei der Schwerpunkt auf der Beschleunigung von Reviews liegt, indem diese so klein wie möglich gehalten werden. Google berichtet, dass die durchschnittliche Code-Prüfung nur 24 Zeilen Code umfasst und innerhalb von 4 Stunden oder weniger in die Produktion überführt wird.

Wir glauben, dass Google die richtige Philosophie und die richtigen Ergebnisse hat. Es gibt viele Vorteile für kleine und schnelle Reviews. Die Produktivität steigt, die Frustration wird verringert und kleine Fehler führen nicht zu großen Verwirrungen. Aber vielleicht am wichtigsten ist, dass es auf diese Weise größeren Entwicklerteams ermöglicht wird, Änderungen mit einem Minimum an Konflikten zusammenzuführen. Was braucht es, damit dies in Ihrer Organisation geschieht? Pull-Requests machen es nicht leicht, den Code zu überprüfen. Zunächst einmal führt die Überprüfung von Code in einem Browser statt in der IDE zu derselben Art von Kontextproblemen, die wir bereits bei Tools wie Slack besprochen haben. Darüber hinaus können Frustration und Aufwand vermieden werden, wenn man frühzeitig und oft nach Reviews fragt, selbst bei nicht freigegebenem Code.

Bei CodeStream haben wir eine Lösung entwickelt, die dies erleichtert. Wir verpacken einfach jede Änderung, die ein Entwickler in seinem Editor vornimmt, organisieren sie, ordnen sie ein und lassen den Entwickler entscheiden, welche Teile zur Überprüfung eingereicht werden sollen. Der Reviewer kann dann alle Änderungen im Kontext in seinem Editor sehen, bei Bedarf Kommentare anhängen und die Arbeit dateiweise genehmigen oder ablehnen. Unser Team führt nun mehr als 10 Überprüfungen pro Tag und Entwickler durch, und unsere Geschwindigkeit hat sich seit Beginn dieses Prozesses um mehr als 20% erhöht.

Transparenz und Sichtbarkeit

Die Arbeit im Homeoffice bringt neue Herausforderungen im Bereich der Präsenz mit sich. Wir können uns nicht nur nicht mehr im Büro sehen, sondern es ist auch schwieriger, ohne die richtigen Tools eine optimale Zusammenarbeit zu gestalten. Um die richtige Arbeitsweise zu erreichen, müssen wir mit einer Philosophie der Transparenz beginnen. In einer Welt, in der wir von verschiedenen Orten aus arbeiten, müssen wir uns dafür entscheiden, dass jeder sehen kann, was wir tun. Ohne dies gibt es zu viel Konflikte und wir verlieren an Bodenhaftung. GitLab hat die Transparenz bekanntlich in ihre Six Values aufgenommen. Wie setzen Sie Transparenz in Ihren Entwicklungsprozess ein, um alle auf die gleiche Seite zu bringen? Das werden wir in Teil 3 dieser Serie behandeln.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -