Die Freigabe eines Produkts ist der wichtigste Teil der Arbeit eines Softwareunternehmens. Aber wenn Sie Angst haben, eine Veröffentlichung zu machen, dann machen Sie vielleicht etwas falsch. Ich werde Ihnen sagen, wie ich normalerweise die Veröffentlichung organisiere. Dieser Artikel ist kein umfassender Leitfaden, da in der Softwareentwicklungsbranche alles individuell ist.
Wie bereite ich mich auf die Veröffentlichung vor?
Wählen Sie eine verantwortliche Person
Sie können sich abwechseln, Würfel werfen oder Streichhölzer ziehen - jeder Weg ist gut. Wichtig ist die Rotation der Leute und die Ausbildung derjenigen, die nicht wissen, wie man eine Veröffentlichung macht. Wenn Sie beispielsweise Würfel werfen, können Sie die Regeln eingeben, zu deren Übertragung derjenige berechtigt war, der zuletzt Dienst hatte. Wenn er zweimal hintereinander Dienst hatte, sind Sie automatisch nicht im Dienst. Die Pflicht sollte nicht als Bestrafung oder Wehrpflicht angesehen werden, und es muss Menschen geben, die versichern können.
Kalender anpassen
Legen Sie ein Datum im Unternehmenskalender fest und vergewissern Sie sich, dass alle Beteiligten informiert sind.
Erstelle einen Tisch im Wiki
Geben Sie die Tabellenversion, das Datum und die Person an, die für die Freigabe verantwortlich ist. Dies ist für die Pflege historischer Daten wichtiger. Sie können und sollten sofort feststellen, ob die Veröffentlichung erfolgreich war und was genau in der Veröffentlichung enthalten war.
Versionshinweise
Dies ist genau das, was genau in der Veröffentlichung enthalten war. Zuallererst müssen diese Daten mit Analysten geteilt werden: Sie können alle Änderungen im KPI mit den in der Veröffentlichung enthaltenen Daten vergleichen. Basierend auf diesen Daten können sie Rückschlüsse darauf ziehen, welche Funktionalität Benutzer benötigen, welche Ideen gut sind und welche nicht und was in die nächste Iteration einfließen wird.
Interne Ankündigung
Für andere Abteilungen ist es wichtig zu wissen, wann die Freigabe stattgefunden hat, z. B. um Stellen in sozialen Diensten zu besetzen. Netzwerke über eine neue Version eines Produkts (Erstellen eines Informationsleitfadens), Überwachen des KPI (Metriken können steigen oder fallen) usw.
Während der Veröffentlichung
Release Brunch erstellen
Der freizugebende Code sollte nicht geändert werden, außer um kritische Fehler zu beheben. Und im Idealfall sollte jeder Fix eine Poolanforderung durchlaufen. Außerdem sollten alle Tests grün sein.
Benachrichtigung senden
Sie müssen jeden per E-Mail oder im Messenger benachrichtigen, dass ein Release-Brunch erstellt wurde und die Vorbereitungen für die Veröffentlichung laufen.
Tag erstellen
Stellen Sie sicher, dass Sie ein Tag erstellen, wenn die Veröffentlichung abgeschlossen ist, und ziehen Sie die Fixes im Entwicklungszweig fest.
Release selber machen
Idealerweise sollten Sie über Mechanismen verfügen, die die Freigabe steuern: Geben Sie beispielsweise nur 10% der Benutzer oder nur Nichtzahler frei. Das ist dafür nötig. um den Schaden durch Fehler zu verringern, die während des Entwicklungsprozesses aufgetreten sind und beim Testen nicht gefunden wurden.
One Button Release
Mythisch. Je weniger menschliche Faktoren an der Veröffentlichung beteiligt sind, desto besser. Das ist aber normal, wenn nicht alles automatisiert werden kann.
Wenn alles schief gelaufen ist wie geplant
Im Falle eines Fehlers können Sie sich natürlich nicht gegenseitig die Schuld geben, aber Sie müssen das Problem gemeinsam lösen und einen Plan ausarbeiten, um solche Vorfälle in Zukunft zu verhindern.
Nach der Freilassung
Zu überwachen
Vergessen Sie nicht, Fehler zu überwachen, Serverlast. Es lohnt sich auch, auf KPI zu achten: Wenn Sie eine Freigabe vorgenommen und Ihre DAU gelöscht haben, funktioniert möglicherweise etwas nicht so, wie es sollte, oder die Überwachungstools selbst sind defekt. Jede verdächtige Aktivität ist es wert, überprüft zu werden.
Erfolg und Misserfolg melden
Es ist viel besser, wenn sie von Entwicklern und nicht von Benutzern über das Problem erfahren. Und wenn Sie Probleme gelöst haben, können Sie sich sicher rühmen.
Rückblick
Dies hängt natürlich teilweise von der Entwicklungsmethode ab, aber wenn während des Veröffentlichungsprozesses etwas schief gelaufen ist, lohnt es sich, darüber zu diskutieren. Wenn etwas gut war, dann ist es auch eine Diskussion wert. Im Idealfall sollte an der Tafel für jeden Punkt des Scheiterns ein Punkt des Erfolgs oder der Dankbarkeit eines Kollegen stehen. Dies wird dazu beitragen, eine Retrospektive nicht in Nörgelei und Negativ zu verwandeln.
Pizza bestellen und feiern
Bei solchen Treffen werden nur Kollegen zu Freunden und Kameraden. Und das bedeutet, dass Freunde Sie im nächsten Kampf nicht im Stich lassen werden.
Bereiten Sie sich auf die nächste Version vor
Ich mag die Idee von Release Train sehr, wenn jedes Release regelmäßig zu klar definierten Terminen stattfindet. Dank dessen wird der Freigabemechanismus vom Team getestet. Wie ich oben geschrieben habe, ist es nicht erforderlich, 100% der Benutzer freizugeben: Es kann für eine kleine Gruppe von Personen bereitgestellt werden.
Wie veröffentlichen andere Unternehmen?
Spotify
Spotify wird häufig auf der Grundlage von Release Train veröffentlicht. Wie der Name dieser Übung andeutet, ähnelt die Veröffentlichung einem Zug: Diejenigen, die keine Zeit hatten, ihre Arbeit zu beenden, warten auf die nächste Veröffentlichung. Der Vorteil dieses Ansatzes besteht darin, dass ein ausgefallenes Team die Produktauslieferung nicht verzögert und nicht versucht, nicht abgeschlossene Aufgaben voranzutreiben. Infolgedessen werden die Telefone der Entwickler nachts nicht zerrissen, und das Einsatzteam erscheint morgens nicht mit Taschen unter den Augen bei der Arbeit. Natürlich funktioniert dieser Ansatz nicht für ein Outsourcing-Unternehmen: Der Kunde bezahlt nicht für unfertige Arbeiten. Ehrlich gesagt: Ich mag die Unternehmenskultur. Ich rate Ihnen, sich ein Video (https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) über die Funktionsweise anzusehen.
Buchung
Diese Jungs sind auch sehr cool. Ihre Veröffentlichungen basieren auf A / B-Tests. Angenommen, es gibt eine aktuelle stabile Version - Version A, und es gibt eine Version, die der Entwickler gerade fertiggestellt hat - Version B. Wenn der KPI in Version B besser ist, lohnt es sich, den Prozentsatz der Benutzer für diese Version zu erhöhen. Wenn Version B schlechter ist, gibt es zwei Möglichkeiten: Version B ist einfach nicht stabil oder nur eine Funktion, die niemand benötigt. Dieser Ansatz ist für ein Unternehmen geeignet, das sich um sein Arbeitsprodukt kümmert, aber höchstwahrscheinlich keine Revolution vollzieht. Wenn Sie mehr über Lean Manufacturing erfahren möchten, lesen Sie das Lean Startup-Buch (http://theleanstartup.com/).