Sprints, agile Softwareentwicklung und Zwischenlieferungen

[Sithys]

Moin zusammen,
mich würde mal interessieren wie hier Programmierer aus agilen Teams in Projektarbeiten mit dem Thema Zwischenlieferung umgehen. Unser Sprint läuft 3 + 1 Woche, also 3 Wochen Entwicklung und 1 Woche Qualitätssicherung in welcher die Entwicklung "ruht".

In einem Projekt kann es jetzt vorkommen, dass der Kunde möglichst zeitnah Zwischenlieferungen haben möchte. Wie bildet ihr das ab? Wir tun uns extrem schwer damit. Wir haben noch einen zweiten Partner in dem Projekt, der die Zwischenlieferungen abnimmt, bevor diese zum Kunden gehen. Stellt der Partner jetzt einen Fehler fest, werden Features nicht zur Abnahme bereitgestellt und der Kunde muss wieder 4 Wochen warten.

Vielleicht könnt ihr dazu ja einfach mal Eure Erfahrungen posten.

 

[evilnear]

ein fester sprintzyklus klingt ja schonmal gar nicht so agil.
bei uns sind wir da recht flexibel und ein kleinerer bugfix kann auch so mal eben eingebaut, kurz getestet und dem kunden geschickt werden.

 

[LencoX2]

Es wird unterschieden zwischen regelmäßigen Releases also den Sprints sowie Bugfix Releases.
Ein Bugfix Release wird immer auf der Prod Version gebaut und dann natürlich auch in die aktuelle Entwicklung übernommen.
Im Normalfall ist auf Prod letzte Release Sprintversion.

 

[Burfi]

ein fester sprintzyklus klingt ja schonmal gar nicht so agil.

Nach Scrum sollte der Zyklus auch fix sein. Das heisst ja nicht, dass man sich dadurch an Releases bindet - nur das es am Ende vom Sprint ein Inkrement geben muss, dass released werden kann.

@RedGunPanda:
Euer Problem dürfte schon bei der Trennung von Entwicklung und Qualitätssicherung anfangen. Die Qualitätssicherung ist ein Teil jeder Story. Sie kann also gar nicht done sein, bevor nicht auch die Qualität gesichert ist.
Im Normalfall enthält die Definition of Done (DoD):

• Entwicklung
• Testing
• Review
• Deployment

Spezifisch zu eurem Problem solltet ihr euch beim Planning Zeit für wiederkehrenden Support einplanen.
Bug Fix Releases sollten dann auch unabhängig vom eigentlichen Releasezyklus sein. Dass heisst, sobald Bugs behoben sind (=DoD für den Bug fix ist erfüllt), wird während dem Sprint Deployed.

 

[Tumbleweed]

Euer aktuelles Vorgehen ist nicht wirklich mit einigen Punkten des agilen Manifests vereinbar.

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

Ich empfehle frühen Kontakt zwischen dem Entwickler eines Features und jemandem vom Kunden, der dazu sprechfähig ist. Eine Story ist normalerweise nicht so detailliert ausformuliert, dass der Entwickler sich 3 Wochen verbuddeln kann und dann mit dem goldenen Ei hervorspringt. Das war beim klassischen Vorgehen mit Pflichten-/Lastenheft mal so die Idee. Warum ist man davon abgerückt? Weil es zu oft vorkommt bzw. fast schon die Regel ist, dass es zu unterschiedlichen Interpretationen einer Spezifikation kommt. Der Entwickler produziert dann etwas, was der Kunde sich ganz anders vorgestellt hat. Oder aber er trifft beim Entwickeln auf Probleme, die der Spezifikateur gar nicht auf dem Schirm hatte. All das ist Motivation dafür, in kurzen Zyklen Vorabversionen gemeinsam anzuschauen und zu besprechen oder zumindest auf Testsystemen zur Verfügung zu Stellen und Feedback zu bekommen, bevor das Kind in den Brunnen gefallen ist.

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen.

