1. Testen zeigt die Anwesenheit von Fehlern

Das Hauptziel des Testens ist es, Fehler und Mängel in einem System zu identifizieren. Es ist jedoch wichtig zu bedenken, dass das Testen nicht beweisen kann, dass ein System absolut fehlerfrei ist. Das Ausbleiben entdeckter Fehler bedeutet nicht zwangsläufig, dass das System perfekt ist.

2. Vollständiges Testen ist nicht möglich

Es ist unpraktisch und oft unmöglich, alle Kombinationen von Eingaben, Szenarien und Ausführungspfaden in einem komplexen System zu testen. Daher ist eine Teststrategie erforderlich, die auf Risikobewertung und Priorisierung basiert.

3. Grundsatz: Frühzeitiges Testen

Die Minimierung der Kosten und des Zeitaufwands für die Fehlerbehebung erfordert den Beginn der Testaktivitäten so früh wie möglich im Entwicklungszyklus. Der „Shift-Left“-Ansatz im Testen unterstreicht dieses Prinzip.

4. Grundsatz: Häufung von Fehlerzuständen

Das Pareto-Prinzip, auch bekannt als 80/20-Regel, ist auch im Testen relevant: 80% der Fehler treten normalerweise in 20% der Module auf. Dies unterstreicht die Bedeutung einer gezielten Testplanung.

5. Pestizid-Paradoxon bzw. Pestizid-Resistenz

Wiederholtes Durchführen derselben Tests führt schließlich zu einer Abnahme ihrer Effektivität bei der Identifizierung neuer Fehler. Daher ist es wichtig, Tests regelmäßig zu überprüfen und zu aktualisieren, um ihre Effektivität zu erhalten. (Siehe auch meinen Beitrag Pestizid-Paradoxon – Resistenz von Bugs und Fehlern)

6. Grundsatz: Testen ist kontextabhängig

Die Art und Weise, wie getestet wird, hängt stark vom Kontext ab, in dem das System eingesetzt wird. Ein Finanzsystem erfordert beispielsweise strengere Testanforderungen als ein persönliches Blogging-Tool wie WordPress.

7. Grundsatz: Fehlerabsenz-Trugschluss – Keine Fehler bedeutet ein brauchbares System

Das erfolgreiche Durchlaufen von Tests ist nicht gleichbedeutend mit der Einsatzbereitschaft des Systems. Eine sorgfältige Bewertung der Testergebnisse und der Qualität des Systems insgesamt ist unerlässlich, bevor eine Bereitstellungsentscheidung getroffen wird.

Fazit

Indem diese Grundprinzipien beachtet und in die Teststrategie integriert werden, kann man die Qualität von Systemen sicherstellen. Vor allem lassen sich die Systeme dadurch effektiv bewerten und kontinuierlich verbessern.

Ein spezifisches Manifest, das ausschließlich die Grundprinzipien des Testens behandelt, ähnlich wie das Agile Manifest, die Werte und Prinzipien agiler Softwareentwicklung definiert, existiert nicht. Die genannten Grundprinzipien sind jedoch weitgehend anerkannt und in zahlreichen Standards, Best Practices und Schulungsmaterialien für das Testen von Software und Systemen festgelegt.

Einer der am häufigsten referenzierten Standards ist das ISTQB (International Software Testing Qualifications Board), das ein detailliertes „Body of Knowledge“ für das Softwaretesten bietet und dabei viele dieser Grundprinzipien behandelt. Dazu werde ich bestimmt in naher Zukunft auch noch einen Beitrag schreiben.

Außerdem gibt es Manifeste und Prinzipien, die sich mit Qualitätssicherung und Testen im Kontext spezifischer Ansätze wie Agile oder DevOps befassen. Diese Manifeste betonen oft Aspekte wie kontinuierliches Testen, die Einbeziehung von Testen in alle Phasen des Entwicklungslebenszyklus und die Bedeutung von Automatisierung beim Testen.

Der Beitrag Die Sieben Grundprinzipien des Testens – Eine Übersicht erschien zuerst auf CEOsBay.

Was ist Design Thinking?

