Kategorien
Software-Entwicklung

Software-Evolution mit aim42 – Architecture Improvement Method

Dieser Eintrag ist Teil 2 von 7 in der Serie OOP 2014 Report

OOP 2014 Report

OOP 2014 – erster Tag

OOP 2014 – erster Tag

Software-Evolution mit aim42 – Architecture Improvement Method

Software-Evolution mit aim42 – Architecture Improvement Method

Improving estimates – the #NoEstimates view

Improving estimates – the #NoEstimates view

Imposing Rule-Based Architecture on Legacy Systems

Imposing Rule-Based Architecture on Legacy Systems

Gehirnwäsche für Führungskräfte

Gehirnwäsche für Führungskräfte

OOP 2014 – zweiter und dritter Tag

OOP 2014 – zweiter und dritter Tag

Martin Fowler: „Not just code monkeys“

Martin Fowler: „Not just code monkeys“

Auf der OOP2014 starteten Stefan Tilkov und Gernot Starkeaim42“ – die Architecture Improvement Method.

Viele Teams, die eine Software über einen längeren Zeitraum, sehen den Bedarf für (technische) Verbesserungen, um die Qualität und die Wartbarkeit der Software zu erhöhen. Das Problem dabei ist, das Management davon zu überzeugen, die nötigen Aufwände zu investieren. Die Nachricht hier ist, dass Änderungen am System durch Geld motiviert sind, d. h. man nicht mit Qualitätsverbesserung oder Professionalität argumentieren sollte.

aim42 soll helfen, die nötigen Verbesserungen zu finden, zu bewerten (möglichst in Geld) und umzusetzen. Dabei soll die „42“ an „arc42“ erinnern, eine Plattform für freie Resourcen für Software-Architekten. Aim42 ist ein offener, Community getriebener Ansatz.

Die drei Phasen von aim42 sind (Zitat):

Die drei Phasen von aim42

  • analyze – find problems, risks, deficiencies and technical debt within your system and your development process
  • evaluate – understand root-causes of problems, determine „value“ of
    problems, issues and their remedies, prioritize
  • improve – systematically improve code and structures, reduce technical debt, remove waste and optimize

Das ganze ist natürlich ein iterativer Prozess. In der Analyse-Phase werden alle Stakeholder befragt, es können Qualitätsanalysen und statische Code Analyse zum Einsatz kommen. Erst im zweiten Schritt werden die ermittelten Probleme bewertet. Ziel dabei ist, die Stakeholder zu überzeugen, die Probleme anzugehen. Im dritten Schritt wird dann eine Auswahl an Verbesserungen angegangen. Dazu steht ein Fundus an Mustern bereit.

aim42 soll nur „Industrie erprobte“ Muster und Praktiken enthalten. Es gibt auch ein github-Repository.

Es hat mich beeindruckt, dass die beiden auf der OOP2014 diesen Ansatz gestartet haben.

Die Präsentation-Folien sind online verfügbar.

OOP 2014 Report

OOP 2014 – erster Tag Improving estimates – the #NoEstimates view

Eine Antwort auf „Software-Evolution mit aim42 – Architecture Improvement Method“

Die Kommentare sind geschlossen.