期限を守る: 開発者が労力を見積もるために使用する方法

こんにちは、みんな！ソフトウェア開発を始めるには、膨大な量の理論を知っておく必要があります。一部の専門家 (たとえば、Java やその他の言語を使用するバックエンド開発者) はそれについて詳しく知っていますが、他の専門家 (たとえば、JavaScript や React Native を使用するフロントエンド開発者) はあまり詳しくない場合があります。そうは言っても、どちらのグループも、技術的な知識だけでなく、「組織的な」知識も大量に持っている必要があります。この「組織的」知識は、フロントエンド開発者とバックエンド開発者にとって重複する領域の 1 つです。 今日は、この非技術的な組織知識の一側面について話したいと思います。今日は工数の見積もりについてお話します。アジャイル手法の使用経験しかないため(最も人気があると考えられています)、より具体的には スクラム フレームワークについて、スクラムのコンテキストで工数の見積もりを検討します。初めに、労力の見積もりは難しいと言わざるを得ません。私にとって、これは開発者としての仕事の中で最も困難で不快な側面の 1 つです。タスクに必要な作業量の見積もりに影響を与える可能性がある、考慮すべきさまざまな要因が多数あります。さらに、将来の開発計画はあなたの見積もりに基づいて行われます。

間違った見積もりを出した場合はどうなりますか?

開発者が、最終的にそのタスクに費やされる時間よりもはるかに長い時間をタスクに見積もった場合、その見積が非常に不正確であるため、開発者の専門知識が疑問視される可能性があります。言い換えれば、それは勝手な推測でした。同時に、開発者が予測された時間内に作業を完了できなかった場合、製品または新機能をリリースするという顧客の計画が危うくなります。これはビジネスであり、ビジネスはお金です。このようなスリップを喜ぶ顧客はほとんどいないでしょう。実際、それが私が見積もりが好きではない理由です。タスクを完了するのに必要な時間を正確に判断するのが非常に難しい場合があるからです。

時間の見積もりの​​立て方

原則として、見積もりは時間またはストーリーポイントで行われます。私の個人的な好みは、ストーリー ポイントを使用して推定プロセスを実行することです。具体的な物理的オブジェクトについては誤解しにくいですが、ストーリー ポイントはもう少し抽象的です。ソフトウェア開発チームは通常、時間、日、週、月などの時間として見積もりを提示します。これらの時間の見積もりは、主に個人的な経験、推測、直感に基づいています。この場合、開発者は単にタスクを見て、どれくらいの時間がかかるかについての推測を表明します。その結果、作業期間に影響を与える可能性のある要因が多すぎるため、これらの見積もりが正確になることはほとんどありません。アジャイル手法を使用する多くのチームがストーリー ポイントも使用するのはそのためです。飛び込んでみましょう！

ストーリーポイントとは何ですか?

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

• 不正確な時間の見積もりを回避できます。
• 時間単位で作成される見積もりとは異なり、ストーリー ポイントを使用すると、チーム メンバーと顧客間のコミュニケーション、チームのさまざまなディスカッションや計画活動、予期せぬ状況などの諸経費を考慮することができます。
• 各チームは異なる尺度を使用して自分たちの作業を見積もります。つまり、チームの能力 (ポイントで測定) が異なります。
• 各ストーリー ポイントを割り当てるスケールを定義することで、多くの議論を起こさずに迅速にポイントを割り当てることができます。

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

残念なことに、ストーリー ポイントは悪用されることがよくあります。ストーリー ポイントは、人々を評価したり、詳細な期限やリソースを定義したりするために使用されたり、パフォーマンスの尺度と誤解されたりすると、誤解を招く可能性があります。代わりに、チームはこれらを使用して、各タスクの範囲/複雑さを理解し、優先順位を設定する必要があります。おそらく、より難しいと思われる部分に最初に取り組む必要があるため、スプリントが終了する前に完了でき、簡単なタスクは後回しになる可能性があります。スクラム方法論におけるスプリントとは何かを思い出してください。 この期間の長さは開発の開始時に決定され、チームと顧客の間で合意されます。これは、2 週間、1 か月、またはその他の期間にすることができます。原則として、工数の見積もりは各スプリントの開始時に行われ、完了した作業が顧客に納品されるスプリントの終わりまでに完了できる作業を計画します。 デモは、製品開発の進捗状況を確認し、顧客からフィードバックを受け取り、顧客のビジョンに従ってプロジェクトの軌道を調整するのに役立ちます。しかし、少し話がそれました。見積もりの​​話に戻りましょう。1 人の開発者にすべてのタスクの見積もりを提供させるのは主観的すぎます。したがって、このプロセスは通常、チームの取り組みとなります。チームが見積もりを生成するために使用できるテクニックは数多くあります。今日は最も人気のあるテクニック、スクラム ポーカーについて見ていきます。このテクニックには、スクラム ポーカーのモデレーターとして機能するマネージャーが必要です。これは、スクラム マスターまたは場合によってはPMである可能性があります。

スクラムポーカーとは何ですか?

