Application Lifecycle Management (ALM)
Ein ganzheitlicher Ansatz, der das Ziel verfolgt, bestehende oder zukünftige Software als Objekt mit einem umfassenden Lebenszyklus zu verstehen. Software bzw. Applikationen existieren in der Regel nicht für die Ewigkeit und haben irgendwo ihren Ursprung/Endpunkt. ALM hat das Ziel, dieses Asset über den kompletten Lifecycle zu begleiten.

Agiles Manifest
Das agile Manifest ist ein Extrakt aus den verschiedenen agilen Softwareentwicklungsmethoden und wurde am 13.02.2001 von der Agile Alliance in Wasatch Mountains/Utah gemeinsam entwickelt. Vertreter verschiedener agiler Methoden wie Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, und anderer Methoden sympathisierten mit dem Gedanken, methodenübergreifende Säulen für die agile Softwareentwicklung zu definieren, die für alle Methoden ihre Gültigkeit hätte. Unter ihnen befanden sich u.a. auch die beiden Erfinder der agilen Projektmanagement Methode Scrum. Ziemlich schnell kam man im Kreis dieser Personen auf folgendes Manifest:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Die Werte auf der rechten Seite werden zwar als wichtig angesehen und sind keinesfalls zu ignorieren, allerdings sind die Werte auf der linken Seite wichtiger, wenn es um agile Methoden geht.

Clean Code
Clean Code beschreibt eine Menge von Prinzipien und Best Practices, die dafür sorgen, dass Software Code sauber aufgesetzt, ordentlich formatiert, klar strukturiert und dokumentiert ist. Das Ziel besteht darin, eine klar verständliche Programmierung zu hinterlassen, dies auch einem anderen Entwickler ermöglicht, das Projekt ohne große Probleme übernehmen zu können.

 

Change Evaluation
In ITIL 2011 wurde der Prozess "Change Evaluation" hinzugefügt. Bei vielen Unternehmen läuft dieser Prozess als sogenanntes Vorprojekt ab, bei dem der durchzuführende Change erst mal im Kleinen durchgeführt und evaluiert wird.

Vor allem bei größeren, komplexeren Änderungen (Changes) ist es sinnvoll, den Umfang und die Auswirkungen eines solchen im Vorfeld im Rahmen eines kleinen Testprojektes zu evaluieren - sowohl kostentechnisch als auch aus Sicht der ein zusetzenden Ressourcen. Sobald das Ergebnis vorliegt, kann das CAB über die Durchführung entscheiden und mit der Releaseplanung gestartet werden.

CFIA – Component Failure Impact Analysis
Die Component Failure Impact Analysis, abgekürzt CFIA, ist eine einfache, etablierte, von IBM in den 1970ern entwickelte Methode. Die CFIA ist eine Auswirkungsanalyse für den Ausfall von Komponenten. Die Auswirkung von Ausfällen auf Services können (aus technologischer Sicht) prognostiziert und evaluiert und folglich Gegenmaßnahmen geplant werden. Die CFIA ist neben der SFA (Serviceausfallanalyse) und der FTA (Fault Tree Analysis – Fallbaumanalyse) eine der empfohlenen best practice Methoden aus der ITIL© Service Design Publikation.

Das Ergebnis einer CFIA kann dabei helfen herauszufinden, wo zusätzliche Ausfallsicherheit benötigt wird und wo nicht, in welchen Bereichen detaillierte Wiederherstellungs- und Entstörungsdokumente benötigt werden und schließt eine Risikobetrachtung auf Komponentenebene ein.

CAB-Sitzung
CAB-Sitzung ist ein regelmäßiges Treffen (idealerweise alle 2-4 Wochen) von fest definierten Personen, die sicherstellen, das verschiedene Änderungen/Themen rechtzeitig für die nächsten Releaseplanung berücksichtigt und eingeplant werden. Das CAB Meeting ist der zentrale Entscheider für die Einsteuerung von Anforderungen an die IT.
Änderungen/Themen können sowohl technisch, prozessbedingt, gesetzlich, satzungsrechtlich und/oder regulatorisch begründet sein. Ein hoher Anteil kostenintensiver IT-Service-Störungen lässt sich häufig auf schlecht koordinierte oder unzureichend gesteuerte Änderungen an der IT-Servicelandschaft zurückverfolgen. Diesen Störungen soll das CAB durch entsprechende Planungs- und Freigabemaßnahmen präventiv entgegen wirken.

