Der erste Tag der agilen Testtage in Berlin ist vorüber. Vor Wochen hatte ich die Konferenz noch als kleindeutsch abgeschrieben. Nachdem ich auf der Agile 2009 in Chicago aber von vielen gehört hatte, dass sie hier sein würden, hatte ich schon die Vermutung, dass sie größer und internationaler wird, als ich zuerst annahm. Diese Vermutungen haben sich heute bestätigt. Es haben sich viele interessante Gespräche und Kontakte ergeben. Zu der angenehmen Atmosphäre trägt mit Sicherheit auch das gut ausgestattete und architektonisch interessant gebaute Konferenzhotel bei.
Kleiner Wehrmutstropfen am Abend: die ganzen Sprecher haben sich zum „Speaker Dinner“ verabschiedet. Die normalen Leute bleiben also unter sich, und Thomas und ich werden gleich mal sehen, wo wir noch andere Agile Tester zum Abendessen auftreiben.
[nggallery id=13]
Designing a Lean Software Development Process, von Mary und Tom Poppendieck
Besucht und geschrieben von: Andreas
Laut dem Abstract des Tutorials sollten Möglichkeiten aufgezeigt werden, die (stagnierenden) Produktivitätssteigerungen, die sich allein durch agile Softwareentwicklung ergeben, zu analysieren und Möglichkeiten zur Verbesserung aufzuzeigen.
Zur Analyse des bestehenden Prozesses bietet sich die Visualisierung des „Value Streams“ von einem Ende (dem unglücklichen Kunden, dem ein Feature fehlt) zum anderen Ende (dem nun zufriedenen Kunden) an. Der Value Stream umfasst alle dazwischen liegenden Aktivitäten: z.B. Marketing, Product Management, Budgetierung, Recruiting, Project Staffing, Design, Entwicklung, Test, System Test, Auslieferung, Installation. Danach kann betrachtet werden, wie viel der Kalenderzeit tatsächlich wertschöpfend ist, und wie groß der „waste“ ist:
Process Cycle Efficiency = Value Added Time / Total Cycle Time
Das problematische an dem Maß: je tiefer man gräbt, desto niedriger wird der Wert, da man immer mehr Zeitanteile findet, die „waste“ sind, also eigentlich überflüssig. Trotzdem kann man damit ganz gut identifizieren, auf welchen Bereich man die Optimierungsversuche konzentrieren sollte.
Der unglückliche Kunde, die neuen Anforderungen an das Produkt, können unterschiedlich motiviert sein: Der „Value Demand“ ist Nachfrage nach Mehrwert, neuen Funktionen. Hier kann man die Kundenerwartungen übertreffen und den Kunden überraschen und zufriedenstellen. Der „Failure Demand“ wird durch die selbst gemachten Fehler verursacht. Hier kann also überlegt werden, durch welche Maßnahmen der Aufwand, der in den „Failure Demand“ gesteckt wird eliminiert werden kann (z.B. kein 1st/2nd level support, Kunden sprechen direkt mit den Entwicklern, diese bekommen dann direkt das Kundenfeedback und lernen daraus), um den Durchsatz für den „Value Demand“ erhöhen zu können.
„Support calls are caused by a difference in mental models of developers and customers“
Eine Strategie, die nicht funktioniert, um den Durchsatz zu erhöhen ist einfach Ziele zu definieren: Maximale Bearbeitungszeit für Kundenanfragen darf 20 Tage betragen. Es muß schon das darunterliegende System geändert werden, ansonsten wird sich keine Änderung im Durchsatz einstellen.
Was passiert mit Anforderungen, die in absehbarer Zeit nicht umgesetzt werden können? Man soll akzeptieren, dass es nicht nur eine „Now“ und eine „Next Release“ Queue, sondern auch eine „Never“ Queue an Features gibt. Kunden würden zwar ein „Nein“ zu einem Feature Request ungern hören, um so mehr freuen sie sich aber um ein zuverlässiges „Ja, in den nächsten 4 Wochen“.
Eine der wichtigsten Fragestellungen bei der Produkt-/Softwareentwicklung ist: Wann ist es fertig? Hier sollte, zumindest nicht nach den Aussagen aus diesem Tutorial, zu einem Plan (Schedule) gegriffen werden, sondern ein zuverlässiger Workflow erschaffen werden. Ein Plan hat die Eigenschaft alle zu 100% zu verplanen, was selten eintreffen wird. Außerdem versucht ein Plan alle Abhängigkeiten des komplexen Systems zu berücksichtigen, während sich ein Workflow einfacher kontrollieren lässt. Die „Lessons Learnt“ aus dem Bau des Empire State Buildings (ca. 1 Jahr!) waren:
- Entwerfe das System, um den Rahmenbedingungen (Constraints) zu entsprechen; Leite nicht die Rahmenbedingungen vom Entwurf ab
- Entkopple Workflows; breche Abhängigkeiten
- Workflows sind einfacher zu kontrollieren und besser vorhersagbar als Pläne
Es ist bestimmt eine Frage der Übung, aber ich kann mir Umsetzung von entkoppelten Workflows in der Softwareentwicklung momentan noch schwer vorstellen – deshalb wird in Scrum ja auch alles nötige innerhalb eines Sprints gemacht, in einer Reihenfolge wie es gerade für die Aufgabe am geeignetsten ist. A propos Scrum, ein interessantes Zitat: Scrum sei entworfen worden, um die Knappheit der Entwicklerressourcen zu adressieren, diese also am besten auszunutzen.
Zurückblickend denke ich, dass die Geschichten und Beispiele (Der Bau des Empire State Buildings und Southwest Airlines Ignoranz des Loadfaktors) unterhaltsam und inspirierend waren, aber ich glaube ich hätte Beispiele aus dem Bereich der Softwareentwicklung besser gefunden, nur um zu sehen, dass die ganzen Prinzipien auch hier bestand haben.
Acceptance Test Driven Development (ATDD) in Practice, von Elisabeth Hendrickson
Besucht und geschrieben von: Thomas
Was nehme ich mit aus dem Tutorial „Acceptance Test Driven Development (ATDD) in Practice“ von Elisabeth Hendrickson? Zunächst einmal knapp 10 vollgeschrieben Din A4 Seiten mit Notizen, die als sicheres Indiz gelten dürfen, dass es eine interessante und spannende Veranstaltung war. Neben einer Menge Papier hat es aber auch viele konkrete Anregungen gegeben, wie man ATDD in eigenen Projekten umsetzen kann. Auf der anderen Seite war es aber sicherlich ebenso interessant die vielen Erfahrungen anderer Konferenzteilnehmer zu diesem Thema zu hören. Dabei kann man schon recht klar sagen, dass die Probleme hier momentan noch überwiegen. Es sind dabei jedoch weniger technische Probleme oder fehlende Tools, sondern vielmehr organisatorische Probleme, die auch bei der Einführung anderer agiler Techniken immer wieder auftreten.
Die Tools und Prozesse hinter ATDD lassen sich jedoch in einer bereits agilen Organisation denke ich sehr gut verwirklichen und bieten auch die Chance auf einen echten Mehrwert. Dabei machen auch die Tools immer weitere Fortschritte und es hat mich natürlich gefreut ein neues Feature des Robot Frameworks in Aktion zu sehen, welches es erlaubt Anforderungen zu einem guten Teil Umgangssprachlich zu formulieren. Damit können die Tests als „Ausführbare Spezifikationen“ implementiert werden und bilden ein gemeinsames Fundament für den Product Owner (= Kunde) und das Entwicklungsteam.
Im Folgenden habe ich einfach mal ein paar Quotes aus dem Tutorial gesammelt.
- The Technical Team is „The tribe of the how“ while the Product Owner is „The Voice of the What“. See also Agile Anarchy
- A bug is a valid expectation of the Product Owner that is violated.
- How do we test automated tests? Explorative Testing
- Lean does not mean: Be stupid!
- Gold plating is a big risk in Software Development, as it creates things no one actually wanted.
- Agile is the most diciplined software developing approach.
Es ist auch noch einmal klar geworden, dass ein erfolgreiches Entwicklungsteam (z.B. ein Scrum-Team) alle nötigen Skills im Team vereint. Es darf kein Silo-Denken geben, mit wohlmöglich eigenen Teams für Tester der Architekten. Dies geht in diesselbe Richtung, die Boris Gloger bei unserem letzten Meet the Experts angesprochen hat, dass in einem Team idealerweise jedes Team-Mitglied 90% der anfallenden Aufgaben bearbeiten kann. Während der gesamten Diskussion ist auch immer wieder klar geworden, dass es schwierig ist mit ATDD zu starten, wenn man nicht bereits ein „agiles Fundament“ hat. Elisabeth hat auch betont, dass sich Testautomatisierung und Agile nicht trennen lassen, sondern dass diese nur gemeinsam erfolgversprechend sind. Ein gutes „Schlusswort“ für die Zusammenfassung des Tutorials wie ich finde.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Andreas Ebbert-Karroum
18.11.2020 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Andreas Ebbert-Karroum
Agile Principal Consultant
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.