Im aktuellen Linux Magazin habe ich einen interessanten Artikel zum Thema agile Methoden in der Systemadministration gefunden. In der Softwareentwicklung ist der agile Gedanke zunehmend verbreitet. In dem Tagesgeschäft eines IT-Administrators wird agilen Ansätzen derzeit wenig Beachtung geschenkt.

Marcel Wegermann beschreibt in dem Artikel wie sich die agilen Praktiken auf die Arbeit eines Administrators übertragen lassen. Durch Anpassen der Regeln lässt sich so eine ASA (Agile Systemadministration) auf die Beine stellen.  So werden in diesem Artikel Zehn agile Regeln für die Systemadministration aufgestellt, die sich an XP Grundpraktiken orientieren:

1. Jede neue Funktion (z.B. Server, Service, Standleitung oder das Hosting) muss durch automatisierte Tests abgedeckt sein.
2. Teammitglieder administrieren zu zweit an der Konsole, wenn sinnvoll
3. Dokumentation auf Papier ist tot. Automatisierte Tests und die Konfiguration selbst sind Dokumentation genug. Kommentare ergänzen die Monitoring-Tests.
4. Das Team bespricht jeden Notfalleinsatz in der Retrospektive. So findet es die Ursachen für Wochenend- oder Notfalleinsätze und stellt sie zügig ab.
5. Risiken müssen aufgedeckt und schnell beseitigt werden (Transparenz schaffen)
6. Technische Entscheidungen liegen beim Team. Alle Mitglieder tragen sie gemeinsam. Das Team allein hat die Verantwortung für den Betrieb. (Team Commitments).
7. Die Administratoren führen Projekte iterativ und inkrementell durch.
8. Regelmäßig wiederkehrende Aufgaben erledigen alle Teammitglieder reihum.
9. Die Administration arbeitet möglichst zusammen an einem Ort in der Nähe des Kunden. (First- und Second-Level-Support, Entwickler oder Endanwender).
10. Ein großer Bildschirm zeigt nach Art einer Ampel den aktuellen Status der Server und Auslastung für alle gut sichtbar an. Das fördert die osmotische Kommunikation.

Mein Fazit:

Für mich der erste Beitrag zum Thema ASA. Als großer Anhänger der agilen Methoden sind für mich die Punkte eins bis acht lohnend und sicherlich in den meisten Rechenzentren anwendbar. Eine Nagios-Installation leistet bereits  in vielen Unternehmen seine Dienste und kann für die gesamte Testautomatisierung herangezogen werden. Allerdings ist es dann umso wichtiger qualifizierte Kommentare in der Konfiguration zu finden.

Punkt zwei und acht sehe ich als besonders effektiv an. Denn hier steht nicht nur der agile Gedanke im Vordergrund, sondern das Vorhandene Wissen wird auf mehrere Köpfe verteilt. Damit kann dem Problem mangelnder Vertretungen entgegen gewirkt und die Abhängigkeit von Einzelpersonen aufgelöst werden.

Aber nicht alle Ansätze lassen sich so einfach umsetzen. Insbesondere den Punkt neun sehe ich als kritisch an, denn in Zeiten von Outsourcing und Service-Rechenzentren ist die örtliche Nähe zum Kunden nicht immer möglich.

Der Einsatz von Whiteboards, Pinnwänden oder Flipcharts im Administrationsbereich kann zur Sprintplanung genutzt werden oder die Teambesprechungen unterstützen. Wie Teamräume aussehen können ist hier zu sehen. Ein Ticket-Trouble-System wie OTRS kann die auftretenden Störungen kanalisieren und ist zudem revisionssicher. Darüberhinaus ist für die Projekte ein Wiki das Tool der Wahl und zur Kommunikation mit der „Außenwelt“ kann ein Blog sehr hilfreich sein. So könnten dort aktuelle Störungen oder Planungen von Downtimes kommuniziert werden.

Insgesamt haben die agilen Methoden potenzial auch in der Systemadministration einzuziehen. Die bisherigen strikten Zuständigkeiten für Systeme oder Anwendungen können so effektiv aufgebrochen und eine höhere Dienstleistungsqualität erreichet werden.

Ich habe heute ein tolles Plakat zum Thema Scrum entdeckt. Es wurde von der InterFace AG in Zusammenarbeit der TU-München und der TEG erstellt und ist unter folgender Stelle zu finden.
Wie ich finde ist das Plakat inhaltlich gelungen und auch die Idee es auf einem A4 – Drucker auszudrucken finde ich toll.

Verfügbar ist es in englischer oder deutscher Sprache in den Formaten A2 / A1. Aufgehängt bietet es einen guten Überblick über den agilen Prozess Scrum.

Da ich in der Vergangenheit auch zu den Leidtragenden gehörte, die aufgrund von ungenauen Vorgaben Termine nicht einhalten konnte, ist es sicherlich auch hier einmal Zeit einen Beitrag zum Thema Anforderungsmanagement zu widmen.Aber zuerst eine Definition:

