Implementierung eines Veröffentlichungszeitplan

Question

Die Firma für die ich arbeite versucht, ein Release-Plan zu implementieren, und ich möchte etwas konstruktives Feedback von den Leuten erhalten, die in besser strukturierten Umgebungen arbeiten, als ich bin in.

Wir haben ein Produkt, das ist fertig und von mehreren Kunden genutzt, aber wir haben 4 weitere Produkte in Arbeit - und werden aktiv vermarktet, als wären sie fertig. (Stellen Sie sich das vor!)

Wir sind ein sehr kleines Unternehmen, das sehr schnell arbeitet (und ja, manchmal schlampig) und mit engen Terminen und knappen Budgets, also haben wir nicht den Luxus geschriebener Anforderungen, systematischer QA-Prozess, usw. Grundsätzlich kommen die Eigentümer des Unternehmens zu den Entwicklern (3 von uns) mit Ideen und wir setzen sie um. Dann testen die Experten die Funktionen, um sicherzustellen, dass die App das tut, was sie tun soll.

Ich weiß, dass der letzte Absatz mich auf alle Arten von "Sie können es nicht so tun" Arten von Feedback öffnet, aber ich brauche das nicht. Ich verstehe, wie falsch dieser Ansatz ist. Irgendwann konnte ich die Besitzer überzeugen, einen Projektmanager und eine QA-Person einzustellen, aber nach kurzer Zeit wurden beide aufgrund von Umsatzeinbußen entlassen. Wir sind dort, wo wir sind, und an diesem Punkt ändert sich die Kultur nicht.

Was ich versuche zu tun, ist die Erwartungen zu verwalten. Wir haben eine Meile lange Liste von gewünschten Features und hier ist, was ich vorgeschlagen habe.

Wir werden vierteljährlich die Produktion unserer fertigen Produkte veröffentlichen. Die erste Veröffentlichung wird im Oktober sein. Anstatt zu versuchen, zu verwalten, was zwischenzeitlich auf der Grundlage der Prioritäten Hoch/Mittel/Niedrig geschehen wird, werden wir Funktionen auf der Grundlage dessen verwalten, was zwischen September und September abgeschlossen werden kann und was nicht. An diesem Punkt werden wir die Entwicklung aller Features einstellen und uns darauf konzentrieren, Fehler zu testen und zu beheben, um das Produkt im nächsten Monat zur Veröffentlichung vorzubereiten. Wir werden diesen Vorgang jedes Quartal wiederholen. Grundsätzlich sind die Schritte wie folgt:

1) Legen Sie alle herausragenden Funktionen in eine zukünftige Version, je nachdem, wie kritisch es ist. 2) Arbeiten Sie an diesen Funktionen während des Quartals. 3) Wenn neue Funktionen angefordert werden, platzieren Sie sie für einen bestimmten Freigabezyklus in eine "Warteschlange". 4) Wenn die Funktion in die aktuelle Version verschoben werden muss, verschieben Sie die anderen Funktionen auf die nächste Version. 5) Überprüfen Sie an bestimmten Punkten während des Zyklus, welche Funktionen möglicherweise nicht in die aktuelle Version gelangen, und passen Sie sie entsprechend an. 6) Beenden Sie die Entwicklung von Features mindestens 30 Tage vor dem geplanten Push-to-Production und konzentrieren Sie sich auf Tests und Fehlerbehebung. 7) Schiebe etwas zum geplanten Termin in die Produktion und nimm dann die Hitze, um nicht alles fertig zu haben, dem wir anfangs zugestimmt haben (hey, ich bin realistisch ... die Leute, für die ich arbeite, sind es nicht.)

Oh, auch, wenn Sie planen, mir zu sagen, "einen neuen Job zu bekommen" dann nicht die Mühe zu beantworten. Das ist im Moment keine Option.

Wenn Sie irgendwelche Ratschläge zu diesem vorgeschlagenen Ansatz oder Links zu Ressourcen haben, die mir helfen könnten, besser zu verstehen, wie dieser Prozess strukturiert wird, würde ich dies sehr schätzen.

Vielen Dank im Voraus für Ihre Hilfe.

Darvis

Answer 1

Ganz einfach, da es keinen definierten Prozess gibt, ist die Wahrscheinlichkeit groß, dass ein fester Veröffentlichungsplan erfolgreich implementiert werden kann. Das ist nicht nur Pessimismus, obwohl ich bereitwillig zugeben, dass es ist.

Ähnlich wie der Erfolg größtenteils auf harter Arbeit und etwas Glück basiert, basieren solide, wiederholbare Veröffentlichungspläne auf dem Prozess; Dinge wie funktionale Spezifikationen und Designspezifikationen sind wirklich wichtig, um in einem konsistenten, soliden Zeitplan veröffentlichen zu können. (Sie wissen, dass es einen Grund gibt, warum Leute solche Spezifikationssachen haben, richtig?) Und das heißt nicht, dass Sie Ihren Zeitplan nicht treffen und Erwartungen ohne solche Dinge freigeben können; Sie können sehr wahrscheinlich. Aber wenn Sie einen solchen Prozess implementieren, erhöhen Sie Ihre Chancen, die Erwartungen zu erfüllen, zumindest teilweise, weil dadurch sichergestellt wird, dass die Erwartungen nicht in "unangemessene" Bereiche fallen, während Sie noch implementieren.