Kanban in der IT
Der Begriff Kanban entspringt den japanischen Begriffen kan (für Signal) und ban (für Karte) und genau darum handelt es sich in der klassischen Lean Management Systematik auch. Eine Kanban ist eine Signalkarte mit der signalisiert wird, dass Nachschub benötigt wird was dafür sorgt, dass man am Arbeitsplatz weniger Teile vorrätig halten muss und trotzdem immer genug für die Montage hat. Berühmt wurde der Begriff im Rahmen des Toyota Production System (TPS), weil man damit die Produktionsflüsse im Automotivebereich so steuerte, dass selbst komplexe Variantenfertigungen effizient möglich wurden und die klassische Fließbandarbeit nach Henry Ford damit ablösten. Mehr zu Kanban in der Automobilindustrie finden Sie hier.

Auch wenn man in der IT keine "Teile" im klassischen Sinne hat, lässt sich dieses System trotzdem sehr gut als Steuerinstrument von Aufgaben in Teams heranziehen. Wie im Automotivebereich gilt es auch hier, die Engpässe innerhalb einer Entwicklung (oder jeder anderen Teamumgebung) zu identifizieren und aufzulösen.

Product Backlog
Das Product Backlog ist ein sogenanntes Artefakt der agilen Projektmanagement Methode Scrum und gehört dem Product Owner. Hierin werden alle Anforderungen, die während eines Projektes bekannt werden, gesammelt und strukturiert. In der Regel geschieht das anhand von sogenannten Epics (übergeordneten Anforderungen) und daraus abgeleiteten User Stories (sehr konkrete Anforderungen), die priorisiert und dementsprechend detailliert werden. Zu Beginn handelt es sich bei dem Product Backlog um eine Art von Ideenpool, in dem alle möglichen Anforderungen gesammelt und gewichtet werden. Die Anforderungen, die frühzeitig umgesetzt werden sollen, müssen zuerst konkretisiert/detailliert werden.
Ob eine Anforderung konkret genug ist, also der Definition of Done entspricht, entscheidet das Developer Team im sogenannten Sprint Planning. Sofern das nicht der Fall ist, muss der Product Owner seine Anforderungen noch weiter konkretisieren, wobei ihm der Scrum Master mit Hilfe verschiedener Techniken helfen kann.

RACI-Modell
RACI ist ein Akronym für eine Methode, die die Verantwortlichkeiten eines Prozesses oder einer Aktivität definieren soll. Abgeleitet aus dem Englischen stehen die vier Buchstaben für:

Responsible:
Der/die Durchführungsverantwortliche ist der eigentliche Macher, d.h. von dieser Person wird die Aufgabe operativ durchgeführt.

Accountable:
Der/die Ergebnisverantwortliche ist die Person, die sowohl kostentechnisch als auch rechtlich die Verantwortung trägt und i.d.R. eine Führungsposition in der Organisation innehat.

Consulted:
Diese Person (bzw. Personengruppe) kann beratend hinzugefügt werden und fungiert als Experte bzw. Wissensträger für ein konkretes Themengebiet. Diese Person ist in der Regel nicht aktiv am Prozess beteiligt. Je nach Definition muss oder soll diese Person beratend hinzugezogen werden.

Informed:
Der Informationsempfänger soll über einen Status, Fortschritt oder ein Ergebnis im Prozess informiert werden. Er hat demzufolge ein Informationsrecht und muss über den Verlauf oder das Ergebnis durch den Responsible informiert werden (=Informationspflicht für R).

Sprint Backlog
Das Sprint Backlog ist eines der drei Artefakte innerhalb der agilen Projektmanagement Methode Scrum. Es gehört dem Development Team, welches hierin alle Anforderungen verwaltet, die es innerhalb des aktuellen Sprints abarbeiten wird.
Das Sprint Backlog wird während des Sprint Planning erstellt und beruht auf den Anforderungen des Product Owners. Damit diese überhaupt in das Sprint Backlog gelangen, müssen diese die sogenannte Definition of Ready (DoR) erfüllen und vom Team angenommen worden sein. Anders gesagt, nur Anforderungen die konkret/detailliert genug sind und vom Team im Sprint Planning Phase I akzeptiert wurden, gelangen in diese Anforderungsliste.
Sobald das Sprint Planning Phase I abgeschlossen ist, startet das Developer Team mit der detaillierten Planung des Sprints, in dem es die angenommenen Anforderungen in einzelne Tasks zerlegt, in Reihenfolge bringt und untereinander zuordnet. Wie genau das geschieht, bleibt dem Team überlassen.

Das Sprint Backlog ist also letztendlich eine Sammlung aller Aufgaben (Tasks) innerhalb eines Sprints und wird von nun an täglich beim Daily Scrum aktualisiert. Aufgaben, die erledigt sind, werden entsprechend markiert was dazu führt, dass man ein Echtzeitbild der Arbeit erhält, welches sich idealerweise in einem Burndown-Chart grafisch darstellen lässt.