Projekt Unicorn. Gene Kim
wäre großartig! Wow, ich bin begeistert, Maxine«, sagt Randy. »Ich bekomme normalerweise nie irgendwelche Senior Engineers dazu, an diesen Problemen zu arbeiten. Alle Entwickler, die etwas taugen, werden immer von anderen Teams abgeworben. Sie werden mit der Arbeit an Features, die die Kunden zu Gesicht bekommen, weggelockt, anstatt an langweiliger Infrastruktur zu arbeiten … So, wo ist Josh bloß?«, murmelt er und sieht sich um. »Hier laufen so viele Freelancer und Berater herum, dass es manchmal schwierig ist, die eigenen Mitarbeiter zu finden.«
In diesem Moment kommt ein junger Kerl mit Laptop vorbei und setzt sich an den Schreibtisch neben ihnen. »Tut mir leid, dass ich zu spät bin, Randy. Ich habe mich um den Build-Crash von gestern Abend gekümmert. Einige Entwickler haben mit ihren Änderungen den ganzen Build korrumpiert. Ich bin noch dabei, das genauer zu prüfen.«
»Ich helfe dir gleich, Josh. Aber ich möchte dir zuerst Maxine Chambers vorstellen.« Randy zeigt auf Maxine.
Maxine muss zweimal hinschauen. Josh sieht kaum älter aus als ihre Tochter. Sie könnten Klassenkameraden an derselben Schule sein. Randy hat keine Witze gemacht, als er von »jungen Leuten« in seinem Team gesprochen hat.
»Maxine ist Senior Engineer und uns für ein paar Monate zugeteilt. Sie ist die leitende Architektin des MRP-Systems. Kannst du ihr zeigen, was sie wissen muss, damit sie hier produktiv werden kann?« »Äh, hi, Mrs. Chambers. Schön, Sie kennenzulernen«, sagt er, streckt die Hand aus und schaut irritiert. Er fragt sich wahrscheinlich, wie er dazu gekommen ist, für jemanden verantwortlich zu sein, der seine Mutter sein könnte, denkt sie.
»Schön, Sie kennenzulernen«, sagt sie lächelnd. »Bitte nennen Sie mich einfach Maxine«, fügt sie hinzu, auch wenn es sie normalerweise ärgert, wenn die Freunde ihrer Töchter sie beim Vornamen nennen. Aber Josh ist ein Arbeitskollege, und sie ist froh, einen einheimischen Guide zu haben, der sie herumführen kann. Auch wenn er nicht alt genug sein dürfte, um schon Auto zu fahren, amüsiert sie sich.
»Okay, lassen Sie es mich wissen, wenn Sie etwas brauchen«, sagt Randy. »Maxine, ich freue mich darauf, Sie dem Rest des Teams vorzustellen. Unsere nächste Mitarbeiterversammlung ist kommende Woche.«
Randy wendet sich an Josh. »Erzähl mir mehr über die Probleme mit dem Build.«
Maxine hört aufmerksam zu. All diese Geschichten darüber, dass sich die technischen Praktiken im Phoenix-Projekt auf Höhlenmenschen-Niveau bewegen, sind tatsächlich wahr. Sie hat im Lauf ihrer Karriere gelernt, dass die Katastrophe nicht lange auf sich warten lässt, wenn die Leute ihre Builds nicht konsistent durchführen können.
Sie sieht sich auf der Etage um. Über 100 Entwickler tippen und arbeiten auf ihren Laptops an ihren eigenen kleinen Systembereichen. Ohne ständiges Feedback durch ein zentralisiertes Build-, Integrations- und Testsystem haben sie alle nicht die geringste Ahnung davon, was passiert, wenn ihre eigene Arbeit mit der aller anderen Entwickler gemergt wird.
Josh dreht seinen Stuhl zu Maxine um. »Mrs. Chambers, ich muss Randy etwas zeigen, aber ich habe Ihnen gerade gemailt, was wir an Dokumentation für neue Entwickler haben – es gibt Wiki-Seiten, auf denen ich alle bisherigen Versionshinweise und die Dokumentation der Entwicklungsteams zusammengestellt habe. Es gibt auch Links zu den Punkten, die wir noch umsetzen müssen. Hoffentlich hilft das für den Anfang?«
Maxine stimmt ihm mit erhobenem Daumen zu. Nachdem die beiden gegangen sind, loggt sie sich mit ihrem neuen Laptop ein und kann direkt auf ihre E-Mails zugreifen – wie durch ein Wunder gleich beim ersten Mal. Aber bevor sie sich anschaut, was Josh ihr geschickt hat, stöbert sie ein bisschen herum, um zu sehen, was sonst noch auf ihrem neuen Laptop ist.
Sofort ist sie verwirrt. Sie findet Links zu HR-Systemen, Netzwerkfreigaben zu diversen Unternehmensressourcen, Links zum Spesenabrechnungssystem, zur Gehaltsabrechnung, zu Zeiterfassungssystemen … Sie stößt auf Microsoft Word und Excel und den Rest der Office-Suite.
Sie runzelt die Stirn. Das passt für jemanden im Finanzwesen, denkt sie, aber nicht für einen Developer. Es sind weder Entwicklertools noch Codeeditoren noch Versionsverwaltungen installiert. Sie öffnet ein Terminalfenster und stellt wie schon erwartet fest, dass es keine Compiler, kein Docker, kein Git gibt – nichts davon ist installiert. Nicht einmal Visio oder OmniGraffle!
Du meine Güte! Was wird hier eigentlich von neuen Entwicklern erwartet? Dass sie E-Mails lesen und Memos schreiben?
Wenn man Klempner oder Schreiner beauftragt, geht man davon aus, dass sie ihr eigenes Werkzeug mitbringen. Aber in einer Softwareorganisation mit mehr als einem Entwickler nutzt das gesamte Team gemeinsame Werkzeuge, um produktiv zu sein. Anscheinend ist hier beim Phoenix-Projekt der Werkzeugkasten leer.
Sie öffnet ihren E-Mail-Client, um nachzusehen, was Josh geschickt hat. Dabei landet sie auf einer internen Wiki-Seite, einem Tool, das viele Entwickler benutzen, um gemeinsam an Dokumentationen zu arbeiten. Sie versucht, in der Wiki-Seite hinauf- und hinunterzuscrollen, aber das Dokument ist so kurz, dass es nicht einmal eine Bildlaufleiste gibt.
Sie starrt ziemlich lange auf den fast leeren Bildschirm. Geh zur Hölle, Chris, denkt sie.
Von makabrer Neugier getrieben, wühlt Maxine die nächste halbe Stunde weiter. Sie klickt sich hin und her, findet aber lediglich eine Handvoll Dokumente. Sie liest PowerPoint-Folien mit Architekturdiagrammen, viele Besprechungsnotizen und Sprint-Retrospektiven sowie ein drei Jahre altes Dokument mit Anforderungen an das Produktmanagement. Sie ist begeistert, als sie verlockende Verweise auf einige Testpläne findet, aber als sie auf die Links klickt, wird sie von einem Authentifizierungsbildschirm aufgefordert, Log-in und Passwort einzugeben.
Anscheinend braucht sie Zugang zu den QA-Servern.
Sie öffnet eine neue Notiz auf ihrem Laptop und hält mit einem Hinweis an sich selbst fest, dass sie jemanden finden muss, der ihr den Zugang ermöglicht.
Sie beschließt, es mit der Dokumentation für den Moment gut sein zu lassen und die Quellcode-Repositories zu suchen. Entwickler schreiben Code, und Code landet normalerweise in Repositories. Es gibt Entwickler, die an Phoenix arbeiten, also muss es hier irgendwo auch ein Phoenix-Quellcode-Repo geben, denkt sie.
Zu ihrer Überraschung kann sie trotz fast zehnminütiger Suche nichts finden. Sie ergänzt ihre Notizen:
Phoenix-Quellcode-Repo lokalisieren.
Sie findet Links zu internen SharePoint-Dokumentationsservern, auf denen vielleicht Hinweise zu finden wären, aber sie hat keine Konten auf diesen Servern.
Sie tippt noch eine Notiz:
Zugang zum SharePoint-Server DEVP-101.
Die ganze nächste Stunde geht es so weiter – Suchen. Nichts. Suchen. Nichts. Suchen. Klick. Log-in-Screen. Klick. Log-in-Screen.
Jedes Mal fügt sie ihrer wachsenden Liste eine weitere Notiz hinzu:
Zugang zum SharePoint-Server QA-103.
Zugang zur Netzwerkfreigabe PUL-QA-PHOENIX.
Zugang zur Netzwerkfreigabe PUL-DEV-PHOENIX.
Sie fügt weitere Notizen und Aufgaben hinzu, legt eine Liste mit Benutzerkonten an, die sie benötigt, ergänzt den QA-Wiki-Server, den Performance-Engineering-Wiki-Server, das Wiki für mobile Anwendungen und eine Reihe anderer Gruppen mit Akronymen, auf die sie sich noch keinen Reim machen kann.
Sie braucht Log-in-Daten fürs Netzwerk. Sie braucht Installer für all die erwähnten Tools. Sie braucht Lizenzschlüssel.
Maxine schaut auf die Uhr und wundert sich, dass es schon fast eins ist. Sie hat in zwei Stunden nichts erreicht, außer 32 Dinge aufzuschreiben, die sie unbedingt braucht. Und sie weiß immer noch nicht, wo sich die Entwicklungswerkzeuge oder die Quellcode-Repos befinden.
Wäre die Phoenix-Entwicklung ein Produkt, wäre es das schlechteste Produkt aller Zeiten.
Aber jetzt braucht sie erst mal was zu essen. Sie schaut sich in der fast leeren Etage um, und ihr wird klar, dass sie die Mittagspause verpasst hat.