Noch einmal, das bedeutet nicht, dass Sie nicht erreichen können, was Sie tun müssen, was Sie oben beschrieben haben; Um ehrlich zu sein, wenn Sie sich in einer Umgebung befinden, die einem solchen Prozess aktiv feindlich gegenübersteht, arbeiten Sie wahrscheinlich am besten, um das zu erreichen, was Sie brauchen. Und ich möchte nicht völlig pessimistisch sein; Es hört sich an, als hättest du ein gutes Gespür dafür, wie man versucht, dieses Zeug zu erledigen; Für das, womit Sie arbeiten müssen, klingt es, als hätten Sie einen vernünftigen Prozess an Ort und Stelle. Aber ich kann praktisch garantieren, dass es dir besser geht, wenn du nur zwei Dinge bekommst; 1) eine funktionale Spezifikation vom Management, die beschreibt, was die Software tun soll, und 2) eine Designspezifikation von der technischen Beschreibung bis zum Management, wie Sie die Software dazu bringen wollen, was sie in der funktionalen Spezifikation tun wollen.Ich denke, du könntest das vielleicht sogar in deinen Prozess einbauen; funktionale Spezifikationen müssen nicht kompliziert sein; Das Wichtigste an ihnen ist, dass sie aufgeschrieben sind, was verhindert, dass man sich darüber streitet, was das Management verlangt; es ist genau da. Und Design-Spezifikationen müssen auch nicht viel Zeit in Anspruch nehmen. Ein schneller One-Pager, damit das Management weiß, wie (auf einer hohen Ebene) Sie implementieren, was sie benötigen, gibt ihnen die Sicherheit, dass Sie sie gehört haben, und kann ihnen helfen, die Komplexität zu verstehen (aber nicht gehen zu tief hinein, sonst laufen Sie Gefahr, sie zu langweilen und ihre Aufmerksamkeit zu verlieren).

Answer 2

Veröffentlichung früh und häufig.

Ich finde oft, dass die Benutzer nicht wissen, was sie wollen, bis wir sie zeigen. In unserer Einrichtung haben wir ein leichtes QA/Test-System. Lassen Sie die Benutzer neue Dinge ausprobieren. Wenn Nutzer Ideen befürworten, versetzen wir sie in die Produktion.Dadurch können wir immer an neuen Dingen arbeiten, Schnittstellen testen, Datenbanktabellen und -spalten hinzufügen, ohne den Produktionscode zu unterbrechen.

Der einzige "Trick" erinnert den Kunden ständig daran, dass die Testplattform nicht die Produktionsplattform ist.

Answer 3

Angesichts des Mangels an Projektmanagement, Organisation, etc. - Ich denke, dass Sie Probleme haben werden, versuchen Sie sich in einen vierteljährlichen (oder jeden festen Termin) Release-Zyklus zu zwingen. Dies trifft besonders dann zu, wenn Sie "große" Funktionen haben, die mehr als 2 Monate benötigen, um Entwicklungszeiten zu ermöglichen.

Mein Vorschlag wäre, einen Feature-basierten Release-Zyklus zu machen. Machen Sie einfach Ihre Warteschlange von Funktionen, entscheiden Sie, welche Sie in einem bestimmten Zeitraum vernünftigerweise tun können. Implementieren Sie diese Funktionen, geben Sie sich einen Monat (oder was auch immer) zum Testen, dann veröffentlichen Sie sie. Wechseln Sie zur nächsten Gruppe von Funktionen. Wenn es 2 statt 3 Monate dauert, großartig. Wenn es 4 dauert, ist das auch in Ordnung.

Das sagte, würde ich konzentrieren auf den Versuch, dies kürzer zu machen, nicht länger. In diesem Fall werden Ihnen mehr, kleinere Releases helfen, zumal Sie nicht über die formellen Prozeduren (und das Personal) verfügen, um mit QA, etc. umzugehen. Flexibel zu bleiben wird Ihnen helfen, Probleme zu beheben, die in Ihre Releases gelangen ...

Answer 4

Was verwenden Sie für die Quellcodeverwaltung?

Wir verwenden SVN und haben die Flexibilität, bei Bedarf eine Vielzahl verschiedener Zweige zu erstellen, abhängig davon, was in der nächsten Version bereitgestellt wird. Wenn die Releases a1, a2 und a3 freigegeben sind, können wir diese Änderungen in eine Abzweigproduktion zusammenführen. Wenn a2 weniger Priorität bekommt, können wir nur die Änderungen von a2 zurücksetzen, oder wenn es Überlappungen gibt, einfach einen neuen Zweig erstellen und nur a1 und a3 zusammenführen, wobei a2 für eine spätere Version übrig bleibt.

Wie wahrscheinlich sind die Besitzer, eine Spezifikation vor einer gegebenen Ausgabe neu zu schreiben? Wo ich arbeite, passiert das häufig, wodurch die Möglichkeit, Gänge zu schalten und Rollback/Re-Merge durchzuführen, sehr hilfreich ist.

Answer 5

Meine Firma wird auch mit Feature-Anfragen festgefahren.

Wir haben alle Funktionen durchgespielt und schätzen die benötigte Zeit für die Implementierung. Dann überlassen wir es unserem "Change Committee" (unserem CEO, Teamchefs usw.), uns die Features zu geben, die wir im nächsten Sprint absolvieren werden.

Auf diese Weise erhalten wir keine unangemessen großen Arbeitsbelastungen, und der Endbenutzer hat ein gewisses Mitspracherecht.