You Bild it, you Run it, you Own It - Wird der Ansatz bei euch "gesund" gelebt?

[Chris-Info]

Gesundes, neues Jahr zusammen!

Ich hab mal eine Frage bezüglich dem DevOps Motto "You Bild it, you Run it, you Own It". Das lese ich aktuell in relativ vielen Stellenanzeigen.
Grundsätzlich finde ich das Motto, genau wie die DevOps Philosophie dahinter sehr gut.
Bei den Stellenanzeigen, in denen das Motto genannt wird, habe ich aber immer einen eher schlechten Eindruck. Meistens kommt das Motto in Stellenanzeigen vor, die die berühmte ein Mann/Frau IT-Abteilung suchen. Sprich man soll Fullstack Developer und Admin sein, darüber hinaus noch Product Owner etc.
In ein paar Gesprächen (die aber nur relativ wenige waren) hat sich mein Eindruck dann erhärtet, da sich herauskristalisiert hat, dass es zwar Product Owner etc. gibt, die die Entscheidungen vorgeben, die Verantwortung danach aber quasi auf mir als Entwickler lasten soll.

Da das nur meine eigene, mittlerweile sehr negative Wahrnehmung ist, wollte ich mich gern mal möglichst konstruktiv mit euch austauschen, wie ihr mit dem Thema umgeht und wie eure Eindrücke aus Stellenbeschreibungen und Firmenkultur sind.

VG
Chris

[Pixelfuchs]

Meiner Erfahrung nach funktioniert das nur, wenn das Unternehmen sehr groß ist oder die zu entwickelnde Software eine wichtige Kernkomponente des Unternehmens ist. Nur dann gibt es ausreichend Entwicklerkapazitäten (und auch entsprechend eingearbeitete Vertretungen) dafür.

In den meisten Unternehmen gibt es gar nicht so viele Entwickler um diesen Ansatz zu fahren. Oftmals ist es in kleineren Unternehmen so, dass irgendwer mal irgendwas entwickelt hat und der sich dann als einziger Wissensträger weiter darum kümmert. Gerne werden auch Werkstudenten oder Dienstleister eingespannt, um irgendwas initial zu entwickeln. Die Inhouse-IT muss dann den Betrieb machen und betet, dass bloß nichts passiert und die Software nach dem Motto "never change a running system" lange reibungslos weiter läuft. Das bekommt dann gerne in Stellenausschreibungen das Etikett "You Build it, you Run". Das würde ich aber nicht DevOps nennen wollen und von einer professionellen Entwicklung und einem professionellen Softwarelebenszyklus kann man da auch nicht sprechen. Wenn der "Entwickler" (bewusst in Anführungsstriche gesetzt) krank ist oder geht, hat das Unternehmen ein großes Problem.

[pr0gg3r]

vor 7 Stunden schrieb Chris-Info:

dass es zwar Product Owner etc. gibt, die die Entscheidungen vorgeben

Der PO gibt nur das "was" vor, nicht aber das "wie". Das "wie" ist Sache der Entwickler. Dabei legt der PO die Product-Backlog-Items (PBI) vor und priorisiert diese. Die Entwickler können aber das Sprint-Ziel und die dazugehörigen PBI selber beim Sprint-Planning festlegen ("welche PBI wollen und können wir in der nächsten Iteration machen, um was von uns festgelegte Sprint-Ziel zu erreichen?"), wobei der PO natürlich unterstützen und eine Richtung festlegen kann. Hintergrund ist, dass die Entwickler selbstverantwortlich für "ihr" Sprint-Ziel sind (und man mehr Verantwortung für eine Sache zeigt, die man selbst festlegen darf). Der PO hat hier also eigentlich nichts zu entscheiden (außer eben seine PBI zu definieren und zu priorisieren) bzw. bei der Entscheidung zu unterstützen. Soviel zur Theorie, in der Praxis sieht es leider nicht immer so aus.

vor 7 Stunden schrieb Chris-Info:

"You Bild it, you Run it, you Own It".

