In diesem Beitrag erzählt unser Kollege Thiago Garcia Da Silva über die Erfahrungen unseres Tech-Teams, die es bei der Umstellung auf die Arbeit im Homeoffice gesammelt hat. Er stellt kurz ihre Prozesse und die Tools vor, die seit dem dabei zum Einsatz kommen.
Seit dem Beginn der Pandemie im Jahr 2020 arbeitet das gesamte Team von metr im Homeoffice und hier möchte ich speziell auf die Erfahrungen des technischen Teams eingehen. Wir waren vorher ein sehr büro-basiertes Team, daher war der Wechsel zum Homeoffice nicht ganz einfach, aber wir haben die Gelegenheit genutzt und versucht, das Beste daraus zu machen. Seit dem ersten Tag haben wir unsere Arbeit im Homeoffice nie als eine vorübergehende Sache geplant, auch wenn wir nicht wussten, ob wir ins Büro zurückkehren würden.
Ein gutes Beispiel dafür, warum wir ein sehr büro-basiertes Team waren, war unser Sprint-Board: eine riesige Tafel mit lauter Klebezetteln, auf die wir sehr stolz waren. Uns gefiel es, echte Dinge zu bewegen. Zu unserem Glück haben wir eine Woche, bevor wir wussten, dass wir ab sofort remote arbeiten mussten, alles zu GitHub verlagert, und das war der Beginn unserer aktuellen Arbeitsweise.
Neue Arbeitsweise
Die Umstellung auf GitHub war nicht nur eine gute Entscheidung, sondern der Beginn einer kompletten Überarbeitung unserer bisherigen Arbeitsweise. Wir nutzten alles, was dort verfügbar war, und machten GitHub zum zentralen Ort für unsere Kommunikation, sowohl asynchron als auch synchron. Wir beschlossen, dass unsere Kommunikation auch dort stattfinden sollte, da sie sich hauptsächlich um den Code dreht, der nun auch dort verortet war. Das Tool “Slack” wurde für direkte Nachrichten und Ankündigungen beibehalten. Wir haben dort nur selten einen Thread, um zum Beispiel ein Problem oder etwas, das mit Code im Allgemeinen zu tun hat, zu diskutieren.
Wir haben unser altes physisches Sprint-Board gegen die Projektboard-Funktion von GitHub ausgetauscht. Und wir nutzen es, um den Überblick über das Scrum/Kanban-Board zu behalten: wer macht was, welche Aufgaben werden erledigt, was ist bereits abgeschlossen. Es funktioniert gut, man organisiert die Aufgaben in den Spalten, wie in jedem anderen Board. Es ist auch möglich, einige nützliche Automatisierungen vorzunehmen, wie z. B. das Verschieben von Spalten, wenn ein Ticket geschlossen wird. Wir haben dort einige Boards, um verschiedene Stufen unseres Prozesses zu verfolgen. Wir haben zum Beispiel eines, um Tickets zu erfassen, die verfeinert werden müssen oder Ideen für die Zukunft sind und ein weiteres nur für den aktuellen Sprint. Wir haben auch Boards für andere Teams. Ein Beispiel ist das Operations-Team, das die Arbeit an den m-gates vor Ort gemeinsam mit uns verfolgen und organisieren muss.
In diesem Beitrag erzählt unser Kollege Thiago Garcia Da Silva über die Erfahrungen unseres Tech-Teams, die es bei der Umstellung auf die Arbeit im Homeoffice gesammelt hat. Er stellt kurz ihre Prozesse und die Tools vor, die seit dem dabei zum Einsatz kommen.
Seit dem Beginn der Pandemie im Jahr 2020 arbeitet das gesamte Team von metr im Homeoffice und hier möchte ich speziell auf die Erfahrungen des technischen Teams eingehen. Wir waren vorher ein sehr büro-basiertes Team, daher war der Wechsel zum Homeoffice nicht ganz einfach, aber wir haben die Gelegenheit genutzt und versucht, das Beste daraus zu machen. Seit dem ersten Tag haben wir unsere Arbeit im Homeoffice nie als eine vorübergehende Sache geplant, auch wenn wir nicht wussten, ob wir ins Büro zurückkehren würden.
Ein gutes Beispiel dafür, warum wir ein sehr büro-basiertes Team waren, war unser Sprint-Board: eine riesige Tafel mit lauter Klebezetteln, auf die wir sehr stolz waren. Uns gefiel es, echte Dinge zu bewegen. Zu unserem Glück haben wir eine Woche, bevor wir wussten, dass wir ab sofort remote arbeiten mussten, alles zu GitHub verlagert, und das war der Beginn unserer aktuellen Arbeitsweise.
Neue Arbeitsweise
Die Umstellung auf GitHub war nicht nur eine gute Entscheidung, sondern der Beginn einer kompletten Überarbeitung unserer bisherigen Arbeitsweise. Wir nutzten alles, was dort verfügbar war, und machten GitHub zum zentralen Ort für unsere Kommunikation, sowohl asynchron als auch synchron. Wir beschlossen, dass unsere Kommunikation auch dort stattfinden sollte, da sie sich hauptsächlich um den Code dreht, der nun auch dort verortet war. Das Tool “Slack” wurde für direkte Nachrichten und Ankündigungen beibehalten. Wir haben dort nur selten einen Thread, um zum Beispiel ein Problem oder etwas, das mit Code im Allgemeinen zu tun hat, zu diskutieren.
Wir haben unser altes physisches Sprint-Board gegen die Projektboard-Funktion von GitHub ausgetauscht. Und wir nutzen es, um den Überblick über das Scrum/Kanban-Board zu behalten: wer macht was, welche Aufgaben werden erledigt, was ist bereits abgeschlossen. Es funktioniert gut, man organisiert die Aufgaben in den Spalten, wie in jedem anderen Board. Es ist auch möglich, einige nützliche Automatisierungen vorzunehmen, wie z. B. das Verschieben von Spalten, wenn ein Ticket geschlossen wird. Wir haben dort einige Boards, um verschiedene Stufen unseres Prozesses zu verfolgen. Wir haben zum Beispiel eines, um Tickets zu erfassen, die verfeinert werden müssen oder Ideen für die Zukunft sind und ein weiteres nur für den aktuellen Sprint. Wir haben auch Boards für andere Teams. Ein Beispiel ist das Operations-Team, das die Arbeit an den m-gates vor Ort gemeinsam mit uns verfolgen und organisieren muss.
Eine neue Form der Kommunikation
Ich denke, dass es bis zu diesem Zeitpunkt keine großen Auswirkungen auf unsere Prozesse hatte, es war immer noch das gleiche Board, das wir früher hatten. Die Veränderung kam, als wir begannen, alle unsere Diskussionen in die Tickets (sogenannte Issues) und Pull Requests (PR) zu verlagern. Nun fand die Konversation zwischen unserem Product Owner und den Entwicklern hauptsächlich in den Issue- und PR-Kommentaren statt, und zwar asynchron. Dadurch konnten sich die Mitarbeiter nicht nur mehr auf ihre Arbeit konzentrieren, sondern es entstand auch eine „automatische“ Dokumentation, die Informationen darüber enthält, was getan wurde und wann es geschah. Wir haben einen weiteren Beitrag darüber geschrieben, wie wir “Commits” anstelle von Code-Kommentaren verwenden, und jetzt ist dieses Tool sogar noch leistungsfähiger.
Um nun weitere Informationen über den Code zu finden, muss man einfach einen Blick in seine Historie werfen. Da diese Codezeile einen Commit hat, gehört dieser Commit zu einem PR und der PR steht in Verbindung mit einem Issue. Es ist möglich, alle Entscheidungen nachzuvollziehen, die getroffen wurden, um zu dieser Lösung zu kommen. Das macht das Entwickeln viel einfacher. Meistens muss man niemanden um Hilfe bitten, weil man direkten Zugang zu dem hat, was man sucht.
Verbesserte Dokumentation
Ich glaube nicht, dass das ohne die Arbeit im Homeoffice möglich gewesen wäre. Im Büro ist es fast unmöglich, den Drang zu kontrollieren, etwas mit jemandem zu besprechen. Diese Art von Gespräch geht dann verloren und ist für den Rest des Teams und für die Zukunft unzugänglich. Nachdem wir erkannt hatten, wie leistungsfähig und organisiert unsere asynchrone Kommunikation ist, begannen wir, uns bewusster zu machen, wie wir PRs einreichen und öffnen. Das Verfassen von Texten ist wichtiger geworden, und die Suche nach dem besten Weg, Informationen weiterzugeben, ist jetzt Teil unserer Arbeit. Es gibt mehr PRs mit Screenshots und besseren, klareren Beschreibungen. Und nicht nur unsere PRs und Issue-Beschreibungen haben sich verbessert. Es gibt mehr Wiki-Einträge, Dokumentationen darüber, wie man etwas tut, das man einmal entdeckt hat. Dies ist für das gesamte Team zugänglich. Die Konsequenz ist, dass diese Änderung den Bedarf an Anrufen bei den Teamkollegen senkt, um zu fragen, wie etwas zu tun ist.
Nicht alles hat sich verändert
Wir führen immer noch einige wenige Besprechungen durch, die wir nicht ausfallen lassen möchten. Und nicht alle Kommunikationen sind asynchron. Es gibt immer noch einige private Nachrichten in Slack, die eigentlich ihren Weg in einen öffentlichen Thread finden sollten, um für das gesamte Team zugänglich zu sein. Wir sind immer noch dabei, uns anzupassen.
Meiner Meinung nach sind wir ein echtes Remote-Team geworden. Wir nutzen die Vorteile, die uns die Online-Kommunikation bieten kann. Wir versuchen, mehr mit allen zu teilen, weniger privates Wissen zu haben und dadurch unserem Team mehr Kontrolle über ihre eigene Zeit zu geben.
Der Beitrag erschien im Original (in englischer Sprache) auf unserem Medium-Blog.
Weitere Blogbeiträge, die Sie interessieren könnten
Datenschutz bei der Digitalisierung der Wohnungswirtschaft
Laut dem Statistischen Bundesamt gab es im Jahr 2020 108.474 polizeilich erfasste Fälle von Cyberkriminalität. Es wird davon ausgegangen, dass die Dunkelziffer noch weitaus höher ist. Die Schadenssumme durch Datendiebstahl, Industriespionage oder Sabotage in Unternehmen in Deutschland lag im Jahr 2021 insgesamt bei 223,5 [...]
Eine neue Form der Kommunikation
Ich denke, dass es bis zu diesem Zeitpunkt keine großen Auswirkungen auf unsere Prozesse hatte, es war immer noch das gleiche Board, das wir früher hatten. Die Veränderung kam, als wir begannen, alle unsere Diskussionen in die Tickets (sogenannte Issues) und Pull Requests (PR) zu verlagern. Nun fand die Konversation zwischen unserem Product Owner und den Entwicklern hauptsächlich in den Issue- und PR-Kommentaren statt, und zwar asynchron. Dadurch konnten sich die Mitarbeiter nicht nur mehr auf ihre Arbeit konzentrieren, sondern es entstand auch eine „automatische“ Dokumentation, die Informationen darüber enthält, was getan wurde und wann es geschah. Wir haben einen weiteren Beitrag darüber geschrieben, wie wir “Commits” anstelle von Code-Kommentaren verwenden, und jetzt ist dieses Tool sogar noch leistungsfähiger.
Um nun weitere Informationen über den Code zu finden, muss man einfach einen Blick in seine Historie werfen. Da diese Codezeile einen Commit hat, gehört dieser Commit zu einem PR und der PR steht in Verbindung mit einem Issue. Es ist möglich, alle Entscheidungen nachzuvollziehen, die getroffen wurden, um zu dieser Lösung zu kommen. Das macht das Entwickeln viel einfacher. Meistens muss man niemanden um Hilfe bitten, weil man direkten Zugang zu dem hat, was man sucht.
Verbesserte Dokumentation
Ich glaube nicht, dass das ohne die Arbeit im Homeoffice möglich gewesen wäre. Im Büro ist es fast unmöglich, den Drang zu kontrollieren, etwas mit jemandem zu besprechen. Diese Art von Gespräch geht dann verloren und ist für den Rest des Teams und für die Zukunft unzugänglich. Nachdem wir erkannt hatten, wie leistungsfähig und organisiert unsere asynchrone Kommunikation ist, begannen wir, uns bewusster zu machen, wie wir PRs einreichen und öffnen. Das Verfassen von Texten ist wichtiger geworden, und die Suche nach dem besten Weg, Informationen weiterzugeben, ist jetzt Teil unserer Arbeit. Es gibt mehr PRs mit Screenshots und besseren, klareren Beschreibungen. Und nicht nur unsere PRs und Issue-Beschreibungen haben sich verbessert. Es gibt mehr Wiki-Einträge, Dokumentationen darüber, wie man etwas tut, das man einmal entdeckt hat. Dies ist für das gesamte Team zugänglich. Die Konsequenz ist, dass diese Änderung den Bedarf an Anrufen bei den Teamkollegen senkt, um zu fragen, wie etwas zu tun ist.
Nicht alles hat sich verändert
Wir führen immer noch einige wenige Besprechungen durch, die wir nicht ausfallen lassen möchten. Und nicht alle Kommunikationen sind asynchron. Es gibt immer noch einige private Nachrichten in Slack, die eigentlich ihren Weg in einen öffentlichen Thread finden sollten, um für das gesamte Team zugänglich zu sein. Wir sind immer noch dabei, uns anzupassen.
Meiner Meinung nach sind wir ein echtes Remote-Team geworden. Wir nutzen die Vorteile, die uns die Online-Kommunikation bieten kann. Wir versuchen, mehr mit allen zu teilen, weniger privates Wissen zu haben und dadurch unserem Team mehr Kontrolle über ihre eigene Zeit zu geben.
Der Beitrag erschien im Original (in englischer Sprache) auf unserem Medium-Blog.
Weitere Blogbeiträge, die Sie interessieren könnten
Datenschutz bei der Digitalisierung der Wohnungswirtschaft
Laut dem Statistischen Bundesamt gab es im Jahr 2020 108.474 polizeilich erfasste Fälle von Cyberkriminalität. Es wird davon ausgegangen, dass die Dunkelziffer noch weitaus höher ist. Die Schadenssumme durch Datendiebstahl, Industriespionage oder Sabotage in Unternehmen in Deutschland lag im Jahr 2021 insgesamt bei 223,5 [...]
Über das Pair-Programming bei metr
Unsere Kollegin Alina Cucu, Backend Software Developer in unserem Tech-Team, gibt in diesem Beitrag einen Einblick in das Pair-Programming bei metr. Was Pair-Programming mit Philosophie zu tun hat und warum Code manchmal erst reifen muss, erfahren Sie in ihrem Beitrag. Ich bin jetzt [...]