大きなタスクを評価する方法

ユーザーストーリーを評価する方法は多数あります。 独自の方法論を使用して、コードを記述する前にタスクを評価および解決します。 どうやってこれに到達したのか、そしてなぜ私たちのアプローチがPlaning Pokerよりも優れているのかを、以下で説明します。

プランニングポーカーについて

3年間、Planning Pokerを使用しました。 このアプローチでは、各プログラマーは、0.5、1、2、3、5、8、13、20、40の従来型ユニット（ストーリーポイント）でクローズされたストーリーを評価します。 そして、最高と最低の成績を与えた人々は、なぜこのタスクが彼らにとってとても難しいように見えるか、またはその逆であるかを説明します-シンプル。 全員が共通の評価に達するまで、議論は続けられます。



スプリントの完了後、スクラムマスターは、完了したストーリーに含まれるストーリーポイントの数を計算します。 収集された統計に基づいて、彼は次のスプリントに適合するタスクの数を決定します。

実際に問題は何ですか

外出先でストーリーを理解します

ユーザーストーリーの評価を行うには、少なくとも一般的な用語で、開発者はそれを実装する方法を理解する必要があります。 実装方法を理解するには、クライアントが何を望んでいるかを理解する必要があります。 これはすべて、評価中に明確化および議論されます。 チームは1つのストーリーに5〜30分かかります。 同時に、トピックに精通している2〜3人が積極的にディスカッションに参加します。 残りは時間の無駄です。



評価の時間は依然として非常に限られているため、開発者は重要なポイントを見逃すことがよくあります。 これは、ストーリーが大幅に過小評価されている、またはゼロからやり直さなければならないという事実につながる可能性があります。



マネージャーがクライアントから重要なニュアンスを学ばず、履歴の評価を延期する必要があることが判明する場合があります。

ビッグストーリーの正確な評価の幻想

1つのストーリーは20と見積もられます。別の10ストーリーはそれぞれ2と評価されます。 合計で10の小さなストーリーのスコアは1つの大きなストーリーに相当します。 ただし、大きなストーリーはほとんどの場合、同じ評価の小さなストーリーよりも長くなります。



この推定方法では、 20> 2 * 10です。



なぜこれが起こっているのですか？ ストーリーが大きいほど、評価するときに考慮すべきことを忘れる可能性が高くなります。 すべてを考慮しても、1つのストーリーを50％過小評価する可能性は、10のストーリーを過小評価する可能性よりも高くなります。

仕事を何パーセント終えましたか？

サイズ20のタスクの途中で、マネージャーは開発者にいつ終了するかを尋ねます。 開発者は、明確ではない何かに答えるか、楽観的すぎる評価をするか、楽観的評価に2を掛けます。マネージャーは正確な評価を得ることはできません。



これは、答えとして、開発者がタスクを自分が行った部分と残った部分に分割し、その後、残りの部分をすばやく評価するという事実によるものです。 彼は、彼がまだしなければならないことすべてを考慮に入れようとすること、およびこの部分のサイズを評価することにおいて間違っているかもしれません。 さらに、マネージャーを待たせないように、この評価を単独で非常に迅速に行います。

40 =不明

チームは履歴に40のスコアを与えます。つまり、プログラマーはタスクにかかる時間を実際には知りません。 彼らはそれをどのように行うかを完全には理解していません。



同じ問題は、程度は劣りますが、グレード20、13、8に関係します。1組の文で記述されたストーリーが13または20のグレードである場合、これは開発者がその方法を完全に理解していないことも意味します。 評価中にチーム全体で問題の解決策を詳細に説明することは、時間の無駄です。 これは1人で行うことができます。 この問題を解決するために、各タスクについて、チームの評価の前にソリューションを書いた人を任命しました。 しかし、決定がどの程度詳細であるかについての明確な基準はありませんでした。 問題の解決策を理解できるようにするために、いくつかの文で十分な場合もあれば、いくつかの段落が必要な場合もあります。

パーツに分割する

これらの問題に対処するために、次のアイデアを思いつきました。それぞれの問題を解決するのに必要な時間について誰も質問しないまで、ストーリーをサブタスクに分割する必要があります。 サブタスクのサイズを単純に加算することで推定値を取得できるように、サブタスクは同じサイズでなければなりません。



その結果、設計評価プロセスは次のようになります。

