Agile Entwicklung in einem DevOps-Team

Hintergrund

Durch meinen Wechsel zur 1&1 Internet AG im Jahr 2009 wurde ich Teil eines DevOps-Teams, welches die Projekt-Entwicklung, den Betrieb und das Monitoring der Jboss-ApplicationServer und der darauf laufenden Server-Anwendungen stemmen musste.

Im Laufe der Zeit stiegen die Anforderungen an die Planung der Projekte.
Die Herausforderung dabei: Entwicklung und Operations unter einen Hut zu bringen um die Wünsche externer Anforderer in time zu befriedigen und gleichzeitig den reibungslosen und fehlerfreien Betrieb zu gewährleisten.

Ziel

Das Ziel war es, einen 2-wöchentlichen Sprint-Rhythmus zu etablieren, in welchem die bereits geplanten Tasks abgearbeitet werden sollen.

Folgende Maßnahmen waren dazu notwendig:
– Einschätzung des Operation-Anteils am Tagesgeschäft (Operations) innerhalb des Teams
– Reservierung eines Entwicklers im Sprint-Wechsel als ersten Ansprechpartner für eingehende Anfragen

Jeder, der sich in den letzten Jahren mit IT-Projekten auseinandergesetzt hat, hat die Begriffe agile, scrum und kanban mehr oder weniger oft gehört und nicht unbedingt immer im positiven Zusammenhang:
Man kann unvorhergesehene Incidents, Anfragen, Fehlersuche etc. nicht einplanen, da man nicht weiß, ob sie eintreten werden und wie lange das Team damit beschäftigt sein wird.

Zwischenstand

Ich kann an dieser Stelle das Fazit ziehen: man kann – wenn man sich entsprechend aufstellt und organisiert.

Damit im Team die Akzeptanz für eine agile Arbeitsweise nicht von Beginn an torpediert wird, sollte klar sein, dass ein Ansatz wie Scrum niemals nach der reinen „Lehre“ praktiziert werden wird.
Im Gegenteil: man macht sich einen der agilen Grundsätze zu Nutze und ist flexibel indem man für sein Team die Ansätze adaptiert, die einen weiterbringen.

Konkret bedeutet das:
Man plant den Operation-Anteil in die Sprint-Kapazität mit ein. Hat das Team vorab festgestellt, dass jeder im Schnitt 3h täglich mit derartigen Aufgaben beschäftigt ist, dann verwendet man die verbleibenden 5h (bei einer 40h Woche) zur weiteren Planung (unter Berücksichtigung von Krankheitsquoten etc.)
Der Nachteil ist offensichtlich: das Team kann sich nicht ungestört den eigentlichen Sprint-Tasks zuwenden.

Ein weiterer Ansatz den ich eingangs erwähnt habe:
Von Sprint zu Sprint kümmert sich ein anderes Team-Mitglied um Incidents, Anfragen, Recherchen, Bugfixes etc.
Vorteil: Das Team arbeitet ungestört. Die Rolle wechselt durch. Das Wissen verteilt sich.

JIRA

Als Werkzeug der Stunde hat sich schnell JIRA der Firma Atlassian etabliert.
Damit ist es relativ leicht möglich, den unterschiedlichen Anforderungen aus dynamischem Tagesgeschäft (Tickets)  und agiler Projekt-Entwicklung (Sprint-Planung, Backlog) gerecht zu werden.
Im Zusammenspiel mit Confluence aus gleichem Hause gibt es auch keine Rechtfertigung mehr, wenn keine bzw. kaum Zeit in Dokumentationen investiert wird.

Erkenntnis

Erkenntnis aus den letzten Jahren:
Man darf die Basics nicht vernachlässigen. Das bedeutet immer transparent zu machen, was man tut und wieso man es tut. Und dies entsprechend zu kommunizieren.
Nichts ist kontraproduktiver als das Team und die involvierten Stakeholder im Unklaren zu lassen.
Dadurch verbaut man sich schon zu Beginn die Möglichkeit, eine agile Arbeitsweise einzuführen.
Mein Anspruch ist es, diesen Anforderungen gerecht zu werden, um alle Beteiligten zufriedenzustellen und damit eine erfolgreiche Projektarbeit zu gewährleisten.