Sollten agile Teams täglich neue Funktionen bereitstellen?

Mein Unternehmen befindet sich inmitten eines Übergangs von der Entwicklung im Wasserfallstil zu Agile / Scrum. Unter anderem wird uns mitgeteilt, dass wir am Ende eines jeden Tages neue funktionierende, überprüfbare (durch QS überprüfbare) Funktionen erwarten .

Die meisten unserer Entwickler verlieren ungefähr 2 Stunden pro Tag durch Meetings und andere unternehmerische Aktivitäten. Dies bedeutet, dass wir in einem gegebenen Zeitraum von 6 Stunden (im besten Fall) genügend Code entwerfen, schreiben, Komponententests durchführen, erstellen und (mit Versionshinweisen) bereitstellen müssen, um eine vollständige Funktion für die Qualitätssicherung zu erstellen. Ich verstehe, dass das Erstellen / Bereitstellen / Versionshinweise mit einem richtigen CI-Setup automatisiert werden könnten, aber wir sind noch nicht da.

Wir haben auch ein großes Offshore-Kontingent, das unseren serverseitigen Code schreibt, und der Zeitunterschied von 12 Stunden macht dies noch schwieriger.

Wir versuchen, die Storys in enge, tiefe vertikale Abschnitte zu unterteilen, um die Features so schnell wie möglich zu Ende zu bringen. Die meisten Tage sind jedoch ziemlich hektisch, und ich sehe oft Leute, die dumme, fragile Verknüpfungen verwenden, um sicherzustellen, dass die Qualitätssicherung ihren Aufbau hat. Dieses Problem verschärft sich, nachdem ein Sprint einige Tage lang ausgeführt wurde, wenn die unvermeidlichen Mängel auftreten und in dasselbe 6-Stunden-Fenster passen müssen.

Ist dies ein normales Tempo für agile Teams? Selbst wenn es uns gelingt, ein CI-Setup zu implementieren, kann ich nicht sehen, wie wir dieses Tempo aufrechterhalten und dennoch qualitativ hochwertige Software erstellen können.

Edit: Hier gibt es mehrere gute Antworten. Mir wurde klar, dass ich wirklich gefragt habe, ob agile Teams täglich neue Funktionen bereitstellen sollen. Ich habe den Titel entsprechend aktualisiert.

Die Verbrechen, die heutzutage im Namen von Agile begangen werden, machen mich traurig. Viele Menschen tun sich schwer mit diesem Übergang.

Agiles Manifest: "Wir schätzen Menschen und Interaktionen gegenüber Prozessen und Werkzeugen." Wenn die Menschen eindeutig verletzt sind, ist der Prozess falsch. Ich möchte Ihnen nicht sagen, wie es geht, aber ich werde Ihnen mitteilen, wie ich es mache.

In meinen Teams ist es wichtig, zu vermeiden, dass ein gemeinsamer Repo-Code festgelegt wird, der in einer Weise beschädigt wird, die den Rest der Teamzeit verschwendet. Nur in diesem Sinne bemühe ich mich, "jeden Tag Arbeitscode zu liefern". Unterbrechen Sie nicht die Qualitätssicherung. Blockiere keine anderen Entwickler. Im Idealfall checke ich keine Bugs ein. (ha ha).

Die Implikation ist nicht, dass Sie jeden Tag etwas begehen müssen. Die Implikation ist, dass Sie nur gute Dinge begehen sollten, damit Sie jeden Tag einen Build all der guten Dinge erhalten, die jeder begangen hat. Auf diese Weise schießt das Team weiter auf alle Zylinder.

In meinen Teams ist die Qualitätssicherung konstant. Ich baue kommerzielle Produkte, daher ist das Projekt nie zu Ende, bis das Produkt veraltet ist. QA-Ingenieure testen die Funktionen, die zum Testen zur Verfügung stehen. QA-Ingenieure haben immer einen Rückstand. Es gibt nie genug Zeit für die Qualitätssicherung, um alles zu testen oder zu automatisieren, was wir uns idealerweise wünschen.

Wenn Entwickler mehrere Tage benötigen, bevor sie Änderungen für eine Funktion oder einen Fix vornehmen, ist es in Ordnung, wenn sie den Code schneller finden, bevor sie unsere Zeit aufs Spiel setzen. Entwickler können Code für ihr privates Repo oder ihre Filiale festlegen, ohne das Team oder die Qualitätssicherung zu beeinträchtigen. Entwickler können Komponententests oder Regressionsautomatisierung mit Code ausführen, der aus dem Repo eines Entwicklers oder einer privaten Zweigstelle erstellt wurde. In besonders riskanten Fällen arbeitet ein QS-Techniker vor dem Zusammenführen mit dem Entwickler zusammen, um das Team vor Verzögerungen zu schützen.

In diesem Sinne übe ich, was Ihre Manager wollen. In den letzten 12 Jahren hatten meine Entwicklungsteams fast täglich Code, der im gemeinsam genutzten Repository funktioniert. Wir sind immer fast versandbereit. Gelegentlich schaffen wir das nicht, aber wir sorgen uns nicht zu sehr darum. Manchmal ist es beabsichtigt, größeren Werkzeugänderungen oder schwierigen Zusammenführungen Rechnung zu tragen.