Es ist im Grunde genommen eine problemlösende Methode, die darauf abzielt, innovative Lösungen zu entwickeln, indem sie sich auf die menschliche Erfahrung, Experimente, Zusammenarbeit und kreatives Denken konzentriert. Es ist nicht nur auf Produktdesign beschränkt. Man kann es auf alle Bereiche des Lebens anwenden, in denen innovative Lösungen erforderlich sind.

Kurze Zeitreise

Der Ursprung des Konzepts lässt sich auf das letzte Jahrhundert zurückverfolgen und ist eng mit mehreren führenden Denkern und Institutionen verknüpft.

Die frühe Verbindung kann man auf den britischen Designer und Theoretiker John Christopher Jones zurückführen, der in den 1960er Jahren die Idee vorstellte, dass Design ein Denkprozess ist, der nicht auf die Gestaltung von Produkten beschränkt ist.

In den 1970er Jahren prägte der amerikanische Architekt und Städteplaner Horst Rittel den Begriff „wicked problems“ für komplexe Probleme, die nicht man nicht durch herkömmliche lineare oder logische Ansätze lösen konnte. Diesen Begriff hat man später in den Prozess des Design Thinking integriert.

Die Popularisierung und Weiterentwicklung des Konzepts kann man der Stanford University und dem Hasso-Plattner-Institut für Design (besser bekannt als die „d.school“) zuschreiben. Den Begriff selbst haben jedoch erstmals David M. Kelley, dem Gründer von IDEO und Professor an der Stanford University sowie Tim Brown, dem CEO von IDEO, in die Geschäftswelt eingeführt. Sozusagen, die Ersten, die Design Thinking als Methode für Innovation und für die Problemlösung definierten und systematisierten.

Es ist demnach nicht nur auf die historischen Persönlichkeiten und Institutionen beschränkt. Es ist ein dynamisches und sich ständig weiterentwickelndes Feld, das Beiträge von Designern, Forschern, Pädagogen und Praktikern aus der ganzen Welt beinhaltet.

Seit der Entstehung hat sich Design Thinking von einer Nischenmethode zu einer weit verbreiteten Praxis entwickelt, die in einer Vielzahl von Kontexten Anwendung findet. Von Produkt- und Servicedesign über soziale Innovation, bis hin zu strategischer Planung und Bildung.

Die Prinzipien des Design Thinking

Es basiert auf fünf Kernprinzipien:

1. Empathie für den Nutzer: Hier geht es darum, die Bedürfnisse und Erwartungen der Nutzer zu verstehen, um Lösungen zu finden, die wirklich relevant und effektiv sind.
   
2. Definieren des Problems: Hier wird das Problem klar und präzise definiert, um den Fokus auf die tatsächlichen Herausforderungen zu legen.
   
3. Ideenfindung: In diesem Schritt generiert man möglichst viele Lösungsansätze, ohne sie zu bewerten. Der Zweck besteht darin, kreatives Denken und die Innovation zu fördern.
   
4. Prototyping: Hierbei setzt man ausgewählte Ideen in konkrete Modelle um, um zu sehen, wie sie in der Praxis funktionieren.
   
5. Testen: In dieser Phase testet man die Prototypen auf ihre Effektivität und gegebenenfalls nimmt man noch Anpassungen vor.

Warum ist Design Thinking wichtig?

In einer sich schnell verändernden Welt sind traditionelle Methoden oft nicht mehr ausreichend, um neue Herausforderungen zu bewältigen. Es bietet einen flexiblen und kreativen Ansatz, der es Unternehmen und Individuen ermöglicht, Probleme zu lösen und Innovationen zu entwickeln, die den Bedürfnissen der Nutzer entsprechen.

Durch die Einbeziehung des Nutzers in den Designprozess und die Förderung des kreativen Denkens kann Design Thinking dazu beitragen, Produkte und Dienstleistungen zu schaffen, die wirklich auf die Bedürfnisse der Nutzer abgestimmt sind. Dies kann zu einer höheren Kundenzufriedenheit und zu einem nachhaltigen Geschäftserfolg führen.

Wie man Design Thinking in der Praxis anwendet

Die Anwendung von Design Thinking erfordert ein offenes Denken, Experimentierfreude und die Bereitschaft, aus Fehlern zu lernen. Im Folgenden sind einige Schritte, die man befolgen kann, um es in einer Organisation zu implementieren:

Man beginnt mit Schulungen und Workshops, um das Bewusstsein für Design Thinking zu schaffen und um die notwendigen Fähigkeiten zu entwickeln.

Zielsetzung ist die Förderung einer Kultur der Kreativität und Offenheit, in der neue Ideen willkommen sind und bei der man Fehler als Lernchancen sieht.

Design Thinking-Tools und -Techniken, wie Brainstorming, Storyboarding, Nutzerinterviews und Prototyping helfen dabei, kreative Lösungen zu entwickeln.

Es empfiehlt sich, vielfältige Teams zu bilden, die verschiedene Perspektiven und Fähigkeiten einbringen, um kreative Lösungen zu entwickeln bzw. um die Betrachtung von Herausforderungen aus verschiedenen Blickwinkeln zu ermöglichen.

Schließlich kann man den Erfolg von Design Thinking-Initiativen messen, um zu sehen, ob sie zu den gewünschten Ergebnissen führen und wo man gegebenenfalls ansetzt, um weitere Anpassungen vorzunehmen.

Zusammenhang Design Thinking und DevOps

Der Zusammenhang zwischen Design Thinking und DevOps liegt in ihrer gemeinsamen Ausrichtung auf kontinuierliche Verbesserung, Benutzerorientierung und Kollaboration. Man kann Design Thinking am Anfang des Produktentwicklungsprozesses anwenden, um Benutzerbedürfnisse zu verstehen, Probleme zu definieren und innovative Lösungen zu entwerfen. Im Anschluss kann man DevOps nutzen, um diese Lösungen schnell und effizient zu entwickeln, zu testen und zu releasen, wobei man auch eine Kultur der Zusammenarbeit und des kontinuierlichen Verbesserns fördert.

Wenn man Design Thinking und DevOps zusammen anwendet, kann es dabei helfen, Produkte und Dienstleistungen zu erschaffen, die nicht nur technisch hochwertig und zuverlässig sind, sondern auch die Bedürfnisse und Erwartungen der Benutzer in einem größeren Umfang erfüllen. Diese Synergie kann zu höherer Benutzerzufriedenheit, schnellerer Markteinführungszeit und insgesamt besseren Geschäftsergebnissen führen.

Fazit:

Design Thinking ist eine mächtige Methode, um Innovation zu fördern und um Probleme zu lösen. Indem man Empathie für den Nutzer entwickelt, kreatives Denken fördert und durch iterative Prozesse lernt, kann man Produkte und Dienstleistungen entwickeln, die wirklich den Bedürfnissen der Kunden entsprechen.

Ganz unabhängig davon, ob man ein neues Produkt entwickelt, eine Dienstleistung verbessert oder eine geschäftliche Herausforderung bewältigen möchte, Design Thinking kann dabei helfen, effektive und innovative Lösungen zu finden. Es ist eine Reise, die Neugier, Empathie und Mut erfordert, aber die Ergebnisse können es wert sein.

Der Beitrag Design Thinking – Kreativität und Innovation fördern erschien zuerst auf CEOsBay.

Die Grundprinzipien von Scrum

Scrum basiert auf drei grundlegenden Säulen: Transparenz, Inspektion und Adaption. Diese Säulen stellen sicher, dass alle Beteiligten über den Projektstatus informiert sind, kontinuierlich überprüfen, wie die Arbeit voranschreitet, und bei Bedarf Anpassungen vornehmen, um die Ziele zu erreichen.

Transparenz: Alle Projektinformationen müssen für alle Teammitglieder sichtbar und zugänglich sein. Dazu gehören Fortschritt, Hindernisse und Änderungen am Projektplan.

Inspektion: Das Team prüft regelmäßig die Fortschritte und identifiziert Probleme oder Verbesserungspotenziale. Dies geschieht durch verschiedene Meetings und Feedback-Loops.

Adaption: Hat man Probleme identifiziert, müssen Maßnahmen folgen, um diese zu beheben und den Prozess zu verbessern. Die Umsetzung der Änderungen sollte schnell und effektiv erfolgen.

Rollen in Scrum