1. 入り口では、ユーザーストーリーはクライアントにメリットをもたらす最小限の機能です。 ユーザーストーリーは、受け入れられるように、マネージャーまたはクライアントが理解できる受け入れ基準を必ず持っている必要があります。
2. ストーリーが大きすぎるように見える場合、MVPは際立っています。すべてが破棄され、クライアントは最初にそれなしでできます。 このストーリーの最後で、次の処理が行われます。この処理では、既に追加されている機能が拡張されます。
3. このストーリーの背後で、必要に応じてストーリーを個別のタスクに分割し、各タスクを他のタスクと並行して実行できるようにする人が任命されます。 多くの場合、タスクに分解しても意味がないユーザーストーリーがあります。それらは並行していないか、ストーリーが小さすぎます。 可能であれば、タスクを個別にテストできるように実行する必要があります。 その後、最初のタスクの完了後にテストを開始でき、ストーリー全体が完了するまで待機する必要はありません。
4. 次に、責任者は各タスクをサブタスクに分割します。 各サブタスクは段落であり、1つの文から段落への説明があります。 非プログラマーにとっては意味がないかもしれません。 「クラスの書き込み」や「このクラスのテストの書き込み」などの個別のサブタスクは正常です。 サブタスクに分割する場合、責任者は次のルールに従って誘導されます。
   
   
   
   
   • すべてのサブタスクは、ほぼ同じ最小サイズ（1ストーリーポイント）である必要があります
   • 各サブタスクについて、その中で何を行う必要があるかを明確にする必要があります
   • サブタスクにはプログラマーの受け入れ基準があります（クラスが作成され、テストに合格します）
   
   
   
5. チームはタスクを評価します。 チームが評価する際、責任者がどの程度うまくソリューションを解決し、サブタスク間で大きすぎても小さすぎても、タスクをサブタスクに分割したかどうかのレビューがあります。 この場合：
   
   
   
   
   • 特定のサブタスクが誰かに理解できない場合、より詳細に説明されます。
   • サブタスクが大きすぎるとチームが判断した場合、サブタスクは部分に分割されます。
   • サブタスクの説明を読むときに、責任者が回答できない多くの質問がある場合、タスクはより詳細な調査のために送信されます。
   • チームが問題の解決策を好まない場合、外出先で変更されるか、再設計のために送信されます。

すべてのタスクを評価した後、ユーザーストーリーの評価を取得します。 ストーリー内のサブタスクの数-これは、ストーリーポイントでの評価です。

の引数

迅速なチーム評価

評価オプションの数は非常に限られているため、チームの評価は高速です。 各サブタスクに投票せず、自由回答形式の質問をすると、チームの評価をさらに加速できます。

• どのサブタスクが明確ではありませんか？
• どのサブタスクを分割する必要がありますか？
• どのサブタスクを組み合わせる必要がありますか？

設計品質の形式化

タスクをサブタスクに分割し、チーム全体で設計結果を評価するための明確な基準は、重要なポイントを忘れる可能性を減らし、設計中にだまされないようにします。 タスクの実行を担当する人がそれをかなり小さな部分に分割すると、その機能の顧客と既存のコードの両方に自動的に質問があり、リファクタリングが必要になる場合があります。 これは、タスクの作業中に同じ質問が発生する場合よりも優れています。



さらに、設計者に質問がなかった場合は、チームの評価中に質問されます。 チケットの作業中にのみタスクが解決される場合、1人の担当者のみがこれを担当し、重要な質問をすることはできません。その結果、タスクをやり直す必要があります。



ある人がストーリーを作成し、別の人がそれを行っていることがよくあります。 ただし、評価の前に開発者にタスクを割り当てたい場合でも、チームがタスクの設計段階と評価段階を別々に分けると便利です。 評価段階で、チームの1人がタスクを簡単にする方法を言うかもしれません。または、必要な機能が既にあるどこかで、それをまったく行う必要がないことが判明するかもしれません。 もちろん、開発者にタスクを割り当てても、プロセスに柔軟性は追加されません。 チーム開発者が設計されたタスクを実行できるように、プロセスを構築することをお勧めします。

タスクがどこまで完了したかの明確な理解

各サブタスクにはプログラマーが理解する受け入れ基準があるため、彼は常に、自分が完了したサブタスクの数と残りの数を理解しています。 したがって、彼はタスクが受け入れられるときに質問に簡単に答えることができます。

反対論

チーム評価のためのタスクの準備には時間がかかります

通常、1つのタスクをサブタスクに分割するには約5〜30分かかりますが、困難な場合には、いくつかのタスクで構成されるストーリーに数日かかることがあります。



より正確な評価のためだけに多くの時間を費やす価値がありますか？ もちろん違います。 しかし実際、ほとんどの時間はタスクの分割ではなく、ソリューションの開発と設計に費やされています。 一部のストーリーのソリューションを詳細に説明するには、複数の人と議論して既存のコードを表示する必要があります。 これには多くの時間がかかります。 この場合、サブタスクに分割するプロセスは、最悪の場合30分かかります。



チームが作業を開始する前に評価できる事前に設計されたソリューションは、多くの時間を費やす価値があります。

これは機敏ではありません

通常、アジャイルアプローチでは、設計は開発と同時に実行されます。 この観点から、私たちのアプローチはあまり機敏ではありません。 ただし、アジャイルの鍵は、できるだけ早く顧客に価値を提供することです。 MVPを割り当てる場合、MVPを開発する順序はそれほど重要ではありません。 MVPの開発後のみ、クライアントからフィードバックを受け取ります。

可能なスナップ効果

チームは、設計の責任者が提供したパーティションを公然と評価するため、拘束効果が生じる可能性があります-特により権威のある開発者によって作成された場合、チームメンバーは既に定義されたパーティションに同意します。 私たちの実践では、この問題はそれほど顕在化しません。通常、人々はサブタスクが大きすぎる、小さすぎる、または理解できないと言って恥ずかしがりません。 ただし、チームでこれに問題がある場合は、次のオプションを使用して各サブタスクを非公開投票に送信できます。

• 大きすぎて分割できません。
• 他と組み合わせるには小さすぎる。
• ちょうどいい。

同時に、投票前に、サブタスクを理解していないすべての人が質問をすることができます。

開発者は、自分の前ですべてがすでに考え抜かれているタスクを実行することはできません

詳細なタスクを実行するとき、プログラマは創造性の自由がはるかに少なくなります。 開発者が自分のために設計されたストーリーのコードのみを作成する場合、開発者は成長せず、非常に意欲を失わせる可能性があります。 したがって、チームのすべての開発者が設計に携わる機会を持つことが重要です。誰もがストーリーをタスクとサブタスクに分割する必要があります。 経験豊富な開発者がユーザーストーリーに取り組む可能性が高い場合は問題ありません。 後輩でも少しデザインをすることが重要です。

大きなストーリーをすぐに評価することはできません。

パーティションを介してタスクを評価するプロセスはかなり面倒なので、迅速な評価には使用できません。 ストーリーの予備的な大まかな評価には、2〜3人の専門家による評価を使用できます。 このような評価は不正確ですが、それを優先するのに十分です。 ストーリーポイントで予備的な評価を行う価値はないため、この評価の正確性の錯覚はありません。



予備評価には古き良き週を使用することをお勧めします。半週間、1、2、1か月です。 チームがストーリーを評価した後、専門家の評価を行った人は、自分の週間をストーリーポイントに変換するだけで、自分の間違いをすぐに見つけることができます（統計から開発者の平均速度を知っています）。



可能であれば、優先順位を付ける前にタスクを評価しないようにしてください。 ストーリーを評価した後、長時間延期されると、時間を失うことになります。

• この時間を今すぐクライアントに役立つものに費やすことができます。
• このストーリーに取り組むまでに、リファクタリングや新機能のためにその評価は無関係になる可能性があります。

したがって、評価には、必ず実行する必要のあるタスクが必ず来るはずです。 優先順位付けにストーリーにかかる時間を知る必要がある場合は、予備評価を行う必要があります。



Planning Pokerを使用した評価に満足しているが、デザインの品質に問題がある場合は、評価と優先順位付けの後にストーリーをサブタスクに分割できます。 次に、開発プロセスは次のようになります。

• Planning Pokerでストーリーを評価し、
• 優先する
• 開発者がソリューションをサブタスクに書き込み、
• チームはこの決定を評価し、
• 開発者がコードを記述します。

このアプローチを使用すると、開発者がコードの記述を開始する前に、設計結果のレビューを取得できます。 全体として、このようなプロセスには時間がかかる可能性があります。

例

たとえば、次の機能を使用してみましょう。サブスクリプション用のjs-pluginとブラックジャックと詩人を使用して、ブラウザーにプッシュ通知を実装します。 理想的には：

• jsプラグインは、プッシュ通知をサポートするすべてのブラウザーで機能します。
• jsプラグインはhttpsサイトとhttpサイトの両方で機能します。
• 通知は、大量に手動で送信するか、個々の消費者にイベントで送信できます。
• 通知の配信とクリックを追跡します。

この機能からMVPを選択します-少なくとも1人のクライアントに役立つ機能を取得できるように、可能なすべてのものを破棄します。

• プッシュ通知の独自の実装があるため、Safariサポートを削除します。
• httpサイトのサポートを削除します。これをサポートするには、複雑なハックを作成する必要があるためです。
• httpsサイトを持つほとんどのクライアントは、まず大量送信を必要とするため、通知の一括送信のみを残します。
• 最初は統計情報なしで処理するため、配信とクリックの追跡は後で延期します。

MVP機能は次のタスクに分割でき、各タスクは個別に実行できます。

1. 通知のサブスクライブと表示を担当するjsライブラリ。
2. プッシュ通知を送信するマイクロサービス。
3. 一括送信通知のUI。

Googleのウェブプッシュ通知のドキュメントを少し調べてから、最初のタスクをサブタスクに分割します。

1. 次のメソッドをjsライブラリに実装します。
   
   
   • ブラウザがプッシュ通知をサポートしていることを確認します。
   • サイトユーザーが通知を購読しているかどうかを確認します。
   • 通知のサブスクリプション。
2. プッシュ通知をサポートするブラウザーとサポートしないブラウザーで、これらのメソッドが正しく機能することを確認するテストを作成します。
   
   これにはBrowserStackを使用します。 別の方法として、この段落には、さまざまなブラウザーでjsメソッドを手動でテストするタスクがあります。
3. serviceWorkersとの連携を学びます。
   
   サービス通知はserviceWorkerによって処理されます。 以前は使用していなかったため、新しい技術の研究に1Sを割り当てます。
4. 通知を処理するserviceWorkerを作成します。 このserviceWorkerの登録をサブスクリプションメソッドに追加します。
5. serviceWorkerでテストを作成します。

その結果、5Sで最初の問題を評価しました（もちろん、チームがそのようなパーティションに同意しない限り）。 残りのタスクも同じように分類されます。

統計について少し

チームの評価により、ストーリーの準備ができたことがわかります。 このため、前の週に完了したストーリーポイントの数が考慮されます。



ストーリーは、受け入れられたり使用されたりした場合にのみ、完了したと見なされます。 本当に関心があるのは、正確にお客様に価値を提供するスピードであり、タスクがどれほど迅速に受け入れられるかではありません。



このような評価が機能するためには、レビューと承認の最大条件に同意する必要があります。 たとえば、わが国では、タスクのレビューの責任者は、タスクがレビューに送信された瞬間から2日以内に最初のレビューを行う義務があり、レビューの結果に基づく修正は日中に受け入れられる必要があります。



小さなMVPを分離できず、一部の機能が2つのスプリントにまたがっている場合、スプリントの統計はジャンプします。 ただし、この場合でも、最後の数回のスプリントの平均結果を取得すれば、チームの速度を計算できます。

タスクの再評価

どのようにタスクをうまく実行しても、常に何かを考慮に入れない可能性があります。 機能の作業中に、新しい未処理のサブタスクが表示される場合、それらを過小評価する必要があります。 そうすれば、タスクが完了するまでのおおよその時間を常に知ることができます。 スプリントのストーリーポイントを推定した量に関する統計を収集することもできます。 これは、推定誤差を理解するのに役立ちます。



過小評価されたストーリーポイントを使用して、チームの速度を計算することはできません。 最後のスプリントのチームが50ストーリーポイントでストーリーを作成し、スプリント中に10ストーリーポイントでそれらを過大評価した場合、これは次のスプリントで60ストーリーポイントを獲得できるという意味ではありません。 今度はあなたが何かを過小評価する可能性があるので、50を取ります。

おわりに

ストーリーを事前にサブタスクに分割し始めたとき、大きなタスクを過小評価することで問題が少なくなりました。 不適切な設計のためにタスクを最初からやり直す必要がある状況はもうありません。



Planning Pokerでチームの時間を使いすぎており、大きなタスクの評価や設計に問題がある場合は、このアプローチを試すことをお勧めします。