Wir sind in der Gesundheitsbranche tätig, wo Fehler die Gesundheit der Menschen beeinträchtigen können. Infolgedessen haben wir damit begonnen, den Code in der Staging-Umgebung einzufrieren, damit die QA jeden Build testen kann. Zusätzlich:
Aus diesem Grund wird Code, der bis Donnerstagmorgen nicht fertiggestellt wurde, in dieser Version nicht veröffentlicht. Mit anderen Worten, der gesamte Codeentwicklercode von Donnerstag bis Freitag wird nicht im aktuellen Sprint geliefert.
Aus diesem Grund schlug ich den Stakeholdern vor, den Engineering-Sprint und die Code-Lieferung zu trennen und die erwartete Sprint-Lieferung auf einige Tage nach dem Ende des Sprints festzulegen. Wie erwartet erhielt ich viel Gegenwind von den Stakeholdern, die mir sagten, dass sie noch nie von so etwas gehört hätten und dass ich den Scrum-Prozess unterbreche. Das Problem ist, dass ich ihnen zustimme, aber ich kann mir keinen anderen Weg vorstellen, außer mich in jedem Sprint weniger zu verpflichten und die Entwickler in den letzten Tagen an anderen Dingen arbeiten zu lassen (Support, Tickets für den nächsten Sprint).
Jemand mit einem ähnlichen Setup - wie hast du es gelöst?
Nachdem ich in zwei regulierten Umgebungen gearbeitet habe (Luft- und Raumfahrt und Pharma/Gesundheitswesen), habe ich das Problem gesehen, dass eine unabhängige Qualitätssicherung für eine Leistung erforderlich ist.
Ein paar Dinge zu beachten:
Bauen Sie QA-Zeit in Ihren Sprint ein. Meine aktuelle Organisation führte früher zweiwöchige Sprints durch. Wir begannen an einem Mittwochnachmittag (einige Teams beginnen am Donnerstagmorgen) mit der Sprintplanung und haben die Entwicklung bis zum Freitag der nächsten Woche. Code-Freeze war Freitagnachmittag. QA hat mindestens 2,5 Tage (Montag nach dem Einfrieren des Codes bis Mittwochnachmittag) Zeit, um ausschließlich einen Release Candidate zu testen. Wir haben dies kürzlich geändert, um Sprints mit Sprint-Planung am Mittwochnachmittag oder Donnerstagmorgen (je nach Team) zu beginnen. Für eine bestimmte Version erfolgt das Einfrieren des Codes mit dem Sprint Review am Mittwoch. Wenn es eine geplante Veröffentlichung gibt (wir veröffentlichen nicht nach jedem Sprint), Dies ist als Teil der Sprint-Planung mit der Tatsache geplant, dass QA-Mitarbeiter manuelle Testfälle ausführen oder Ad-hoc-Test- und Automatisierungsteammitglieder automatisierte Abnahme- und Leistungstestfälle überprüfen und dokumentieren. Jede erforderliche Kapazität und Unterstützung durch das Team ist bekannt und geht in die Sprint-Planung ein.
Beziehen Sie die QA in jeden Schritt des Prozesses ein. Wenn Ihr Produktmanagement-Team beginnt, Ideen und Anforderungen (Storys, Backlog-Items) zu entwickeln, binden Sie die QA ein, damit sie Feedback zur Testbarkeit geben kann. Wenn Sie diese Anforderungen verfeinern, ziehen Sie QA hinzu, um sie zu überprüfen. Wenn Sie Akzeptanzkriterien verwenden, lassen Sie sich von der QA helfen, diese zu schreiben, um sicherzustellen, dass sie vollständig sind. Wenn Sie eine Schätzung durchführen, einschließlich des QA-Aufwands in der Schätzung. Wenn Sie Ihre Arbeit planen, beziehen Sie die QA mit ein, um sicherzustellen, dass sie sicher sind, dass die geplante Arbeit innerhalb des Sprints erledigt werden kann (entwickelt, von der Entwicklung angemessen getestet und durch einen geeigneten QA-Prozess geführt werden kann).
Beziehen Sie Entwickler in die Qualität mit ein. In einer Umgebung, in der Entwickler ihre Arbeit nicht testen können, können sie auch nach einem Code-Freeze noch wertvolle Arbeit leisten. Es können Fehler (oder Fragen) auftauchen – die Entwickler müssen mit der QA zusammenarbeiten, um Probleme zu beheben und Bedenken auszuräumen. Andernfalls können sie die automatisierte Testabdeckung verbessern, um Regressionen bei zukünftigen Änderungen zu verhindern, oder Entwicklertools und -infrastruktur verbessern. Wenn die Qualität nicht viel verbessert werden muss, können sich die Entwickler auf die Risikominderung für anstehende Arbeiten konzentrieren, indem sie die Fähigkeiten erlernen und verbessern oder anstehende Funktionen prototypisieren.
Sie müssen Änderungen an Scrum vornehmen, damit es in einer regulierten Umgebung funktioniert, aber ich würde Scrum nicht brechen. Stellen Sie sicher, dass Ihr Inkrement (durch Entwicklung und Qualitätssicherung) am Ende des Sprints fertig ist. Stellen Sie sicher, dass Ihr Entwicklungsteam über alle erforderlichen Fähigkeiten verfügt, um die Arbeit zu leisten, und dass die Einschätzung und der Aufwand aller berücksichtigt werden.
So wie ich es sehe, läuft Ihr Problem auf die Definition von erledigt hinaus . Enthält Ihr DoD die Anforderung, dass Ihr Code die QA bestanden hat?
Wenn dies der Fall ist, wird die Zeit, die Ihre QA für die Überprüfung des neuesten Builds benötigt, am Ende des Sprints automatisch zu einer ungenutzten Zeit für Ihre Entwickler. Das ist nicht unbedingt eine schlechte Sache. Sie können in dieser Zeit Backlog-Verfeinerung, Recherche, Lernen, Refactoring usw. durchführen (wenn keine Fehler auftauchen). Sie können einfach keine neuen Builds veröffentlichen. Sie können immer noch am Freitag mitten im Sprint bereitstellen. Fehler würden einfach behoben, wenn die Entwickler am Montag wieder da sind. Wenn Sie so vorgehen möchten, sollten Sie jedoch die Zeit minimieren, die die QA für ihre Arbeit benötigt. Ihr Feedback-Zyklus sollte so kurz wie möglich sein.
Wenn Ihr DoD die Anforderung für QA-Tests nicht enthält, ist Ihre vorgeschlagene Lösung die richtige: Ihr Team wird neue Builds veröffentlichen, wann immer sie diese haben. Der letzte Build, der in den letzten Tagen des Sprints auftritt, wenn Sie fertig sind. Alle Probleme, die QA findet, werden dann wie neue Backlog-Elemente behandelt. Sie werden wie jede andere Aufgabe entsprechend ihrer Priorität in Sprints aufgenommen. Wenn die QA einen besonders kritischen Fehler findet, kann die PO den Umfang Ihres aktuellen Sprints neu verhandeln, um dieses Problem einzubeziehen (im Allgemeinen auf Kosten von etwas anderem).
Wenn es um die Verwaltung der Release-Kadenz geht, hat ein Unternehmen wirklich nur drei Möglichkeiten, unabhängig von Branche oder Framework:
Während High-Compliance-Umgebungen Agilität nicht rechtfertigen, können die Anforderungen der Compliance-Anforderungen ein Unternehmen manchmal dazu zwingen, sich der Tatsache zu stellen, dass unterschiedliche Prozesse, die sich mit unterschiedlichen Geschwindigkeiten bewegen, nicht im Gleichschritt ausgeführt werden können. Umgebungen mit hoher Compliance neigen auch dazu, dem Trugschluss der 100-prozentigen Auslastung zum Opfer zu fallen, sodass die Vorstellung, dass im Prozess genügend Spielraum vorhanden ist, damit unterschiedliche Prozesse im gleichen Rhythmus bereitgestellt werden können, unrealistisch ist.
Entkopplung, wenn sie durch die richtigen technischen und Prozesskontrollen unterstützt wird, ist normalerweise der Ausweg, der die Gesundheit bewahrt.
Während es im Allgemeinen am besten ist, QA direkt in Ihre Sprints zu integrieren, übersehen viele Unternehmen den Wert der Entkopplung von Lieferung und Bereitstellung von Release . Während Scrum vorschreibt, dass die Ausgabe eines Sprints ein potenziell versandfähiges Inkrement ist, erfordert es nicht wirklich, dass das Inkrement für Endbenutzer freigegeben wird.
In einem regulierten Umfeld sind agile Teams immer noch dafür verantwortlich, Inkremente zu liefern, die der Definition of Done entsprechen. Nachgelagerte Prozesse wie Tests durch Dritte oder Produktionsfreigaben müssen jedoch nicht im Gleichschritt mit dem Entwicklungsteam ablaufen.
Die Hauptprobleme, mit denen Sie wahrscheinlich konfrontiert werden, wenn Sie Lieferungen von Ihren anderen Prozessen entkoppeln, sind: die Notwendigkeit, mit dem Unternehmen über Fehlerbehebungen zu verhandeln, und die Zuweisung der Verantwortung für Releases außerhalb des Scrum-Teams.
Bei kanonischem Scrum müssen Fehler, die außerhalb des Entwicklungszyklus gefunden wurden, erneut in das Product Backlog aufgenommen werden. Die Geschäftsverträge mit dem Scrum-Team, um den Rückstands- und Schätzungsprozess nicht zu umgehen, obwohl vorzeitige Kündigungen (so teuer sie auch sind) sicherlich eine Option bleiben.
Darüber hinaus bedeutet ein wirklich entkoppelter Veröffentlichungsplan, dass QA oder ein anderes Team die Veröffentlichung besitzen wird. Ob das Unternehmen versucht (und wahrscheinlich scheitert), jedes gelieferte Inkrement testen und freigeben zu lassen, oder ob es den Release-Teams vernünftigerweise die Befugnis gibt, Lieferungen zu stapeln und ihre eigene Kadenz für das Taggen und Bereitstellen von Releases festzulegen, ist ausschließlich eine Managemententscheidung.
Es gibt sicherlich Variationen dieser Themen, aber der Kerngedanke ist, dass jeder Sprint seine Integrität gegen ungeplante Arbeit bewahren muss und dass jede Arbeit, die außerhalb des Teams verschoben wird, sich daran halten muss. Solange das stimmt, ist die Entkopplung von Freisetzungen der Ansatz, den ich im Gesundheitswesen und in der Regierung befürworte.
Kann QA nicht in Ihr Scrum-Team integriert werden? Das bedeutet nicht nur, dass Sie eine Person integrieren, die QA durchführt, sondern Sie verbreiten das QA-Wissen in Ihrem Team.
Das Hauptziel beim Aufbau eines Scrum-Teams besteht darin, dass das Team in der Lage ist, ein Produktinkrement selbst zu erstellen (oder noch besser bereitzustellen). Darüber hinaus gibt es im Team keine anderen Rollen als Entwickler. Ihr Team kann also einen QA-Spezialisten haben, aber alle anderen Entwickler sollten in der Lage sein, bei der QA zu unterstützen. Umgekehrt sollte Ihr QA-Spezialist in der Lage sein, die Entwicklung zu unterstützen. Vielleicht müssen Sie dafür den Wissenstransfer managen.
Auf diese Weise könnten Sie QS-Aufgaben vollständig in Ihre Sprintplanung integrieren. Jeder in Ihrem Team könnte jede Art von Aufgabe, Entwicklung und Qualitätssicherung übernehmen oder zumindest unterstützen. Sie können jederzeit im Sprint QA für fertige Features durchführen. Sie können jederzeit im Sprint auf QAs-Feedback zur Entwicklung reagieren.
Vielleicht ist es auch sinnvoll zu definieren, was Sie unter QA verstehen. Ist es wirklich Qualitätssicherung oder eher ein Benutzer-/Stakeholder-Akzeptanztest?
Further there are no other roles in the team than developer. So your team can have a QA specialist, but all other developers should be able to support in QA.In regulierten Umgebungen wie dem Gesundheitswesen ist dies schwierig. Das formelle Testen eines Liefergegenstands muss von jemandem durchgeführt werden, der nicht am Design und der Entwicklung des Features beteiligt war. Für die Compliance ist es wichtig, dass eine unabhängige QA die Qualität von Anforderungen und/oder Akzeptanzkriterien bewertet, Testfälle anhand dieser Anforderungen und Akzeptanzkriterien schreibt, automatisierte Akzeptanztests implementiert und manuelle Testfälle durchführt.
Balala
Kuf