In der Organisation, für die ich arbeite, haben wir ein RIESIGES Produkt. Es hat etwa 10 zugehörige Scrum-Teams. Wir haben zwei Arten von Releases: 1. Die Großen 2. Service Packs
Für Nr. 1 haben wir die System-QA. Für Nr. 2 haben wir Service Pack QA.
Beides Testsystem, das Bereiche anderer Scrum-Teams umfasst.
Mir ist dieser Ansatz unangenehm, denn wenn jemand etwas findet, ist es entweder um 11 Uhr und wir müssen herumrennen, oder sie finden etwas, aber Scrum-Teams sind sich dessen manchmal nicht bewusst.
Haben Sie eine solche Situation erlebt? Haben Sie einen Ausweg gefunden oder ist dies das gleiche Modell, das auch in Ihrer Organisation verfolgt wird?
Danke im Voraus.
Wir sehen uns dieser Situation heute in unserer AOL-Werbeplattform gegenüber. Wie @MrHinsh vorschlägt, ist das allererste, was zu tun ist, die gesamte QA in die Scrum-Teams zu verschieben. Wir sind gerade dabei, unsere gesamte QA in Entwicklungsrollen zu versetzen, wo sie etwas entwickeln, und alle unsere Entwickler in Richtung Full-Stack-Automatisierung.
Du musst aufhören, Big-Bang-Releases zu machen. Klar kann man Sachen für den Kunden in Big Bangs aufdrehen, es sollte aber schon alles in der Produktion gelaufen sein. Code Rots, sobald Sie mit dem Codieren aufhören, läuft es nicht mehr synchron mit der Produktion und jeder anderen Person, die codiert. Sie müssen also so schnell wie möglich loslassen.
Hier sind die Dinge, die funktionieren und was wir tun, um den Weg der kontinuierlichen Bereitstellung weiter zu gehen.
Wichtige Unterscheidung, um die Sie sich kümmern müssen: Bereitgestellt – Codieren Sie es in die Produktion, unter Flags, damit nur die Entwicklung es sehen kann. Auf diese Weise können Sie den Code mit der Produktion testen, ohne dass der Kunde ihn sieht. Immer wenn eine User Story fertig ist, sollte sie bereitgestellt werden.
Freigegeben - Dies ist, wenn Sie Kunden es sehen lassen. Sie können Ihre Veröffentlichungen auf vierteljährlich beschränken, indem Sie die Dinge unter Flags halten. Oder lassen Sie es einfach einige Kunden sehen, während andere dies nicht tun. Der Code sollte bereits lange vor der Veröffentlichung bereitgestellt und getestet worden sein.
Dass 1 & 2 existieren, zeigt mir, dass Ihre Teams zwar nicht agil sind. Sie sollten funktionierende Software produzieren, ohne dass weitere Arbeiten erforderlich sind, um sie mindestens alle 30 Tage zu versenden.
Sie müssen alle Tests durchgeführt haben, bevor Sie die 11. Stunde erreichen. Dies bedeutet im Allgemeinen, dass Sie Ihre Tester in die Entwicklungsteams integrieren und stark in die Automatisierung investieren müssen.
Jedes Team sollte zu demselben funktionierenden Inkrement der Software beitragen, die mit derselben Kadenz getestet wird.
Wenn Sie keine organisatorische Zustimmung haben, um diese Änderung vorzunehmen, müssen Sie Tests in Ihren eigenen Entwicklungsteams einbauen. Wenn Sie genügend Qualität einbauen, werden Ihre QA-Teams irgendwann zu einer Kostenstelle, die wenig Wert bietet.
Sie sollten Ihre Software viel häufiger veröffentlichen und die ganze Idee von Service Packs aufgeben.
Fokus auf häufiges Arbeiten und integrierte Software.
Das Ziel von Scrum ist es, am Ende jedes Sprints einen veröffentlichbaren Code zu haben. Das bedeutet nun nicht zwangsläufig, dass Sie in jedem Sprint ein Release machen müssen. Nur dass der Code, den Sie haben, möglicherweise freigegeben werden kann . Es könnte sein, dass Ihr Product Owner nicht jeden Sprint veröffentlichen möchte, aber er sollte immer die Wahl haben.
Es kann sich lohnen, über eine Staging-Umgebung nachzudenken, die effektiv produktionsbereiten Code enthält. Alle Produktionsfreigaben würden von dieser Staging-Umgebung aus erfolgen und die Freigabe würde keine zusätzlichen Tests oder Konfigurationen erfordern . Mit anderen Worten, Ihre Staging-Umgebung ist produktionsbereiter Code, der zufällig noch nicht in Produktion ist.
Diese Staging-Umgebung stellt das Ende einer Release-Pipeline dar und enthält den integrierten Release-Code aller Scrum-Teams. Jedes Team testet auf Einheitsebene, auf Funktionsebene und führt vollständige Integrations- und Regressionstests auf dem Hauptcode-Trunk durch. Dies geschieht in jedem einzelnen Sprint.
Es ist normalerweise nicht praktikabel, dies mit manuellen Testmethoden zu tun. Ein besserer Ansatz sind automatisierte Integrations- und Regressionstests, die von allen Teams gepflegt (und über kontinuierliche Integration ausgeführt) werden.
Dies mag wie ein schwieriger Ansatz erscheinen, bietet jedoch den wesentlichen Vorteil, dass Fehler nicht zur elften Stunde entdeckt werden (ein Problem, das Sie in Ihrer Frage erwähnen). Sie könnten auch eine parallele Releasepipeline für Ihre Service Packs ausführen, indem Sie einen separaten Codezweig verwenden.
Ich würde Ihnen wärmstens empfehlen, einen Blick in das Buch „Continuous Deliver“ von Jez Humble und David Farley zu werfen, um eine detaillierte Beschreibung dieser Art von Setup zu erhalten.
jason.t.knight