Anforderungsmanagement (engl. Requirements Management) ist eine Managementaufgabe für die effiziente und fehlerarme Entwicklung komplexer Systeme. Es umfasst die Anforderungserhebung  Requirements-Engineering) sowie Maßnahmen zur Steuerung, Kontrolle und Verwaltung von Anforderungen, also Risikomanagement, Änderungsmanagement und Umsetzungsmanagement.

Quelle: Wikipedia

Bei meiner Suche zum Thema agiles Anforderungsmanagement, bin ich auf einen Vortrag von Detlef Buder und Alexander Fischbach gestoßen, in dem sie die Fragen beantworten:

• Benötigen agile Entwicklungsmethoden überhaupt ein Anforderungsmanagement im klassischen Sinne?
• Wie viel ist “soviel Dokumentation wie nötig” in Bezug auf die Anforderungsanalyse?
• Wie viel muss ich über ein zu erstellendes System wissen, damit ich mit der iterativ / inkrementellen Entwicklung starten kann?

Ich sehe das Anforderungsmanagement als eines der Kernthemen im Projektmanagement, bleibt zu klären, in wie weit es sich in agile Vorgehensmodell integrieren läßt.

Die Vorteile von agilen Vorgehensweisen in IT-Projekten sind hinlänglich bekannt (oder hier nachzulesen).  Kritiker meinen, dass bei diesen Methoden häufig der Gesamtüberblick verloren geht. Dadurch dass das Big Design Up Front (oder Bug Desgin Up Front) fehlt, und die Systeme iterativ entworfen werden, kann man schnell das ingenieurmäßige Vorgehen vermissen.

Agile Projekte stehen aber nicht im Konflikt mit den Ingenieurswissenschaften. Ganz im Gegenteil, dort werden sie seit den 80 erfolgreich eingesetzt. Ziel agiler Projekte ist vielmehr der Blick auf das Wesentliche zu beschränken. Dennoch fehlt häufig das „Big Picture“ für den Gesamtüberblick.

Genau dort kommt das Fundamental Modeling Concept (FMC) zum Einsatz. Mit Hilfe des FMC kann man Fach- und IT-Landkarten erstellen,  die allen Projektbeteiligten helfen einen schnellen Überblick zu bekommen.  Ich habe mir das Landkartenkonzept einmal näher angesehen und bin davon überzeugt. Im Vergleich zu Unified Modeling Language (UML), kann man FMC –Blockdiagramme ohne großen Lernaufwand auf Anhieb verstehen.  Das genügt um nach meinem Grundsatz zu handeln:

“So einfach wie möglich – aber nicht einfacher”

Probieren Sie es mal aus: http://www.fmc-modeling.org/

In meinem letzten Artikel habe ich bereits das Thema Scrum kurz angerissen. In dieser Präsentation habe ich die Konzepte von agilen Methoden und insbesondere von Scrum etwas genauer erklärt. Bei Gelegenheit werde ich noch eine Tonspur hinzufügen und einen Slidecast daraus machen. Also viel Spaß damit.

| View | Upload your own

Wer kennt es nicht, der Kunde reicht ständig Anforderungen nach, da er die Gesamtanforderungen nicht kennt. Das Projektteam wird ständig bei der Arbeit unterbrochen und der Kunde ist mit den Ergebnissen nicht zufrieden. So, oder so ähnlich habe ich es in einem meiner letzten Projekte erlebt. Für die zweite Phase musste nun ein Vorgehensmodell her, das auf solche Belange eingeht.

Auf der JAX habe ich auch die agile Lego Hour besucht und damit erstmals einen Einblick in die agilen Methoden bekommen. Ich habe mich nun etwas mit Scrum auseinander gesetzt und werde es für die zweite Phase dieses Projekts einsetzen.

Scrum ist ein leichtgewichtiges Prozessmodell das in Japan zur Produktentwicklung entstanden ist. Kern von Scrum ist das “Product Backlog”, in dem die einzelnen Anforderungen des Kunden beschrieben werden. Der Kunde ist der “Product Owner” und pflegt zusammen mit dem Team das “Product Backlog”; er vergibt die Prioritäten für die anfallenden Aufgaben, welche dann in dem sogenannten “Sprint” abgearbeitet werden. Die Sprints sind Entwicklungszyklen, welche mit zwei bis vier Wochen sehr kurz gehalten sind. Bei der täglichen Zusammenkunft (Daily Scrum) treffen sich die Entwickler (Scrum Team) und entscheiden die nächsten Schritte. Hierbei wird geklärt: “Was habe ich gestern gemacht?”, “Was mache ich heute?” und “Welche Hindernisse sind aufgetreten?”. Das Meeting sollte nicht länger als 15 Minuten gehen. Mit dem “Sprint Burndown” wird visualisiert wie das Projekt voranschreitet Transparenz geschaffen.

In der Ausgabe Nr 13 der Zeitschrift ct ist ein Artikel über Scrum zu finden, der einen guten Überblick der agilen Methoden bietet. Außerdem kann ich noch die Seite von Alexander Kriegisch empfehlen. Dort habe ich mich in das Thema eingelsen.

In kürze werde ich hier berichten wie erfolgreich das Projekt mit der agilen Methode wirklich war.