Was wir in früheren Blogbeiträgen schon mehrfach gesagt haben, scheint mittlerweile auch auf der anderen Seite des Atlantiks angekommen zu sein. Spass beiseite; zwei Blogbeiträge auf «CM Crossroads» thematisieren die Wichtigkeit, ja Notwendigkeit vonVersionsmanagement, Automatisierung, privaten Workspaces und Continuous Integration für die agile Entwicklung. Und wer macht heute schon keine agile Entwicklung?
Den ganzen Beitrag lesen »
Tags: Automatisierung, Best Practices, Continuous Integration
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 »
Tags: ALM-Integration, Automatisierung, Werkzeuge
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 »
Tags: ALM-Integration, Best Practices, Nutzen
«Sollen Anforderungsmanagement-Werkzeuge eingeführt werden, müssen vorher viele Vorurteile aus den Köpfen geräumt werden.» So beginnt der Artikel «Von den Vorurteilen gegenüber den Werkzeugen im Anforderungsmanagement» von Jens Palluch in der Elektronik-Praxis.
Das gilt nicht nur für Werkzeuge des Anforderungsmanagements sondern für jede Werkzeugeinführung in der Software-Entwicklung!
Der Artikel hat Substanz und Humor: ein Lesevergnügen – sofern man keine Angst davor hat, in den Spiegel der eigenen Unzulänglichkeiten zu blicken.
Jens Palluch nennt die klassischen drei Argumente gegen jede Werkzeugeinführung: das Werkzeug ist zu komplex, passt nicht zu unserem Prozess, erhöht die Qualität nicht. Das sind meist Vorurteile. Palluch zeigt, wie sie entstehen und wie man ihnen begegnet: durch angemessene Schulung und den rechtzeitigen Einbezug aller Betroffenen ins Einführungsprojekt.
Als «Klassiker» bezeichnet er die zutreffenden Aussagen «A fool with a tool is still a fool» und «Erst den Prozess definieren, dann das Werkzeug einführen», denen zu wenig oder keine Beachtung geschenkt wird, so dass sie tatsächlich ihre negative Wirkung entfalten können. Auch hier wieder: Ausbildung verhindert falsche Werkzeuganwendung und ein Werkzeug kann keinen fehlenden Prozess ersetzen!
Aber lesen Sie selbst:
«Von den Vorurteilen gegenüber den Werkzeugen im Anforderungsmanagement». Der Artikel wird Ihnen gefallen. Und überdies enthält er Hinweise auf weiterführende Literatur.
Tags: Best Practices, Werkzeuge
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 »
Tags: ALM-Integration, Best Practices, Kennzahlen
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 »
Tags: ALM-Integration, Best Practices, Problemfälle und Auswirkungen
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 »
Tags: ALM-Integration, Best Practices, Problemfälle und Auswirkungen
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 »
Tags: ALM-Integration, Best Practices
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.
Tags: ALM-Integration, Best Practices, Werkzeuge
Was überhaupt ist ALM?
Dass auf dem Zürcher S-Bahnnetz überhaupt Rollmaterial fährt, dass die Waggons sauber (na ja …) und funktionstüchtig sind, dass dieses Jahr nach 20 Jahren S-Bahn die dritte Rollmaterialgeneration in Betrieb geht – das ist dem «Rollmaterial-Management» zu verdanken. Es umfasst alle Tätigkeiten, um sicheres, zeitgemässes Rollmaterial in genügender Menge zum richtigen Zeitpunkt bereitzustellen.
Ersetzen Sie «Rollmaterial» durch «Anwendung» – und wir haben die ALM-Definition.
Die Definitionen sind zwar gleich, die Realität verschieden: Wäre das Lifecycle-Management der Bahn auf dem gleichen Qualitätsniveau wie jenes unserer IT-Anwendungen, läge die Zufriedenheit der Bahnkunden wohl um Einiges tiefer!
ALM als Disziplin begreiflich machen
Die IT – und innerhalb der IT die IT-Anwendungen– sind immer noch nicht überall als betriebswirtschaftliche Ressource erkannt. Jedem ist klar, dass Rollmaterial, Gebäude, Maschinen und Finanzen bewirtschaftet werden müssen. Jemand muss die Verantwortung dafür tragen, muss planen, was wann gepflegt, erneuert, ersetzt werden muss.
Welches Glück, dass IT-Anwendungen sich nicht abnutzen! Oder etwa vielmehr: welches Pech?! Das ist einer der Gründe, warum es ALM so schwer hat. Die Abnutzung eines materiellen Gutes kann jeder mit seinen Sinnen wahrnehmen, oder zumindest begreift er sie. Die physisch nicht stattfindende – aber trotzdem existierende – Abnutzung von Software und Abläufen begreiflich zu machen ist viel schwieriger! Software und Prozesse passen nicht mehr in ihre sich wandelnde Umwelt: die Anwenderbedürfnisse und Plattformen ändern, Komfortansprüche und Sicherheitsanforderungen steigen. Die Anwendungen werden erst angepasst, wenn es nicht mehr anders geht – und das ist dann meist der dümmste Augenblick – mit entsprechenden kostensteigernden Auswirkungen.
ALM schafft genau hier Abhilfe. Anstatt von den Änderungen in der Umgebung angetrieben zu werden, nimmt der ALM-Manager das Heft in die Hand, plant die Evolution der Anwendungen und setzt diese Pläne um.
Was meinen Sie: Ist das nicht der Weg, den man von einem geordneten Betrieb erwarten würde?
Tags: ALM, Nutzen
