Diese Beitragsreihe basiert auf dem Artikel «Five Imperatives for Application Lifecycle Management» der IBM Rational-Mitarbeiterin Carolyn Pampino.
Im abschliessenden Beitrag geht es um kontinuierliche Prozessverbesserung: ein Dauerthema, wie die Bezeichnung selbst es sagt.
Gesagt heisst noch nicht gehört,
gehört noch nicht verstanden,
verstanden noch nicht einverstanden,
einverstanden noch nicht angewandt
und angewandt noch nicht beibehalten.
Die einen schreiben dieses Wort dem Verkaufstrainer Heinz Goldmann zu, andere dem Zoologen, Verhaltensforscher und Nobelpreisträger Konrad Lorenz.
Egal, Prozesse unterliegen diesem Gesetz ganz besonders: Sie werden nicht von alleine beibehalten, sie verlottern, sie erodieren.
Den ganzen Beitrag lesen »
Diese Beitragsreihe basiert auf dem Artikel «Five Imperatives for Application Lifecycle Management» der IBM Rational-Mitarbeiterin Carolyn Pampino.
Ich kenne aus eigener Erfahrung die Vorteile von Kollaborationswerkzeugen in der Software-Entwicklung. Sie sind für mich die humane Version der Workflow-Werkzeuge: Sie gängeln mich nicht mit einer täglichen To-do-Liste, sondern sie bieten mir eine Arbeitsplattform, die mir und den anderen Informationen einfach zugänglich macht. Hake ich in einem Kollaborationswerkzeug einen To-Do-Eintrag ab, oder ergänze ich eine Anforderungsbeschreibung, so steht diese Information sofort allen zur Verfügung.
Übrigens sind hier mit Kollaborationswerkzeugen weniger die unter dieser Bezeichnung daherkommenden Werkzeuge wie Lotus Notes, Sharepoint oder Zimbra u.a. gemeint, sondern von ALM-Lösungen (für das Anforderungsmanagement, die Ticketverwaltung usw.), die nach den Prinzipien der Kollaborationswerkzeuge bzw. auf einem solchen gebaut sind.
Den ganzen Beitrag lesen »
Diese Beitragsreihe «Five Imperatives for Application Lifecycle Management» basiert auf dem Artikel «Five Imperatives for Application Lifecycle Management» der IBM Rational-Mitarbeiterin Carolyn Pampino.
Diesmal geht es um Zahlen.
Nur was man misst, kann man auch managen.
Sich auf das Gefühl allein zu verlassen, ist im Management gefährlich. Zahlen können ein Gefühl unterstützen oder in Frage stellen und damit zu ganz neuen Einsichten führen.
Den ganzen Beitrag lesen »
Diese Beitragsreihe basiert auf dem Artikel «Five Imperatives for Application Lifecycle Management» der IBM Rational-Mitarbeiterin Carolyn Pampino. Im letzten Beitrag haben wir über die integrierte Planung geschrieben.
In diesem Beitrag geht es um die Verbindungen zwischen den Artefakten einerseits und zwischen Artefakten und Teamplayern andrerseits. Das Kennen dieser Verbindungen ist für den Projekterfolg wichtig, denn nur wenn ich weiss, wer woran arbeitet, wer wofür zuständig ist, welche Dinge voneinander abhängig sind, sich gegenseitig beeinflussen usw., wird ein Projekt übersichtlich und steuerbar.
Artefaktverknüpfungen kennen = das Projekt kennen
Ganz konkret geht es darum zu wissen, wer an der Behebung von Fehler “x” arbeitet, welche Module, Tests, Dokumentationen, Bildschirmdarstellungen, Listen, Dateien, Datenbanken, Formulare usw. von der Änderung “y” betroffen sind. Wo überall wird Modul “z” verwendet, das wir ändern wollen? Wo sind welche Schnittstellen davon betroffen? War dieser Fehler im Vorgänger-Release auch schon drin?
Der Beziehungen sind Legion. Wer die Beziehungen kennt, kennt sein Projekt, kennt Abhängigkeiten und Auswirkungen, womit er die Chance hat, die Kontrolle zu haben.
Den ganzen Beitrag lesen »
Diese Beitragsreihe basiert auf dem Artikel «Five Imperatives for Application Lifecycle Management» der IBM Rational-Mitarbeiterin Carolyn Pampino. Im ersten Beitrag haben wir die Reihe vorgestellt, heute gehen wir auf das erste der fünf Muss ein – die integrierte Planung.
Das «integriert» hat mich auf den ersten Blick etwas stutzig gemacht, denn wer in der IT eine zeitgemässe Lösung anpreist, bezeichnet diese als integriert. Integriert ist hier jedoch keine leere Modefloskel, sondern eine Absage an eine Planung, die ein Eigenleben führt, losgelöst von der Realität der Umsetzung. Eine solch wirklichkeitsnahe Planung ist nur möglich mit einfach zu handhabenden Werkzeugen, die Soll und Ist miteinander verbinden.
Den ganzen Beitrag lesen »
Was Carolyn Pampino, Mitarbeiterin von IBM Rational, im Artikel «Five Imperatives for Application Lifecycle Management» auf CM Crossroads schreibt, können wir aus methodischer und betriebswirtschaftlicher Sicht voll unterstützen. Dass der Text darüber hinaus ein Plädoyer ist für Rational-Produkte, versteht sich. Aber im Mittelpunkt stehen Überlegungen zum Application Life Cycle Management (ALM), die sich jeder machen muss, der professionell Software entwickelt.
In diesem und weiteren Blogbeiträgen stellen wir Pampinos Kernaussagen vor, wobei wir die produktbezogenen Aspekte weglassen.
Druck auf die Software-Entwicklung
Die Software-Entwicklung steht unter Druck: Einerseits verlangen Konkurrenz- und Innovationsdruck immer kürzere Abstände zwischen Software-Releases und andererseits fordern die umfangreicher werdenden Softwaresysteme und Infrastrukturen die Entwickler immer mehr. Wie können Entwickler unter solchen Umständen Software termingerecht und im Kostenbudget herstellen, ohne bei der Qualität Abstriche zu machen?
Den ganzen Beitrag lesen »
Die Einführung der Versionskontrolle steht an erster Stelle eines Sieben-Schritte-Plans, um IT-Projekte zu sanieren, deren Code und Architektur gegen die Prinzipien und Praktiken des Clean-Code-Developments verstossen.
Solche «Brownfield-Projekte» laufen Gefahr, dass Software und Software-Architektur zunehmend zerfallen, bis sie nicht mehr erweiterbar sind.
Brownfield-Projekte sind das Gegenstück zu Greenfield-Projekten – solche, die auf der grünen Wiese gestartet wurden. Mit anderen Worten: Jedes IT-Projekt mit Geschichte ist ein Brownfield-Projekt, eines bei dem nicht alles so ist, wie man’s heute machen würde. Also: Fast alle Projekte.
Im soeben erschienenen Sonderheft «iX Developer Programmieren heute» stellen Stefan Lieser und Ralf Westphal im Artikel «Kontra Verrottung» zunächst die Prinzipien und Praktiken der «Clean Code Developer» und danach einen Sieben-Schritte-Plan, um Brownfield-Projekte zu sanieren. Schritt Nr. 1: Versionskontrolle einführen.
Es geht nicht anders: Ohne geordnete Ablage und ohne Buchführung über die Veränderungen verschwinden die Wirkungen aller anderen Massnahmen. Das Verschwinden ist wortwörtlich zu nehmen; im schlimmsten Fall verschwinden Änderungen oder ganze Artefakte auf obskure Weise, weil Ablage und Versionskontrolle versagen.
Unter dem Titel «Release-Management – eine lästige, aber notwendige Pflicht» berichtet die Computerwoche von der erfolgreichen Einführung eines IT-gestützten Release-Managements bei der Schufa:
«Projektbezogene Dokumentationen und Konfigurationen, uneinheitliche Versionierung sowie ungestützte Change-Prozesse – so sieht das “Release-Management” in vielen Unternehmen aus. Es führt ein Schattendasein als ungeliebte und aufwändige Pflichtaufgabe im Bereich Softwareentwicklung. – Das war bei der Schufa zunächst nicht anders.»
So schildert der Bericht die Ausgangslage der Schufa, die heute ein IT-gestütztes Release-Management betreibt, «um die Qualität der Softwareentwicklung zu steigern.»
Den ganzen Beitrag lesen »
«Problem erkannt – nun muss das Handeln folgen.» – So der treffende Titel des am 15. Oktober 2010 veröffentlichten, frei verfügbaren Berichts über eine Befragung zu ALM, die SIGS-Datacom in Zusammenarbeit mit Microsoft bei 90 ITlern kürzlich durchgeführt hat.
«Beim Thema ALM ist es ein weiter Weg von der Erkenntnis- zur Handlungsebene.»
Was sind wohl die Gründe für diesen Mangel? Die Studie sagt dazu nichts, aber die Ursachen liegen auf der Hand:
- ALM ist kein Hype-Thema, sondern eine der scheinbar unspektakulären weil unabdingbaren Daueraufgaben der IT, mit deren erfolgreicher Bewältigung der CIO aber kurzfristig keinen Prestigegewinn einheimsen kann – zumindest derzeit noch.
- Kein Soforterfolg. ALM ist eine Denk- und Handlungsweise, die die IT und die ganze Firma durchdringen muss. (Kleine) Einzelerfolge können sich kurzfristig zeigen, der grosse Erfolg ist aber erst nach Monaten sichtbar.
- Das Tagesgeschäft geht vor. Aber Hand aufs Herz: Würden Sie in eine Luftseilbahn steigen, die nicht regelmässig gewartet wird? Aber gerade weil es an ALM fehlt, bindet das Tagesgeschäft – die Feuerwehrübungen! – immer mehr Ressourcen. Ein Teufelskreis, aus dem man nur durch ALM ausbrechen kann.
- Keine Zahlen. Wüssten viele Firmen wirklich, wieviele Kosten der IT auf mangelhaftes ALM zurückzuführen sind, würden sie schleunigst die Konsequenzen ziehen.
Den ganzen Beitrag lesen »
Zwei Drittel der von der Firma Expeso für das dritte Java-Trendbarometer Befragten sind mit den Prozessen für Anforderungsanalyse, Entwicklerdokumentation, Test und Qualitätssicherung unzufrieden.
Das Ergebnis überrascht in seiner Aussage und noch mehr in seiner Deutlichkeit. Nur ein Drittel ist zufrieden. Was immer sich hinter «unzufrieden» verbirgt, das Spektrum der Mängel wird breit gefächert sein. Es ist aus wirtschaftlichen Gründen notwendig, diese Prozesse unter die Lupe zu nehmen, denn: «Das Verbesserungspotenzial ist erheblich, hier lauern enorme Risiken.» So die Autoren der Studie.
Den ganzen Beitrag lesen »