Das Agile Manifest fasst für mich das Beste aus den neuen Überlegungen zum Entwicklungsprozess der 90er Jahre zusammen. Ich glaube ziemlich genau an diese Prinzipien, aber die Prozessdetails können variieren. Aus meiner Sicht geht es bei Agile darum, Ihren Prozess an die Bedürfnisse Ihres Produkts und Ihrer Kunden anzupassen, und nicht darum, ein zu verarbeitender Sklave zu sein.

Wenn Sie gestern eine funktionierende Software hatten, warum würde sie heute nicht funktionieren? Wenn Sie heute keine Aufgaben erledigt haben, ist der heutige Build derselbe wie gestern. Tägliche Builds und das Entwicklungstempo sind verschiedene Dinge. Nur weil Sie tägliche Builds haben, heißt das nicht, dass Sie in jedem Build neue Funktionen haben.

Wenn endlich eine Funktion fertiggestellt und in der Hauptniederlassung eingecheckt ist, sollten Sie einen automatisierten Prozess haben, der die Software erstellt und Tests ausführt. Wenn beim Erstellen oder Ausführen von Tests ein Problem auftritt, wird das Team benachrichtigt und konzentriert sich darauf, dass die Tests wieder funktionieren. Auf diese Weise funktioniert CI und hilft Ihnen dabei, ständig funktionierende Software freizugeben.

Kurze Antwort: Nein . Es kann einfach nicht täglich durchgeführt werden.

Ein agiles Team sollte jedoch in jedem Sprint funktionierende Softwareteile oder User Stories liefern . In der Regel finden täglich Statustreffen statt, um den Fortschritt und die Hindernisse zu ermitteln.

In Bezug auf Qualitätssoftware stellen die vorhandenen Prozesse der kontinuierlichen Integration (Continuous Integration, CI) sicher, dass die Qualitätskontrolle auf kleine Arbeitsschritte (Einchecken) angewendet und so häufig wie konfiguriert durchgeführt wird. Es zielt auch darauf ab, die quality of softwareQualität zu verbessern und den Zeitaufwand für die Bereitstellung zu verringern, indem die traditionelle Praxis der Qualitätskontrolle nach Abschluss der gesamten Entwicklung ersetzt wird.

Nein, es sollte nicht erwartet werden, dass jeden Tag neue Funktionen bereitgestellt werden. Nicht alle Features können auf eine so geringe Größe heruntergebrochen werden, dass ein Entwickler das Feature in ca. 6 Stunden Entwicklungszeit fertigstellen kann.

Wenn Sie Scrum machen, sollten Sie mindestens zwei Wochen Sprints mit Features machen, die so bemessen sind, dass sie ungefähr 0 bis 8 Tage dauern. Das Versprechen an den Produktbesitzer besteht darin, neuen, getesteten und überprüften korrekten Arbeitscode zu liefern, der am Ende des Sprints in die Produktion gehen könnte. (ANMERKUNG: Sie müssen es nicht wirklich in Produktion setzen, aber das Ziel ist, dass es sein könnte, wenn Sie wollten)

Nach einer guten Methodik sollten Sie einen CI-Server (Continuous Integration) einrichten, auf dem Sie die Erstellung mindestens eines täglichen Builds funktionierender Software automatisiert haben. Die Idee ist, dass Sie Ihren Code einchecken, sobald Sie das Feature fertiggestellt haben, damit es im nächsten Erstellungszyklus und dann in den Händen von QA zum Testen sein kann.

Denken Sie daran, dass das Ziel darin besteht, Features bis zum Ende des Sprints fertigzustellen und zu testen! Sie möchten nicht, dass die Qualitätssicherung bis zum letzten Tag des Sprints auf Sie wartet, um den Build zu erstellen und dann alle Funktionen zu testen. Sie werden keine Zeit haben, alles zu testen und Sie werden keine Zeit haben, Fehler zu beheben ...

Wenn Sie keinen CI-Server einrichten können, müssen Sie in der Regel jedes Mal manuell einen neuen Build für die Qualitätssicherung erstellen, wenn ein Entwickler seinen fertigen Code eincheckt und behauptet, dass er mit einer Funktion fertig ist und zur Übergabe an die Qualitätssicherung bereit ist.

Es hängt tatsächlich von der Größe des Projekts ab. Wenn es sich um ein großes Projekt handelt, ist dies nicht realisierbar.

Tägliche (oder noch häufigere) Builds, die aus fortlaufenden Integrationstools stammen, bedeuten keine funktionierende Software. es bedeutet kaum kompilierbaren Code.

Es gibt viele Projekte, die tägliche Builds liefern, die dank kontinuierlicher Integration funktionierende Software sind. Zumindest theoretisch.

Dies bedeutet, dass es nicht unbedingt neue Funktionen enthält. Vielleicht ein paar kleinere Fehlerbehebungen oder gar nichts.

Theoretisch müssen Sie entweder die Anzahl der Entwickler erhöhen oder die Anzahl der Tester verringern, wenn Sie nicht in der Lage sind, mehr Arbeit für Ihre tägliche Qualitätssicherung bereitzustellen. Schreckliche Idee!

Ihre Aufgabe ist es, Dinge zu erledigen.

Sagen Sie der QA, dass sie etwas zum Testen bekommen, wenn es erledigt ist. Sie müssen ihnen erklären, warum.

Ich denke, Sie sind verwirrt über die Idee von "CI". Vielleicht möchten Sie diesen hervorragenden Artikel von Martin Fowler über die Funktionsweise von CI lesen. Damit sollten Sie Ihre Frage richtig beantworten.