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 »
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 »
«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.
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.
Der Artikel «Stiefkind der Enterprise IT» in der Computerwoche Online fasst unsere immer wieder vorgebrachten Feststellungen zum und Argumente für das ALM (Application Life Cycle Management) zusammen, bestätigt und verstärkt sie nachdrücklich.
Die Quintessenz
IT-Führungskräfte sehen das ALM als lästige Daueraufgabe und Kostentreiber, verursacht durch ein heterogenes Anwendungsportfolio. Wenn man sich jedoch klar macht, dass diese Heterogenität die Folge von Mängeln im ALM ist, so bekommt das ALM plötzlich ein neues Gesicht:
Fehlendes ALM verursacht Kosten, funktionierendes ALM hingegen ist eine lohnende Investition, um aus dem Teufelskreis unzureichender Anwendungen und horrender Wartungskosten auszubrechen.
Den ganzen Beitrag lesen »
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 »