Nun gibt man natürlich dem Scrum-Team nicht nur die Verantwortung eine Software "nur" zu entwickeln, sondern diese auch zu betreiben und Support etc. dafür zu übernehmen. Kann ja auch Sinn machen (muss es aber nicht). Rein aus Scrum-Sicht würde ich sagen, dass der Betrieb oder auch der Support nicht unbedingt in einen Sprint (und dessen Ziel) reinpasst. (Aber das tun Bugfixes o. ä. Aufgaben ja auch nicht immer 100%ig). Muss man halt handeln (im schlimmsten Fall ist das Sprint-Ziel in Gefahr).

vor 7 Stunden schrieb Chris-Info:

Sprich man soll Fullstack Developer und Admin sein, darüber hinaus noch Product Owner etc.

Ein Scrum-Team benötigt das gesamte Know-How, die Sprint-Ziele zu erreichen (Cross functional team). Das heißt nicht, dass jeder alles können muss. Das heißt aber, dass quer durch die Entwickler alle benötigten Skills vorhanden sein sollten/müssen um Abhängigkeiten nach außen zu minimieren. Es muss also nicht jeder Frontend, Backend, Tester, DevOps, Linux, Kubernetes, Datenbankspezialist etc. sein, aber wenn das nötig ist um ein Sprint-Ziel zu erreichen, ist es natürlich gut, wenn man diese im Team hat.

Da du den PO hier erwähnst. ein PO ist im besten Fall nicht auch ein Entwickler, weil diese unterschiedliche und widersprüchliche Interessen haben können.

vor 7 Stunden schrieb Chris-Info:

die Verantwortung danach aber quasi auf mir als Entwickler lasten soll.

Die Verantwortungen sind ja geteilt. Der Scrum-Master verantwortet die Scrum-Prinzipien und -Werte, der PO verantwortet gegenüber den Stakeholdern das Produkt und dass sich das weiter entwickelt (im besten Fall in die Richtige Richtung) und die Entwickler verantworten das erreichen des Sprint-Zieles und das Produkt-Inkrement. Man kann eher als Entwickler froh sein, dass man "nur" das verantwortet. Mit "You run it" kommt halt noch hinzu, dass zusätzlich der Betrieb verantwortet wird. Das heißt aber nicht, dass es alleine auf deinen Schultern lastet (was natürlich enorm wäre). Deshalb würde ich das gar nicht so streng sehen. Die Skills müssen allerdings natürlich im Team irgendwo stecken.

vor 7 Stunden schrieb Chris-Info:

Da das nur meine eigene, mittlerweile sehr negative Wahrnehmung ist, wollte ich mich gern mal möglichst konstruktiv mit euch austauschen, wie ihr mit dem Thema umgeht und wie eure Eindrücke aus Stellenbeschreibungen und Firmenkultur sind.

Ob die Unternehmen für ihr Team nun ein jemanden suchen der alles kann oder einen Spezialisten, ist ja erst mal "egal". Die Frage ist, was du machen möchtest. Grundsätzlich sind die Anforderungen in den Stellenausschreibungen erst mal immer eher höher angesiedelt, als tatsächlich benötigt. Davor schreckt man natürlich erst ein mal ab, ist aber durchaus nicht ungewöhnlich.

Beispiel meine aktuelle Stelle: Ich habe zwar alles schon mal irgendwo gehört, aber nur in einem wirklich gut und in der Praxis bereits gemacht. Dennoch hat es gepasst und ich mache hauptsächlich die eine Sache. Im Gegensatz dazu meine vorherige Stelle: zig verschiedene Technologien gemacht, von denen aber keine in der Stellenausschreibung erwartet wurde.

[allesweg]

vor 9 Stunden schrieb Chris-Info:

Sprich man soll Fullstack Developer und Admin sein, darüber hinaus noch Product Owner etc.

Am besten nennt das Unternehmen das Ganze dann noch Scrum, damit ich sofort erkennen kann, dass nur BuzzwordBingo gespielt wird.

Scrum ist für Run The Business ungeeignet.

Wenn man DevOps will, wozu braucht man Admins in diesem Bereich?

[Chief Wiggum]

vor 45 Minuten schrieb allesweg:

Wenn man DevOps will, wozu braucht man Admins in diesem Bereich?

Die Admins retten den DevOps die Systeme, wenn die mal wieder "kreativ" gewesen sind. Hab mich lang genug mit DevOps rumschlagen dürfen.

[Gast]

