{"id":81776,"date":"2019-01-09T10:50:00","date_gmt":"2019-01-09T15:50:00","guid":{"rendered":"https:\/\/applausecomstaging.kinsta.cloud\/blog\/software-wachsen-lassen\/"},"modified":"2025-07-21T11:22:22","modified_gmt":"2025-07-21T15:22:22","slug":"software-wachsen-lassen","status":"publish","type":"post","link":"https:\/\/applausecomstaging.kinsta.cloud\/de\/blog\/software-wachsen-lassen\/","title":{"rendered":"Der agile Ansatz: Wie du dein Softwareprodukt in der Praxis wachsen l\u00e4sst"},"content":{"rendered":"

Der agile Ansatz: Wie du dein Softwareprodukt in der Praxis wachsen l\u00e4sst<\/h1>\n

In\u00a0meinem vorherigen Artikel\u00a0<\/a>ging es um die Unterschiede zwischen Software, die man wachsen l\u00e4sst, und Software, die man \u201ebaut\u201c. Beim Wachsenlassen profitiert man im Gegensatz zum rigideren Konzept des Bauens von den Aspekten, die das Wesen von Software ausmachen \u2013 Vielseitigkeit, Flexibilit\u00e4t und leichte Aktualisierbarkeit. Im Folgenden m\u00f6chte ich auf die praktische Umsetzung dieses Konzepts eingehen.<\/p>\n

Software wachsen lassen: Wie f\u00e4ngt man an?<\/strong><\/h3>\n

Schritt 1: Der Use Case<\/strong><\/h4>\n

Zu Beginn jedes neuen Projekts liegt der Schwerpunkt darauf, einen einzelnen Use Case zu haben, der end-to-end funktioniert. F\u00fcr maximale Effektivit\u00e4t sollte dein Anwendungsfall in die drei folgenden Kategorien fallen: vertikal, typisch und einfach.<\/p>\n

Vertikal insofern, als er alle Software-Schichten durchkreuzt und jede Schicht beteiligt ist. Beispielsweise sollte der Use Case bei einer Webanwendung sowohl Frontend (Daten- und Pr\u00e4sentationsschicht) als auch Backend (Datenbank- und Datenverarbeitungsschicht) umfassen.<\/p>\n

Typisch insofern, als die gr\u00f6\u00dften und h\u00e4ufigsten Herausforderungen getestet werden. Wenn die Software beispielsweise \u00fcber eine Datenbank verf\u00fcgt, sollte diese getestet werden, um sicherzustellen, dass die Risiken unter Kontrolle sind.<\/p>\n

Und schlie\u00dflich sollte der Use Case so einfach wie m\u00f6glich strukturiert sein, damit m\u00f6glichst wenige Variablen zu ber\u00fccksichtigen sind. Ziel ist es, diesen Use Case schnell abzuschlie\u00dfen, um zeitnah Feedback zu erhalten.<\/p>\n

Auf den ersten Blick bietet ein solcher Anwendungsfall nur minimale Funktionalit\u00e4t und wenig Mehrwert. Und doch:<\/p>\n

    \n
  • Er schafft einen Wert, wenn auch nur einen kleinen.<\/li>\n
  • Er ist nachweisbar, was bedeutet, dass der Wert f\u00fcr die Nutzer klar ist \u2013 und du entsprechend Feedback dazu erhalten kannst.<\/li>\n
  • Er hat durch Ber\u00fccksichtigung der wesentlichen Aspekte und Kontrolle der Risiken zum Softwaredesign beigetragen und so eine reibungslose weitere Entwicklung erm\u00f6glicht.<\/li>\n
  • Ein solcher Mehrwert ist rasch realisiert und kompensiert den geringen tats\u00e4chlich geschaffenen Wert weitestgehend.<\/li>\n<\/ul>\n

    Schritt 2: Wir lassen die Software wachsen<\/strong><\/h4>\n

    Sobald diese minimale Funktionalit\u00e4t erreicht ist, kann man wie im vorherigen Artikel beschrieben zur Wachstumsphase \u00fcbergehen. Das bedeutet:<\/p>\n

      \n
    • Ausschlie\u00dflich kleine Anpassungen vornehmen, die stets einen Mehrwert bieten<\/li>\n
    • Sicherstellen, dass der Mehrwert der Anpassungen stets nachweisbar ist<\/li>\n
    • Stets die Integration der Anpassungen mit der restlichen Software gew\u00e4hrleisten<\/li>\n
    • Die \u00c4nderungen an verschiedenen Teilen der Software vornehmen, ohne den Build in seiner Gesamtheit zu gef\u00e4hrden<\/li>\n<\/ul>\n

      Dabei k\u00f6nnen wir jederzeit Fehler machen und schnell zu unserem vorherigen Stand zur\u00fcckkehren. Das ist einfach, weil die Schritte klein sind. Es ist also kein Problem, Code wegzuwerfen. Schlie\u00dflich ist immer nur ein kleiner Teil der Arbeit betroffen.<\/p>\n

      \n
      \n

      Wenn wir uns in der Denkweise des \u201eWachsenlassens\u201c \u00fcben, k\u00f6nnen wir jederzeit Fehler machen und schnell zu unserem vorherigen Stand zur\u00fcckkehren. Das ist einfach, weil die Schritte klein sind. M\u00fcssen wir Code wegwerfen, betrifft das immer nur einen kleinen Teil unserer Arbeit.<\/p>\n<\/div>\n<\/blockquote>\n

      Produktmanagement: Entwicklung in kleinen Schritten<\/strong><\/h3>\n

      Wenn man Software wachsen l\u00e4sst, ist eine inkrementelle Vorgehensweise entscheidend f\u00fcr den Produkt-Entwicklungsprozess. Dabei sind folgende Punkte wichtig:<\/p>\n

      Bereitstellung klarer Anweisungen zur Aufspaltung des Backlogs<\/strong><\/h4>\n
        \n
      • Die Software muss zu jedem Zeitpunkt einsatzf\u00e4hig sein \u2013 nachweisbar und vollst\u00e4ndig integriert.<\/li>\n
      • Alle Backlog-Elemente m\u00fcssen einen Mehrwert bieten.<\/li>\n
      • Um schnellstm\u00f6glich Feedback zu erhalten, ist es notwendig, Elemente des Backlogs aufzuteilen bzw. herauszutrennen.<\/li>\n<\/ul>\n

        Die richtige Denkweise einnehmen<\/strong><\/h4>\n
          \n
        • In der ersten Phase der Entwicklungsarbeit soll ein Live-Build entstehen, aber auch sichergestellt werden, dass sich die Softwarearchitektur an das Projekt anpasst.<\/li>\n
        • Bei der Erstellung funktionaler Software nicht mehr als das absolute Minimum bereitstellen<\/li>\n
        • Bereit sein, Code zu verwerfen, der ein problemloses \u201eWachstum\u201c der Software verhindert<\/li>\n<\/ul>\n

          Befolge die Grunds\u00e4tze des Produktmanagements<\/strong><\/h3>\n
            \n
          • Entwickle kleine Funktionen, teste sie und optimiere sie dann \u2013 das ist der Lean-Startup-Ansatz, den ich in einem fr\u00fcheren Artikel beschrieben habe.<\/li>\n
          • Wende ein inkrementelles Vorgehen und m\u00f6glichst schnelle Iterationen an.<\/li>\n
          • Achte darauf, Risiken angemessen zu ber\u00fccksichtigen, um das Produktentwicklungs-Tempo nicht zu gef\u00e4hrden.<\/li>\n
          • Vergeude keine Zeit mit Dingen, die keinen Mehrwert schaffen.<\/li>\n<\/ul>\n

            Risiken bei Nichtbeachtung der Wachstums-Denkweise<\/strong><\/h3>\n

            Wer an der Vorstellung des Bauens von Software festh\u00e4lt, beschr\u00e4nkt seine M\u00f6glichkeiten, Fortschritte im Hinblick auf eine wirklich agile Vorgehensweise zu machen. Noch schlimmer ist es, wenn man glaubt, bereits agil zu entwickeln, die Product Operations jedoch unver\u00e4ndert bleiben. Mit folgenden Konsequenzen ist dann zu rechnen:<\/p>\n

              \n
            • Die M\u00f6glichkeiten, das Produkt in die Produktion zu \u00fcberf\u00fchren, sind eingeschr\u00e4nkt. Release-Zeiten m\u00fcssen explizit geplant werden, anstatt \u00fcber eine jederzeit auslieferbare Code-Basis zu verf\u00fcgen. Die unmittelbare Folge ist, dass jeder Produktions-Launch von unerwarteten und unangenehmen \u00dcberraschungen begleitet wird.<\/li>\n
            • Das Produkt ist f\u00fcr Anpassungen nicht ausgelegt. Je weiter die Code-Basis w\u00e4chst, desto schwieriger wird es, sie zu ver\u00e4ndern. Die Teamleistung wird immer schlechter einsch\u00e4tzbar. Gleichzeitig schnellen Produktionszeit-Sch\u00e4tzungen in die H\u00f6he. Folglich beklagen sich die Entwickler bei jedem weiteren Request, der reinkommt.<\/li>\n
            • Das System rebelliert. Durch die mangelnde Flexibilit\u00e4t rebelliert das gesamte System gegen das Unternehmen und seine Nutzer, um jegliche Weiterentwicklung (und Aufw\u00e4nde) m\u00f6glichst zu begrenzen. So wird beispielsweise die \u201eDefinition of Ready\u201c immer strikter und prozeduraler. Das Team beginnt vom \u201eScope Creep\u201c zu sprechen, ungeplanten Anforderungen, die den Launch verz\u00f6gern, jedoch f\u00fcr die Endanwender wesentlich sind.<\/li>\n
            • Umsetzer versus Strategen. Dein Team befolgt eine Umsetzungsmentalit\u00e4t, anstatt \u00fcber die eigentliche Bedeutung hinter dem Produkt und die Aufgabe nachzudenken, die es erf\u00fcllen soll.<\/li>\n<\/ul>\n

              Agil zu entwickeln, aber gleichzeitig an der Denkweise des Bauens statt des Wachsens festzuhalten, bedeutet, dass du wahrscheinlich genauso wie vorher arbeitest und eine Art Pseudo-Agilit\u00e4t betreibst. So kannst du keine echten, greifbaren Fortschritte machen.<\/p>\n

              Eine Analogie als Orientierung<\/strong><\/h3>\n

              Die Wachstumsprozesse der Natur als Analogie f\u00fcr die Softwareentwicklung zu benutzen ist also durchaus schl\u00fcssig. Die Natur ist so komplex, dass eine Analyse der Grundprinzipien, nach denen Leben gedeiht, zweifellos der richtige Weg ist, um der Komplexit\u00e4t von Software-Entwicklungsprojekten Rechnung zu tragen.<\/p>\n<\/div><\/div><\/div><\/div><\/div>","protected":false},"excerpt":{"rendered":"

              Mein zweiter Artikel \u00fcber den agilen Ansatz Software wachsen zu lassen. Gehen wir nach der Theorie nun zur Praxis \u00fcber.<\/p>\n","protected":false},"author":42,"featured_media":74791,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[282],"tags":[943],"resource-industry":[],"resource-solution":[],"resources\/types":[1244],"class_list":["post-81776","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unkategorisiert","tag-agile","resource-type-blogs-de"],"acf":[],"_links":{"self":[{"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/posts\/81776","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/users\/42"}],"replies":[{"embeddable":true,"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/comments?post=81776"}],"version-history":[{"count":0,"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/posts\/81776\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/media\/74791"}],"wp:attachment":[{"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/media?parent=81776"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/categories?post=81776"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/tags?post=81776"},{"taxonomy":"resource-industry","embeddable":true,"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/resource-industry?post=81776"},{"taxonomy":"resource-solution","embeddable":true,"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/resource-solution?post=81776"},{"taxonomy":"resource-type","embeddable":true,"href":"https:\/\/applausecomstaging.kinsta.cloud\/de\/wp-json\/wp\/v2\/resources\/types?post=81776"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}