スクラムでは、主に研究であるバックログアイテムの見積もりをどのように行いますか？
数スプリント前、私は主に研究であるタスクを割り当てられました。私たちが開発しなかった非常に複雑なブラックボックスと製品を相互運用する方法を理解する必要がありました。
この作品を見積もる方法が思いつかなかった。ボールを転がして当面の問題を知っていたとしても、その後に解決しなければならない問題がいくつあるのかわからなかった。ほぼ完了したのか、それとも遠く離れているのか、私にはわかりませんでした。このようなバックログアイテムをどのように見積もるのですか？
この課題の性質を詳しく説明したいと思います。私は、ブラックボックスと相互運用するためにどのような呼び出しを行う必要があるかを知っていました。それは簡単な部分でした。しかし、APIは非常に複雑なオブジェクトをパラメーターとして受け取りました。 APIを呼び出すとエラーがスローされ、そのエラーが何を教えてくれているのかを理解するのは簡単ではありませんでした。ブラックボックスは、私の要求で間違っているすべての問題を教えてくれるわけではなく、最初に見つけた問題を教えてくれるだけです。これは私がどれだけの仕事を残したかを知ることを非常に困難にしました。
見積もることができず、このシナリオでは、プロセスの特定の部分にかかる時間を事前に知る方法が実際にはないように思われる場合、次善の選択肢はtime-box努力：どこにでも行けるかどうかにかかわらず、どれだけの時間を費やしても構わないと思っているか
あなたがそれに入ると、あなたは残りの努力を見積もる方法についてより良い考えを持っているかもしれません
信じられないほどシンプル：それは常に3ポイントです。
（または別の定数を選択してください）。これは私たちが最後の仕事で取ったアプローチであり、比較的うまくいったと思います。
アイデアは、実際のストーリーでいっぱいのバックログがあり、そのうちの1つは、あなたが何も知らないデバイスとの統合ストーリーであるということです。誰かが私にそれ以上の知識なしにその物語（実際の統合）のサイズを決めるように頼んだら、私は非常に控えめな見積もりをします。過去に同様の統合を行った場合、ハイエンドでストーリーポイントを選択する可能性があります。同様の仕事をしたことがなく、どこから始めればよいのかさえわからない場合は、100万ポイントを選ぶだけです。
それで、明らかに製品の所有者が戻ってきて、100万ポイントを獲得することはできないと言ったので、研究について別のストーリーを作成しましょう。リサーチストーリーの目標IS統合をコーディングしないでください。それはISあなたが直面する可能性のあるすべての問題を解決することではありません。プライマリおよびのみリサーチストーリーの目標は、実際のワークストーリーのより良い点推定を提供することです。すべてのAPI呼び出しの使用方法を理解し、実際の統合設計/コードを考え出すことに迷わないでください。代わりに、アプローチあなたの前にある複雑さを理解することは、高レベルからです。
リサーチストーリーの最後に、あなたの＃1の成果物（可能なリサーチノート、プロトタイプなど）は、統合の点推定であり、統合ストーリーをいくつかの小さな部分に分割する可能性があります。十分な調査が行われているため、これらのそれぞれにはまだ未知のコンポーネントがあることに注意してください。その未知の部分を制御できるはずです（つまり、APIの使用法について読んだら、5ポイントになるようです。安全のために）。
調査タスクを割り当てられた開発者は、ほぼ一定の時間数で常にSteamを使い果たしていることがわかりました（明らかに多少の変動はありますが、最終的には平均化されます）。その後、2倍の時間を費やすことができますが、統合ストーリーの見積もりはこれ以上良くなりません。
それが彼らがそれらを呼ぶ理由です推定。
純粋に研究関連の仕事の正確な見積もりはありそうにありません。それが研究の本質です。しかし、実際には見積もることができるのに、見積もることができないと思うこともあることを指摘する価値があると思います。科学者はこれを知っています。ほとんどの研究作業は反復的でありふれたものです...必要な時間の変動を引き起こすのは理論化と方向の変化です。
したがって、研究関連の作業の見積もりを作成する方法は、通常の開発の見積もりを作成する方法と同じです。タスクを細かく分割し、各部分を個別に評価します。研究仕事は、その点で通常の非研究開発と同じです。あなたは仕事を定量化し、それからそれにあなたの最良の推測を与えます。
たとえば、「このブラックボックスがどのように機能するか、およびソフトウェア製品をどのようにインターフェースするかを決定する」というタスクを見積もることができない場合があります。ただし、次の独立した見積もりを考え出すことができる場合があります。
- ブラックボックスのAPIを評価して理解する
- ブラックボックスの動作を評価する
- どのコマンドが必要な動作を実行するかを決定します
- 安全上の懸念の可能性を分析、特定、軽減します
- ソフトウェアからのコマンドをブラックボックス内のコマンドにマップし、返されたデータを評価します。
などなど。
一部の見積もりは、前の手順の完了に依存する場合があります。たとえば、ステップ＃3は、ステップ＃2が完了するまで推定できない場合があります。
見積もりは単一の数値ではありません。推定値は、ハイエンド、ローエンド、および信頼度を持つ範囲です。 「どれくらい時間がかかりますか」という最初の質問では、見積もりは「14時間かかる」ではなく、「10〜18時間かかる」というものです。
プロセスを洗練するにつれて、見積もりの範囲がますます狭くなる可能性があります
（出典： construx.com ）
これは、「平均で収束する」ということではなく、推定値の変動性を示していることに注意してください。見積もりは、「10〜18時間かかる」から始まり、「14〜18時間かかる」、「16〜18時間かかる」の順になります。
見積もりで最も頻繁に引用される本の1つは ソフトウェア見積もり：ブラックアートの謎を解く スティーブマコネルによる。
最良の場合と最悪の場合がある非常に広い見積もりから始めます。次に、すぐに調査を開始し、別の見積もりを行い、次に別の見積もりを行います。それがいつ1つの番号で行われるかについて約束をしてから、それを作ろうとしないでください。
見積もりを生成するには、さまざまな手法があります。過去の見積もりからの履歴データを使用します。それがどれほど大きいか、複雑さ、そしてそこからの作業について考えてみてください（リストは続きます、これについて書かれた本全体があります）。
私が使用している2つの方法：
意図的な発見アプローチ：2つのストーリーから始めます（逆の順序で）：
- システムを理解するのにどれくらいの時間が必要か
- システムを理解するために必要な時間を見積もるのに必要な時間-意図的に非常に短くしてください
重要なのは、それらのいずれも機能の値によって制限されるということです。機能Xを提供するためにシステムを考え出すのに1年を費やすことは意味がありません。その半分の時間で機能Yを提供でき、Yの方がビジネス価値が高い場合です。あなたのPOはあなたに番号を与えることができるはずです： 'それを理解するのに2ヶ月以上必要な場合、それは価値がありません'。 2番目のストーリーを完了したら、最初のストーリーの見積もりを調整します。
近づくにつれて発見する：
私たちが開発しなかった非常に複雑なブラックボックスと製品を相互運用させる方法。
これは大きな物語への道です。あなたが取り組むことになる最初のこと/機能/側面は何ですか（どれが最も価値がありますか？）。 「ブラックボックスにログインする」と同じくらい簡単かもしれません。これは単純な話です。統合ポイントはそれほど悪くないはずであり、最小限の調査でかなり簡単に見積もることができます。それを見積もります。他のストーリーをビジネス価値の境界に置き、詳細を学びながら洗練していきます。
どちらのアプローチも長期計画に関して問題があります。開始したとき、すべての機能がいつ完了するかわからないだけです。それは大丈夫です-専門知識を構築しながら、明日、来週、来月、そして6か月の信頼できる予測をすることから始めます。
多くの研究タスクは自由形式で行うことができますが、これには明確な（っぽい）要件があります。「製品を...ブラックボックスと相互運用する方法」です。
私たちは、以前に行った仕事に類似/関連する仕事を見積もるのが得意です。これまでに行ったことがないため、ジョブをチャンクに分割し、各チャンクにタイムボックスを与えることしかできません。そのような仕事は永遠に続く可能性があり、各タイムボックスの進行の終わりに、残っているタスクを再評価する必要があります。極端な場合、これは、実行/非実行の決定を行う必要がある場合です。
私がそのような仕事に取り組むとき、私は5つのステップのプロセスを定義します
（1）初期計画。 （2）開始するために何をする必要があるかを最初に推測し、（3）一連の反復/段階を定義し、それぞれに（4）レビューと（5）再計画ステップが続きます。例えば：
はじめにタスク。この場合、「ブラックボックスの仕様を取得する」、「仕様を調べる」、「ブラックボックスを取得する」、「サンプルソフトウェアを取得する」、「サポートリンクを確立する」などです。
繰り返し1.「基本的な操作をテストします。基本的なデバッグ環境をセットアップします。確認します。再計画します。」
反復2 ...など、大きな進捗レビューの前に3回以上5回以下、または7回程度の反復。
各反復にはどのくらい時間がかかりますか？それらにタイムボックスを設定します-そうしないと、そのような仕事は永遠に続きます。ボックスが1時間、1日、1週間、...であるかどうかを言うことができるのはあなただけです。
また、柔軟に対応してください。学習するにつれて、計画を変更する必要がある場合があります。自分を罰しないでください。この種の仕事はデバッグのようなものです-あなたは自分自身を教えなければなりません。しかし、デバッグと同様に、他の人からの入力を得るのに役立ちます。そして、デバッグのように、マルチタスク中にそれを行うことはできません。