開発者はタスクを評価するためにどのような方法を使用しますか?

こんにちは、みんな！開発を開始するために必要な理論は非常に広範囲に及びます。一部のスペシャリスト (Java やその他の言語のバックエンド開発者) はそれを多く持っていますが、他のスペシャリスト (たとえば、JavaScript - React Native のフロントエンド開発者) は少し少ないです。ただし、両者とも技術的な知識だけでなく、「組織的な」知識も豊富に蓄えている必要があります。この「組織的」知識は、フロントエンド開発者とバックエンド開発者にとっての交差点の 1 つです。 今日は、そのような非技術的、組織的な知識の 1 つの側面、つまりタスクの評価(見積もり)について話したいと思います。また、私はアジャイル方法論 (実際、最も一般的であると考えられています)のみで作業したため、そのサブパートであるスクラムにおいて、スクラムのコンテキストでタスク評価を検討します。すぐに言っておきますが、評価（推定とも呼ばれます）は難しいです。開発者である私個人にとって、これはこの仕事の中で最も困難かつ望ましくない側面の 1 つです。タスクの評価に影響を与える可能性がある、考慮すべきさまざまな要素が多数あります。同時に、さらなる開発の計画はあなたの予測に基づいて行われます。

正しく評価されなかったらどうしますか？

開発者が最終的に費やす時間よりもはるかに多くの時間をタスクに費やした場合、見積もりが非常に不正確であるため、開発者は最高のスペシャリストではないと思われる可能性があります。いわば、空の指です。同時に、開発者が予測された時間内に投資しない場合、顧客の製品/新機能のリリース計画が危険にさらされます。これはビジネスであり、ビジネスとはお金を意味します。そのようなパンクを好む顧客はほとんどいません。 実はこれが、私が見積もりを好まない理由なのです。タスクを完了する正確な時間を判断するのが非常に難しい場合があるからです。

時間はどのように評価されますか?

原則として、見積もりは時間またはストーリー ポイントで実行されます。個人的には、ストーリー ポイントでの評価プロセスに非常に近いです。時計が物理的なものであれば、誤解される可能性がありますが、ストーリー ポイントは少し別のもの、より抽象的なものになります。通常、ソフトウェア開発チームは、時間、日、週、月などの時間形式で見積もりを出します。このような時間の見積もりは、主に個人的な経験、推測、または直感に基づいています。この場合、開発者は単にタスクを見て、どれくらい時間がかかるかを見積もって声を出します。その結果、作業の完了期限に影響を与える可能性のある要因が多すぎるため、正確であることはほとんどありません。したがって、アジャイル手法に従って作業する多くのチームはストーリー ポイントを使用します。それを理解しましょう。

ストーリーポイントとは

ストーリー ポイントは、特定の作業領域 (機能) を完全に実装するために必要な総労力の評価を表す測定単位です。つまり、これは非常に複雑です。チームは、作業の複雑さ、作業範囲、リスクまたは不確実性に基づいてストーリー ポイントを割り当てます。通常、これらの値は、作業をより効率的に小さな部分に分割するために割り当てられ、それによって不確実性が排除されます。これにより、時間の経過とともに、チームが一定期間内に何を達成できるかを理解し、次の作業領域をより正確に計画するのに役立ちます。これは完全に直観に反しているように思えるかもしれませんが、この抽象化は実際には非常に便利です。これにより、チームは作業の複雑さについてより厳しい決定を下すようになります。計画にストーリー ポイントを使用する理由をいくつか見てみましょう。

• 時間間隔の推定の不正確さを回避できます。
• 時間をかけて見積もるのとは異なり、チームメンバーと顧客間のコミュニケーション、チームでのさまざまな議論や計画、予期せぬ状況など、諸経費をより適切に考慮することができます。
• 各チームは異なるスケールで作業を採点します。つまり、チームのスピード (ポイントで測定) も異なります。
• 各ストーリー ポイントを割り当てるスケールを定義することで、大きな議論を起こさずにポイントを迅速に配布できます。

ストーリーポイントを使用しない方法

残念ながら、ストーリー ポイントは他の目的に使用されることがよくあります。ストーリー ポイントは、人々を評価したり、詳細な期限やリソースを定義したりするために使用されたり、パフォーマンスの尺度として誤って取られたりする場合に欠陥が生じる可能性があります。代わりに、チームはそれらを使用して、各タスクの作業の量と複雑さを理解し、優先順位を付ける必要があります。スプリントが終了する前に完了できるように、より難しいと評価された部分を最初に実行する必要がある可能性がありますが、簡単な部分は後回しにすることができます。スクラム方法論におけるスプリントとは何かを思い出してください。 この期間の長さは、開発の開始時にチームと顧客の間の合意によって決定されます。これは、2 週間、1 か月、またはその他の期間である可能性があります。通常、タスクの見積もりはスプリントの開始時に実行され、完了した作業が顧客に引き渡されるスプリントの終わりまでに完了できる作業量を計画します。 製品開発の進捗状況を確認し、顧客からのフィードバックを受け取り、顧客のビジョンに従ってプロジェクトの開発を調整するのに役立ちます。それでも、少し話がそれました。推定の話に戻りましょう。たった 1 人の開発者がタスクを評価するのは主観的すぎます。したがって、原則として、これはチームワークです。チーム評価にはさまざまなテクニックがあります。今日はその中で最もよく使われるスクラムポーカーを見ていきます。この手法には、このスクラム ポーカーのリーダーのようなマネージャーが必要です。これは、スクラム マスター( PM)を専門とする人である可能性があります。

スクラムポーカーとは

