Scrum in der Administration ...
Immer, wenn ich den Begriff "Scrum" oder "Agiles Projektmanagement" höre, denke ich, dass wir in der System Administration schon immer so arbeiten. Klar, wir haben nicht so "hippe" Begriffe für die einzelnen Phasen, aber der Weg ist in Summe der gleiche.
Wer sich für Scrum im Allgemeinen interessiert, dem lege ich gerne das Openbook Scrum - auf dem Bierdeckel erklärt ans Herz, das gibt einen sehr guten Überblick.
Roland hat mir vor Jahren einen Crashkurs in Scrum gegeben und schon damals fand ich schade (wie auch heute noch), dass solche Betrachtungen immer nur aus der Sicht des Software Engineering gemacht werden und dass auch bei grossen Softwareprojekten sehr selten System Engineers ins Boot geholt werden.
Klar, mit DevOps wird alles anders, aber welche Definition von DevOps meint Ihr, ich kenne etwa ein halbe Dutzend zum Teil widersprüchliche Definitionen.
Geht es darum, dass System Management mit Development Methoden betrieben wird? Oder geht es darum, dass Developer und Operations als getrennte Teams enger zusammenarbeiten? Oder geht es darum, dass Developer Operation übernehmen (Beispiel Site Reliability Engineers)? Oder wird System und Applikation als ein einziges "Produkt" betrachtet?
Wie ändert sich die Betrachtungsweise, wenn nicht hunderte von Servern vorhanden sind, die das gleiche tun, sondern eine Applikation nur auf vier Systemen in vier Stufen (Development, Test, Acceptance, Production) betrieben wird oder sogar noch kleiner nur aus den zwei Stufen Acceptance und Production oder sogar nur aus Production besteht?
Hypethemen sind toll und helfen sicherlich neue Denkansätze in den Fokus zu bringen. Aber nicht alles, was neu aussieht, ist es auch und nicht jeder Ansatz klappt überall gleich gut.
"Die Wahrheit liegt häufig in der Mitte."
Wer sich für Scrum im Allgemeinen interessiert, dem lege ich gerne das Openbook Scrum - auf dem Bierdeckel erklärt ans Herz, das gibt einen sehr guten Überblick.
Roland hat mir vor Jahren einen Crashkurs in Scrum gegeben und schon damals fand ich schade (wie auch heute noch), dass solche Betrachtungen immer nur aus der Sicht des Software Engineering gemacht werden und dass auch bei grossen Softwareprojekten sehr selten System Engineers ins Boot geholt werden.
Klar, mit DevOps wird alles anders, aber welche Definition von DevOps meint Ihr, ich kenne etwa ein halbe Dutzend zum Teil widersprüchliche Definitionen.
Geht es darum, dass System Management mit Development Methoden betrieben wird? Oder geht es darum, dass Developer und Operations als getrennte Teams enger zusammenarbeiten? Oder geht es darum, dass Developer Operation übernehmen (Beispiel Site Reliability Engineers)? Oder wird System und Applikation als ein einziges "Produkt" betrachtet?
Wie ändert sich die Betrachtungsweise, wenn nicht hunderte von Servern vorhanden sind, die das gleiche tun, sondern eine Applikation nur auf vier Systemen in vier Stufen (Development, Test, Acceptance, Production) betrieben wird oder sogar noch kleiner nur aus den zwei Stufen Acceptance und Production oder sogar nur aus Production besteht?
Hypethemen sind toll und helfen sicherlich neue Denkansätze in den Fokus zu bringen. Aber nicht alles, was neu aussieht, ist es auch und nicht jeder Ansatz klappt überall gleich gut.
"Die Wahrheit liegt häufig in der Mitte."
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Sasch am :
Dirk Deimeke am :
Sasch am :
Dirk Deimeke am :
Mathias am :
Christoph am :
Dirk Deimeke am :
Dirk Deimeke am :
Ein Sprint läuft zwei, drei oder sogar vier Wochen. Meine Arbeit kann ich schon über einen längeren Zeitraum planen. Sonst würde ich ja auch überhaupt nicht vorwärts kommen. Es hilft dabei, maximal 50% des Tages zu planen.
Wir sind ein Team von fünf Personen (zwei arbeiten 80% und einer 40%), von denen einer dediziert für das Tagesgeschäft verantwortlich ist. Die anderen werden da nur im Notfall gestört.
Allerdings sind wir auch so stark automatisiert, dass das Tagesgeschäft im Regelfall etwa eine Stunde pro Tag in Anspruch nimmt, ausser es kommt zu grösseren Problemen.