「それで、これはいつ行われるのですか？」を処理する最良の方法

スプリントの真ん中にある毎日のスタンドアップミーティング中に、デファクトプロジェクトマネージャー/スクラムマスターは通常、開発者に次のバージョンを尋ねます。

「それで、これはいつ行われるのですか？」

「では、今日の午後4時までにこのタスクを完了させることはできますか？」

「このサブタスクには何時間残っていますか？」

これは率直に言って非常に迷惑であり、物事をより速く終わらせません。その結果、開発者は多くのプレッシャーにさらされていると感じることが多く、スタンドアップはコラボレーションよりも戦場のように感じることがよくあります。

開発者として、これを処理する確かな方法は何ですか？

「それで、これはいつ行われるのですか？」を処理する最良の方法

「スプリントの終わりに」。

私はそれが卑劣な答えであることを理解していますが、そこにはいくつかの真実が隠されています。それは誰が質問しているのか、そしてなぜ彼らがその質問をしているのかによります。

プロジェクトマネージャーは、実際にそのような質問をするビジネスはありません。進行中のタスクに関する詳細情報が必要かどうかをスクラムマスターに尋ね、毎日のスタンドアップ以外で行う必要があります。

質問しているのがスクラムマスターである場合、おそらく彼らは、次のロードブロックに備えることができるように求めています。その場合は、正直に言ってください。

スクラムでは、チームは現在のスプリントに関連するストーリー（バンド外のホットフィックスではなく）について質問していると想定して、スプリントの最後まで特定のタスクやストーリーを完了する義務はありません。ストーリー内のタスクの締め切りはチームが所有しており、プロジェクトマネージャーからのプレッシャーを感じるべきではありません。

ただし、ソフトウェア開発は共同プロセスであるため、そのような質問に適切に対応することは合理的です。

ソリューション？あなたの視点から：スタンドアップ中であれば、できるだけ正直に、できるだけ短時間で答えてください。質問されているタスクに積極的に取り組んでいる場合は、いつでも「数時間かかると推定されるため、今日完了することができるかもしれません」という言葉に沿って何か言うことができます。あなたがそれに取り組んでいないのであれば、単純に「わからない、私はそれに取り掛かっていません。見積もりはまだかなり正確に思われます」。

彼らの視点から：彼らはあなたの答えを受け入れる必要があります。

「では、今日の午後4時までにこのタスクを完了させることはできますか？」

その答えは、ほとんどの場合「いいえ」です。スプリントの途中のタスクについて、1日の終わりに成果物をコミットする必要はまったくありません。タスクが今日の午後4時に終了するか、明日の午前9時に終了するかは、ストーリー全体がスプリントの終わりまでに終了する限り、無関係です。

「このサブタスクには何時間残っていますか？」

それは、尋ねるのに合理的な質問です。正直に答えてください。それはとても難しいことだと思います。そこに行ったことがある。開発者は本質的に楽観的だと思います。タスクを見て、「数時間しかかからない」と考え、それがわかるまでに1日が過ぎてしまいます。それがアジャイルが機能する理由です-私たちは見積もりの​​制限を認め、可能な限り最小のチャンクに物事を分解するために最善を尽くします。

スクラムマスターに、スプリントとスタンドアップミーティングの目的を明確にしてもらいます。スクラムを使用するほとんどすべての人は、スプリントの目的はスプリントの期間中に何が行われるかを決定することであり、私はスプリント中に何が原因であるかについて聞いたことがありません。

多分あなたはそれに参加する緊急事態が本当にスプリントとは何の関係もないです。スプリントの外でこれらの義務を負うチーム/開発者は、スプリント計画の一部としてこれを行う時間を含めないようにする必要があります。多分あなたは8時間の労働日を持っているかもしれませんが、あなたが火を消すために1〜2時間を費やしているなら、あなたはそれを見積もりの​​一部として含めることを期待することはできません。

スタンドアップミーティングに関する限り、ある種のサポートチケットシステムのように、特定の即時タスクがいつ完了するかを追跡する他のシステムを提案することができます。これらについては、スタンドアップ中に議論するべきではありません。

スクラムマスターを再訓練するか、そもそもなぜスクラムをやっているのかを考え直す必要があるようです。すべてのグループや状況に適しているわけではありません。一番上の誰かがそれに買いませんでした。

私はこのようなマイクロマネージメントを経験してきましたが、それをうまく処理した方法は、非常に透明性があり、コミュニケーションをとることです。マネージャーの自信を得るのに時間がかかりません。あなたは信頼を築き、彼らは後退します。時には、より広い空間と緯度を与えることさえあります。あなたの上司は不安を感じたり、コントロールできなくなったりしているかもしれません。明らかにそれは理想的ではありませんが、あなたはチームであり、すべて同じ結果を望んでいるはずです。幸運を。

「それは終わったときに行われます。」

開発者から完了の見積もりを取得しようとしても意味がありません。特に時間ベースの場合、見積もりは不正確です。さらに、管理職の人々はこれらの見積もりをコミットメントとして解釈する傾向があり、開発者が感じている悪影響をもたらします。

1つのオプションは、時間のコミットメントに関して質問に答えないようにすることです。

「このタスクは、A、B、Cを実行した後に実行されます。」

「わかりました。それにどのくらい時間がかかりますか？」

「一日の終わりに会います。」

会話を時間のコミットメントから実行する必要のあるものに変更することは、優位に立つのに役立ち、「完了するまでにかかる時間」は「完了するまでにかかる時間」よりも重要ではないことを示すことができます。

