チケットの推定時間を作成するとき、テスター（QA）にかかる時間をチケットの推定に含める必要がありますか？以前は、テスターの時間なしで常に見積もっていましたが、常にそれを含めることについて話し合っています。チケットがあと1週間でかかる合計時間を知る必要があるため、現在のスプリント、リリース前の最後のスプリントには意味があります。

チームのリソースを制限する傾向があるため、見積もりは開発者向けの時間であると常に理解していました。同僚は、テスターの時間より前に働いていた場所はどこでも含まれていると言っています。

明確にするために、これは、開発者が適切なカバレッジでユニット、統合、およびUIテストを記述しているプロセスのためのものです。

私の推奨事項：チケットにテスト時間を含めるか、テストタスク自体を表すチケットを追加します。他のアプローチでは、必要な実際の作業を過小評価します。

開発者の時間は多くの場合ボトルネックですが、私の経験では、テストに制約のある多くのチームがいます。制限のあるリソースが証拠のないいずれかであると仮定すると、噛みつく可能性があります。

あなたの同僚として、テスト時間を考慮に入れていない成功した組織を見たことはありません。

明確化のための補遺：開発者が自動化テスト、特に単体テスト（統合テストの方が優れている）を作成しても、適切にテストするには不十分です。

QA関係者が関与している場合、その時間を何らかの方法で推定する必要があります。QAの人を給与から削除することを決定した場合にのみ、その人の作業時間が事実上なくなり、見積もりから削除できます。しかし、これには無視しやすい副作用があります。また、パフォーマンス、ストレス、セキュリティ、受け入れテストがまだ不足している可能性があります。

強調して、はい

テストは開発プロセスの一部です。チームが実際にソフトウェアのテストに時間を費やしている場合、テストに費やした時間は見積もりの​​一部である必要があります。

これがアジャイルであれば、ストーリー全体のポイントの一部としてテスト作業を含めます。たとえば、開発作業はおそらく1日で、テストは1日なので、2ポイントのストーリーになります。

それはあなたの定義が何であるかに依存しますが、通常はその開発が完了し、ビジネスが受け入れられ、テストがイテレーションで終了します。DoDが単なるビジネス承認である場合、テストの努力をストーリーポイントに含める必要はありませんが、追跡する必要があります。

見積もりでは、チケットを完了するために必要なすべての作業を考慮に入れる必要があります。テストがチケットの必須部分である場合は、見積もりに含める必要があります。テストが別のチケットである場合、そうすべきではありません。

開発専用5と開発専用8の違いは、開発およびQA 5と開発およびQA 8にかなり比例するため、ストーリーポイントの使用を開始すると、もちろんすべてがあいまいになります。

テスター時間の仕事を含めて見ました。個別のストーリーが機能するのを見てきました。私は別々のタスクを見てきました。それぞれがタスクを実行するグ​​ループによって推定されます。すべてのプロセスがあなたに奉仕するためにそこにある後、あなたにとって意味のあることをしてください。

これに答えられないという事実は、なぜ見積もりを書いているのかわからない（または少なくとも、見積もりを書いている理由を同僚に同意していない）ことを強く示唆しています。これは、見積もりにテストを含めるべきかどうかを決めるよりも大きな問題です。

見積もりを書いている理由を見つけるか、合意に達します。特定のチームが特定の時間に何を達成するかを予測する場合、答えは単に、あなたが推定しているチームがテストを行うかどうかに依存します。QAチームが独立しており、独自のスケジュールを設定している場合、彼らはあなた（開発者）が与えられたチケットでどれだけのテスト時間を必要と考えているかを知りたいと思うかもしれません。彼らはあなたの数字を無視して自分の数字を入れるかもしれません。いずれにしても、開発者の時間の見積もりとは別にそれを追跡できます。

一方、1つのチームがすべての開発、テスト、およびQAを行っており、時間見積もりの​​目的が特定の時間枠でそのチームが行っていることを予測および計画することである場合、もちろん時間見積もりにはQA、および記載された目標を達成するためにそのチームが実行する必要がある他のタスク。チケットごとにキックオフミーティングを開催する必要がある場合、または完了時にいくつかの書類を記入する必要がある場合は、管理者の時間をどこかに置く必要があります。無視することはできません。

すべてが「開発者」と「テスター」に分かれた役割を持つすべてのチームである場合、分割の片側のみが作業できるチケットがたくさんあることを意味し、（おそらく完全に仮想的な）ガントチャートが見えます2つの別々のチームのチャートが正確に見えるように。この事実は他の方法論よりもいくつかの方法論を混乱させるでしょう、そしてあなたはそのために計画を分割するほうが良いかもしれませんが、もしそれを分割しないなら、あなたはチームがする必要があるすべてを発券し、推定しなければならないか、あなたの予測は絶望的です。

見積りの目的が予測と計画以外のものである場合、たとえば、「それらを含む空の儀式を無意識にたどる」ため、または「管理者が残業をするために私たちを打ち負かすための棒として使用するため」、または「固定価格で入札する必要があり、数値が膨大な計算式になるため」（John Wuに感謝）、それが何を含めるべきかを理解するのが難しいかもしれません;-)

ユーザーストーリー/機能/チケットを本当に完成させるために必要なすべての作業を常に見積もります。これをDoneDoneと呼びます。

ときに我々はしている私たちが行っている生産準備。

これには、手動および探索的テストが含まれますが、ユーザー受け入れテストも含まれます。

アジャイルチームは、いつでも完成した作業の新しい部分をリリースできる必要があります。なので：

稼働中のソフトウェアは、進捗状況の主要な指標です。

テストしていない場合、それが機能するかどうかをどのように確認しますか？ここで、開発時間があなたの時間のボトルネックであると書きます。QAエンジニアとして、ほとんどのチームは能力のテストにボトルネックがあるか、単にショートカットを取っていると思います。

長い話を短くするために、テストの労力も見積もります。これは速度に影響する可能性があることに注意してください。ストーリーポイントで相対的な推定を行っている場合、テストは既に平均速度に組み込まれている可能性があります。

ここに非常に重要なものがあります。すべての見積もりには、仮定と除外を伴う必要があります。

これには、含まれるものの指定が含まれます：開発のみ、設計と開発、開発と単体テスト、受け入れテストのカバレッジ、インフラストラクチャの構築など。

見積もりドキュメントをプロジェクトマネージャーに提供している場合、彼らはそのドキュメントをクライアントまたは（内部プロジェクトの場合）PMOの作業指示書または作業明細書に変換します。彼らはありオーバーヘッド追加するための経験により、契約またはセットで設定されている（例えば、いくつかのプロジェクトは、カバーのガバナンスおよびプロジェクト管理へのY％を追加し、QAをカバーするためにX％追加すること）セット式を有します。そして、あなたは二重に数えたくありません。一方、それらは自動的に追加されない場合があります。

プラクティスは異なります。これらの数値を使用している人は、数値の意味を知る必要があり、テスト時間を含めるかどうかを明確にする必要があります。

時間は見積もりに含まれるべきであるが、あなたは代わりに、テスターの時間を見積もるべきではないテスターは自分の時間を見積もる必要があります。

テスト時間を含めないことは、かかる合計時間の誤った推定値ですが、開発者の時間とテスターの時間は互換性がありません（特に、テスターとのイタレーションの後に並行して作業するため）、それらを個別に推定する必要があります。さらに、テスターが変更をテストするのに必要な時間を見積もる立場にありません。テストクルー自身がそれを行う必要があります。

カプセル化

ソフトウェア開発の観点と言語の観点からこれにアプローチします。

• あなたは大きなマシンの小さな歯車です。
• チームの外部から、チケットシステムはチームへのインターフェイス/ APIとして機能します
• チケットシステムを使用するビジネスユーザーは開発者ではありません

優れたソフトウェア設計から、できるだけ単純化してカプセル化する必要があります。

そのため、ビジネスユーザーの観点からプロセスを見ると、実際には2つのことしか気になりません。

1. いくらかかるでしょうか？
2. まだ終わってないか？

チームの内部プロセスをビジネスユーザーに知らせることは、不適切な管理です。public内部状態へのアクセスを与えることに似ています。

チームの内部状態を保護できなかった場合、他のチームがリソースを管理し、内部状態を混乱させてしまいます。