Die Begleitseite zum cards42-Projekt. Now also availabile in English!
#adr
#ausreden
#bierdeckel
#codesmell
#dokucheck
#erfolg
#expectation
#expertise
#idol
#investment
#minidoku
#minirisiko
#nutzen
#powerskills
#produktbox
#quickcheck
#roadmap
#rootcause
#schmerzen
#schulden
#shitstorm
#standards
#standort
#tonne
#torte
#traum
#unbekannte
#vergleich
#wege
#zauberstab
#expectation
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!
#quickcheck
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
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
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 investiert:
Beurteilt eure genutzte Zeit auch danach, ob ihr von der Arbeit getrieben seid oder ob ihr über die Zeit selbst bestimmen könnt:
Mehr Informationen
#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:
Durch die Beantwortung solcher Fragen bekommt ihr ein besseres Gefühl dafür, wofür ihr die Software wirklich entwickelt.
Mehr Informationen
#standards
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
#bierdeckel
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.
Diskutiert euer 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
#unbekannte
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
#schmerzen
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
#rootcause
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
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:
Mehr Informationen
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
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.
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:
Fragt euch auch, welche Schwächen derzeit vorhanden sind:
Sucht auf dieser Basis Gelegenheiten, um die identifizierten Schwächen zu kompensieren:
Identifiziert ebenfalls Risiken, die sich in eurer Software verbergen:
Mehr Informationen
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 gefundenen Punkte untereinander, damit klarer wird, an was es Eurem Softwaresystem wirklich mangelt.
Mehr Informationen
#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:
Mehr Informationen
#codesmell
Ähnlich wie in Horrorfilmen, gibt es auch in der Softwareentwicklung Monster. Diese kosten euch zwar nicht das Leben, dafür aber sehr viel Zeit, Nerven und im schlimmsten Fall Geld. Gottklassen, von denen eine riesige Anwendung abhängt, switch-Anweisungen mit unzähligen Einträgen oder eine Parameterliste, welche den halben Bildschirm einnimmt: all das sind die Monster, die uns jeden Tag begegnen können. Wie sieht dein persönliches Code-Smell-Monster aus? Male es auf die Karte und überlege dir, wie du es besiegen kannst.
Weitere Informationen
#dokucheck
Oft haben wir hunderte Seiten Dokumentation – und gefühlt versteht diese niemand oder sie ist hoffnungslos veraltet. In der Folge wird meist weniger Dokumentation erstellt oder vorhandene nicht mehr weiter gepflegt. Selten hinterfragen wir allerdings den Grund für das Unverständnis. Mit unserer Checkliste könnt ihr in ein paar Minuten prüfen, ob die vorhandene Dokumentation korrekt auf die Zielgruppe abgestimmt und auf dem aktuellen Stand ist.
Hakt dafür bei jedem Aspekt, den ihr klar mit “Ja!” beantworten könnt, das entsprechende Kästchen an. Gibt es Aspekte, die nicht OK sind? Dann habt ihr schon die ersten Anhaltspunkte, wo ihr eure Dokumentation schrittweise verbessern könnt. Idealerweise führt ihr diesen Check regelmäßig durch, damit ihr sicher sein könnt, dass eure Dokumentation immer zielgerichtet und aktuell bleibt.
Ihr wisst bei einem kniffligen Problem nicht mehr weiter? Ihr müsst etwas schnell umsetzen, habt aber eine Denkblockade? Ihr seid verzweifelt, weil euch die einfachsten Ideen fehlen?
Fragt euch: Was würde jetzt eine Person, zu der ihr aufschaut, in eurer Situation machen?
Zieht euch aus eurer misslichen Lage, indem ihr euch bewusst eine andere Sichtweise auf eure Probleme schafft!
#zauberstab
Wäre es nicht schön, wie Hermine Granger in “Harry Potter” den Zauberstab schwingen zu können und sofort ist die Brille – oder in unserem Fall ein Software-System – repariert?
Leider ist die Welt nicht so einfach und wir haben keinen Weg, um per Zauberspruch unsere Probleme zu lösen. Stattdessen bedarf es viel harter Arbeit, um problematische Systeme zurück in geordnete Bahnen zu führen.
Aber vielleicht hilft es euch beim Nachdenken, wenn ihr unseren goldenen Zauberstab schwingt. Überlegt euch, was euer Zauberspruch reparieren würde, wenn ihr die Möglichkeit hättet. Diskutiert anschließend die Ergebnisse in der Gruppe. Und wer weiß, vielleicht findet sich ja ein magischer Einfall, der das ein oder andere Problem löst.
#powerskills
Verschiedene Softwaresysteme mit ihren verschiedenen Softwarearchitekturen brauchen auch verschiedene Fähigkeiten der Beteiligten, um erfolgreich zu sein.
Findet es mit dieser Karte heraus, in dem ihr die vier wichtigsten Skills in die vier Felder schreibt! Ihr wollt es noch genauer machen? Dann vergebt zusätzlich noch Punkte zwischen 0-100, um die Ausprägung der jeweiligen Fähigkeit festzulegen.
Stellt ihr fest, dass euch notwendige Skills fehlen, sucht nach Möglichkeiten, euch diese gezielt anzueignen oder holt euch Leute in euer Team, die diese Skills besitzen.
Wir Techies können es oft gar nicht erwarten, bei einem neuen Softwareprojekt in die Tasten zu hauen. Zu selten fragen wir uns aber: “Sind denn die Grundlagen für ein erfolgreiches Softwaresystem bekannt?”
Ist dies nicht der Fall ist, kann sich ein Team noch so stark anstrengen:
Diese Checkliste hilft euch bei der Einschätzung, ob ihr in der Anfangsphase eures Projekts an die wichtigsten Dinge gedacht habt, und gibt Denkanstöße, was euch noch fehlen könnte.
Weitere Informationen
#investment
Investitionen sagen viel über den Status eines Softwareprojektes aus. Häufig müsst ihr als Architekt*innen technische Themen (wichtig) gegenüber den Produktthemen (dringend) vertreten.
Support/Bugfixing – Fehler sind oft leichter zu beheben, je eher sie im Zyklus der Softwareentwicklung gefunden werden. Hotspots bei Fehlern sind gute Kandidaten für Refactorings. Ihr solltet hier idealerweise einen Wert unterhalb von 10% haben – sehr wahrscheinlich ist der Wert aber größer.
Technische Verbesserungen – Reduziert ihr technischen Schulden eures Systems,
so verbessert ihr dadurch die Qualität der Software und reduziert gleichzeitig
die Kosten für Fehlerbehebung sowie Entwicklungszeiten neuer Themen.
Die Empfehlung liegt bei etwa 10-15%.
Neue Features – Die Entwicklung neuer Funktionen bringt den Geschäftswert, daher solltet ihr hier am meisten investieren. Mindestens 50% oder mehr eurer Entwicklungszeit solltet ihr darauf verwenden, neuen Wert zu schaffen.
Architekturarbeit – Nur durch kontinuierliche Arbeiten an der Architektur könnt ihr die Software am Leben halten und ermöglicht das Adressieren neuer Zukunftstrends sowie Anforderungen. Ein Empfehlungswert liegt hier bei 15-20% in größeren Projekten.
Mehr Informationen
Viele Personen verbinden mit Architekturdokumentation lange und komplexe Dokumente, deren Aussagekraft meist fragwürdig ist. Dementsprechend hoch sind die Hürden, selbst mit einer Dokumentation anzufangen. Dass dies aber auch ganz einfach sein kann, demonstriert unsere Minidoku.
Beginne damit, den geschäftlichen Grund der Software zu nennen oder kurz zu beschreiben. Damit ist klargestellt, warum man diese Software überhaupt braucht. Anschließend notiere die drei wichtigsten Qualitätsmerkmale, geordnet nach ihrer Priorität. Zum Schluss werden noch die wichtigsten Design-Entscheidungen skizziert, damit diese nachhaltig dokumentiert und nachvollziehbar sind.
Mit dieser Minidoku ist dann auch erfolgreich der Grundstein zu einer umfangreicheren Architekturdokumentation gelegt. Um diese ohne unnötigen Overhead zu erstellen, kann z. B. ein Template wie arc42 verwendet werden.
Mehr Informationen
Jeden Tag werden Entscheidungen getroffen, die unsere Software oft langfristig gestalten. Jeder dieser Entscheidungen liegen mehrere Optionen zu Grunde, von denen allerdings immer nur eine als Lösungsansatz gewählt werden kann. Die gewählte Option wird meistens in einer Architekturdokumentation beschrieben und ist damit nachvollziehbar. Was ist aber mit den Optionen, die ebenfalls betrachtet aber nicht ausgewählt wurden? Auch diese sollten dokumentiert werden, um die getroffenen Entscheidungen langfristig nachvollziehen zu können.
Überlegt euch nun, welche Wege ihr bewusst nicht in eurer Software eingeschlagen habt. Tragt diese auf der Karte ein und beschreibt, was der Grund für die Ablehnung der einzelnen Optionen war. Die Ergebnisse dieser Karte könnt ihr beispielsweise verwenden, um Architecture Decision Records für eure Software anzulegen, um so deren Historie nachvollziehbarer zu gestalten.
Mehr Informationen
#expertise
Niemand von uns kann alles, aber sicher kann jede/r etwas besonders gut. Dieses besondere Wissen zu teilen, hilft euch, euer Team noch besser zu machen und Wissensinseln zu verringern.
Was ist also euer absolutes Expertenthema? Schreibt dieses Thema – jede und jeder für sich – auf eine Karte und überlegt euch, welche fünf Anleitungen, Bücher, Blogs oder sonstige Ressourcen euch dabei geholfen haben, in das Thema einzusteigen. Sortiert diese, beginnend bei der leichtesten Einstiegsressource, und schreibt sie ebenfalls auf die Karte.
Tauscht euch im Anschluss über eure Ergebnisse aus. Hat vielleicht noch jemand dieses Thema gewählt und es war niemandem bewusst? Perfekt! Denn dadurch ergibt sich eine größere Ansammlung an Wissen und vielleicht auch unterschiedlichen Lernressourcen. Sammelt die ausgefüllten Karten idealerweise an einem Ort, der jeder und jedem im Team zugänglich ist. So könnt ihr jederzeit auf die Lernressourcen zurückgreifen und euer Wissen erweitern.
#minirisiko
Auch wenn wir es ungerne hören: Risiken begleiten unsere Projekte vom ersten Moment an. Häufig wird jedoch vergessen, sowohl diese Risiken als auch deren Gegenmaßnahmen, entsprechend zu dokumentieren. Dies kann später fatale Folgen haben, wenn beispielsweise auf zu fragile Nachbarsysteme gesetzt, oder vielleicht auch relevante Regulatorik übersehen wird.
Überlegt euch, welche Risiken es in eurem Projekt gibt und dokumentiert je ein Risiko pro Karte. Im Anschluss daran notiert ihr die Maßnahme zur Minimierung des Risikos und die davon erwarteten Auswirkungen.
Diskutiert die Ergebnisse miteinander. Habt ihr möglicherweise ein bisher unbekanntes Risiko entdeckt? Sehr gut! Damit könnt ihr euer Projekt gleich etwas sicherer machen und die Architekturdokumentation erweitern. Zusätzlich könnt ihr sowohl euch als auch betroffene Stakeholder dafür sensibilisieren.
#vergleich
Wer kennt es nicht: Man darf ein neues Projekt starten und hat die Qual der Wahl bei der Auswahl der zu nutzenden Technologie. Als Techniker*in nimmt man natürlich am liebsten die neueste Sprache oder das neueste und hipste Framework, aber ist das wirtschaftlich überhaupt vertretbar? Häufig gibt es für neue Technik kaum Support, wenige Spezialisten und hier und da muss auch das Rad erst wieder neu erfunden werden. Das alles kostet Geld – im Worst Case sehr viel Geld. Damit ihr den wirtschaftlichen Faktor einer Technologieentscheidung nicht vernachlässigt, hilft euch diese Karte, die wichtigsten Fragen zu beantworten.
Vergleicht dazu zwei Technologien, die ihr für euer Projekt auswählen würdet. Dann entscheidet für jede Frage, welche der beiden die Anforderungen besser erfüllt. Dazu könnt ihr ein für euch passendes Bewertungssystem nutzen, beispielsweise eine Bewertungsskala von 1-5. Zählt am Ende die Einzelbewertungen pro Technologie zusammen und vergleicht das Ergebnis. Möglicherweise seid ihr überrascht, dass vielleicht doch nicht die neue Supertechnologie “gewonnen” hat, sondern etwas Älteres und Etabliertes.
Das Ergebnis dieser Bewertung könnt ihr nun für die weitere Projektplanung und eine Architekturdokumentation nutzen. Außerdem hilft euch die Bewertung dabei, eine Entscheidung auch bei Projektleiter*innen / -manager*innen vertreten zu können, die weniger auf Technik, aber dafür umso mehr auf Wirtschaftlichkeit einer Lösung achten.
Kennt ihr das? Ihr kommt ganz frisch von einer Konferenz und möchtet den ganzen neuen Kram jetzt und sofort bei euch umsetzen. Dann aber denkt ihr darüber nach, und irgendetwas hindert euch dann doch daran: der ganze vorhandene alte Kram!
Es sind oft die vorhandenen Rahmenbedingungen, welche es (zumindest jetzt) schwer machen, den Tech-Stack zu aktualisieren. Aber wie könnt ihr frühzeitig kommunizieren, dass ihr schon die ein oder andere neue Sache im Blick habt?
Diese Karte hilft euch, einen klaren Kopf zu behalten, anstatt zu verzweifeln und das Handtuch zu werfen. Legt offen, welche Technologie ihr in welchem Stadium der Adaption seht. Bewertet nicht nur die neuen Trend-Themen, welche ihr interessant für eure Software findet, sondern versucht auch, bereits verwendete Technologie in eine der folgenden Stadien einzuordnen und damit die aktuelle Sichtweise auf die Technologien zu kommunizieren:
Mehr Informationen
“Lasst uns doch dieses neue Framework einbauen, das letzte Woche erschienen ist!”
Bestimmt habt ihr in einem eurer Projekte diese Aussage in ähnlicher Form schon einmal gehört oder gar selbst getroffen. In erster Linie schreibt ihr eure Software für eure Anwender*innen oder euren Kund*innen. Und dennoch wird bei Entscheidungen viel zu selten darauf geachtet, welchen Nutzen eure Zielgruppe von der bevorstehenden Änderung hat.
Ihr wollt ein eigenes komplexes Logging-Framework für eure Software schreiben und rechnet mit ca. sechs Wochen Entwicklungszeit? Dies wird für die Stakeholder sehr wahrscheinlich – hoffentlich! – keine spürbaren Auswirkungen haben, hindert euch aber gleichzeitig daran, in dieser Zeit neue Features zu entwickeln.
Ihr habt vor, eine weitere, neue Bezahlmethode in euerem System zu integrieren, seid aber nicht sicher, ob dafür neun Wochen Entwicklung verwendet werden können? Viele eurer Anwender*innen könnten dankbar sein, dass sie eine neue Möglichkeit bekommen, Produkte bei euch zu bezahlen. Dieses Feature hat also einen sehr großen Nutzen.
Mit dieser Karte könnt ihr bei euren nächsten Entscheidungen überprüfen, wie viel Nutzen die Anwender*innen daraus ziehen und ob die Änderungen tatsächlich sinnvoll oder notwendig sind.
Mehr Informationen
04.11.2019: Das 2. Set ist on- und offline verfügbar!
11.10.2019: Die Karten des 2. Sets sind im finalen Review.
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).
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!
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.
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.
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 ;-)
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.
Dieses Werk ist lizenziert unter einer Creative Commons: Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International (CC BY-SA 4.0).
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!
