Wie schaffen Sie einen großen Product Backlog? [geschlossen]

Question

Wir haben einen großen Rückstand von Dingen, die wir in unserer Software in vielen verschiedenen Kategorien, zum Beispiel tun sollen:

• Neue Problembereiche für unsere Produkte zu lösen
• Neue Funktionalität unterstützt bestehende Problembereiche
• Neue Funktionalität angefordert durch unsere bestehenden Benutzer
• Usability und "Look" Erweiterungen
• Architektur Upgrades auf das Back-End
• Bug fixes

all diese in einer vernünftigen Art und Weise zu managen ist ein Job, der zu Produktmanagement fällt, aber es ist für eine Vielzahl von Gründen schwierig. Erstens haben wir eine Reihe von verschiedenen Systemen, die die verschiedene Dinge (Marktanforderungen Dokument in Dateien, Fehler in einer Fehlerdatenbank, Kundenanforderungen in unserem Help-Desk-System, Engine Wunsch-Liste in unserem Intranet, usw.) zu halten. Und zweitens sind viele der Elemente von wild unterschiedlicher Größe, Umfang, Komplexität und natürlich Wert, was bedeutet, dass die Wahl nicht so einfach wie nur eine Liste nach Priorität der Bestellung.

Weil wir jetzt ziemlich groß sind, hat ein komplexes Produkt und viele Kunden, die Basislösungen (eine Tabelle, ein Google-Dokument, ein Basislager to-do-Liste) ist einfach nicht ausreichend, um damit umzugehen. Wir müssen einen Weg Gruppe Dinge zusammen auf verschiedene Weise, priorisieren sie auf einer laufenden Basis, machen deutlich, was wir tun und was kommt -. Ohne sie alle jemandes Zeit erfordert, um nur einige Tool zu verwalten

Wie kann man dies in einer Art und Weise verwalten, die das Geschäft ermöglicht es, immer das zu tun, was am wertvollsten ist für bestehende Kunden, hilft neue zu bekommen, und hält die Software Innereien gesund?

Beachten Sie, dass dies von der Entwicklung Seite unterschiedlich ist, was ich denke, wir haben ziemlich gut an. Wir entwickeln alles in einer iterativen, agilen Art und Weise, und einmal etwas für Design und Implementierung gewählt wurde, können wir das tun. Es ist der Teil, wo wir brauchen, um herauszufinden, was zu tun, neben das ist am schwersten!

Haben Sie eine Methode oder ein Werkzeug gefunden, das funktioniert? Wenn ja, bitte teilen! (Und wenn Sie die Antwort wissen möchten, die Frage bewerten, so bleibt es sichtbar:)

Nachtrag: Natürlich all Fehler es ist schön, zuerst zu beheben, aber in einem realen System, das tatsächlich auf den Maschinen der Kunden installiert ist, das ist nicht immer praktisch. Zum Beispiel können wir einen Fehler haben, die nur sehr selten vorkommt und dass es eine riesige Menge an Zeit und architektonischen Umbruch zu beheben nehmen würde - wir könnten, dass für eine Weile verlassen. Oder wir könnten einen Fehler haben, wo jemand denkt, zu verwenden etwas ist schwer zu, und wir denken Festsetzung es für einen größeren Umbau dieses Bereichs warten soll. Also, es gibt viele Gründe, warum wir nicht nur, sie alle sofort beheben, aber sie offen halten, so vergessen Sie nicht, wir. Außerdem ist es die Priorisierung des nicht-Bugs, die das härteste ist; nur vorstellen, wir haben keine:)

Answer 1

einen großen Rückstand auf aggressive Weise zu managen ist fast immer verschwenderisch. Durch die Zeit, die Sie in die Mitte eines priorisierten Haufen Dinge bekommen haben öfter als nicht verändert. Ich würde empfehlen, die Annahme etwas wie das, was Corey Ladas ruft eine Priorität Filter:

http://leansoftwareengineering.com/2008/08/19/priority-filter /

Im Wesentlichen haben Sie ein paar Eimer Größe zunehmender und abnehmender Priorität. Sie erlauben Beteiligten, sie zu füllen, sondern sie zwingen, den Rest der Geschichten zu ignorieren, bis es Öffnungen in den Eimer sind. Sehr einfach, aber sehr effektiv.

Edit: Allan gefragt, was zu tun ist, wenn Aufgaben unterschiedlicher Größe sind. Grundsätzlich ist ein großer Teil dieser Arbeit zu machen ist rechts Sizing Ihre Aufgaben. Wir setzen nur diese Priorisierung User Stories. User Stories sind in der Regel deutlich kleiner als „eine Community-Site erstellen“. Ich würde die Community-Site Bit ein epische oder auch ein Projekt in Betracht ziehen. Es wäre in wesentlich kleinere Bits, um priorisiert zu werden werden müssen abgebaut werden.

Wie gesagt, kann es noch Geschichten zu machen eine Herausforderung sein, zu ähnlich großen. Manchmal kann man einfach nicht, so zu kommunizieren, dass während Ihrer Planungsentscheidungen.

Im Hinblick auf die sich bewegenden Wibbles zwei Pixel, viele dieser Dinge, die einfach sind, können für „frei“ erfolgen. Sie müssen nur darauf achten, diese zu balancieren und tun sie nur, wenn sie frei wirklich nahe sind, und sie sind tatsächlich ziemlich wichtig.

Wir behandeln ähnlich Bugs. Bugs erhält eine von drei Kategorien, nun bald oder schließlich. Wir reparieren Jetzt und Soon Fehler so schnell wie möglich mit dem einzigen Unterschied, wenn wir das Updates veröffentlichen. Schließlich Fehler nicht bekommen, es sei denn, fix Devs langweilig und haben nichts zu tun, oder sie irgendwie mit höherer Priorität werden.

