学習中に見積もりが増加したため、チームは新しいスキルを習得した後、将来の見積もりを減らす必要がありますか？
最近、ユニットテストを推進しています。これは私のチームにとって新しいスキルです。私は10年以上ユニットテストを書いた経験がありますが、基本的にはチームでこれだけの経験がある唯一の人です。私は最近、これらのスキルを習得するための予算を立てる方法に苦労しています。人々（私を含む）に、勤務時間外に新しいスキルをすべて習得させることはできません。家族がいます。仕事で働く。自宅で。私たちは全員、四半期ごとにトレーニング時間を割り当てられています。ただし、ブログ投稿、YouTubeビデオ、PluralSightチュートリアルでは、これまでのところしか手が届きません。
ユニットテストが必要なストーリーのストーリーポイントを増やすという、この頭のいいアイデアを思いつきました。これにより、ストーリーポイントごとに提供できる機能の量が効果的に削減されます。総力を上げているので、当時は元気でした。私の考えでは、この増加は、単体テストを書くことの「未知数」によって正当化されました。私たちのチームメンバーがユニットテストの能力を身につけた後、ストーリーポイントの見積もりが戻ってくることも期待しています。
私はもともと、Seleniumを使用した自動エンドツーエンドテストの記述を必要とするストーリーのストーリーポイントの見積もりを増やすために、別のヘアブレーンのアイデアからこのヘアブレーンのアイデアを得ました。これにより、以前は1階建てであった機能が6階以上に爆発しました。ストーリー＃1には、開発と単一の自動テストの記述が含まれていました。これは通常、13ポイントのストーリーであることが判明しました。原則として、チームは3週間のスプリントで8ポイントのストーリーを快適に提供できます。より高いものと私たちの自信は指数関数的に低下します。 13ポイントの話が気になります。 1つのスプリントで20ポイントのストーリー？ええ、そして私たちがそこにいる間、私もポニーが欲しいです。
したがって、最初のストーリーは13ポイントとなり、4〜5ストーリーはそれぞれ3〜5ポイントと推定されます。小さめのストーリーは、Seleniumページモデルなどのテストインフラストラクチャコードの追加を含め、文字通り自動テストを記述するために必要な労力でした。これらのテストはすべて、明確でテスト可能なエンドユーザーの動作を検証しました。
チームの速度は最初は低下しましたが、最終的には上昇しました。ストーリーポイントの見積もりが下がることはありません。ストーリーの内訳を続けて1つの13ポイントストーリーをまとめ、次に3〜5ポイントのストーリーをまとめて自動テストを作成しました。
今、私たちはユニットテストを学ぶ私の現在の状況に早送りします。チームはストーリーを13ストーリーポイント以上で推定し、このストーリーをより小さなものに分解する方法はありません。私たちのチームにとって、「ストーリー」は基本的にエンドユーザーが操作できるものです。かなり一般的ですが、エンドユーザーがそれを表示または操作できない場合、それはユーザーストーリーではありません。
電子メールの送信に使用されるインターフェイスで単一のメソッドをモックする必要がある単体テストを実行するように要求しました。 Postal NuGetパッケージを使用して電子メールを作成して送信します。これにより、ビューモデルとかみそりテンプレートを使用してWebページをレンダリングするよりも電子メールを送信するのが簡単になります（私たちのチームは、 ASP.NET MVC）。
ユニットテストは、ビジネスカスタマーアカウントからユーザーを削除するときに呼び出される「サービス」クラスをカバーします。削除された人は誰でも電子メール通知を受け取るはずです。新しいユニットテストでは、削除された各ユーザーに電子メールが送信されるという事実をカバーする必要があります。電子メールが送信されるということだけで、電子メールの内容をアサートする必要はありません。これには、IEmailService.Send(Email)メソッドのモックが含まれます。
この13点の話は私を緊張させます。 3週間のスプリントの途中であり、ユニットテストの基本についての基本的な質問がまだあります。このスプリントの目標を達成できなくなるのではないかと思います。そのため、ストーリーは13ポイントの見積もりを獲得しました。ユニットテストを導入しようとするたびに、小さくてシンプルなストーリーでも、チームは常に13ポイント以上の見積もりを出しました。開発、自動テスト、単体テストを考慮に入れると、1回のスプリントに十分なストーリーはもうありません。これは単に、このチームのスピードとスキルレベルにとっては大きすぎます。このプロジェクトをリードしてきた4年間全体で気付いた傾向です。私はただレンガの壁を叩いているだけです。
ストーリーポイントを調整する は、誰がストーリーを割り当てられるかに基づいて行いません。正直なところ、とにかく一人でストーリーに取り組む人はいません。私は読みました 新しいスキルの学習はアジャイルにどこに適合しますか？ ですが、ある時点で新しいスキルを利用する必要があり、これは私の難問です。私はチームリーダー、スクラムマスター、ビジネスアナリスト、グラフィックデザイナー、BDDプラクティショナー、およびこのプロジェクトのアーキテクトであるため、プログラムをチームのすべての人とペアにする時間がないことがよくあります。この多数の責任も、すぐには変わりません。
速度の低下に対処するか、推定値を増やす必要があるようです。 2つのうち後者を選択しました。
ユニットテストを学ぶためにストーリーポイントの見積もりを増やした後、チームは、ユニットテストを書くことの学習の「不明」がもはや存在しないという仮定に基づいて、同様の作業の将来のストーリーポイントの見積もりを減らします。不明ですか？
ここにいくつかの潜在的な問題があります。
ストーリーポイントと速度を使用する全体のポイントは、時間ごとの見積もりを手動で振り分けることですが、最終的にストーリーポイントは、チームが物事を完了するのにかかる時間に何らかの形で最終的に相関する必要があります。チームが3週間のスプリントごとに（残業なしで）30ストーリーポイントを完了することができる場合、各ストーリーポイントの完了には約4時間かかります。
私の意見では、ストーリーポイントと速度は推定プロセスに通知する必要があります逆ではありません。単に見積もりを増やすだけではうまくいきません。チームは、ストーリーポイントと速度が最終的に正常化するように、よりタイムリーな方法で物事を成し遂げる方法を理解する必要があります。
チームがタスクに対して30ストーリーポイントを見積もったが、スプリントの第1週にそれを完了し、スプリントの終了前に他の優先順位でさらに10ストーリーポイントを完了する時間がある場合、それは良い問題です。しかし、それはあなたが直面する問題ではありません。
だからここに私の考えは、順不同です。
モックによる単体テストは困難で費用がかかります。私の経験では、テストのためにモックを必要としないようにAPIを設計することをお勧めします。また、バーゲンでより良いデザインを得ることができます。最初にテストを書くことを検討してください最初に、APIの設計に通知し、部分的な「完了の定義」として機能するようにします。
タスクの細分性を高める方法を見つけてください。完了しやすい小さなタスクは、見積もりも簡単です。チームが特に統制されていない限り、タスクの20ストーリーポイントは、スプリントごとに30ポイントしか利用できないチームには大きすぎます。
チームの速度とストーリーのポイントを自分で説明してみましょう。チームがタスクごとに一貫してより多くのストーリーポイントを見積もる場合は、見積りを徐々にダイヤルし直し、バックログに空白を埋めるための多くの作業があることを確認します。完了するまでに時間がかかる場合は、見積もりを引き延ばし、作業の遅延の根本的な原因に取り組みます。
実用主義のルール。ユニットテストが導入される前に、チームが一貫して信頼できるソフトウェアを作成していた場合は、アプローチを再評価するときかもしれません。スタッフのレベルを確認してください。増加したワークロードに対応するには、より多くの開発者が必要になる場合があります。
あなたの速度とストーリーのポイントは、問題があることを示しています。これらの指標を再設計しないでください。根本原因に取り組みます。
実話：かつてのボスは、ストーリーポイントシステムとソフトウェア開発プロセスが非常に制度化され、彼の仕事の1つで破損したため、フォームにドロップダウンを追加するなどの単純な変更が完了するまでに3か月かかったと言っていました。見積もりプロセスを乗っ取りました。これをあなたに起こさせないでください。
その2020年には、すべての開発者がユニットテストトレインにすでに乗り込んでいると思っていたでしょう。
ポイントと見積もりに関しては、詳細にこだわっていると思います。あなたはユニットテストが長期的に開発を加速し、それを要件として受け入れたことを知っています。
単体テストを含む「完了の定義」を用意し、開発者にタスクを推定させます。彼らの見積もりに挑戦したり心配したりせず、ベロシティを追跡し、それを使用して終了日を予測してください。見積もりに対するあなたのストレスがそれらを押し上げ、会議で時間を浪費することを期待します
また、8ポイント= 3週間の場合、ポイントは少し大きくなると思います。 1週間のスプリントを推奨し、日数で見積もります。チームに独自の目標を設定させます。
ストーリーの定義も問題の一部である可能性があります。 「マウスオーバーでボタンを緑色にして」はストーリーになる可能性があります
あなたはコメントに書き込みます：私は、開発者がメソッドの単体テストを書くことを要求するのに3週間以上かかることを恐れていますが、単体テストなしで1日かかるかもしれません。
チームがユニットテストを実行することを望まないように聞こえるため、見積もりの労力が増加します。トレーニング予算を使用してユニットテストワークショップを行います。強制する前に単体テストが必要だと説得します。
単体テストを作成すると、ストーリーの複雑さが増します。したがって、ポイント数が増加し、スプリントごとに実行される機能が少なくなります。最初は効果が大きくなります（ただし、実際に感じるほど大きくはありません）。
単体テストのため、将来のリファクタリングが容易になります。リリース作業は中止または消失する可能性があります。リリースに表示されるバグが少なくなり、バグ修正の労力が軽減されます。これらの安全な時間は機能の実現に費やすことができるため、速度が向上します。
開発、自動テスト、単体テストを考慮に入れると、1回のスプリントに十分なストーリーはもうありません。
それが問題の根本だと思います-あなたの物語は単に大きすぎます。 13ポイントのストーリー（チーム全体で約5週間かかる）を3つまたは4つの小さなストーリーに分割できないとは信じられません。
私の推奨は、チームにもっと良い、より小さなストーリーを書くように挑戦することです。ストーリーが小さいほど、正確な見積もりが得られます。あなたの投稿であなたが与えた数字に基づいて、私はそのストーリーのすべてのテストのための時間を含めて、ストーリーが4ポイントを超えないことを要求することを提案します。それよりも大きい場合は、2つのストーリーに分割します。
ユニットテストを学習するためにストーリーポイントの見積もりを増やした後、チームは、ユニットテストを書くことの学習の「不明」がもはや未知ではないとの仮定に基づいて、同様の作業の将来のストーリーポイントの見積もりを減らしますか？
チームは人為的にストーリーポイントを減らすべきではありません。ただし、人為的にストーリーポイントを追加する場合は、それをやめるべきです。
チームがスキルを開発するにつれて、ストーリーポイントは自然に下がるはずです。ストーリーポイントは、すべてのテスト、ドキュメントなどを含む、ストーリーを完全に完成させるためのチームの正直な意見を反映する必要があります。テストの熟練度が上がると、時間は自然に短縮されます。