Product Owner: Der Product Owner ist für die Definition und Priorisierung der Anforderungen an das Produkt verantwortlich. Verantwortlich für den sogenannten „Product Backlog“, eine Liste von Aufgaben und Funktionen, deren Implementierung in das Produkt erforderlich ist.

Scrum Master: Der Scrum Master ist ein Coach und Vermittler für das Team. Verantwortlich für die Einhaltung der Scrum-Prinzipien und -Praktiken. Hilft bei der Beseitigung von Hindernissen, die die Arbeit des Teams beeinträchtigen können.

Entwicklerteam: Das Entwicklerteam ist eine Gruppe von Fachleuten, die zusammenarbeiten, um die Aufgaben des Product Backlogs in funktionsfähige Produktinkremente umzusetzen.

Artefakte

Scrum verwendet mehrere Artefakte, um die Planung und den Fortschritt des Projekts zu verfolgen:

Product Backlog: Eine Liste aller gewünschten Funktionen, Anforderungen und Verbesserungen, deren Umsetzung im Produkt erforderlich ist. Der Product Owner ist für die Priorisierung und Aktualisierung des Backlogs verantwortlich.

Sprint Backlog: Eine Liste der Aufgaben, die das Team im aktuellen Sprint (einem festgelegten Zeitraum von normalerweise zwei bis vier Wochen) abgeschließt. Die Erstellung des Sprint Backlogs ist die Aufgabe des Entwicklerteams und basiert auf den Prioritäten des Product Backlogs.

Inkrement: Das Ergebnis eines jeden Sprints, ein potenziell auslieferbares Stück des Produkts, das neue oder verbesserte Funktionen bietet. Inkremente sollen den Wert des Produkts für den Kunden kontinuierlich steigern.

Events

Scrum definiert verschiedene Events oder Meetings, um den Kommunikationsfluss und die Zusammenarbeit im Team zu fördern und um den Fortschritt zu überwachen:

Sprint Planning: Zu Beginn jedes Sprints trifft sich das gesamte Team, um den Umfang des nächsten Sprints zu planen. Dabei wählen sie die wichtigsten Elemente aus dem Product Backlog aus und erstellen das Sprint Backlog.

Daily Scrum: Ein tägliches, kurzes Stand-up-Meeting, bei dem jedes Teammitglied den Fortschritt, die Pläne für den Tag und mögliche Hindernisse teilt. Dies fördert die Transparenz und hilft, Probleme frühzeitig zu identifizieren.

Sprint Review: Am Ende jedes Sprints präsentiert das Team das fertige Inkrement dem Product Owner und den Stakeholdern, um Feedback zu erhalten und den Fortschritt zu bewerten.

Sprint Retrospektive: Nach dem Sprint Review reflektiert das Team intern über den Sprint und identifiziert Verbesserungsmöglichkeiten für zukünftige Sprints.

Fazit

Scrum ist ein agiles Rahmenwerk, das den Fokus auf Transparenz, Inspektion und Adaption legt, um den Projekterfolg zu fördern. Durch die Definition klarer Rollen, Artefakte und Events unterstützt Scrum die effektive Zusammenarbeit innerhalb des Teams und die kontinuierliche Verbesserung der Arbeitsprozesse. Die Implementierung von Scrum kann zu einer erhöhten Produktivität, schnelleren Anpassungsfähigkeit an Veränderungen und einer besseren Kundenzufriedenheit führen. Unternehmen und Projektteams, die sich für einen agilen Ansatz entscheiden, können Scrum als wertvolles Instrument in Betracht ziehen, um ihre Ziele zu erreichen.

Der Beitrag Scrum – Kontinuierliche Verbesserung und Anpassungsfähigkeit erschien zuerst auf CEOsBay.

Was ist Clean Code?

Clean Code bezieht sich auf den Ansatz, Code so zu schreiben, dass er leicht verständlich, wartbar und erweiterbar ist. Das Konzept wurde von Robert C. Martin, auch bekannt als „Uncle Bob“, in seinem Buch „Clean Code: A Handbook of Agile Software Craftsmanship“ populär gemacht. Im Kern geht es darum, Softwareentwicklung als Handwerk zu betrachten und stets auf hohe Qualität und Präzision in der Codegestaltung zu achten.

