cards42.org

Darstellung verschiedener cards42-Karten als Beispiel
Cards for Analyzing and Reflecting on Doomed Software

Die Begleitseite zum cards42-Projekt.

Einleitung

Willkommen beim cards42-Projekt! Die Karten von cards42 unterstützen bei der täglichen Arbeit mit Softwarearchitekturen. Die Karten geben kurze Denkanstöße für festgefahrene Situationen und helfen, neues Licht auf schwierige Herausforderungen zu werfen. Diese Webseite bietet ausführliche Erklärungen sowie die Hintergründe und weitere Informationen zu den Karten.

Karten

ResourceAllocationExpectation

#expectation
Das Bild für die Karte mit dem Namen ResourceAllocationExpectation

Oft sind wir in unserer eigenen Welt mit all ihren Beschränkungen gefangen. Wir sind darauf konditioniert, uns bescheiden zu geben – bescheiden sind damit dann auch unsere Lösungen.

Aber was wäre, wenn ihr unerschöpfliche Ressourcen nutzen könntet? Was würde es im Softwaresystem bewirken? Was sind die maximal sinnvollen Ressourcen? Wie weit seid ihr hiervon weg? Wie bekommt ihr die wirklich wichtigen Ressourcen, um euer Softwaresystem noch besser zu machen?

Sammelt die Möglichkeiten auf dieser Karte und diskutiert sie mit eurem Team!

Architektur-Quick-Check

#quickcheck
Das Bild für die Karte mit dem Namen Architektur-Quick-Check

Wichtige Qualitätsziele bestimmen Entscheidungen bei der Umsetzung von Softwaresystemen maßgeblich. In diesem Quick-Check kannst Du Deine TOP 3 Qualitätsziele mit der umgesetzten Lösung vergleichen, um zu sehen, ob diese zusammenpassen.

Finde als erstes heraus, was die TOP Qualitätsziele sind. Dann identifiziere die wesentlichen Architekturansätze Deines Softwaresystems. Das sind die Dinge, die Du einer technikaffinen Person erzählst, die wissen will, wie ihr die Software aufgebaut habt. Schätze dann ab, wie gut der jeweilige Architekturansatz die Erreichung eines Qualitätsziels unterstützt (oder auch entgegenwirkt).

Mehr Informationen

Architecture Decision Record

#adr
Das Bild für die Karte mit dem Namen Architecture Decision Record

In länger entwickelten Softwaresystemen ist es mit der Zeit sehr schwierig, getroffene Entscheidungen aus der Vergangenheit nachzuvollziehen. Daher ist es wichtig, Entscheidungen und deren Beweggründe verständlich zu dokumentieren.

Mittels Architecture Decisions Records (ADRs) gibt es die Möglichkeit, Entscheidungen möglichst leichtgewichtig und einheitlich zu dokumentieren. Zudem werden hier die Gründe für eine Entscheidung und die dabei durchlaufenen Gedankengänge sowie der Kontext (Zeit, Wissen, Beteiligte, etc.) festgehalten.

Mit diesem Template könnte ihr üben, eure Entscheidungen nach den Ideen der ADRs zu strukturieren.

Mehr Informationen

Die 8-Stunden-Torte

#torte
Das Bild für die Karte mit dem Namen Die 8-Stunden-Torte

Der Tag hat 24h und die Nacht ist auch noch da. — Unbekannt.

…und plötzlich war der Tag schon wieder vorbei. Aber was habt ihr bewegt? Diese Zeittorte hilft euch zu sehen, worin ihr eure wertvolle Zeit investierst:

  • Nutzt ihr eure Zeit auch wirklich effektiv?
  • Welche der Zeitslots könnt ihr einfach loswerden?
  • Wie hart am Anschlag seid ihr ausgelastet?

Beurteilt eure genutzte Zeit auch danach, ob ihr von der Arbeit getrieben seid oder ob ihr über die Zeit selbst bestimmen könnt:

  • Welche Zeit investiert ihr für zukunftsgerichtete Arbeit?
  • Wie viel Zeit verschwendet ihr mit ungeplanten Arbeiten?
  • Welche Zeit geht für Routinearbeiten drauf?

Mehr Informationen

Deine Produktbox

#produktbox
Das Bild für die Karte mit dem Namen Deine Produktbox

Oft fehlt bei in die Jahre gekommenen Softwaresystemen die Vision oder das Zielbild. Was ist der richtige Weg? Für wen machen wir all das? Ergibt das überhaupt alles noch einen Sinn?