スクラム ポーカー(またはプランニング ポーカー) は、合意に達することに基づく評価手法です。主に、今後の作業の複雑さ、またはソフトウェア開発中に解決すべきタスクの相対的な量を評価するために使用されます。スクラム ポーカーは開発において一般的な手法であり、それがどのような種類の猛獣であるかを確実に知る必要があることにすぐに気づきます。このプロセスでは、通常、特定のタスクのチーム評価を組織できる、ある種のアプリケーションまたは Web サイトを使用します。これはどうして起こるのでしょうか? チームはバックログ項目 (新しいタスク、機能) を取り上げ、それに関連する可能性のある落とし穴やその他のニュアンスについて簡単に議論します。次に、各参加者は、難易度の評価を表す数字が記載されたカードを選択します。ああ、推定するときに使用されるのは通常の級数ではなく、フィボナッチ数です。 フィボナッチ数がスクラム ポーカーで非常に人気があるのは、それらの間の差が時間の経過とともに増加するためです (ピラミッド レベルを彷彿とさせます)。非常に複雑なタスクがあり、少数のストーリー ポイントを達成することはできません。 珍しいカードの説明:

エンドポイントの数が不明です

無限に長いタスク

休みたい

さらにまれな推定方法:

• Tシャツのサイズ - S、M、L、XL
• または犬の場合 - チワワ、パグ、ダックスフント、ブルドッグなど (私の意見では、これはタスクを評価するための最も奇妙な単位です =D)

次に、チームは、同じ問題に対してさまざまな開発者が出した見積もりを比較し、彼らが同意すれば、素晴らしい結果が得られます。そうでない場合には、評価（主張）の違いが生じた理由を議論する必要がある。この後、私たちは共同で単一の見積もりを導き出すことができ、プラスマイナスを問わず誰もがそれに同意するでしょう。では、なぜ本格的なソフトウェア プロジェクトの計画にポーカーが使用されるのでしょうか? やっぱりこれはなんだか変ですね。実際、このようなゲーミフィケーションは、チームメンバーが独立して考えることを奨励し、チームメイトと同時に結果を示すよう求めます。これにより、他のチームメンバーの意見に依存することがなくなります。そうしないと、経験の浅い開発者が経験豊富なチーム メンバーの評価を見て依存することになり、自分自身の評価の有用性が無効になってしまいます。しかし、結果も同時に公開されるため、これは本質的に不可能です。スクラム ポーカー スケジューリング アプリの例は、Atlassian から提供されています。

課題評価の例

チームがストーリー ポイントでの評価の特定の尺度を特定したと想像してみましょう。 スクラム ポーカーはタスクから開始され、次のように評価します。

• これまでに同様の機能の実装に取り​​組んだことがない - +3
• 中規模のタスクの機能 - +2
• タスクの実装は複雑です - +3
• この機能のテスト作成の複雑さ - +3

その結果、あなたは 11 のストーリー ポイントを獲得しますが、そのようなカードがないため、13 を提供します。あなたの別の同僚がこのタスクを評価します。

• 以前は同様の問題で作業していました - +1
• 中規模のタスクの機能 - +2
• タスクの実装の複雑さは平均 - +2
• この機能のテスト作成の平均複雑さ - +2

その結果、彼は 7 のストーリー ポイントを獲得しましたが、フィボナッチ数にはそのようなものはなく、可能な限り最も近い数字である 8 のカードを置きました。したがって、他のチーム メンバーは主観的な見解に基づいて見積もりを出します。次に、結果を示し、8 を与えた 1 人の開発者を除いて、ほぼ全員の同僚が 13 と見積もったことを発見しました。この場合、彼に発言権が与えられ、彼は理由を述べます。そして、それらは、たとえば次のようなものです。彼は以前にも同じ問題に取り組んでいましたが、見た目ほど難しくはなく、最終的には残りのチームメンバーを説得して、解決策を 13 ストーリーから 8 ストーリーに変更しました。と指摘し、この仕事を引き受ける人がそれを解決するのを手伝うと述べた。あるいは、最終的には自分でやるだろう。そして一般的に、他の人が彼の議論に耳を傾けるかどうかは問題ではありません。何らかの方法でこのタスクに評価が割り当てられ、チームは次のタスクに慣れるために進むからです。 最初は見積もりが不正確になり、次の期間 (スプリント) に実行する予定の作業量の見積もりも不正確になります。結局のところ、これらの推定は推定に基づいて正確に行われます。しばらくしてから (約 3 か月)、チームはタスクをより正確に見積もり始め、スプリントごとにチームが完了できる平均作業量が見えるようになります。しかし、これは作業範囲の一般的な計画であり、時間の問題であり、この場合、影響を与えるさまざまな要因が存在する可能性があります。たとえば、開発者の一人が 2 週間休暇を取ったとします。つまり、一定量の計画された作業 (計画された機能) を取り消す必要があります。または、新しい開発者がチームにやって来ましたが、彼を全面的に信頼する必要はありません。なぜなら... オンボーディングと呼ばれる、プロジェクトに適応するのに必要な時間を考慮する必要があります。プロジェクトの複雑さに応じて、これは 2 週間、またはプラスマイナス 1 週間かかる場合があります。 今日はここまでです。問題推定などの非技術的な部分の知識が少しでも向上できれば幸いです。このトピックとスクラムの詳細をさらに詳しく知りたい場合は、ジェフ・サザーランド著「SCRUM」という本を読むことを強くお勧めします。結果については保証できません。おそらくその後はスクラム マスターになりたいという迷惑な願望が生まれるでしょう =D