Definition of Done Folie 2

Transkript

1 Wann wind wir wirklich fertig-fertig? Johannes Bergsmann Berater, Trainer Inhalt DoD Definition / Einführung Arten von DoD s Wo werden sie benötigt? DoD in verschiedenen Phasen / Ebenen DoD Tipps DoD Fallen Zusammenfassung Folie 2 Seite 1

2 Fragen in Entwicklungsprojekten Ist ein Feature / User-Story hinreichend spezifiziert? Ist die Architektur zukunftssicher, wartbar, etc.? Wann ist der Programmierer fertig mit dem Codieren? Ist es egal, wie ein Review abläuft, welche Kriterien geprüft werden? Wie genau soll der Tester testen? Was ist alles zu beachten, wenn wir die Software auslieferen wollen? Etc. Folie 3 Brainstorming Notieren Sie für sich auf einem leeren Blatt: Ihre Begriffsdefinition zu (DoD) in 1-2 Sätzen. Eine typische, die bei Ihnen verwendet wird. Wenn Sie noch keine DoD verwenden: Überlegen Sie, wie Sie eine DoD formulieren würden. Zeit: 2-3 Minuten Folie 4 Seite 2

3 Definiton of Done - Einführung Folie 5 Was ist? The heart of Scrum is a Sprint, a time-box of one month or less during which a Done, useable, and potentially releasable product Increment is created. When the Product Backlog item or an Increment is described as Done, everyone must understand what Done means. Members must have a shared understanding of what it means for work to be complete, to ensure transparency. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team s current Definition of Done. The Scrum Guide, Sutherland,Schwaber, October 2011 Folie 6 Seite 3