Answer 2

Der Schlüssel ist, aggressive Kategorisierung und Priorisierung.

Fix die Probleme, die Kunden schnell weg, und fügen Sie mehr Funktionen halten die Kunden immer wieder kommen. Zurückzudrängen Fragen, die nur eine kleine Anzahl von Menschen betreffen, es sei denn sie sind sehr einfach zu beheben.

Answer 3

Eine einfache Technik ist eine Priorisierungsmatrix zu verwenden.

Beispiele:

• http://erc.msh.org/quality/pstools/ psprior2.cfm

• http: // es. toolbox.com/blogs/enterprise-solutions/sample-project-prioritization-matrix-23381

Ebenfalls nützlich ist die Priorisierung Quadranten (zwei Dimensionen: Die Bedeutung, Dringlichkeit), die Covey schlägt vor: http : //www.dkeener.com/keenstuff/priority.html . Konzentrieren Sie sich auf die wichtige und dringende, dann die wichtig und nicht dringend. Die unwichtigen Sachen ... naja .. wenn jemand will, dass in :-) ihren freien Stunden zu tun. Eine Variante der Covey Quadranten, die ich verwendet habe, ist mit den Abmessungen von Bedeutung und Leichtigkeit. Einfache ist ein guter Weg, um die Aufgaben innerhalb eines Covey Quadranten zu priorisieren.

Answer 4

Ich glaube, man muss sie alle an einem Ort zu bekommen, so dass der Vorrang eingeräumt werden kann. Mit mehreren verschiedenen Quellen zu sammeln macht dies praktisch unmöglich. Sobald Sie, dass dann jemand / eine Gruppe hat jeden Fehler auf Rang gewünschte Funktion und die gewünschte Entwicklung.

Was Sie priorisieren könnte durch sind:

• Wert zu dem Produkt hinzugefügt
• Bedeutung für die Kunden, sowohl bestehende als auch potenzielle
• Größe der Aufgabe

Answer 5

Sie sollten alle Fehler beheben und dann erst darüber nachdenken, das Hinzufügen neuer Funktionen zu.

Answer 6

All diese Dinge könnten durch eine gute Bug-Tracking-System verfolgt werden, die folgende Merkmale aufweist:

• Möglichkeit von Workitems als Fehler oder Verbesserungsvorschläge markieren
• Kategorie Feld für die Region verantwortlich, dass das Arbeitselement fällt unter (UI, Back-End, etc.)
• Version # Feld für, wenn das Update oder Feature geplant durchgeführt werden
• Statusfeld (in Bearbeitung, abgeschlossen, überprüft, usw.)
• Feld Priorität

Answer 7

Da Sie bereits Dinge in agiler Art und Weise tun, Sie einige Ideen von XP leihen könnten:

• put alle Ihre Geschichten in großen Stapel von Karteikarten (oder ein solches Werkzeug)
• jetzt sollten Entwickler schätzen, wie groß oder klein diese Geschichten sind (hier Entwickler haben letztes Wort)
• und lassen Client (oder deren Stellvertreter - wie Produktmanager), um diese Geschichten, die von ihren Geschäftswert (hier Kunde hat das letzte Wort)
• und wenn die Entwickler denken, dass es etwas technisch, die wichtiger ist (wie die lästigen Fehler zu beheben), müssen sie, dass Client (Unternehmer) kommunizieren und Client machen, dass die Priorität zu erheben (Client noch letzte Wort hat)
• Wählen Sie, wie viele Geschichten für die nächste Iteration wie Ihre Teams Geschwindigkeit erlaubt

Auf diese Weise:

• gibt es eine einzige Warteschlange der Aufgabe, durch Geschäftsanforderungen bestellt
• Kunden erhalten beste Rendite für ihre Investition
• Geschäftswert Antriebe Entwicklung, nicht die Technik oder Geeks
• Entwickler erhalten zu sagen, wie hart die Dinge zu implementieren
• , wenn es keine ROI , Aufgabe bleibt in der Nähe von Boden dieses Haufen

Weitere Informationen finden Sie unter Planung Extreme Programming von Kent Bech und Martin Fowler . Sie sagen, es ist viel besser, als ich je tun.

Answer 8

Ich bin mir nicht sicher, ob das Werkzeug so kritisch wie der Prozess ist. Ich habe Teams sehr erfolgreich sein gesehen ziemlich große Projekte mit etwas so einfachen wie Karteikarten und weißen Tafeln zu verwalten. Eine Sache, die ich in Priorisierung empfehlen würde, ist, stellen Sie sicher, Sie haben eine umfassende Liste dieser Elemente zusammen. Auf diese Weise können die Priorität der Festsetzung eines Problems im Vergleich zu einem neuen Feature wiegen können, etc ..

Answer 9

Darüber hinaus jedes Werkzeug und Prozess sollte es sein ... einige Leute;)

In unserem Geschäft wird er genannt ein Release Manager und er den nächsten Funktionsumfang bestimmt, in der Produktion zu versenden.
Dann gibt es eine Freeze-Manager , der wirklich weiß, über Code und Dateien und Fehler (er ist in der Regel einer der Programmierer), und wird die Auswahl des Release-Manager und überwachen die notwendigen verschmilzt, um durchzusetzen hat etwas zu testen, und dann loslassen.

Zwischen ihnen zwei, eine Priorisierung festgestellt werden kann, die beide auf einem hohen Niveau (funktionale Anforderungen) und Low-Level (Bugs und technische Probleme)