大規模な製品バックログをどのように管理しますか?[閉まっている]

https://stackoverflow.com/questions/109141

01-07-2019
|

質問

私たちは、ソフトウェアで実行すべきことの大量の未処理の作業を、さまざまなカテゴリで抱えています。たとえば、次のとおりです。

当社製品が解決すべき新たな問題領域
既存の問題領域をサポートする新機能
既存ユーザーから要望のあった新機能
使いやすさと「見た目」の強化
バックエンドのアーキテクチャのアップグレード
バグの修正

これらすべてを賢明な方法で管理するのはプロダクト管理の仕事ですが、多くの理由から困難です。まず、さまざまなもの (ファイル内の市場要件文書、バグデータベース内のバグ、ヘルプデスクシステム内の顧客要件、イントラネット上のエンジニアの要望リストなど) を保持するさまざまなシステムが多数あります。そして第二に、項目の多くはサイズ、範囲、複雑さ、そしてもちろん価値が大きく異なります。つまり、リストを優先順位に従って並べるだけでは選択が簡単ではありません。

当社は現在、かなり大規模で、複雑な製品と多くの顧客を抱えているため、基本的なソリューション (スプレッドシート、Google ドキュメント、ベースキャンプの ToDo リスト) だけでは、この問題に対処するには十分ではありません。誰かがツールを管理するだけですべての時間を費やすことなく、さまざまな方法で物事をグループ化し、継続的に優先順位を付け、自分たちが何をしているのか、そしてこれから何が起こるのかを明確にする方法が必要です。

企業が既存の顧客にとって最も価値のあることを常に実行できるようにし、新規顧客の獲得を支援し、ソフトウェアの内部を健全に保つには、どのようにこれを管理すればよいでしょうか?

これは開発側とは異なることに注意してください。開発側についてはかなりよく理解できたと思います。私たちはすべてを反復的かつアジャイルな方法で開発し、設計と実装のために何かを選択したら、それを実行することができます。次に何をすべきかを考えなければならない部分が最も難しいのです。

効果的な方法やツールは見つかりましたか?もしそうなら、シェアしてください！(答えも知りたい場合は、質問を評価して、表示されたままにしてください:)

補遺: もちろん、最初にすべてのバグを修正するのは良いことですが、実際に顧客のマシンにインストールされる実際のシステムでは、それは必ずしも現実的ではありません。たとえば、非常にまれにしか発生せず、修正するには膨大な時間とアーキテクチャ上の大混乱が必要なバグがある場合、それをしばらく放置するかもしれません。あるいは、何かが使いにくいと誰かが考えているバグが存在する可能性があり、それを修正するには、その領域の大規模な改修を待つ必要があると考えます。したがって、すぐにすべてを修正するのではなく、忘れないように公開しておきたい理由はたくさんあります。さらに、最も難しいのはバグ以外の優先順位付けです。何も持っていないことを想像してください:)

解決

大量のバックログを積極的に管理することは、ほとんどの場合無駄になります。優先順位を付けた山の真ん中に到達するまでに、多くの場合、状況は変化しています。Corey Ladas が優先フィルターと呼んでいるもののようなものを採用することをお勧めします。

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

基本的に、サイズが増加し、優先度が減少するバケットがいくつかあります。関係者にストーリーを埋めることを許可しますが、バケツに空きができるまでは、残りのストーリーを無視するよう強います。とてもシンプルですが、とても効果的です。

編集： アランは、タスクのサイズが異なる場合はどうすればよいかを尋ねました。基本的に、これを機能させるために重要なのは、タスクのサイズを適切に設定することです。この優先順位付けはユーザーストーリーにのみ適用されます。ユーザーストーリーは通常、「コミュニティサイトの作成」よりも大幅に小さくなります。私はこのコミュニティサイトを壮大なプロジェクト、あるいはプロジェクトだとさえ考えています。優先順位を付けるには、かなり小さなビットに分割する必要があります。

とはいえ、同じようなサイズのストーリーを作るのは依然として難しい場合があります。それができない場合もあるので、計画を立てる際にそのことを伝えます。

ウィブルを 2 ピクセル移動することに関しては、簡単なことの多くは「無料」で実行できます。これらのバランスに注意し、本当に無料に近く、実際にある程度重要な場合にのみ実行する必要があります。