4 Glossar (DoD) The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful. Exit criteria are the criteria or requirements which must be met to complete a specific process. [ sehr offene Definition, keine Hinweise auf konkrete Kriterien sind dort sinnvoll, wo es gilt, den Abschluss eines Prozess(schritts) oder die Fertigstellung eines Produkt(teils) klar festzustellen. Folie 7 Anwendungsbereiche Der Begriff DoD wurde im agilen Umfeld geprägt. Es sind Checklisten, um die Zielerreichung zu prüfen. DoD sind jedoch nicht auf agile Prozesse beschränkt! JEDER beliebige Prozess dient einem bestimmten Zweck und schafft im Normalfall ein Ergebnis/Produkt Definitions of Done sind daher generell Checklisten für Prozess-Einhaltung Produkt-Eigenschaften Hinweis: In anderen Prozessmodellen heißen Sie ggf. anders (z:b. Meilenstein-Checkliste, Quality-Gate, etc.) Folie 8 Seite 4

5 Arten von Definiton of Done Folie 9 Viele Themen, die relevant sind! soll verschiedene Aspekte abdecken! Folie 10 Seite 5

6 DoD Ebenen in Scrum for a feature (story or product backlog item) for a sprint (collection of features developed within a sprint) for a release (potentially shippable state) Produkt-Backlog Sprint Planning Sprint-Backlog Daily Scrum Sprint (< 30 Tage) Releasetaugliches Produkt (Pair-) Programming Folie 11 Weitere DoD Bereiche Je nach Umfeld, Anwendungsbereich oder Zielgruppe können weitere DoD-Ebenen oder zusätzliche Granularität sinnvoll sein: Codierung Wann kann ein Programmierer sagen, dass er mit dem Code fertig ist? Unit-Test-Abdeckung, Code-Dokumentation, Code-Review, etc. Design / Architektur Checkliste für Systemdesign, Architekturkriterien, Testbarkeit, Wartbarkeit, etc. Testdurchführung Anforderungen an die Tests Testende-Kriterien. Wann hört man auf zu testen? Roll-Out Checkliste für Verteilung, Inbetriebnahme, etc. Folie 12 Seite 6

7 DoD Eigenschaften Nur Aktivitäten / Prüfkriterien in die Checkliste aufnehmen, die SMART sind: Specific / Spezifisch eindeutig definiert (nicht vage, so präzise wie möglich) Measurable / Messbar Kriterien müssen messbar / testbar sein Accepted / Erreichbar müssen von den Betroffenen akzeptiert werden/sein (angemessen) Realistic / Realistisch Einhaltung / Erreichung muss möglich sein. Timely / Terminierbar Es muss klar sein, bis wann bzw. in welchem Schritt das Kriterium erreicht sein muss. Folie 13 Definiton of Done Tipps Folie 15 Seite 7

8 Done Schablone Definieren Sie sich eine Schablone, nach der DoDs formuliert werden z.b.: DoD-Bezeichnung: Ebene / Bereich: Testende-Kriterien für den Sprint Jeder Sprint Produkt/Projekt: Alle Projekte/Produkte mit Risikoklasse 1 Verantwortlich für DoD-Definition: Stakeholder: Entwicklungsleiter Tester, Entwickler, Product-Owner Kriterien: - Entwickler hat alle Unit-Tests entsprechend der DoD Unit- Test Kritierien erstellt und durchgeführt - Integrations- und Systemtests gemäß DoD Integrations- & Systemtest-Kritierien durchgeführt - Alle Tests der Kritikalität 1 automatisiert <weitere Kriterien wurden aus Platzgründen nicht angeführt> Anmerkungen: Keine Folie 16 Done Thinking Grid Schaffen Sie eine Plattform (Board) auf der Ideen zu sinnvollen Done-Kriterien gesammelt werden Geben Sie zur Strukturierung ev. schon sinnvolle Themenbereiche / Ebenen vor (z.b. als Swimlanes ) Requirements / Tasks Architecture / Design Coding Testing Sprint Release Roll-Out Folie 17 Seite 8

9 Integration in den Prozess DoDs sollten nicht allgemein in einer eigenen (abgelegten) Definition beschrieben sein DoDs sollten in den Prozess so integriert sein, dass die jedenfalls eingehalten werden müssen, z.b.: 4-Augen-Prinzip in verschiedenen Prozess-Phasen Pair-Programming (1 programmiert, der andere prüft die Kriterien) Prozess-Verantwortlicher, der übergreifende DoD Einhaltung prüft Quality-Manager für das Projekt, der DoD Einhaltung prüft DoD-Checklisten in die Tools einbauen Workflow-Tool verwenden und DoDs im Prozess integrieren Prüfung und (Selbst-)Kontrolle ist wichtig! Der Mensch tendiert dazu, den einfachsten Weg zu gehen! Folie 18 Die passenden DoDs schreiben Die unklare Begriss-Definition für DoDs könnte dazu verleiten, auch die Abnahmekriterien als DoD zu beschreiben. Für eine einfache und klare Durchführung sollte dies jedoch getrennt betrachtet werden: DoDs sind Qualitätskriterien an die Prozessdurchführung und allgemeine Qualitätskriterien für die Produkterstellung DoDs sollten nicht die Testfall-Beschreibung oder Abnahmekriterien ersetzen Tests jeglicher Art sollten in einer eigenen Spezifikation definiert werden Folie 19 Seite 9

10 Wer soll DoDs wann definieren? Alle relevanten Stakeholder in die Definition einbeziehen: Produkt-Owner / Auftraggeber Entwickler Tester Architekten etc. Vor Projektbeginn/Entwicklungsstart definieren und im Laufe der Entwicklung / Projekt verfeinern / anpassen! Folie 20 Definiton of Done Fallen Folie 21 Seite 10

11 Zu wenige DoDs Wenn Prozesse neu eingeführt oder umgestellt werden, wird meist zu wenig definiert. Erst im Laufe der Zeit kommen fehlende Punkte auf (ev. auch erst nachdem die Software schon lange in Betrieb ist) Um Lernzeit und Fehlschläge zu sparen, sollten die DoDs schon von Beginn an sorgfältig überlegt und definiert werden. Einige Hinweise dazu: 1 einzelne DoD für ein Feature/Story ist in 99,9% aller Fälle zu wenig! Jedes Feature durchläuft verschiedene Phasen / Ebenen. Es sollte eine DoD-Checkliste für jede dieser Phasen / Ebenen geben. Think twice Nach dem ersten DoD-Wurf selbst nochmal drüber nachdenken und noch jemand anderen drüber schauen lassen, um die Kriterien zu reviewen. Folie 22 Unklare DoD s In der Literatur und im Web werden oft (zu) einfache Beispiele für DoD s genannt. Z.B. 1. Code complete 2. Unit tests written and executed 3. Integration tested 4. Performance tested 5. Documented (just enough) Was heißt complete? Was ist hier zu testen? Genügt schon 1 Testfall? Genügt es wirklich, irgendwelche Unit-Tests ausgeführt zu haben? Was müssen die Unit- Tests abdecken? Diese führen in der Praxis zu Problemen: Unterschiedliche Entwickler und Kunden interpretieren dies unterschiedlich! Man meint, man ist fertig tatsächlich sind aber noch viele Fragen offen! Diskussionen, Streitereien, zusätzliche Aufwände/Iterationen, etc. sind absehbar! Folie 23 Seite 11

12 Ungeeignete Kriterien Bei DoD ist es per Definition unklar, welche Kriterien enthalten sein sollen. Dies könnte dazu verleiten, eine universelle Themenbreite für die Kriterien zuzulassen: Management könnte z.b. Zeit- & Kosten-Kriterien hineinreklamieren Das Feature muss in 5 Tagen programmiert sein. Das Release darf max. EUR ,- kosten. Product-Owner könnte z.b. funktionale Kriterien hineinreklamieren Das Feature A muss in folgender Form. realisiert sein. Diese Kriterien sollten nicht in die DoD, sondern sollten in Planungs- oder Spezifikations-Dokumenten definiert werden. DoD soll ausschließlich qualitative Kriterien enthalten! Folie 24 An example of DoD has the following activities: All Acceptance Criteria of the User Story are met Code meets general Coding Standard (e.g. as defined in Checkstyle) Functional tests are performed by team members other than those working on the implementation of that feature Code is either reviewed or produced with a pair-programming method The code is covered by a minimum of 70% Unit Tests and all tests are Green Automated acceptance tests (Selenium) are prepared for the feature and are Green Integration tests of the affected areas are conducted and passed As any other set of rules, there is also a basic meaning behind all of the activities defined in this Definition of done. The meaning is that the feature implemented meets all the requirements of the User Story, that the coding has been performed in compliance with the shared and agreed coding standards. That someone else, rather than the person who implemented the feature has performed a functional test on it. That the code has been reviewed, or by using pair-programming ensured the code has been double-checked, not to allow bad syntax, magic numbers, as well as to make sure the architecture style is in line with the rest of the system. The Unit tests and Selenium tests have been prepared to reduce the human involvement in the testing phase, and to aim for a complete automation of testing. Also it is made sure that for every feature developed, an integration tests has also been carried out, to make sure it fit the system well. All of these activities are aimed to one big target which is improving the quality of the system. Since in SCRUM the team itself is responsible for quality, not a separate quality assurance team, it is essential for the team to invest time and activities on ensuring the quality of the product. SWQL-Präsentation Folie 30 Seite 12

13 Sprint The sprint is an iteration of software development with an aim to deliver a shippable product in the end. The Sprint DoD is to help this target to be achieved: for example by making sure that: All the User Story included in the Sprint are closed and meet the US DoD The agreed development freeze day has been met All Unit Tests, Automated Acceptance tests have passed successfully Regression testing has been performed on the product after the changes and No Critical or Blocker bug exists in the bug backlog This is an example of a Sprint. I am sure many of the activities sound familiar. Again this is tailored by the team on their team processes and practices, but usually and simply it needs to be started with even a couple of agreements, later it will evolve into what the team will come to understand an indispensible part of their daily work. SWQL-Präsentation Folie 31 Other DoD-s? The last of the Scrum Alliance recommended DoD-s is the Release. The release DoD is straightforward to think about and would most likely include activities like making sure the product is tested, making sure the configuration changes are ready that a backup has been made a tag created for a release the possibility of rollback with related risks have been provided etc.. From my experience working with DoD-s there is one particular place where DoD may also make sense to be introduced. It is when a defect/bug is fixed. I would call it a Bug. It would include the following: the defect is fixed if missing, Unit Tests are implemented that covers the fix s code functionality a functional test to cover the bug is performed by a person other than the person who fixed the bug SWQL-Präsentation Folie 32 an automated test is created that checks the flow The reason I see this beneficial is that if with every bug fix missing unit tests are written, as well as the automated script is generated the coverage of both code and functionality will significantly increase, meaning better product robustness and increased quality. It is also very important to post the team s definition of done on a visible place, where everyone is reminded of it every time Seite 13

14 Definitons of Done Tipps & Tricks Folie 33 Definitions of Done DoD Tipps & Hinweise möglichst wenig Interpretationsspielraum lassen! sowohl für Prozess-Abwicklung als auch für Produkt-Qualität definieren. Unterschiedliche Ebenen / Phasen / Bereiche beachten und DoD entsprechend dafür anpassen / definieren DoD soll keine Testfälle enthalten / ist keine Testspezifikation soll umfassend mit allen Betroffenen (Stakeholdern) geklärt und mit diesen diskutiert und finalisiert werden. soll leben bei Unklarheiten sofort klären und DoD anpassen / ergänzen. nach jeder Release / Sprint / Projekt / etc. DoD reviewen und ggf. anpassen. Folie 34 Seite 14

15 Die Welt der Software-Qualität Zusammenfassung (DoD) ist eine Checkliste für durchzuführende Prozess-Aktivitäten zu erreichende (Qualitäts-)Kriterien Themen sind komplex und miteinander vernetzt. Nicht nur 1 DoD erstellen, sondern viele: Für Prozess-Ebenen, Produkt-Entwicklungs-Phasen, etc. Nicht nur auf 1 Thema konzentrieren, sondern das Prozess-System als Ganzes betrachten. Prozess- und Quality-Manager dafür ist hilfreich. Prozesse und Umfeld ändern sich laufend ständig dran bleiben und anpassen! (KVP) Folie 37 Ihr Partner für Software Qualität und Testen Büro Linz A-4041 Linz, Gewerbepark Urfahr 30 Büro Graz A-8053 Graz, Wiener Straße 253 Büro Wien A-1150 Wien, Mariahilfer Straße 136 Büro Lustenau A-6890 Lustenau, Millennium Park 9 Büro München D München, Agnes-Pockels-Bogen 1 [W] Seite 15

16 Johannes Bergsmann Geschäftsführender Gesellschafter CV Diplom Ingenieur Informatik Mehr als 25 Jahre Erfahrung in über 140 Projekten im Bereich der Software-Entwicklung, Projektmanagement und Beratung Seit 2003 Eigentümer und Geschäftsführer der Thematische Schwerpunkte Sonstige Informationen Kontakt Software Entwicklungsprozess, Vorgehensmodelle, Prozessmodelle Requirements-Engineering und Usability Testmanagement Projektmanagement & Controlling, Risikomanagement Standards, Normen und Zertifizierungen IT-Strategie und Unternehmensentwicklung Ausschreibungen und vertragliche Fragen in Software-Projekten Gerichtlich beeideter Sachverständiger für Informatik Staatlich geprüfter und beeideter Ziviltechniker für Informatik Vizepräsident der Österreichischen Vereinigung für Software Qualitätsmanagement Vizepräsident des Austrian Testing Boards (ATB) [E] [T] [M] Folie 39 Seite 16