スクラム ポーカー、またはプランニング ポーカーは、合意に達することに基づく見積もり手法です。これは主に、今後の作業の複雑さ、またはソフトウェア開発タスクの相対的なサイズを見積もるために使用されます。すぐに言うよ、スクラムポーカーは一般的なソフトウェア開発手法であり、それが何であるかを知っておく必要があります。通常、チームによる特定のタスクの見積もりの​​共同作成を促進するために、アプリまたは Web サイトが関与します。これはどうして起こるのでしょうか? チームはバックログから何か (新しいタスク、いくつかの機能) を取り出し、考えられる落とし穴やそれに関連するその他のニュアンスについて簡単に議論します。次に、各参加者は、複雑さの見積もりを反映する番号が記載されたカードを選択します。ああ、もう 1 つ、これらの推定を行う際には、通常の数値ではなくフィボナッチ数列の数値を使用します。 フィボナッチ数はスクラム ポーカーで人気がありますなぜなら、それらの間のギャップはますます大きくなるからです（ピラミッドのレベルに似ています）。一部のタスクは非常に複雑なので、少数のストーリー ポイントでは解決できません。 次のような意味を持つ珍しいカードがいくつかあります。

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

無限に長いタスク

休みたい

あまり一般的ではない推定方法では、次のものが使用されます。

• Tシャツのサイズ — S、M、L、XL
• 犬種 — チワワ、パグ、ダックスフント、ブルドッグなど (個人的には、これは労力の見積もりの​​最も奇妙な測定単位だと思います =D)

次にチームは、同じタスクに対してさまざまな開発者が出した見積もりを比較します。彼らが同意するなら、それは素晴らしいことです！そうでない場合は、異なる推定値の理由 (議論) を議論する必要があります。その後、チームは協力して、多かれ少なかれ誰もが受け入れる単一の見積もりを作成します。では、なぜ本格的なソフトウェア プロジェクトの計画にポーカーが使用されるのでしょうか? これは奇妙であることを認めなければなりません。実際、この種のゲーミフィケーションは、チーム メンバーが独立して考えることを奨励し、チームメイトと同時に自分の見積もりを明らかにするように促します。これにより、一部のチーム メンバーが他のメンバーの意見に依存する状況が生じるのを回避できます。この方法で行われなかった場合、経験の浅い開発者は、経験豊富なチーム メンバーが提供する見積もりを見て、それに集中することになります。そうなると、彼ら自身の推定値はあまり役に立たなくなります。しかし、同時に見積もりを示すと、これは本質的に不可能になります。アトラシアンのオファー計画プロセスで使用する スクラム ポーカー アプリ。

工数見積もりの​​例

チームがストーリー ポイントを見積もりに割り当てるために次のスケールを確立したとします。 スクラム ポーカーはタスクごとにプレイされ、次のように見積もりを提供します。

• これまでに同様の機能を実装したことがありません: +3
• 機能のサイズは平均的です: +2
• 実装は非常に複雑になります: +3
• 機能のテストの作成は非常に複雑になります: +3

各コンポーネントを合計すると、合計 11 のストーリー ポイントが得られますが、そのようなカードはないため、13 を提案します。同僚は、このタスクについて次の見積もりを提案します。

• 彼は以前にも同様のタスクに取り組んだことがあります: +1
• 機能のサイズは平均的です: +2
• 実装の複雑さは平均的に +2 になります。
• 機能のテストの作成は、平均的な複雑さ: +2 になります。

彼の中間結果は 7 ストーリー ポイントですが、その数値はフィボナッチ数列に存在しないため、最も近い数値である 8 を使用してカードを提出します。他のチーム メンバーも主観的な見解に基づいて推定を行います。次に、全員がカードを見せると、8 を提案した 1 人の開発者を除いて、ほぼ全員の同僚が 13 と見積もったことがわかります。この場合、彼は、より低い見積の理由について話すことが許可されています。彼が次のような正当化を提案したとします。彼は以前に同じタスクに取り組んでいましたが、それは思っているほど難しくありませんでした。最終的に、彼はチームの残りのメンバーに、ストーリー ポイントを 13 から 8 に変更するよう説得し、最終的にこのタスクを引き受ける人を助けると述べました。あるいは、彼自身がそれを行うかもしれない。いずれにせよ、そうではありません 他の人が彼の主張を受け入れるかどうかは問題ではありません。何らかの方法でそのタスクに見積もりが割り当てられ、チームは次のタスクの検討に進むからです。最初は、次の期間 (スプリント) で実行する予定の作業量の見積もりと同様に、見積もりも不正確になります。結局のところ、これらの見積もりは見積もりを使用して行われたものです。しばらく後、おそらく 3 か月後、チームはタスクに必要な時間をより正確に見積もるようになり、チームがスプリントで実行できる平均作業量が明らかになります。しかし、これは作業範囲の全体的な計画を立てるプロセスです。主に時間に焦点を当てますが、この場合、関連するさまざまな要因が存在する可能性があります。たとえば、開発者が 2 週間休暇を取ったとします。計画された作業 (計画された機能) を一定量削減する必要があります。または、新しい開発者がチームに加わったが、まだ完全には理解できていないため、彼女がプロジェクトに慣れるまでの時間を与える必要があるとします。オンボーディングプロセス。プロジェクトの複雑さに応じて、これには 2 週間かかる場合もあれば、1 週間かかる場合もあります。それが今日のすべてです！ソフトウェア開発に必要な非技術的な側面である工数の見積もりに関する知識が少しでも向上したことを願っています。このトピックとスクラムの詳細をさらに詳しく知りたい場合は、ジェフ・サザーランド著『SCRUM』を読むことを強くお勧めします。結果については約束できません。読んだ後はスクラム マスターになりたいという迷惑な欲求が湧いてくるでしょう =D