Ich arbeite seit 10 Jahren mit Ops Hintergrund in der Produktentwicklung und bin dort für den Betrieb zuständig - als Sysadmin, Devops Engineer, SRE .. you name it. Meine Fazit aus dieser Zeit ist folgende:

Wenn das Team eine Plattform betreibt und der Kern dieser Plattform eine Eigenentwicklung ist, hat der Umfang des betriebs mindestens eine Vollzeitstelle. Wenn ich eine Faustformel nennen würde: Auf 7 Entwickler mindestens eine Person für Betriebsthemen. Das umfasst neben klassischen Sysadmin Aufgaben (Hochverfügbarkeit, Backups, Security, Monitoring) vor allem auch Themen wie Observability - nicht nur für Produktionssysteme, sondern auch entlang der gesamten CI/CD Pipeline die du brauchst um zu verhindern, dass alles was gerade aus dem Compiler gepurzelt ist deine Plattform zerlegt. Die Herausforderung hier ist einfach, dass du "early Adopter" der Eigenentwicklung bist, und viele Features Verhalten sich bei Last in Produktion anders als in der lokalen Entwicklung. Jemand der hauptberuflich nur Features entwickelt, hat von den Themen die im Produktionsbetrieb wichtig sind in der  Regel keine Ahnung - oder ist längst in einer Lead/Architect Rolle und/oder Selbständig. Auf der anderen Seite reicht es aber auch nicht, so eine Stelle mit einem klassischen Systemadministrator zu besetzen, der zwar ein Profi im RZ Betrieb ist, der aber einen hohen Grad an Observability (sofern er überhaupt in der Lage ist, den herzstellen) nicht nutzen kann, um Fehler zu finden, einzuschätzen und richtig zu adressieren. Umso mehr Entwicklungsknowhow du da mitbringst (z. B. weil du dich von der Meldung bis zum Quellcode fix runterwühlen kannst), umso schneller kannst du dafür sorgen das Bugs, die es durch die CI/CD Pipeline mit ihren Qualitygates geschafft haben, gefunden und behoben werden. 

In einen Team, in dem es beim Betrieb einer Eigentwicklung (das verstehe ich unter "you build it, you run it") für Betriebsthemen kein dediziertes Knowhow und entsprechende Kapazität gibt, wird es ob kurz oder lang nur semi-professionelles Chaos geben. Da lernste nix, da willst du nicht arbeiten. Du siehst vielleicht vieles, aber wenn du 24/7 nur im Chaos am Feuerlöschen bist, wirst du nie irgendwas nach best practices implementieren, was dich vielleicht im nächsten Job von deinen Mitbewerbern unterscheidet. Weil dafür fehlt dann die Kapazität im Daily Business.

Für Entwickler gilt natürlich das gleiche: Wenn du features entwickeln willst und das gut kannst, dann such dir eine Softwareschmiede die genau das suchst, und Betriebsthemen Spezialisten überlässt (die ja gerne auch Teil des crossfunktionalen-/scrum-/produkt- Teams sein können). Wenn du als Entwickler mit 0 Ops Hintergrund plötzlich die Hochverfügbarkeit o.ä gewährleisten sollst: Renn schnell weg.

Bearbeitet 3. Januar von Bitmee

[Chris-Info]

vor 2 Stunden schrieb allesweg:

Wenn man DevOps will, wozu braucht man Admins in diesem Bereich?

Ich versteh die Frage nicht bzw vielleicht ist das auch genau der Eindruck, den ich aus den Stellenanzeigen habe.

Das DevOps für die meisten Firmen irgendwie heißt der Entwickler macht auch Ops oder der Ops Engineer entwickelt auch Features.

[allesweg]

@Chief Wiggum ich dachte, bei DevOps wären alle Systeme soweit automatisiert aus dem Repository wiederherstellbar, dass man im worst case nur auf den "einmal eine neue Welt"-Knopf drückt? 🤔🤫

.

Meine persönliche bösartige Meinung: Wenn man bei einer Software einplant, dass Entwickler sofortigen Zugriff darauf haben können müssen, ist diese vorsätzlich so wenig getestet, dass Änderungen nicht bis zum nächsten Sprint warten können. Bananensoftware - reift beim Kunden.