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 »
«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.
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.
Re-posted from the Trifork blog:
Abstract:
Are you curious about how you can improve your workflows with Mercurial? In this Geek Night, Martin Geisler from aragost Trifork will introduce you to Mercurial, a fast distributed version control system used by large projects such as Firefox and OpenOffice. You will see first-hand how Mercurial is much more light-weight and flexible than legacy systems like CVS, Subversion, ClearCase, etc.
Following the introduction, Gonzalo Casas from isonet ag will describe how and why they migrated 20 developers from Subversion to Mercurial. You will learn how the robust support for merging in Mercurial makes it feasible for them to manage long-term maintenance branches, while still being able to easily create new branches for new features.
Speaker Bios:
Martin Geisler holds a PhD in Computer Science from the University of Aarhus, Denmark. He has been involved in the Mercurial project for three years and is now a member of the core developer team. He relocated to Zurich in the beginning of 2010 to work full-time as a Mercurial consultant for aragost Trifork.
Gonzalo Casas studied Computer Science at the University Siglo 21, Córdoba, Argentina. He currently works for isonet ag as a software engineer and has been in charge of migrating from Subversion to Mercurial and maintaining the Mercurial repositories and the development process on top of it.
Language: English
Place: Technopark Zürich
Date & Time: 13 January 2010, 17.00
Price: Free
Registration: Please send name and company address to Serife Cakmak.
Die soeben erschienene Nummer 1.11 des Eclipse-Magazins widmet dem Titelthema «Verteilte Versionierung» drei Artikel. Deren Lektüre lohnt sich, wenn man Wissen zu diesem Thema aufbauen oder aktualisieren will. Zusätzlich geniesst man den Vorteil, dass die Texte auf praktischen Beispielen aufbauen und dabei Theorie und Praxis vorbildlich miteinander verbinden.
Es erstaunt nicht, dass einem Open-Source-Magazin das Versionsmangement ein Titelthema wert ist. Denn Open Source funktioniert wegen der grossen (offenen) Entwicklergemeinde nur mit einem geregelten, flexiblen und möglichst weitgehend automatisierten Versionsmanagement. Zudem ist die Welt der Versionierungswerkzeuge im Umbruch: Verteilte Systeme – wie Git und Mercurial – lösen ihre zentralistischen Vorläufer ab – etwa cvs und Subversion.
SCCM – ein Dauerthema
SCCM ist ein Dauerthema, weil die Anforderungen sich ständig ändern. Früher war die verteilte Entwicklung die Ausnahme, heutzutage jedoch – in der Open-Source-Welt und beim Offshoring der Entwicklung – ist sie die Regel. Deshalb der Wechsel von zentralen zu verteilten Versionierungssystemen.
Es bewegt sich etwas! Es muss sich etwas bewegen.
Den ganzen Beitrag lesen »
Auf Technikwuerze.de steht ein Podcast über Versionsmanagement auf Platz 6 der Download-Hitliste.
Und nicht etwa mit einem Riesenabstand auf die Spitze: Auf dem ersten Platz steht der Podcast «Motion Design» mit derzeit 8939 Downloads; «Versionsmanagement» vom 5. Februar 2007 kommt auf Platz 6 auf 7505 Downloads. Es hat zwar etwas gedauert, bis der Podcast diesen Platz erreicht hat, was aber nur beweist, dass Versionsmanagement ein Dauerthema ist.
Interviewt von David Maciejewski erläutert Ralf Kühnbaum-Grashorn das Versionsmanagement am Beispiel der Website-Programmierung anschaulich, klar und praxisbezogen mit Subversion als Werkzeug. Theorie und Praxis kommen beide zur Sprache und werden ideal miteinander verbunden. Die gut 40 Minuten Zuhören lohnen sich – für Anfänger und Fortgeschrittene. Ergänzt wird der Podcast mit einer Zusammenfassung und Linksammlung.
Martin Fowler hat seinem «Meinungsbeitrag» über die Empfehlbarkeit von Versionsverwaltungswerkzeugen (über den wir gestern berichteten), einen «Faktenbeitrag» folgen lassen: Open-Source-Werkzeuge führen mit grossem Abstand das Feld an, die Tools grosser Hersteller belegen die Schlussränge.
Fowler berechnet eine «Akzeptanzrate»: Die Open-Source-Werkzeuge git, Mercurial und Subversion erreichen über 90 %, dann folgen Bazaar mit 82 % und Perforce mit 61 % – und dann lange nichts mehr. CVS, der Veteran aus der Open-Source-Welt erreicht 17 %, und am Schluss stehen ClearCase (5 %), VSS (3 %) und TFS (0 %).
Mit 99 befragten Personen ist die Umfrage von der Menge her befriedigend abgestützt. Antwortende waren Abonnenten der ThoughtWork-Mailings. Sicher werden da ziemlich viele Open-Source-Fans dabei sein, aber Fanatiker scheinen es keine zu sein, sonst hätten sie kommerzielle Werkzeuge wie Perforce kaum so gut eingeordnet und sie hätten ihren Veteranen CVS hochgejubelt.
Es lohnt sich, diese Liste anzusehen.
Unter dem Titel «Version Control Tools» hat Martin Fowler einen ausgezeichneten Artikel über Software für das Versionsmanagement geschrieben, der ziemlich Beachtung gefunden hat. Wenn Sie sich gerade Gedanken machen über ein neues Versionskontrollsystem, sollten Sie sich die Zeit zum Lesen dieses Beitrags nehmen. Das wird Ihnen einigen unnützen Aufwand ersparen. Allein diese Zeichnung aus dem Artikel ist ein vielsagende Auslegeordnung, die Ihre Auswahlliste bereits verkürzt.
Unter den Reaktionen ist jene von Jay R. Wren mit dem Titel «Version control is more than just the tools» hervorzuheben, da sie weitere Aspekte in die Diskussion bringt.
ALM wird immer mehr zum Thema. Die Netzwoche hat in der Nummer 13 vom 8. Juli 2009 dazu ein Dossier mit drei Beiträgen veröffentlicht. Wenngleich betont wird, dass ALM mehr ist als Entwicklung und Werkzeuge, sind die drei Beiträge doch Entwicklungs- und Werkzeug-lastig. Schade. Aber lesenswert sind sie trotzdem.
Die Übersichtsdarstellung von David Chappell im Beitrag «Die Anforderungen an Application-Lifecyle-Management-Tools», stammt aus David Chappells Papier «What is ALM?».
Die Netzwoche gibt’s am Kiosk, im Abo oder auch als E-Paper.
Nach dem Motto: «Alles Alte ist schlecht und muss weg!» werden Anwendungen auf homogenen Mainframe-Systemen mit viel Aufwand und Kosten durch Standard-Softwarepakete ersetzt, und/oder durch Eigenentwicklungen abgelöst, meistens auf kostengünstigeren Plattform (Windows, Linux).
Gemäss einer Studie von Jeffrey S. Hammond, Forrester Research, wird aber mit jeder neuen Entwicklungs-Umgebung und/oder -Plattform (Eclipse für JAVA, Visual Studio für .NET, Oracle Application Express, SAP NetWeaver usw.) meistens die zur Entwicklungs-Umgebung passende Software-Verwaltung installiert.
Die viel verpönten «Silo-Anwendungen» verschwinden nach und nach, dafür werden «Software-Verwaltungs-System-Silos» aufgebaut. Wichtige Informationen über externe Applikations-Schnittstellen und Entwicklungsstände von Software-Komponenten sind in diesen «Software-Verwaltungs-System-Silos» gespeichert. Entwickler-Gruppen und IT-Führungskräfte müssen sich Informationen aus den verschiedenen Software-Verwaltungs-Systemen mühsam und zeitraubend zusammensuchen – sofern sie überhaupt Zugriff auf die jeweiligen Systeme haben.
Ohne eine integrierte Software-Verwaltung (SCCM) verlieren Entwickler und IT-Führungskräfte den Überblick über den Stand der Entwicklungsprojekte.
Jeffrey S. Hammond von Forrester Research schreibt dazu in seiner Studie
«European Software Configuration Management Tool Adoption Trends»
Den ganzen Beitrag lesen »