Warum ist es wichtig?

Sauberer Code bietet verschiedene Vorteile, sowohl für den Entwickler selbst, für das gesamte Team und meiner Meinung nach auch für die ganze Welt.

• Verständlichkeit: Clean Code ist einfacher zu lesen und zu verstehen. Das hilft Entwicklern, sich schneller mit dem Code vertraut zu machen und Fehler oder Verbesserungsmöglichkeiten schneller zu erkennen.
• Wartbarkeit: Sauberer Code ist leichter zu warten, da er klar strukturiert und weniger anfällig für Fehler oder unerwartete Probleme ist.
• Effizienz: Da Clean Code einfacher zu verstehen ist, kann das Team schneller arbeiten und die Produktivität steigt.
• Zusammenarbeit: Ein sauberer Code erleichtert die Zusammenarbeit im Team, da jeder den Code anderer Entwickler leichter lesen und verstehen kann.

Prinzipien von Clean Code

Es gibt viele Prinzipien und Praktiken, die beim Schreiben von sauberem Code helfen können. Einige der wichtigsten sind:

• Lesbarkeit: Der Code sollte leicht lesbar und verständlich sein. Das bedeutet, dass man Variablen, Funktionen und Klassen sinnvoll benamt und ihre Funktion leicht erkennbar ist. Kommentare setzt man sparsam ein, um den Code nicht zu überfrachten.

• Einfachheit: Man hält den Code so einfach wie möglich, ohne unnötige Komplexität oder Verwirrung. Das bedeutet, dass man sich auf das Wesentliche konzentrieren und abstrakte Konzepte wie Design Patterns oder Funktionen nur verwendet, wenn sie tatsächlich nützlich sind.

• Modularität: Man teilt den Code in kleine unabhängige Module auf, die jeweils eine bestimmte Funktion erfüllen. Dadurch wird der Code leichter zu verstehen und zu warten.

• Wiederverwendbarkeit: Man schreibt den Code so, dass die Wiederverwendbarkeit gewährleistet ist. Dies bedeutet, dass Funktionen oder Klassen, die eine bestimmte Aufgabe erfüllen, generisch genug sind, um in verschiedenen Situationen Verwendung zu finden.

Clean Code in der Praxis

Hier sind einige konkrete Schritte, die man beim Schreiben von Clean Code in der Praxis beachten sollte:

• Variablen-, Funktions- und Klassennamen: Man wählt sinnvolle, beschreibende Namen, die klar machen, was eine Variable, Funktion oder Klasse macht. Die Vermeidung von Abkürzungen oder unverständliche Namen ist eines der obersten Gebote.

• Single Responsibility Principle (SRP): Jede Funktion oder Klasse sollte nur eine einzige Verantwortung haben. Dies bedeutet, dass sie nur einen Aspekt des Problems lösen sollte, um den Code einfacher und leichter zu warten.

• Funktionen und Methoden: Man hält Funktionen und Methoden kurz und konzentrieren sich darauf, dass sie eine einzige Aufgabe erfüllen. Eine Funktion oder Methode sollte in der Regel nicht länger als 20 Zeilen sein, um ihre Verständlichkeit zu gewährleisten.

• KISS (Keep It Simple, Stupid) Prinzip: Man versucht, den Code so einfach wie möglich zu halten und unnötige Komplexität zu vermeiden. Wenn es eine einfachere Lösung gibt, zieht man diese der komplexeren vor.

• Don’t Repeat Yourself (DRY) Prinzip: Man vermeidet doppelten Code, indem man wiederverwendbare Funktionen oder Klassen erstellt. Das verringert die Wahrscheinlichkeit von Fehlern und macht den Code leichter zu warten.

• Code-Kommentare: Man sollte Kommentare dazu verwenden, den Zweck und die Funktionsweise von Code-Teilen zu erläutern, die nicht sofort offensichtlich sind. Man sollte jedoch nicht zu viele Kommentare schreiben, da dies den Code unübersichtlich machen kann.

• Fehlerbehandlung: Die Implementierung einer angemessenen Fehlerbehandlung sollte unabdingbar sein, um unerwartete Probleme zu erkennen und angemessen darauf zu reagieren. Die Verwendung von Exceptions und try-catch-Blöcken, kann eine gute Lösung darstellen, um Fehler abzufangen und entsprechend darauf zu reagieren.

