Wie kann man die Bereitstellungsfrequenz erhöhen, wenn man viele Prozesse bewältigen muss?

Ich arbeite als Product Owner in einem Fintech-basierten Softwareunternehmen. Mein Entwicklungsteam folgt der Scrum-Methodik und einem 2-Wochen-Sprint. Sie versuchten, der Scrum-Zeremonie zu folgen, aber keine Story-Schätzung vorzunehmen.

Mein Stakeholder hat jeden Monat 1 Produktions-Release festgelegt (z. B. am 25. eines jeden Monats) und einige Zeit zusätzliche Hotfix-Releases. Unser Veröffentlichungszyklus ist sehr komplex. Testen Sie zuerst die Funktion in der SIT-Umgebung. Nachdem Sie die Abmeldung von SIT qa erhalten haben, erstellt das Entwicklerteam das Paket und sendet es zur UAT-Bereitstellung an devips. Nach der UAT-Bereitstellung testen die UAT-Tester die Build-Elemente (eine Sache zu erwähnen, die UAT-Bereitstellung erfolgt nur zum Zeitpunkt der Produktveröffentlichung, nicht nach jedem lieferbaren Sprint). Wenn der UAT-Tester ein Problem gefunden hat, wird es an das Entwicklerteam zurückgegeben, aber sie befinden sich mitten im Sprint und erledigen andere Arbeiten. Dann behebt das Entwicklerteam die vom UAT-Tester aufgeworfenen Probleme und sendet es ihnen erneut. Endlich von UAT abgemeldet geht es in die Produktion.

Jetzt meine Frage, wie kann ich den Prozess rationalisieren? , da das Entwicklungsteam frustriert war, dass es manchmal mitten im Sprint an der Fehlerbehebung oder Priorität arbeiten musste. Ich benötige eine Richtlinie/Expertenmeinung, um die Produktionsfreigabe nach dem Sprint richtig zu verwalten.

Denn wir sprechen von Fintech: Was ist eigentlich das Risiko, wenn die Software einen schwerwiegenden Fehler hat? Millionen? Milliarden? Dann sollten Sie überlegen, ob eine Methodik für sicherheitskritische Software einem agilen Vorgehen vorzuziehen ist.
Ja, das stimmt, aber Agile ist am beliebtesten und mein Management weiß es gut. Und ich glaube, mein Problem ist weit verbreitet und viele erleben dies.
Aus wie vielen Personen besteht das gesamte Entwicklungs- + QA- + Infrastrukturteam?
@lalala: Wir verwenden tatsächlich einen agilen Prozess, um sicherheitskritische Software (von der Art, die offiziell zertifiziert werden muss) zu erstellen, sodass sich die beiden nicht gegenseitig ausschließen.
@BartvanIngenSchenau schließt sich natürlich nicht aus. Was ist Ihr Release-Zyklus aber?
@lalala, wir arbeiten immer noch daran, in jeder Iteration potenziell veröffentlichbare Software zu haben, aber tatsächliche Versionen werden ungefähr alle 2 Monate an unsere (nicht agilen; unternehmensinternen) Kunden geliefert. Nicht alle dieser Versionen enthalten Aktualisierungen der sicherheitskritischen Teile, und nur wenige von ihnen müssen für den Einsatz im Feld zertifiziert werden.

Antworten (2)

Ich zweite ctrl-atl-delor (+1!) - Sie sollten in die Automatisierung investieren.

Die agile Methodik hilft bei der Arbeitsorganisation, aber unabhängig von der Methodik sollten Sie Ihre Arbeit so weit wie möglich automatisieren.

Wir haben ein ähnliches Szenario in unserem Projekt – und ich vermute, dass es bei Legacy-Anwendungen ziemlich häufig vorkommt.

Sie haben zwei Hauptarbeitsbereiche:

Basierend auf Ihrem Szenario müssen Sie bewerten, in welchen Bereichen innerhalb von SDLC oder Testautomatisierung Sie schneller Vorteile erzielen können (die niedrig hängenden Früchte).

Sie benötigen Unterstützung von entweder C-Level und / oder Stakeholdern, da Sie auf jeden Fall Zeit und Mühe investieren müssen.

Ja, ich stimme dir zu. Automatisierung und testgetriebene Entwicklung könnten die meisten meiner Probleme lösen. Aber sein Weg zu gehen. Ich brauche eine Abstimmung mit meinem Management
Wenn Ihr Szenario meinem ähnlich ist, besteht einer der wichtigsten Punkte darin, die an UAT zu liefernden Artikel zu definieren, sie zu identifizieren und sicherzustellen, dass sie getestet werden. Dies kann mit einem (leichteren) Prozess erreicht werden.

Gut gemacht, Sie machen einen tollen Job. Scrum hat Sie dazu gebracht, mehrere Probleme mit Ihrem Prozess zu diagnostizieren.

Ich würde empfehlen, Devops, Developers und Ops zusammenzuführen. Sie werden dann vollständig zum Testen bereitgestellt (das ist dasselbe wie betriebsbereit). Nach dem Testen drücken Sie eine Taste, um es einsatzbereit zu machen. Dockerist ein gutes Werkzeug, um dabei zu helfen.

Die andere (und wichtigste) Sache ist, eine Retrospektive durchzuführen, wann immer Sie ein Problem entdecken (Feedback vom Test: Warum ist das passiert? Unvollständige/geheime Spezifikation?, Unvollständige Entwicklertests?)

In einer Retrospektive Fragen stellen, ohne Schuld. Wenn Sie fragen, verwenden Sie 5-warum. Fragen Sie warum, dann fragen Sie warum (5 Mal). ZB Warum ist es kaputt gegangen? Es ist kaputt gegangen, weil wir den Esel überladen haben. Warum haben wir den Esel überladen? Weil wir nicht wussten, wie viel Last wir ihm auferlegten. Warum? weil die Waage fehlte. Warum? weil sie per Rechnung ausgeliehen wurden. Warum? Denn Bill hat keine eigene Waage. Warum? wegen Budgeteinsparungen. Warum? Weil …

Ich glaube, Sie haben die wichtigste Frage aus dem Feedback verpasst – wie stellen wir sicher, dass so etwas nie wieder passiert? Zu wissen, wie es passiert ist, hilft nicht, wenn Sie nichts unternehmen, um zu verhindern, dass es wieder passiert.
@UKMonkey Ich habe ein bisschen Retrospektiven hinzugefügt.
@ctrl-alt-delor Danke
Wie kann man die Bereitstellungsfrequenz erhöhen, wenn man viele Prozesse bewältigen muss?
AntwortenHierDatenschutz-Bestimmungen1y, 0v