スクラムマスターに怖がらないでください。今後の作業について率直に率直に話します。彼女/彼に緊急度が何であるかなどの質問をします。なぜそれは4で行わなければならないのですか？本当に実行する必要がある場合は、他のタスクを後で実行する必要がある場合があります。トラスを構築する機会です。率直な答えは、後で言い訳をするよりは早いほうがよい。

管理が「ミクロ」であるほど、正確な予測を行うことが難しくなります。8時間のタスクが20個ある場合、それはそれぞれ8時間かかると合理的に見積もられているタスクであり、4週間、または多かれ少なかれ数日で完了する必要があります。私がそのようなタスクを1つ持っている場合、ばらつきはさらに大きくなります。

解決する問題が思ったよりはるかに簡単であることが判明した場合、そのようなタスクには10分かかることがあります。（私に起こった、私はかなり多くのコードを書く必要があると推定しました、そしてそれは誰かがすでに私が必要とするものを正確に書いたことが判明しました）。または、1週間かかる場合があります（修正が必要なライブラリのバグが原因でコードが機能しないため、さまざまな悪影響を及ぼす）。20のタスクでは、これらのバランスが取れています。1つのタスクではありません。

誰かがあなたに未来を予測するように求めています。それはできません。そして、単一のイベントを予測するように求められた、統計はあなたを助けません。このような質問をする人は「見積もる」の意味を理解していないので、「これは4時間で完了しますか？」ありそうもない」

これは良い質問です。ソフトウェア開発を除くすべての分野で専任のプロジェクトマネージャーとして10年の経験を持つ30年の経験を持つ誰かの観点から答えますが、最近、意図せずにソフトウェア開発に出くわしました。チーム全体で使用されている方法論と呼ばれる方法に関係なく、1日の終わりに、開発プロジェクトは、時間、予算、および品質の競合する制約内で目標を達成する必要があるというビジネスの意味で他のプロジェクトと同じです。 -そしてプロジェクトが実行されている間、ビジネスは動き続け、進化し続け、プロジェクトに変更を加える可能性が高くなります。したがって、目標と時間枠を設定し、それにコミットし、頻繁に、要求されたときに更新を提供できるようにする必要があります。私はしません

そうは言っても、私の経験では、ソフトウェア開発における時間の見積もりを特に困難にしているのは、開発プロジェクトには多くの未承認の領域が伴うということです。Project Management InstituteのProject Management Body of Knowledgeによると、「プロジェクト」の技術的な定義では、プロジェクトは一意である必要があります。それでも、ITにおける「プロジェクト」の大多数は、以前に考案された設計図と設計、および実装の実行図書の再実行にすぎません。ソフトウェア開発では、多くの開発を再利用可能にするフレームワークとさまざまな汎用デザインパターンがありますが、それでも各プロジェクトのコアは完全に一意です。

さらに、ほとんどの開発プロジェクトには他のシステムとの統合が必要であり、それをどれだけ迅速に実行できるかは大きな推測です。私が現在プロジェクトに取り組んでいるのは、私の元の時間の見積もりは、プログラムで操作する必要のある4つのシステムにはAPIがあるとの仮定に基づいていたためです。さらに、システムの1つはクラウドでホストされており、私の組織には、実行中の作業を禁止するポリシーがあります。誰がそれを予測できたか？

タイムフレームを危険にさらす発見がなされたため、遅延が発生した理由、予測できない理由などを十分に伝えることが重要です。

私はまた、与えられた時間枠が機能せず、それが多くの「より速い」ことになるように言われました。別のバリエーションは、追加の時間を与えられることなく、開発に注入するための変更のボート負荷を与えられています。物理学には物質を作成したり破壊したりすることはできないという法則があり、これは心の中で、薄い空気から時間を作成することもできないように思えます。開発を加速すると、リリースの品質、製品のサポート性、および/または製品の将来の進化に悪影響を与える可能性があります。

スケジュールに関するリクエストは、一般的なビジネス用語で回答する必要があります。「はい、私たちは以前にコミットされた時間枠を満たすために順調に進んでおり、それを危険にさらすような醸造の問題はありません。」時間をかけずに重要なスコープを追加する、または単に配信を加速するという要求は、「私たちにはそれが可能ですが、開発時間の多くが事前に行われるために本質的にバグのリスクがあることを知っているので、何らかの形であるべきです。バグを導入しないように、そして包括的にテストするように」彼らが「ただ単にテストを速くする」と応答すると、開発テストがアイドル時間を伴わないことを説明する応答が得られ、欠陥を見逃すリスクを導入することなく加速できます。

要約すると、リード、スクラムマスター、またはプロジェクトマネージャーだけでなく、すべての開発者がビジネスコンテキストでタスクについて話し合い、そのトレードオフを認識してプロジェクトパラメーターの変更について話し合う準備をすることを単に提案しています。結果になります。

作業が実行または完了すると、推定残り作業が更新されます。

- スクラムガイド、15ページ

各開発者は、チームが使用している生産性ツール（TFSなど）でタスクのステータスと推定残り時間を毎日更新する必要があります。

したがって、マネージャーへの簡単な答えは、マネージャーをタスクリストの「残り時間」列に導くことです。うまくいけば、彼は自分でこれらの番号にアクセスして、愚かな質問をするのをやめることができることを学びます。

上記の質問のいずれかを尋ねることによって。スクラムマスターが決定しようとしているのは、このスプリントに順調に進んでいることと、このタスクに対抗できるようにするためのブロッキングの問題があるかどうかです。

ストーリーポイントは工数とは相関していませんが、意図したものではありませんが、日付までに何かできるかどうかを尋ねることで、このタスクの競合を妨げているものは何なのかを尋ねています。あなたが何か質問する必要がある場合、私の見解では、彼の役割は、あなたがスプリントを競うことができることを確認することです、それは彼が本当に求めていることです...