バグも同様に扱います。バグは、Now、Soon、またはやがて、の 3 つのカテゴリのいずれかになります。私たちは Now および Soon のバグをできるだけ早く修正しますが、唯一の違いは修正をいつ公開するかです。最終的には、開発者が退屈して何もすることがなくなるか、何らかの理由で優先順位が高くならない限り、バグは修正されません。

他のヒント

重要なのは、積極的な分類と優先順位付けです。

顧客を遠ざけている問題をすぐに修正し、顧客を呼び寄せ続けるための機能を追加します。修正が非常に簡単でない限り、少数の人にのみ影響を与える問題は延期してください。

簡単な手法は、優先順位付けマトリックスを使用することです。

例:

優先順位付け象限 (2 つの次元:重要性、緊急性)、コヴィー氏は次のように提案しています。 http://www.dkeener.com/keenstuff/priority.html. 。重要なものと緊急なものに焦点を当て、次に重要なものと緊急でないものに焦点を当てます。重要ではないもの...そうですね...誰かがオフの時間にそれをしたい場合:-)。私が使用した Covey 四分円の変形は、重要性と容易さの次元です。Ease は、Covey 象限内のタスクに優先順位を付ける良い方法です。

優先順位を付けられるように、それらをすべて 1 か所にまとめておく必要があると思います。複数の異なる情報源を照合する必要があるため、これは事実上不可能です。それができたら、誰かまたはグループが各バグ、要求された機能、および望ましい開発をランク付けする必要があります。

優先順位を付けることができるのは次のとおりです。

製品の付加価値
既存顧客と潜在顧客の両方にとっての重要性
タスクの規模

まずすべてのバグを修正してから、新しい機能の追加を検討する必要があります。

これらすべては、次の機能を備えた優れたバグ追跡システムによって追跡できます。

作業項目をバグまたは機能拡張リクエストとしてマークする機能
作業項目が該当する責任領域のカテゴリフィールド (UI、バックエンドなど)
修正または機能の実行がスケジュールされているときのバージョン番号フィールド
ステータスフィールド (進行中、完了、検証済みなど)
優先フィールド

すでにアジャイルな方法で物事を行っているため、XP からいくつかのアイデアを借用できます。

置く全てあなたのストーリーを大量のインデックスカード (またはそのようなツール) にまとめて保存
開発者は、それらのストーリーがどのくらい大きいか小さいかを見積もる必要があります (ここで開発者が最終決定をします)
そして、クライアント (またはその代理人 (プロダクトマネージャーなど)) にビジネス価値に基づいてストーリーを順序付けさせます (最終決定はクライアントが行います)
そして、開発者が技術的にもっと重要なこと（厄介なバグの修正など）があると考える場合、それをクライアント（ビジネスパーソン）に伝え、クライアントにその優先順位を上げてもらう必要があります（最終決定権はまだクライアントにあります）。
チームの速度が許す限り、次のイテレーション用に多くのストーリーを選択します

こちらです：

ビジネスニーズに応じて順序付けされたタスクの単一のキューがあります
顧客は投資に対して最高の利益を得ることができます
テクノロジーやマニアではなく、ビジネス価値が開発を推進する
開発者は実装がいかに難しいかを語ります
ない場合 ROI, 、タスクはその山の底近くに留まります

詳細については、「」を参照してください。 エクストリームプログラミングの計画 による ケント・ベック そして マーティン・ファウラー. 。彼らは私よりもずっと上手に言います。

ツールがプロセスと同じくらい重要かどうかはわかりません。かなり大規模なプロジェクトを管理するために、インデックスカードやホワイトボードのような単純なものを使用して、チームが非常に成功しているのを私は見てきました。優先順位を付ける際にお勧めしたいのは、これらの項目をまとめた包括的なリストを作成することです。こうすることで、問題を解決することと問題を解決することの優先順位を比較検討できます。新機能など。

あらゆるツールやプロセスを超えて、次のものがあるはずです...一部の人々 ;）

当店では彼をこう呼んでいます リリースマネージャー そして、本番環境に出荷する次の機能境界を決定します。
それから、 フリーズマネージャー コード、ファイル、バグについて実際に知っている人 (通常はプログラマーの 1 人です) で、リリースマネージャーの選択を強制し、何かをテストしてリリースするために必要なマージを監視します。

この 2 つの間で、高レベル (機能リクエスト) と低レベル (バグや技術的問題) の両方で優先順位を確立できます。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow