時間単位の絶対見積もりストーリーポイントでの相対見積の両方を選択可能です。Jira上の課題として作成したタスクの進捗のトラッキングは作業に用いた工数の時間単位で行うため、課題タイプの「サブタスク」にはストーリーポイントを設定できないという仕様があります。この仕様の是非については論を避けますが、Jiraに限らずアジャイル開発について様々な方とやりとりをして感じるのは、「スクラムをはじめとするアジャイル開発のプロセスでは、見積もりに『ストーリーポイント』を用いて相対見積を使うものである」という認識の存在です。用いる見積もり手法には、過剰バッファーや、理想日と実作業日の差異、不確実性への対処、コミットメントと進捗管理の分離など、ソフトウェア開発での見積もりについての問題に対応する上で様々なメリットがあります。筆者も、「アジャイルサムライ」を始めとする書籍やアジャイル開発のコミュニティーでストーリーポイントの用いた相対見積もりの魅力に触れ、そしてアジャイアル開発の案件の中でそれを実践する中でサービスをローンチに導いた経験があります。*1しかし、スクラムを始めとするアジャイル開発の中でストーリーポイントの存在があまりに大きいゆえに、アジャイル開発のフレームワークを論じる上でそれは所与のものとされ、意味の希薄化や教条主義化が発生しているのではないか、というのが筆者の問題意識です。実際、筆者はこのエントリーを調べるに当たって様々なアジャイル開発についての文献をあたりましたが、ストーリーポイントの由来にふれないまま、ストーリーポイントの概念を所与のものとしてあつかう文献を複数確認しました。本エントリーは、「ストーリーポイント」がアジャイアル開発の歴史の中でどういう文脈付けをしてうまれ、そして今日にいたるのかを示しながら、ストーリーポイントのメリットとデメリットについて明らかにするものです。Jeffries氏は、ストーリーポイントの由来について、以下のように述べています。(このツイートの記述については、id:kdmsnrに情報を提供いただきました。訳すなら、「ストーリーポイントは時間の湾曲表現であり、それ以上でもそれ以下でもない」といったところでしょうか。その上で、彼が著者の一人である「XPエクストリーム・プログラミング導入編」ではストーリーポイントについて以下のように示しています。したらいいのか教えてあげよう。私たちは、簡単なポイント制を使ってストーリーの難易度を見積もる。このポイントの呼び方はチームのネーミングルールに従ってもらって構わない。week)と呼ぶチームもある。この呼び名を使うのがよくないと考えるチームもある。完全週数を実際の週数(結局はこれが私たちが使える時間だ)にあわせようとして、結局自分たちにプレッシャーをかけすぎることになるというのが理由だ。「グミペアー」と呼んでいるチームもある。あなたは「ストーリー見積単位」とか、「ドル」と呼ぶほうがいい、と思うかもしれない。Ronの今週のお気に入りは、ただの「ポイント」という呼び名だ。Development」の中でストーリーポイントを取り上げるなどして、XPに限らずアジャイル開発全般にストーリーポイントというものが広まっていきます。Andres氏は「エクストリームプログラミング」の第2版において、ポイントによる見積もりについて以下のように述べています。第1版では、もっと抽象的な見積りモデルを紹介した。いう「ポイント」をつけていたのである。大きなストーリーは計画する前に分割する必要があった。週間で達成できるポイント数をすばやく把握するのである。今では実時間で見積もるほうが私の好みだ。そのほうができるだけ明確で、直接的で、透明性のあるコミュニケーションがとれるからである。見るこのような価値観の相違の中で、ソフトウェア開発のフレームワークとしてのスクラムは見積の単位に対して言及することを巧みに回避しており、「スクラムガイド」の中にはストーリーポイントについての言及はありません。ストーリーポイントによる見積のメリットもちろん、ストーリーポイントによる相対見積は、以下のようなソフトウェアの見積もりに関する処方箋として、きわめて有効です。不確実性コーンへの対処コミットメントと進捗のトラッキングの分離チームの生産性を示す最後に「チームの生産性を示す」をメリットとして示しました。この際に指標として有効なのはストーリーポイントの累積値としてのベロシティーです。組織がアジャイル開発に初めて取り組むときには、ストーリーポイントによる相対見積はプラクティスとして極めて有効です。タスクが、現場で行う実作業と密接に結びつく場合があります。ポイントの見積の総和がスプリント全体での見積となるのが理想的です。それはバックログをスプリントのスコープに入れる時点で開発チームのメンバーが密にコミュニケーションし、バックログを開発チームが十分に咀嚼しているから可能になることです。その視野が抜けた状態でのストーリーポイントの見積もりは、ウォーターフォールの案件でWBS上にタスクに対して見積もった工数を集計する見積手法と大差ありません。時間を単に抽象化したものでした。管理するようなテイラー主義に陥る危険性をはらんでいます。ストーリーポイントの長所の一つは、コミットメントと進捗を管理することの分離にあります。ストーリーポイントによる進捗をチームの評価基準とした途端に、未来のストーリーポイントがコミットメントとして扱われ、ストーリーポイントによって計測される生産性そのものが目的になってしまいます。できるようになること、そしてその産出量としてのベロシティーを、ビジネスサイドの期待に答えることのできるレベルまでひきあげることです。占めるリードタイムや、デリバリーしたことによって生み出したビジネス面のインパクトなど、複数の視点を組み合わせてマネジメントするべきであり、ストーリーポイントはその一要素であるということを認識すべきです。ストーリーポイントに関する批評を読み込むうえでは、上記のようなポイントを抑える必要があります。持っていないためです。「スクラム現場ガイド」ではストーリーの構造に対して、エピックテーマストーリータスクという四階層を示しています。エピックとは長編、指輪物語のような壮大な物語のことだ。エピックのスコープは巨大だ。「ドキュメントのユーザーインターフェイスを再構築する」はエピックだ。テーマとは大きなエピックに含まれる中心的なアイデアだ。「ドキュメントエディタのメニューバー再構築する」はテーマであり、エピック「ユーザーインターフェイスを再構築する」の一部となる。ストーリーはテーマの中の1つのイベントだ。テーマに含まれ、このテーマは「ユーザーインターフェイスを再構築する」エピックに含まれるタスクはストーリーを実現するのに必要なアクションだ。個々のタスクをすべて実施すれば、ストーリーが完成し、出荷可能になる。見るストーリーポイントの長所で示したように、過剰バッファーや、理想日と実作業日の差異、不確実性への対処、コミットメントと進捗管理の分離に対して、ストーリーポイントによる見積は今日でも有効です。その上で、タイムボックスの中でタスクを一個一個着実に消化する先にストーリーのリリースがあるということを踏まえ、相対見積と作業時間による見積もりを適切に使い分けていくことが、ソフトウェア開発には必要です。月別アーカイブはてなブログをはじめよう!setoazusaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。