少し時間がかかりましたが、私が取り組んでいるソフトウェア製品のバージョン 1.0 に必要なすべてのタスクを書き留めることができました。
リストはほぼ 1000 項目の長さです。
私たちは 3 人のチームで、MindMeister、Google ドキュメント、コード内の @todos などを使用して、何とかここまで到達することができました。これで、機能ごとにすべてがきちんとグループ化されました。スケジュールに入れる？
どんなアドバイスでも大歓迎です-私はソフトウェアの推奨事項を探しているわけではありません-バグ修正からアプリケーションモジュールに至るまで、この膨大なタスクの袋をどのように取り、どの順序ですべきかを見つける方法についてアドバイスを求めていますそれらをする。
さりげなく優先。1000 個のアクション アイテムは多くの場合、いくつかを変更したり、他のアイテムを破棄したり、新しいアイテムを追加したりする可能性があります。あなたのリストは、実際にソフトウェアを構築して学んだことでは生き残れません。最も重要なことを最初に行わないと、混乱してしまいます。
すべてのアイテムまたは機能について、次の質問に答える必要があります。これがなくても、製品はまったく使用可能または有用ですか? はいの場合、待つことができます。それ以外はすべてキューの先頭に移動します。
その後、フォーカスごとにマイルストーンをグループ化するのが好きです。機能マイルストーン (または、機能の自然な小さなクラスターがある場合は複数のマイルストーン)、AJAX/リッチ クライアントの対話性に焦点を当てる UI マイルストーン、パフォーマンス マイルストーンを行います。私はプロファイルを作成し、データベースとサーバーのチューニングなどを行います。または、他の方法で分割しますが、間違いなく分割します。各反復に特定の焦点を当てて、より小さなバイトで作業し、次に進む前に各反復がしっかりしていることを確認してください。
私の推奨するアプローチは、アジャイル手法のベスト プラクティスに基づいています...
これで、アジャイル用語で「バックログ」と呼ばれるものが定義されました。これは素晴らしいことです。重要な最初のステップです。
一般的に使用される適切なアジャイル ペースは、2 ～ 3 週間のイテレーションの長さです...そして最後に、リリース可能な一連の機能が得られます。これにより、開発プロセスの「ハートビート」が確立されます。次に、機能をストーリーとタスクに整理してグループ化する方法を決定します。
基盤となるアーキテクチャを成長させ、バックログから選択したストーリーとタスクの順序に基づいて自然に出現させたいと思うでしょう。
リスクを早期に軽減することが重要です。そのため、最大のリスクをもたらす可能性のあるパフォーマンスまたは実装の不明な項目を早期に選択する必要があり、再作業の影響が最大になる可能性があります。たとえば、メッセージング インフラストラクチャの確立は、作業単位を完了するために永続的なメッセージの配信が必要なストーリーを選択した場合に含まれる初期のアーキテクチャ機能である可能性があります。
一連の機能を、1.0 リリースを System of Systems として説明するために自然に進化する可能性のある機能カテゴリにグループ化できますか? たとえば、管理機能、ユーザー プロファイル管理、レポート、外部統合レイヤー、データベース アクセス オブジェクトなどです。
作成できる最も単純なストーリー / ユース ケースは何ですか? それは、あなたが定義した約 1,000 の機能 / 要件のいくつかに対応しますか? 一連のストーリー (またはストーリーからの個々のタスク - ストーリー自体が大きすぎて 1 回の反復で実装できない場合) を選択します。追加の作業が必要になりますが、要件を一連のストーリー/タスクに再構成することが重要です。
その後の反復中にリファクタリングを行うことがわかりますが、安定した 2 週間のハートビート反復スケジュールにより、実際の機能が引き続き提供されます。
さまざまな時点で、クリーンアップ/リファクタリングに集中するためだけにアーキテクチャの反復をスケジュールしたい場合がありますが、それも問題ありません。
これらのアイテムはすべて必須であると示しているため、リストからアイテムを削除する可能性はあまりないと思います (少なくとも今のところ)。それを考えると、いつアイテムを実行するかを決定し、それらを実行するのにどれくらいの時間がかかるかを決定するという 2 つの大きなタスクが手元にあります。
項目を機能ごとに便利にグループ化したので、機能の優先順位付けから始めます。うまくいけば、これにより作業セットが大幅に削減され、妥当な時間内に実際に処理できるようになります。
リスクに基づいて各機能に優先順位を付けます。実装が簡単なものもあれば、難しいものもあります。これらはすべて必須であるため、予期しない問題に対応できるようスケジュールに余裕があるときに、最もリスクの高い機能を最初に実行してください。あなたのサイクルが終わるまで待てば、マーフィーの法則があなたを打ち倒します。
あなたの小さなチームを考えると、機能のリストを周りに送り、実装するのが危険または困難な機能であると考えるかどうかをマークするよう全員に依頼します. すべての点数を合計すると、「リスク評価」が得られ、最も高い得点の項目が最初に割り当てられます。
あるいは、顧客に簡単にアクセスできる場合は、各機能に関連する「リスク」を評価するよう顧客に依頼します (この場合、リスクとは、機能がないという最悪のシナリオを指します。機能を持たないことが製品を使用しないことにつながる場合、それはリスクが高いです)。
プライオリティ キューができたので、次は見積もりを行います。最初の推定では、各機能について 1 桁の推定を行うだけです。すでに機能を分解しているかのように聞こえるので、何かが何時間、何日、または何週間かかるかについて、まともな感覚をつかむことができるはずです. その音からすると、あなたはまだ開発の初期段階にあるので、あと 1 か月ほどで実装されないものについて正確な見積もりを得ようとしてもあまり意味がないと思います。
キューからアイテムを取り出すときに、数時間以上かかるべきではない詳細なタスクを特定することで、チームがより正確な見積もりを提供できるようにします。桁違いの見積もりを改善したい場合は、システムに関する最新の知識に基づいて、残りのタスクの見積もりを段階的に提供できます。
これにより、かなり正確な短期スケジュールと、徐々に正確になるあいまいな長期スケジュールが提供されます。
最後に、長い開発サイクルに直面している場合は、特定の目標または日付を特定し、それらの目標を達成したら、座ってこのプロセス全体を繰り返すことをお勧めします. これらのことを再訪せずに2週間以上行くことはありません. 問題をよりよく理解するにつれて、新しいアイテムが追加され、他のアイテムは追い越されて時代遅れになり、他のアイテムはリスクが高くなります。これらすべてを考慮に入れる必要があります。