cards+
  1. Agil dokumentieren, geht das?

    Das Ziel agiler Entwicklung ist es, den Entwicklungsprozess flexibler und schlanker zu gestalten, als das bei den klassischen Vorgehensmodellen der Fall ist. Gilt das auch für das Dokumentieren?

    Jetzt lesen
  2. Neustart auf „grüner Wiese“.

    Nehmen Sie an, Sie werden beauftragt, ein völlig neues Software-Produkt zu entwickeln. Sie bekommen die Chance, eine individuelle Lösung mit einer agilen Projektorganisation auf der „grünen Wiese” zu entwerfen.

    Jetzt lesen
  3. Zurück auf Anfang.

    Stellen Sie sich ein Szenario vor, in dem ein Auftraggeber ein individuell entwickeltes IT-System durch eine Lösung mit einem Standardprodukt ersetzen will. Sie bekommen den Auftrag, die Migration zu planen und umzusetzen.

    Jetzt lesen
  4. Leistungs­­beschrei­bung für den Auf­trag­­geber

    Auf­grund der noch immer fehlenden Rechts­sicher­heit bei Gewer­ken mit agiler Soft­ware-Ent­wicklung besteht regel­mäßig der Bedarf an einem Lasten­heft. Arbeiten Auftra­ggeber und Pro­dukt­verant­wort­licher konse­quent mit cards+, dann besteht die Mög­lich­keit, die Leistungs­beschrei­bung für das Lasten­heft zu großen Teilen aus dem Wiki zu expor­tie­ren.

    Jetzt lesen
  5. Schnitt­stel­len­­beschrei­bung für Part­ner­­sys­teme

    Schnitt­stellen­beschrei­bungen sind alter­nativ­los in einer kom­plexen IT-System­land­schaft mit vielen unab­hängi­gen Par­tner­systemen aus ver­schiede­nen Organi­sationen eines Unter­nehmens. Ein Pro­dukt­verant­wort­licher darf sich trotz­dem die Frage stel­len, wie umfang­reich so ein Doku­ment sein muss. Mit cards+ kann er das Wiki zu seinem Vorteil nutzen.

    Jetzt lesen
  6. Gute Programmierer – schlechte Software

    Ein Gerichtssachverständiger für Softwarequalität erklärt, warum Software selten dem Stand der Technik entspricht.

    Jetzt lesen
  7. Warum nicht kontinuierlich Dokumentieren?

    Mit Continuous Documentation ändern wir die Art und Weise, wie wir Spezifikationen erstellen und integriert in einer Produktdokumentation konsumieren. Wir folgen den Prinzipien der kontinuierlichen Verbesserung in den Dimensionen Code, Test und Spezifikation.

    Jetzt lesen
  8. Ist Domain-Driven Design überbewertet?

    Ist der Hype um Domain-Driven Design berechtigt oder verbirgt sich dahinter nur alter Wein in neuen Schläuchen?

    Jetzt lesen