Das könnt ihr ja schon gar nicht leisten, weil ihr dem Kunden die Entwicklung erst zeigt, wenn sie fertig ist.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Nach allem was ich bisher so gesehen und mitgemacht habe, seid ihr mit 4 Wochen schon ganz schön weit oben unterwegs. Vielleicht probiert ihr es mal mit kleineren Paketen. Ich würde mich @Burfi bzgl. Trennung von Entwicklung und QA anschließen.

Ich weiß ja nicht, was genau ihr entwickelt, aber CI/CD ist ja nun auch schon ein paar Tage alt. Wie weit seid ihr denn in dem Bereich? Wird jeder commit automatisch auf eine Testumgebung ausgerollt oder als testbares Artefakt für den Kunden/QA vorab zur Verfügung gestellt? Da ich davon ausgehe, dass die Antwort "nein" ist, könntest du ja mal überlegen, wie man in dem Bereich weiterkommen könnte oder konkrete Beispiele nennen, warum das "nicht geht". Entwickelt ihr viele verschiedene Features parallel? Wann integriert ihr die denn - erst kurz vor Schluss?

 

[Penman]

Unser Sprint läuft 3 + 1 Woche, also 3 Wochen Entwicklung und 1 Woche Qualitätssicherung in welcher die Entwicklung "ruht".

Mit einer korrekten Implementierung von CI/CD sollte es kein Problem sein, mehrere Releases pro Tag auszurollen. Laufen die Tests zu lange oder stehen andere Hürden im Weg, muss das transparent gemacht werden. Zu lange laufende Tests können ein Hinweis auf eine zu große Anwendung sein. Dann sollte über stärkere Modularisierung nachgedacht werden.
Andere Hürden können Freigabeprozesse oder z.B. Downtimevermeidung sein. Ersteres muss schlichtweg dem agilen Vorgehen angepasst oder abgeschafft werden, zweiteres sollte nicht vorkommen, da der Versionswechsel fließend passieren sollte.

Wenn euer Partner sich eine Woche Zeit für das Review lässt und dann das komplette Release sprengt, solltet ihr an diesem Prozess ansetzen und diesen Freigabeprozess soweit es geht automatisieren und in die Story integrieren. Bestenfalls ist der Kunde im häufigen Austausch mit dem Team während an einer Story gearbeitet wird. Wenn erst beim Sprintreview auffällt, dass die Anforderung falsch umgesetzt wurde, war der Kunde nicht richtig eingebunden.

Unverblümt gesagt, ist euer Partner das Problem. Welche Rolle spielt er? Stellt er die Anforderungen oder stellt der Kunde die Anforderungen? Das verschiebt nämlich die Rolle des Kunden aus Sicht des Entwicklungsteams.
Wenn der Kunde und das Entwicklungsteam eine Anforderung besprochen und umgesetzt haben (Story geschlossen), was bewertet euer Partner dann noch?

Ist euer Partner zufällig eine Security Abteilung, die Pentests ausführt? Dann automatisiert es und holt das Wissen in das Team!

 

[Mextli]

4 Wochen Sprints sind eher das Maximum und 3+1 geht nunmal gar nicht denn QA ist Teil der Entwicklung. Probiert mal kürzere Sprints (2w) und mehr Integration der Tests.

 

[ayngush]

In einem Projekt kann es jetzt vorkommen, dass der Kunde möglichst zeitnah Zwischenlieferungen haben möchte. Wie bildet ihr das ab?

CI/CD mit automatiseirten Modultests und Releasepipelines.
Manuelle Abnahmen von Features im Vorfeld eines Inkrements passen auch nicht so richtig zu agiler Entwicklung.

Welches agile Vorgehensmodell verwendet ihr? Scrum? XP?
Was sagt euer Scrum-Master dazu?

Oder ist das wie so oft einfach nur das Ding, dass Code & Fix "mit Aufsicht" als agile Entwicklung bezeichnet wird?