アジャイルストーリーポイントと時間：ソフトウェア開発をより適切に見積もる方法
公開: 2021-10-05ソフトウェア開発プロセスに頭を悩ませることは難しい場合があります。 アイデアを思いつき、それを開発者にアプローチするとき、最初に尋ねる2つのことは、実装にかかる費用と構築にかかる時間です。 見積もりは、アプリ開発の最初のステップの1つです。
この記事では、最新のソフトウェア開発で最も人気のある2つの推定モデルであるアジャイルストーリーポイントと時間の比較を行います。
アジャイルで時間を見積もる方法を学び、両方の見積りモデルの要点を理解し、それらの違いを理解し、開発者がどちらか一方を選択する理由を理解するために読んでください。
時間は非常に理解しやすく、長い間ソフトウェア開発の主要な見積もりモデルでした。 工数または労働時間とも呼ばれる時間は、開発者がプロジェクトに費やす時間数です。
では、ストーリーポイントとは何ですか。また、単純で単純な推定モデルがすでにあるのに、なぜそれらが出現したのでしょうか。
コンテンツ：
- ストーリーポイントとは正確には何ですか？
- アジャイルでストーリーポイントが計算される方法は次のとおりです
- ストーリーポイントで見積もる利点
- ストーリーポイントで見積もるデメリット
- 時間単位で見積もる利点
- 時間単位で見積もるデメリット
- ストーリーポイントを時間に変換できますか？
- ストーリーポイントと時間：ソフトウェア開発のために何を選択するか？
ストーリーポイントとは正確には何ですか？
ストーリーポイントは、アジャイルとスクラムに固有の相対的な推定モデルです。 彼らは、開発の3つの側面に取り組むことにより、製品を構築するための努力を見積もっています。
製品に必要な作業量
製品の機能の複雑さ
開発に影響を与える可能性のあるリスクと不確実性
プロジェクト評価の最初の段階で、開発者は製品に含まれる最小で最も単純なユーザーストーリー（たとえば、サインアップユーザーストーリー）を選択し、それを1ポイントのユーザーストーリーとして設定します。 これが基本ストーリーです。複雑さの比較に使用されるユーザーストーリーです。 他のすべてのユーザーストーリーには、ベースストーリーと比較して開発がどれほど複雑であるかに基づいて、いくつかのストーリーポイントが割り当てられます。
一見シンプルに見えますが、各ストーリーのストーリーポイントの数は誰が決めるのでしょうか。
アジャイルでストーリーポイントが計算される方法は次のとおりです
時間と同様に、製品に取り組む人々は通常、開発のストーリーポイントを見積もります。 ただし、推定プロセスはストーリーポイントによってわずかに異なります。
ストーリーポイントをユーザーストーリーに割り当てるには、複数の開発者が関与します。 少なくとも2つあるはずですが、会社はすべての開発者に、業界がPlanningPokerと呼んでいるものをプレイすることで貢献するように依頼できます。 ゲームのルールは次のとおりです。
各開発者は、プランニングポーカーカードのセットを入手します。
開発者はユーザーストーリーを選択し、その複雑さと必要な開発作業について話し合います。
各開発者は、ストーリーに割り当てるポイント数に対応するカードを提示します。
ストーリーポイントの推定値が同じである場合、推定ポイント数がストーリーに割り当てられます。
提案されたストーリーポイントが異なる場合、開発者は、過半数によって承認されたポイントの数を思い付くまで、ユーザーストーリーについて話し合います。
開発者は次のユーザーストーリーを選択します。
手順3〜5を繰り返します。
私たちの活動がすべてリモートになったとき、このプロセスは変更されました。 カードや会議の代わりに、ストーリーのポイントはオンラインディスカッション、ズーム会議、またはメッセンジャーで決定されます。
これは次のようになります。
もちろん、これはストーリーポイントの見積もりに関与するすべての開発者がプロジェクトに取り組むことを意味するわけではありません。 しかし、ストーリーポイントシステムの主な利点は、問題のプロジェクトだけでなく、同様の機能を備えた将来のプロジェクトでも使用できる、多かれ少なかれ普遍的なフレームワークを作成することです。
ストーリーポイントを推定するために頻繁に使用される2つのオプションがあります。 ポイントを割り当てることができます：
任意の整数を使用（1、2、3…13、14、15など）
フィボナッチ数列の数字を使用する（1、2、3、5、8、13…55、89、144など）
フィボナッチ数列は、近似の余地がいくらか残っているため、開発を推定するためのより便利なオプションです。 数値次数モデルは、便利な比較には少し正確すぎます。
開発中およびプロジェクト間で、ユーザーストーリーが当初の見積もりよりも複雑になったり、複雑になったりした場合、割り当てられたストーリーポイントが変更される可能性があります。
ストーリーポイントで見積もる利点
ストーリーポイントを割り当てるプロセスが少し複雑に見える場合は、それがあなたを失望させないでください。 ストーリーポイントを使用したキャパシティプランニングには利点があります。
1.ストーリーポイントは開発者に依存しません
各ストーリーのストーリーポイントは、交渉で複数の開発者によって割り当てられます。その理由は、特定の製品と特定の開発者1人だけでなく、「平均して」番号が割り当てられるためです。 なぜこれが良いことなのですか？
物事は起こります。 場合によっては、プロジェクトの開発者がプロジェクトを離れて置き換えられることがあります。 たぶん、彼らは病気になるか、育児休暇またはサバティカルを取ることを決定するか、単に会社を辞めるでしょう。 たぶん、彼らはプロジェクトの資格が不足しているか、資格が過剰であることが判明するでしょう。
それらが交換されると、新しい開発者は異なる作業速度を持つ可能性があり、それは製品を作成するために必要な労働時間を再見積もることにつながります。
ストーリーポイントはこの問題を最小限に抑えます。 いくつかの異なる開発者によって割り当てられ、特定のユーザーストーリーがどれほど複雑であるかについての一般的な見方を提供します。 ストーリーポイントは、特定の会社のすべての開発者に役立ちます。 （ただし、ストーリーポイントの見積もりは、会社によって正しくないことに注意してください。）
2.ストーリーポイントにより、開発時間の再計算が容易になります
ストーリーポイントを使用したアジャイル時間の見積もりでは、チームは速度という用語を使用して、1回のスプリントでリリースされたストーリーポイントの数を指します。
チームは常に速度を監視しており、最初はかなり変動します。 チームは、1週間で5ストーリーポイント、次の週で20ストーリーポイントに相当する機能をリリースできます。 しかし、それはほんの始まりに過ぎません。 プロジェクトが進むにつれて、速度グラフは均等になります。
チームメンバーが変更された場合、時間の経過とともに、チームメンバーが関与する各タスクを再見積もりして、期限を調整する必要があります。 ストーリーポイントの場合、これは不要です。チームは、全体的な速度の変化を知ることにより、次のスプリントの後にプロジェクトの期限を調整できます。
ストーリーポイントはチーム全体のパフォーマンスを評価し、タスクごとに再評価する必要をなくします。
3.ストーリーポイントはチームのパフォーマンスを監視するのに適しています
チームが同じようなプロジェクトやタスクに異なる時間に取り組んでいる場合、速度は各チームの進捗状況を簡単に示すことができます。 それらはどのくらい改善されましたか？ どのチームまたは開発者が苦労し、追加のトレーニングが必要になる可能性がありますか？ 学習曲線は何ですか？ たぶん、別のチームの方がパフォーマンスが良いでしょうか？
Velocityは、その場でだけでなく継続的にチームのパフォーマンスを評価するための優れたツールです。
4.ストーリーポイントを使用した起動時間の見積もりがより正確になります
チームは速度を追跡することで、1回のスプリントでリリースできるストーリーポイントの数を高精度で把握します。 アプリ開発チームが速度を計算するのには少し時間がかかりますが、一度計算されると、リリース予定日は簡単に予測できます。
さらに、チームメンバー、要件、または機能の数/複雑さの変更は、再見積もりで多くの苦労を引き起こしません。
5.ストーリーポイントを将来のプロジェクトに再利用して、見積もりをスピードアップできます
企業が特定のニッチ（または複数）に精通し、同様の機能セットを備えた複数の製品を構築することは珍しいことではありません。 ストーリーポイントで見積もられたプロジェクトを1つでも完了した後、開発者はこの見積もりを参照して新しいプロジェクトを見つけることができます。 これにより、見積もりにかかる時間が短縮されます。
ただし、状況は変化する可能性があるため、各プロジェクトの速度を追跡し続けることが重要です。
6.ストーリーポイントはチームワークを強化します
従来、開発会社には複数の開発者チームがあり、それぞれが別々のプロジェクトに取り組んでいます。 時間単位で見積もる場合、見積もりを行うのはプロジェクトに取り組んでいる開発者です。 これは一般的に良いことです。なぜなら、それをしている人よりも何かにかかる時間を誰がよく知っているのでしょうか。
ただし、ストーリーポイントの複雑さを見積もることは、同じ分野の開発者が協力する機会を提供します。これは、他の方法ではめったに起こりません。 この種のチームワークは、経験を共有し、お互いにやる気を起こさせる絶好の機会になります。
ストーリーポイントで見積もるデメリット
議論には常に反対側があります。それは、優れたシステムがどのように生まれるかということです。 複雑さに基づく見積もりにも欠点があり、各チームは自分たちが利点を上回っているかどうかを自分で判断する必要があります。
1.ストーリーポイントは複数の開発者が割り当てる必要があります
ストーリーポイントモデルのセールスポイントは、その客観性と将来の見積もりに対する価値です。 しかし、それが真実であるためには、見積もりは複数の開発者によって行われなければなりません。 チームが1つしかない中小企業や、ある分野のスペシャリストが1人だけの企業（つまり、デザイナーまたはiOS開発者が1人だけ）の場合、ストーリーポイントはそれほど多くの利点をもたらしません。 このような中小企業は、伝統的に推定モデルとして労働時間を選択します。
2.ストーリーポイントの見積もりには、かなりのバックログが必要です
ストーリーポイントの可能性を最大限に引き出すには、チームはかなりの時間を費やす必要があります。 チームがこれまで取り組んだことがない（またはフルタイムで取り組んだことがない）機能を備えたプロジェクトに取り組んでいる場合、最初の2〜3回のスプリントはパフォーマンスの観点から予測するのが困難です。 確かに、チームのバックログアイテムが多いほど、統計データが豊富であるため、チームの見積もりはより正確になる可能性があります。 しかし、ストーリーポイントはすぐに使えるシステムではありません。
3.ストーリーポイントは予算編成にとってより複雑です
ストーリーポイントは、正確な期限と発売日を設定するのに最適です。これは、開発者とクライアントのマーケティングにとって重要な場合があります。 ただし、アプリ開発コストの見積もりに関しては、あまり便利ではありません。
重要なのは、開発者はコードの記述（または設計の作成やテスト）だけでなく、プロジェクトに時間を費やしているということです。 チーム内やクライアントとの調査、話し合い、変更などにいくらかの時間が費やされます。ストーリーポイントの見積もりに費やされる時間もプロジェクトに費やされる時間ですが、ストーリーごとのポイントには含まれません。
ストーリーポイントで見積もる場合の予算編成は可能ですが、通常は、プロジェクトに費やした時間とお金を同等にする方が速くて簡単です。
4.速度はチームごとに計算されます
つまり、チームがプロジェクト間で混在している場合は、開発者の組み合わせごとに速度を個別に計算する必要があります。 したがって、あるチームの見積もりが別のチームに当てはまるとは限らず、1人のチームメンバーを変更しただけでも、以前の見積もりが無効になる可能性があります。
一方、複雑さの見積もりを使用して、最もパフォーマンスの高い組み合わせを見つけることができます。 ただし、時間がかかります。
時間単位で見積もる利点
一部のアジャイルチームはストーリーポイントを使用していますが、多くのチームはまだ労働時間から切り替えていません。 それには重要な理由があります。 それらもカバーしましょう。
1.時間はおなじみのモデルです
イノベーションは素晴らしいですが、時間がかかります。 開発者とそのクライアントは同様に、労働時間の見積もりに精通しています。 多くの人にとって、アイデアは「壊れていない場合は修正しないでください」です。 システムが実行可能な見積もりを提供する限り、なぜ他のものに切り替えるのですか？
見積もりの精度の違いは、一部の開発者が物事のやり方を変更するのに十分な大きさではない可能性があります。
2.クライアントは通常何時間も支払います
これは少し詳しく説明する必要があります。 クライアントにとって、複雑さに基づく見積もりは混乱を招く可能性があります。 さらに、クライアントにとって予算が発売日よりも重要である場合（多くの場合そうです）、ストーリーポイントはクライアントにとって重要ではありません。
3.時間ベースの見積もりは1人の開発者が行うことができます
小規模なチームやフリーランサーの場合、ストーリーポイントは複数の視点を必要とするため、ほとんど役に立ちません。 参照がなければ、ストーリーポイントでの見積もりは不必要な手間です。
一方、時間は、プロジェクトに取り組んでいる開発者に、かなり正確な見積もりを自分で行う方法を提供します。
チームの速度についても同じことが言えます。 フリーランサーや部分的なアウトソーシングのように、チームが毎回変わる場合、速度を監視することはほとんど意味がありません。 ここでは、時間ベースの見積もりがより適切な選択です。
時間単位で見積もるデメリット
チームが推定モデルとしての時間の使用をやめることを決定する理由は次のとおりです。
1.見積もりに単独で責任を持つことは、多くのプレッシャーです。
一方では、自分だけに頼っているので、自分の時間要件を見積もるのは簡単です。
一方、見積もりを達成できない場合、それは大きな打撃です。 タスクの開始を待っているチームがあなたのタスクの完了に依存している場合はさらにそうです。
さらに、あなた自身が約束したものを提供するというプレッシャーによって引き起こされるストレスは、他の点では順調に進んでいるタスクを混乱させる可能性があります。
2. 1人の開発者の見積もりは、常にチームの見積もりよりも正確ではありません。
個々の見積もりは主観的であり、見積もり担当者の感情的および心理的状況に関連付けられています。
一部の開発者は、自分自身を過大評価し、後で維持するのに苦労する時間枠を設定する傾向があります。 これは開発を混乱させるだけでなく（罰金がある場合はチームに余分なコストをかける） 、開発者にストレスや燃え尽き症候群を引き起こします。
他の人は自分のスキルを過小評価し、客観的に必要以上に開発を長引かせます。 不安や作業の見直し、チェック、再チェックの習慣により、開発の期限が後日になることがよくあります。また、タスクが期限前に完了することはめったにありません。 チームの入力により、より客観的な見積もりが可能になります。
3.タスクが大きいほど、時間単位で見積もるのが難しくなります
これは、開発以外の状況とも相関関係があります。 3ページの大学の小冊子を読むのにどれくらいの時間がかかるかを言うのは簡単ですが、戦争と平和を終えるのにどれくらいの時間がかかるかを見積もるのは難しいです。
同じことが開発にも当てはまります。 小さなタスクは、ある程度の経験を持つ開発者にとっては簡単に見積もることができます。 ただし、タスクが大きいほど、プロジェクトの内部と外部の両方で発生することが多くなり、開発に影響を与える可能性があります。 時間ベースの見積もりでは、ストーリーポイントのマージンが提供されないため、見積もりが大まかになります。
4.柔軟性がほとんどない
時間ベースの見積もりは開発者ベースです。 製品に取り組んでいる1人のチームメンバーがプロジェクトの途中で変更した場合、チームは、まだ開発中または将来のスプリントに予定されている、影響を受けるすべてのユーザーストーリーを再計算する必要があります。 プロジェクトの段階や、元の開発者と新しい開発者のスキルの違いによっては、これは大変な作業になる可能性があります。 時間ベースの時間見積もりは非常に厳密です。
ストーリーポイントを時間に変換できますか？
クライアントは、ストーリーポイントを見積もるチームに、アジャイルストーリーポイントのマッピングを時間に変換するよう依頼できます。 最新のソフトウェア開発のトレンドに精通していないほとんどの人は、ストーリーポイントをどうすればよいかわかりません。
しかし、クライアントがストーリーポイントが何時間に等しいかを尋ねるとき、明確に答えることは不可能です。 複雑さに基づく見積もりの重要な要素の1つは、ストーリーを完成させるために費やされる労力です。 しかし、努力は費やされた時間に直接変換されません。 時間は、ストーリーポイントよりも曖昧な方法で不確実性に対処します。
タスクが複雑になるほど、不確実性とリスクが高まります。 時間ベースの推定はリスクと不確実性に関してはストーリーポイントよりも近似的であるため、ストーリーポイントを簡単な方法で時間に変換し、速度のみに依存することは、そのようなリスクの多くを説明しません。
ある程度、ストーリーポイントの割り当てにフィボナッチ数列を使用すると、開発時間の不確実性が考慮されますが、直接変換することはできません。
これが例です。
1階建てのポイントストーリー（ベースストーリー）は、たとえば、完了するのに2時間かかります。
13階建てのポイントストーリーは、ベストケースのシナリオでは26時間かかる場合があります。問題が発生したり、邪魔になったりしない場合です。 たとえば、使用するAPIがシームレスに適合する場合、エンドポイント間でエンドポイント間。 ありますどのように多くの不一致に応じて、 -それがない場合でも、話はどこにも30、言う、間および50時間が必要になることがあります。 開発者が問題のAPIをまだ使用していない場合、どのようになるかを事前に言うことはできません。
したがって、ストーリーポイントを時間に変換するには、不確実性に対処するために指数関数的成長の乗数が必要です。 そして、その乗数はチームごとに異なります。
ストーリーポイントと時間：ソフトウェア開発のために何を選択するか？
ご覧のとおり、開発者がプロジェクトを見積もるには、ストーリーポイントと時間の両方が有効な選択肢です。
全体として、より多くの製品会社がストーリーポイントを選択する一方で、アウトソーサーは時間に傾く傾向があると言えます。
固定価格モデルを使用している企業は、通常、時間ベースの見積もりを行います。 スクラムを好むチームは、文字通りスクラムから生まれ、この方法論に固有であるため、ストーリーポイントを選択することがよくあります。
私たちの長年の経験の中で、私たちはそれを次のように見るようになりました：
予算を合わせるよりも発売日を正確に見積もることが重要な場合は、ストーリーポイントを探してください。
正確な発売日よりも予算が重要な場合は、時間を検討してください。
または、何よりも、2つを組み合わせます。
ストーリーポイントは、監視速度が違いを生む長いプロジェクトに取り組む開発チームにとって非常に便利です。
時間は、予算を圧迫することを心配しているクライアントにとって重要です。 また、短期プロジェクトの場合、時間の方が理にかなっています。
複雑さベースのシステムは、スクラム自体と同様にまだかなり若く、開発中です。 両方の推定モデルを組み合わせ、各ストーリーポイントを数時間にすばやく変更するシステムを構築することで、欠点を最小限に抑えながら、両方のモデルの利点を提供します。