• Testgetriebene Entwicklung (TDD): Man schreibt zuerst Tests, bevor man den eigentlichen Code entwickelt. Auf diese Weise kann man sicherstellen, dass die Implementierung den gewünschten Anforderungen entspricht und weniger fehleranfällig ist. Siehe hierzu meinen Beitrag über Test Driven Development.

• Kontinuierliche Integration (CI) und Continuous Deployment (CD): Man verwendet CI/CD-Tools, um den Code regelmäßig zu testen und automatisch zu deployen. Dies stellt sicher, dass der Code immer auf dem neuesten Stand ist und das man potenzielle Probleme schnell erkennen kann.

Fazit

Im Grunde genommen ist dies für mich eine relativ neue Angelegenheit, da ich in der Vergangenheit schon recht of den Code einfach reingehackt habe, da ich mich unter Zeitdruck gefühlt habe. Ich ertappe mich hin und wieder immer noch dabei und dies sehr oft, wie ich auf alte Gewohnheiten und Muster zurückgreife. Doch dies sollte sich hoffentlich in den nächsten Monaten und Jahren auf ein Minimum reduzieren lassen. Ich bin davon überzeugt, dass Clean Code ein wesentlicher Bestandteil einer erfolgreichen Softwareentwicklung ist. Indem man sich auf Lesbarkeit, Einfachheit, Modularität und Wiederverwendbarkeit konzentriert, kann man den eigenen Code nicht nur leichter verstehen, sondern auch schneller und effizienter arbeiten. Durch die Anwendung der oben genannten Prinzipien und Praktiken kann man den Code verbessern und letztendlich zu erfolgreichen, wartungsfreundlichen Softwareprodukten beitragen.

Der Beitrag Clean Code – Elegante Lösungen für effiziente und wartungsfreundliche Software erschien zuerst auf CEOsBay.

Kurze Zeitreise

Anfang 2001 trafen sich vor der Kulisse der Wasatch Mountains in Snowbird, Utah, 17 Personen, um über die Zukunft der Softwareentwicklung zu diskutieren. Die Mitglieder der Gruppe teilten die Enttäuschung über den aktuellen Stand der Dinge, wenn es um die Softwareentwicklung in agilen Teams ging. Zu diesem Zeitpunkt waren Sie sich einig, dass man etwas ändern muss. Lediglich bestand noch keine Einigkeit darüber, was genau und wie genau es aussehen sollte.

Das Problem, so waren sie sich einig, bestand darin, dass die Unternehmen sich so sehr auf die exzessive Planung und Dokumentation ihrer Softwareentwicklungszyklen konzentrierten, dass sie das Wesentliche aus den Augen verloren – die Zufriedenheit der Kunden.

Die Unternehmen rühmten sich zwar mit Unternehmenswerten wie „Exzellenz“ und „Integrität“, aber diese Werte trugen wenig dazu bei, die Menschen – insbesondere die Softwareentwickler – auf einen besseren Weg zu bringen. Das musste sich ändern. Viele der Snowbird 17 hatten bereits Ideen, wie man die neue Ära der Softwareentwicklung einläuten kann. Die Reise in die Berge war die Chance, dies zu diskutieren.

Aus diesem verlängerten Wochenende ging das Agile Manifest mit gerade einmal 68 Wörtern hervor. Dieses kurze und knappe Dokument sollte die Softwareentwicklung für immer beeinflussen. In den zwei Jahrzehnten, die seit der Entstehung vergangen sind, haben unzähligen Einzelpersonen, Teams und Unternehmen (in unterschiedlichem Maße) diese Worte bzw. die nachfolgenden 4 Kernaussagen und 12 Prinzipien übernommen.

Die 4 Kernaussagen

„Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan„

Folglich

Individuen und Interaktionen stehen über Prozessen und Werkzeugen

Funktionierende Software steht über umfassender Dokumentation

Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung

Eingehen auf Veränderung steht über dem Befolgen eines Plans

Die 12 Prinzipien:

„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.„

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Lieferung von wertvoller Software zufrieden zu stellen.

„Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.„

Anforderungsänderungen sind auch spät in der Entwicklung willkommen. Agile Prozesse machen Veränderungen für den Wettbewerbsvorteil des Kunden nutzbar.

„Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.„

Liefern Sie regelmäßig, alle paar Wochen bis alle paar Monate, funktionierende Software, wobei ein kürzerer Zeitrahmen bevorzugt wird.

„Business people and developers must work together daily throughout the project.„

Geschäftsleute (Fachleute) und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.

„Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.„

Bauen Sie Projekte um motivierte Einzelpersonen herum auf. Geben Sie ihnen das Umfeld und die Unterstützung, die sie brauchen, und vertrauen Sie darauf, dass die Arbeit erledigt wird.

„The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.„

Die effizienteste und effektivste Methode der Vermittlung von Informationen an und innerhalb eines Entwicklungsteams ist ein Gespräch von Angesicht zu Angesicht.

„Working software is the primary measure of progress.„

Funktionierende Software ist der primäre Maßstab für den Fortschritt.

„Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.„

Agile Prozesse fördern die nachhaltige Entwicklung. Sponsoren, Entwickler und Benutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.

„Continuous attention to technical excellence and good design enhances agility.„

Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design erhöht die Agilität.

„Simplicity–the art of maximizing the amount of work not done–is essential.„

Einfachheit – die Kunst, die Menge nicht-getaner Arbeit zu maximieren – ist essenziell.

„The best architectures, requirements, and designs emerge from self-organizing teams.„

Die besten Architekturen, Anforderungen und Designs gehen aus sich selbst organisierenden Teams hervor.

„At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.„

In regelmäßigen Abständen reflektiert das Team darüber, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Und das war’s. Seitdem hat sich die Website des Agilen Manifests, wenn überhaupt, nur minimal verändert. Aber die Welt rund um Agile könnte nicht unterschiedlicher sein.

Die große Debatte

Den Snowbird 17 ist es gelungen, ihre unterschiedlichen Standpunkte unter einigen wenigen Kernpunkten zu vereinen. Doch damit war die Debatte noch nicht beendet. In gewisser Weise hat sich Agile in viel mehr Arbeitsweisen aufgesplittert, als die Visionäre es ursprünglich geplant hatten bzw. erahnen konnten. Es scheint, als ob jeder seine eigene Sichtweise von dem Begriff „Agile“ hat und so auch an der eigenen Suppe kocht.

Heute gibt es SAFe und LeSS. Anwendungen von Agile, die nichts mit Softwareentwicklung zu tun haben, auch wenn es im Manifest zu Beginn heißt: „Wir entdecken bessere Wege, Software zu entwickeln, indem wir es tun und anderen helfen, es zu tun“.

Grundsätzlich kann man sagen, dass Zwei Fragen unmittelbar zusammengehören. Die eine richtet sich auf die Wahl des passenden Frameworks als Tool. Die andere auf die Entwicklung der agilen Kultur im Unternehmen. Beides lässt sich nicht getrennt voneinander betrachten.

Darum sollte man sich gleich zu Beginn die Fragen stellen: Was erwartet man? Was soll am Ende des Tages als Ergebnis stehen? Das Skalierungs-Framework selbst ist letztendlich nur ein methodisches Stützrad, um Organisationen Agilität beizubringen. Aber dazu in einem separaten Beitrag mehr.

Dave West, CEO von Scrum.org, der zu verschiedenen Organisationen reist, um agile Praktiken zu beobachten, nannte in einer Publikation ein Forschungsteam, dass agile Methoden einsetzt, um mit Hilfe von Viren ein Heilmittel für genetische Blindheit zu entwickeln.

In der Tat hat sich agiles Vorgehen außerhalb des Softwarebereichs durchgesetzt. Aber es ist nicht unbedingt das, was die Urheber des Manifests beabsichtigten.

Der agile Industriekomplex

Viele argumentieren, dass „Faux Agile“ und sein böser Zwilling „Dark Agile“, durch die Monetarisierung der agilen Ausbildung und Beratung, die gesamte Situation verschlimmern bzw. verschlimmert haben. Einige gehen sogar so weit, dass sie die Organisationen, die hinter dieser Monetarisierung stehen, als „The Agile Industrial Complex“ bezeichnen.

