Kommentar zum 2. Java-Trendbarometer der expeso GmbH

1 Kommentar

Die expeso GmbH hat das zweite Java-Trendbarometer veröffentlicht. Die Ergebnisse lassen sich nach einer Registrierung in Gänze einsehen. In Auszügen sind die Ergebnisse auch auf heise online verfügbar:

So empfinden 75 Prozent der Teilnehmer die Bedeutung der Qualitätssicherung in ihren Projekten als „zu gering“.

In Kommentaren zum verwendeten Prozess fielen Äußerungen wie „brain driven“, „chaos driven“, „code & fix“ und „pseudoagil“. Die Qualität leide unter der häufig sehr stark termingetriebenen Entwicklung.

Agilität bei codecentric

Wie wichtig automatisierte Tests und ein partnerschaftlicher, agiler Prozess mit dem Kunden ist, hat codecentric schon lange verstanden und dementsprechend als Kernpunkte der Unternehmensstrategie festgesetzt. Dies schlägt sich unter anderem in den erfolgreichen Kundenprojekten nieder, siehe dazu auch unsere veröffentlichen Success Stories, die bald noch erweitert werden. Desweiteren unterstreicht die Vielzahl der zertifizierten Scrum Master, dass die Strategie auch vom Unternehmen ideal unterstützt wird.

Aber, allein die Erkenntnis, dass dies der richtige Weg ist reicht nicht, und so wird es vermutlich auch den 82 Teilnehmern an der Umfrage zum Trendbarometer gehen. Viele der Teilnehmer (78%) sind in externen Kundenprojekten tätig, das heißt sie sind dort eventuell auch wider besseren Wissens und ihrer Erfahrung zu den Prozessen genötigt, die der Kunde für ideal befindet.

Continuous Integration

Wie schwierig nach der Erkenntnis die tägliche Umsetzung agiler Softwareentwicklung ist, erfahren wir alle jeden Tag auf’s neue. Das unbequeme an effizienten Prozessen ist, dass alles, was den Prozess ineffizient macht, sofort auffällt. Im Laufe der Zeit entwickelt sich das Team und das gesamte Unternehmen aber weiter (wichtig: Reflection Sessions!), allerdings ist es kein Prozess, der von einem Tag auf den anderen stattfinden kann, da sowohl kulturelle als auch Aspekte der IT-Infrastruktur dem Änderungsprozess unterliegen.

Äußerst hilfreicher Teil der IT-Infrastruktur ist eine Umgebung, welche die Software laufend kompiliert, baut, „unit-testet“, installiert und auch automatisch „integration-testet“. Nur die Kompilierung, der Unit-Test und Zusammenbau der installierbaren Artefakte, also eine „Continuous Integration“-Umgebung, also eine stetige Integration aller Komponenten, jeweils auf dem neuesten Stand, geradezu notwendig. Selbst dies wird aber nur (laut Studie) bei ca. 45% der Befragten „häufig“ eingesetzt (ca. 22% „nie“; ca. 33% „teilweise“). Da aber mehr als 60% der Teilnehmer angegeben haben agil zu entwickeln, verwundert es nicht, dass die Qualität leidet, wenn die unterstützende IT-Infrastruktur fehlt. Immerhin wird dies als Mängel erkannt: fast jeder zweite befragte Java-Experte empfindet die in Projekten vorhandenen Integrationsmechanismen als nicht ausreichend.

Anforderungsanalyse

Noch interessanter ist aber der folgende Punkt (Zitat aus der Studie):

60% der Java-Experten sagen, dass der Anforderungsanalyse zu wenig Bedeutung zugemessen wird. Diese Zahl ist schockierend, zumal die Anforderungsanalyse die Basis der gesamten Entwicklung darstellt und die Notwendigkeit einer optimalen Anforderungsanalyse bekannt ist.

Nun fehlt hier leider die Information wie viel Zeit denn absolut in die Anforderungsanalyse gesteckt wird, um beurteilen zu können wie viel noch als zu wenig angesehen wird. Ich denke aber, dass hier ein anderes Problem offenbar wird: Es ist einfach nicht möglich ein interaktives und komplexes System von A bis Z zu spezifizieren, und alle Rand-, Sonder- und Fehlerfälle zu berücksichtigen. Dies zu versuchen zeugt allein davon, dass der Prozess nicht agil sein kann. Und selbst wenn man es geschafft hat alle Anforderungen zu berücksichtigen, besteht immer noch das Risiko, dass die analysierten Features nicht umgesetzt werden, da 3 Monate nach der Anforderungsanalyse der Kontext ein ganz anderer ist (andere Anforderungen, andere Prioritäten, andere Laufzeitumgebung, andere Wirtschaftslage, etc.). Das ist genau die Krux und bei iterativem Vorgehen am schwierigsten umzusetzen: Zu akzeptieren, dass sich Anforderungen ändern, dass nicht alle Sonderfälle bekannt sind, und einen Prozess zu finden damit zurecht zu kommen.

Weiterbildung

Laut Studie bilden sich die Java-Experten hauptsächlich durch das Internet, Bücher und Zeitschriften weiter. Nur weniger als die Hälfte besuchen Seminare (teilweise auch durch die Firmenpolitik bedingt) und noch weniger lassen sich coachen oder nehmen andere Angebote in Anspruch.

Wie wertvoll die Diskussion mit Experten sein kann, steht so hoffe ich außer Zweifel. Deshalb möchte ich zum Abschluss noch kurz auf unser anstehendes Event „Meet the Experts“ zum Thema Agilität aufmerksam machen, das schon am 4. September bei uns stattfinden wird. Es werden ausgewiesene Experten einem kleinem Kreis an Teilnehmern (limitiert auf 100) durch Vorträge und viele Diskussionen ihr Wissen weitergeben. Zudem bieten wir eine Zertifizierung zum Product Owner an, um die oben beschriebene Problematik der Anforderungsanalyse besser in den Griff zu bekommen.

Insgesamt eine gute Möglichkeit seine Kenntnisse im Bereich der Agilität auszubauen. Angelehnt an das agile Manifest gilt:

Individuals and interactions over magazines and blogs

Andreas Ebbert-Karroum

Andreas Ebbert-Karroum ist Agile Principal Consultant bei codecentric und Product Owner von CenterDevice.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Fabian Lange

    Gute zusammengefast Andreas. Bei der Anforderungsanalyse gehört meiner Meinung nach viel Erfahrung dazu. Man darf nicht den Fehler begehen und sehen „oh die Software entsteht so schnell, deshalb schnell ein Gesamtkonzept schreiben“
    Konzepte sollen mit der Software wachsen und einfach und sinnvoll anfangen ohne alle Sonderfälle abzudecken. Daran zu denken ist zwar löblich, doch ich denke es ist wichtiger Kernfragen welche schon bei einfachen Umsetzungen auftreten ausreichend zu bedenken.
    Dabei muss man aber auch dem Kunden das Gefühl geben seine Sonderwünsche am Ende umzusetzen (sofern er sie dann selber noch will). Denn oftmals ist die Kernproblematik garnicht differenzierend und als Kunde verwende ich lieber meine Zeit auf differenzierende Themen.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.