Die Produktbox hilft euch, wichtige Antworten für eure Software aus der Sicht der Kunden zu finden:

  • Was wird eigentlich entwickelt?
  • Wer hat den Nutzen?
  • Was sind die zentralen Verkaufs- und Nutzungsargumente?
  • Was sind die Kernfunktionen?
  • Wie hebt sich das Produkt von anderen Produkten oder der Vorgängerversion ab?

Durch die Beantwortung solcher Fragen bekommt ihr ein besseres Gefühl dafür, wofür ihr die Software wirklich entwickelt.

Mehr Informationen

Arbeite ich nach gängigen Entwicklungsstandards?

#standards
Das Bild für die Karte mit dem Namen Arbeite ich nach gängigen Entwicklungsstandards?

Mit der immer komplexer werdenden Software haben sich im Laufe der Jahre kontinuierlich mehr Standards etabliert, welche die Entwicklung und Evolution eines Softwaresystems nachweislich positiv unterstützen.

Prüft in eurem Team, welche dieser Standards ihr umsetzt und wo es möglicherweise Nachholbedarf gibt. Überlegt euch auch, warum ihr fehlende oder unzureichende Maßnahmen bisher nicht angegangen seid.

Mehr Informationen

  • Das Buch Accelerate liefert wissenschaftliche Belege zu der ein oder anderen Good Practice

Meine Architektur

#bierdeckel
Das Bild für die Karte mit dem Namen Meine Architektur

Das System ist zu komplex, um es kurz mal eben aufzumalen! – diesen oder ähnliche Sätze hat mit Sicherheit jede*r Entwickler*in schon einmal gehört.

Eine gut strukturierte und klare Softwarearchitektur muss jedoch auf einen Bierdeckel passen.

Versucht, die wichtigsten Strukturen eurer Architektur kompakt auf der Karte zu skizzieren.

  • Wann trefft ihr auf Platzprobleme? Besitzt ihr zu viel unnötigen Balast?
  • Wird es an manchen Stellen zu detailliert? Ist das System vielleicht zu unterschiedlich abstrahiert?
  • Wisst ihr nicht, was ihr malen sollt? Sind wesentliche Konzepte der Architektur nicht bekannt?

Diskutiert euere Vorgehen beim Zeichnen und die Ergebnisse. Überlegt euch, welche Maßnahmen ihr für eine noch klarere Strukturierung eures Softwaresystems vornehmen könnt.

Mehr Informationen

Der unbekannte Bekannte

#unbekannte
Das Bild für die Karte mit dem Namen Der unbekannte Bekannte

Vermutlich hat jede an einem Softwareprojekt beteiligte Person in einer technischen Rolle dieses Problem schon einmal erlebt: Man glaubt, alles richtig zu machen, und auf einmal möchte ein Stakeholder aber etwas ganz anderes. Das Unverständnis ist groß, die Frustration steigt.

Was denkt ihr, bewegt diese Person? Versucht euch, in ihre Lage zu versetzen und überlegt, was die Motivation hinter dem Verhalten des Stakeholders ist. Wie könnt ihr auf seine Bedürfnisse eingehen, um die Situation produktiver und für alle angenehmer zu gestalten?

Mehr Informationen

Mein schmerzhaftestes Problem

#schmerzen
Das Bild für die Karte mit dem Namen Mein schmerzhaftestes Problem

Probleme verursachen Kosten. Wenn diese Problemkosten die Kosten für die Lösung überproportional überschreiten, ist es durchaus rentabel, Probleme aus wirtschaftlichen Gründen anzugehen.

Diese Karte hilft Dir, ein für Dich sehr wichtiges Problem strukturiert zu erfassen und die damit verbundenen Kosten abzuschätzen. Die Intervallschätzung drückt dabei aus, wie sicher oder unsicher Du in Deiner Schätzung bist.

Mehr Informationen

Root Cause Analysis

#rootcause
Das Bild für die Karte mit dem Namen Root Cause Analysis

Softwareentwickler*innen lösen tagtäglich hunderte von kleinen und großen Problemen. Wir sind dadurch darauf konditioniert, schnell Lösungen hervorzubringen. In manchen schwierigen Situationen ist dies aber kontraproduktiv. Wir reagieren hier oft auch mit unserem antrainierten Lösungsreflex auf das erste vermeintliche und für uns klar erscheinende Problem.

Diese Karte soll euch dabei helfen, den ersten Reflex zu unterdrücken, in dem ihr mit gezielten Warum?-Fragen erst die wahren Probleme ergründet.