„Es gibt den agilen Cargo-Kult, bei dem man zwar die richtigen Dinge tut und sagt aber die grundlegenden Prinzipien nicht versteht bzw. schlichtweg nicht einhält. Ich selbst kann dies noch nicht so gut beurteilen, da ich noch nicht so viele agile Teams in Aktion gesehen habe, um eine global repräsentative Aussage zu treffen.

Man kann es nennen, wie man will. Ob „faux“, „dark“ oder „Cargo-Kult“, diese agilen Subversionen führen oft zu Situationen, die den Intentionen des Manifests zuwiderlaufen – Mikromanagement, Burnout-Rate, mangelnde Lieferfähigkeiten und das Festhalten an veralteten Prozessen bzw. Konzepten, statt an Prinzipien, sind die auffälligsten Beispiele. Selbst wenn man in dem Bereich ein Zertifikat erworben hat, führen Erfahrungen wie diese, die man in Zusammenhang mit agilen Methoden hatte, oft dazu, dass manche Menschen agilen Methoden ganz abschwören oder sie so umschreiben, dass sie ihre realen Erfahrungen damit widerspiegeln.

Ron Jeffries, einer der Snowbird 17, hat versucht, diesen Irrwegen mit folgender Einschränkung zu begegnen:

“Here and in other writings, I use the quoted word ‘Agile’ to refer to the many instances, approaches, and processes that use the word ‘agile’ to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to ‘Faux Agile’ for emphasis, or to ‘Dark Agile’, which I use to describe so-called ‘Agile’ approaches that have really gone bad. I might refer to ‘Manifesto Agile’ to mean the core ideas from the Manifesto, in which I still believe.”

„Hier und in anderen Schriften verwende ich das zitierte Wort ‚Agile‘, um mich auf die vielen Instanzen, Ansätze und Prozesse zu beziehen, die das Wort ‚Agile‘ verwenden, um sich selbst zu beschreiben, die aber nicht unbedingt den Buchstaben oder dem Geist der Agilen Softwareentwicklung entsprechen, über die wir im Agilen Manifest geschrieben haben. Ich beziehe mich manchmal auf „Faux Agile“, um dies zu betonen, oder auf „Dark Agile“, womit ich sogenannte „agile“ Ansätze beschreibe, die wirklich schlecht geworden sind. Mit ‚Manifest Agile‘ bezeichne ich die Kernideen des Manifests, an die ich immer noch glaube.“

Jetzt kann man sich natürlich die Frage stellen, ob das Agile Manifest angesichts der weiten und manchmal fehlgeleiteten Verbreitung von Agile immer noch ein Dokument darstellt, auf das man sich beziehen sollte oder ob es nicht schon obsolet ist.

Ist das Manifest noch relevant?

Nun, nachdem ich mich erst seit kurzer Zeit mit dieser Thematik auseinandersetze, mag meine Einschätzung nicht qualifiziert genug sein. Dennoch glaube ich, dass Zeit relativ ist. Und soweit es mir meine Recherchen und unzähligen Gespräche mit Mitstreitern sowie Entwicklerfreunden gestatten, bin ich davon überzeugt, ein recht gutes Bild von der Ist-Situation erhalten zu haben. Die Antwort lautet „Ja!“. Man kann sich meiner Meinung nach immer noch auf das Manifest beziehen!

Fazit

Die zwölf Prinzipien machen deutlich, dass die Anfänge des agilen Projektmanagements von einer Ablehnung traditionellen Projektmanagements mit intensiver Planung, Überwachung und Steuerung geprägt sind.

Das agile Manifest beinhaltet vier Werte und zwölf Prinzipien. Damit ist es keine Checkliste, die man befolgt und abhakt. Vielmehr gilt es, diese Werte und Prinzipien im Team zu etablieren und damit ein agiles Mindset zu entwickeln.

Damit lassen sich meiner Meinung nach komplexe Anwendungen sinnvoll und human, sowohl mit kleinen als auch großen Teams realisieren.

Der Beitrag Agile Manifest – Die bessere Art der Softwareentwicklung erschien zuerst auf CEOsBay.