Versucht die sog. “5 Whys” bei verzwickten Situationen einzusetzen, um nicht nur ständig Symptome zu lösen, sondern die richtigen Problemursachen bei der Wurzel anzupacken.

Mehr Informationen

Erfolg in der Zukunft

#erfolg
Das Bild für die Karte mit dem Namen Erfolg in der Zukunft

Oft liegen sehr naheliegende Lösungen vor uns, welche maßgeblich zum Erfolg eines Softwaresystems beitragen, aber wir sehen sie gerade nicht. Zu sehr sind wir mit unserer Engstirnigkeit im Tagesgeschäft gefangen.

Diese Karte löst dieses Dilemma dadurch, dass sie euch gedanklich ganz bewusst in die ferne Zukunft versetzt. Damit eröffnet sich eine völlig andere Perspektive auf das “heutige damals”, da ihr nun auf die Gegenwart zurückblickt.

Gedanklich in der Zukunft angekommen, sammelt die TOP 3 Aktionen, die passiert sind, um euer Softwaresystem so richtig erfolgreich werden zu lassen. Diskutiert anschließend wieder im Hier und Jetzt, warum ihr die Maßnahmen noch nicht getroffen habt:

  • Was muss passieren, damit ihr es besser habt?
  • Was passiert kurz davor?
  • Was passiert dann als nächstes?
  • Wie könnt ihr jetzt loslegen?

Mehr Informationen

Wie schlimm redest Du Dir das Dokumentieren?

#ausreden
Das Bild für die Karte mit dem Namen Wie schlimm redest Du Dir das Dokumentieren?

Das Schreiben einer Dokumentation gilt als eine der unbeliebtesten Aufgaben in der Softwareentwicklung. Sehr häufig wird die Wichtigkeit der Dokumentation nicht gewürdigt oder als umständlich abgetan.

Eine gute Dokumentation hilft nicht nur anderen, sondern auch der schreibenden Person selbst. Das Schreiben und Aktualisieren der Dokumentation muss kein Hexenwerk sein, es kann parallel zur Entwicklung geschehen – sogar innerhalb der bereits geöffneten Entwicklungsumgebung. Die Verwendung von arc42 bildet eine gute Grundlage für eine gute und einfache Dokumentation von Softwarearchitekturen.

Mehr Informationen

Das Worst-Case-Szenario

#tonne
Das Bild für die Karte mit dem Namen Das Worst-Case-Szenario

Häufig überlegt man erst nach dem Ende eines Projekts was zu dem oft fatalen Ausgang geführt hat. In agilen Projekten werden zudem Retrospektiven veranstaltet, um frühzeitig Risiken für ein Projekt zu finden, aber beschränken sich diese oft nur auf die Ereignisse der vergangenen Wochen.

In beiden Fällen könnten wir fröhlich vor uns hin arbeiten bis es einen harten Cut in Form eines Projektabbruchs kommt – den wir uns dann so gar nicht erklären können.

Aber warum muss es erst so weit kommen? Macht euch Gedanken, was dazu führen könnte, dass euer Produkt in der nahen Zukunft gegen die Wand gefahren wird. Nimmt dies für unterschiedliche Zeiträume vor, damit ihr nicht im Hier und Jetzt gefangen seid. Nutzt dann diese Erkenntnisse, um geeignete Gegenmaßnahmen zu definieren und umzusetzen.

Standortbestimmung

#standort
Das Bild für die Karte mit dem Namen Standortbestimmung

Vielen Teams ist nicht bewusst, wie gut ihre Software eigentlich ist und wo für ihren Erfolg Gefahren lauern. Die Standortbestimmung hilft euch dabei, ungenutzte Chancen zu finden und blinde Flecken zu identifizieren.

Diskutiert hierfür untereinander, mit welchen Stärken eure Software punkten kann:

  • Was lief bisher richtig gut?
  • Worauf seid ihr so richtig stolz?

Fragt euch auch, welche Schwächen derzeit vorhanden sind:

  • Wo tut ihr euch schwer?
  • Was fehlt euch?

Sucht auf dieser Basis Gelegenheiten, um die identifizierten Schwächen zu kompensieren:

  • Welche Chancen könnt ihr in naher Zukunft nutzen?
  • Was könnt ihr gleich selbst ändern?

Identifiziert ebenfalls Risiken, die sich in eurer Software verbergen:

  • Welche ungünstigen Entwicklungen in eurem Umfeld gibt es?
  • Wo lauern mögliche Gefahren?

Mehr Informationen

Technische Schulden

#schulden
Das Bild für die Karte mit dem Namen Technische Schulden

Der Begriff “Technische Schulden” wirkt heutzutage schon sehr abgedroschen, diffus und auch abstrakt. Mache für Dein Softwaresystem sichtbar, was ihr im Team damit meint. Schätzt dazu ab, was und wie viel an “Technischen Schulden” ihr habt. Definiert und diskutiert die gefundenden Punkte untereinander, damit klarer wird, an was es Eurem Softwaresystem wirklich mangelt.

Mehr Informationen

Vermeide den #Shitstorm!

#shitstorm
Das Bild für die Karte mit dem Namen Vermeide den #Shitstorm!

Es gibt Personen in und um eure Software, welche einen großen Einfluss haben, ohne dass ihr es wisst. Findet heraus, welche Personen wie wichtig für den Erfolg eures Softwareprodukts sind und wie sie euer Softwaresystem sehen. Sind sie damit eher die Gewinner bzw. oder Nutznießer? Oder verlieren sie etwas, wenn euer Softwaresystem erfolgreich ist? Haben sie eine Hidden Agenda und manipulieren euere Entwicklung vielleicht sogar?

Geht entsprechend der Ansichten über euer Softwaresystem auf die jeweiligen Personen zu:

  • Wie könnt ihr Influencer besser informieren?
  • Wie könnt ihr Zusicherungen nachhalten?
  • Wen könnt ihr besser in die Pflicht nehmen?
  • Wer kann euch helfen, wenn ihr etwas eskalieren müsst?

Mehr Informationen

News

09.08.2019: Wir haben an der Performance und an der Usability gearbeitet

07.08.2019: Das Review des Redesigns des 2. Packs ist erfolgt

08.07.2019: Das Repo zur cards42.org-Seite ist nun public (Tweet)

04.07.2019: Die 1. Auflage von cards42 ist nach der Java Forum Stuttgart Konferenz komplett vergriffen (Tweet)

02.07.2019: 1. Nachdruck des 1. Teils wurde in Auftrag gegeben (mit verbesserter Banderole)

26.06.2019: Die Arbeiten am 2. Teil-Pack (von 3) beginnen. Es wird teils noch spielerischer (Tweet).

24.06.2019: Wir feiern Premiere auf der Konferenz “Developer Week 2019” (Tweet, Blog-Post).

18.06.2019: Wir gehen live (Blog-Post)! Der dazugehörige Tweet geht durch die Decke (Tweet). Wir sind gespannt, wie die gedruckten Karten bei euch ankommen!

Häufig auftretende Fragen

Wie komme ich an die Karten?

Die ersten gedruckten Kartenpacks gibt es auf Konferenzen, wo INNOQ mit vertreten ist (wie z. B. der DeveloperWeek, dem Java Forum Stuttgart oder dem Herbstcampus). Wenn alle 42 Karten fertig sind, denken wir über eine Online-Bestellmöglichkeit nach.

Wie entstand die Idee?

Markus ging eines Abends (noch nachhaltig beeindruckt von einem INNOQ Event) in eine Buchhandlung und entdeckte dort die “50 Karten: Kunterbunte Mitmach-Karten für das Handgepäck”. Diese Karten sollen Kinder zum Nachdenken über verschiedenste Dinge anregen. Markus hat sich von diesem Konzept für die “Mitmach-Karten für Softwarearchitekten*innen” inspirieren lassen und so entstanden die ersten Ideen für cards42.

Ein Foto welches die ersten Kartenideen zeigt

Warum der Name “cards42”?

Wir folgen damit der Tradition von Gernot Starke (INNOQ Fellow) bei der Namensgebung. Gernot hat bereits die Projekte arc42 und aim42 ins Leben gerufen. Er hat auch den Ursprung von 42 erklärt.

OK, und die Domain war natürlich auch noch frei ;-)

Feedback

Gerne kannst Du uns Feedback zu cards42 zukommen lassen. Nutze hierfür bitte GitHub Issues oder schreibe uns auf Twitter an. Für längere Rückmeldungen kannst Du gerne auch den Initiator des Projekts, Markus Harrer, direkt per E-Mail unter markus<punkt>harrer<at>innoq<punkt>com anschreiben.

Mitwirkende

Kontakt

Dir gefällt cards42 und Du möchtest mehr davon haben? INNOQ bietet Dir ein umfangreiches Angebot an Themen rund um Softwarearchitektur.

Besuche uns unter https://www.innoq.com/de/architektur/ oder kontaktiere uns unter https://www.innoq.com/de/kontakt. Gerne stellen wir auch das cards42-Projekt inkl. Hands-On direkt in Deiner Firma vor!