- スクラムとは?
- スクラムを構成するもの
- ユーザーストーリーとは
- なぜユーザーストーリーなのか？:無駄な工程である文書化を防ぐため
- PBIの見積もり
- 人間のプロジェクトでの見積もりはがっかりするほど適当
- どうすれば可能な限り正確な見積もりが出せるのか？
- アジャイルでの見積もり注意点
- アジャイルでの「二つの見積もり方法」
- まとめ
- 制約理論と継続的なフロー
- バックログのタスクを早く終わらせるには
- 事例: ゲーム開発会社
- アジャイルでのイテレーションの回し方
- スクラムパターン
スクラムとは?
スクラムとは
小さなチームが新製品を開発する際に、素早くイノベーションを行うこと。
by ジェフ、サザーランド
これらのフレームワークはソフトウェア開発だけでなく、仕事の仕方そのものに適用できることがある。
スクラムの導入の仕方は?
A1. いきなり始まる。
この仕事はスクラムでやるよ。という感じで切り替える
強いリーダーシップで実行するのもあり。
A2. スクラムマスター認定資格を得た人が、丸一日かけてエクササイズを行う。
会社で抱えている課題を、スクラムで解決する。そのありがたみを体験することが大事。
定義されたプロセス
伝統的なウォーターフォールプロセスは最初に計画を定義し、厳密にその計画に従って最後まで進める。
このアプローチの前提として、計画からのずれが最小である必要がある。そうでないと、計画は成功しない。
しかし、プロジェクト中に要求が変化する可能性は60%あるといわれており、その結果ウォーターフォールプロジェクトが成功する確率は13%しかない。
ウォーターフォールプロジェクトが辿る結末の内訳は以下の通り。
成功率:13%
遅延、予算超過：59%
失敗：28%
これを解決するのが、スクラムであり、ジェフ、サザーランド博士が1993年に開発した。
スクラムは、経験的プロセスに基づいている。
化学工学では、経験的プロセスを用いていた。
化学工学とは、結果がわからない実験を、仮設し、実行するプロセス。
経験的プロセス
予測できない変化が起きるプロセスを制御するには、フィードバックループを導入しなければならない。
経験した結果を検査しそこから学んだことを、次のサイクルの計画へ定期往査せ、変更を加えていく
プロダクト開発を繰り返しながら増分を積み上げる方法で作る。
一つ一つの機能は短いサイクルで完成させる。
検査と適応を通じて成功するためには、作業のプロセスを透明化する
スクラムの経験的プロセスとは、透明性、検査、適応の三本柱で成り立っている。
アジャイルとは
アジャイルとは考え方
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くプロダクトを
契約交渉よりも顧客との協調を
計画に従うよりも変化の対応を
価値とする。
左の部分に価値があると認めながらも、右側のことがらにさらに価値を置く。
ちなみに、アジャイルの語源は「アジャイルな競争相手とバーチャルな組織 - 顧客を豊かにする戦略」からきている。
スクラムとは結局何か?
デリバリーのフレームワーク
アジャイルは日本企業の働き方から生まれた
日本では新製品を開発するときの手法研究を、野中幾次郎、竹内博隆さんが論文として作成した
NASA : 工程ごとに、チームや組織が分かれている。
ドキュメントでチームごとに分類されている
他チームの仕事は知らない。
無事ゼロックス
- 工程の最初と最後が重なり合っている。
本田、キャノン
工程がすべて重なり合っている。
自分の専門性を発揮しつつ、ほかチームの仕事も手伝う。
となりのチームが責任を果たせなかったら、自分のチームで責任を追っている。
この働き方がスクラムの元
作りすぎのムダ
- その時点で必王のない物を作る
手持ちの無駄
- 前工程の部品を待つこと
運搬の無駄
- 必要以上の移動
加工そのものの無駄
- 伝統的要素を重要しすぎる
...
なぜ日本にスクラムの考え方がなくなったのか
日本の「トヨタ生産方式」がもとになったにもかかわらず、なぜ日本にスクラムの考え方がないのか?
1950では「トヨタ生産方式」はあった
しかし、1980のバブル崩壊で、「業績偏向型」に変わってしまった
その結果、分社化が進み、「ソフトウェア」「ハードウェア」等の役割ができる。
最終的には「受発注」の考え方が進み、ウォーターフォールが強くなってしまった。
スクラムを構成するもの
スクラムの単純なルール
5つの会議
3つの役割
プロダクトオーナー
スクラムマスター
開発者
3つの成果物
シンプルで明確な目的と原則とは、高度で知的な行動を生む -> これを、自己組織化と呼ぶ
逆に、複雑なルールと規制は単純で愚かな行動を生み出す。
スクラムでは、The Rule Book という名前で、スクラムのルールを定めており、これは世界共通の認識。
しかし、これはあくまでスクラムのルールであり、実運用はチームによってカスタマイズされており、自己組織化されている必要がある。
そのため各プロジェクトチームは、スクラムフレームワークに戦術を取り入れるため、Scrum Play Bookという名前で作る。
5つの会議とスプリント
スクラムのMTG
プロダクトオーナーから、スタートする
周りの意見から、チームがやるべきリストを作り出す
-> プロダクトバックログ
プロダクトで最初に何をやるかはスプリントプランニングを作る。
スプリント
なんのためにスプリントをやるのか
スプリントはスクラムにおける⼼臓の⿎動であり、スプリントにおいてアイデアが価値に変わる。
⼀貫性を保つため、スプリントは 1 か⽉以内の決まった⻑さとする。前のスプリントが終わり次第、新しいスプリントが始まる。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペク
ティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で⾏われる。
スプリントでは、
スプリントゴールの達成を危険にさらすような変更はしない。
品質を低下させない。
プロダクトバックログを必要に応じてリファインメントする。
学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要に
なる場合がある。
スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり、予測可能性が⾼まる。
スプリントの期間が⻑すぎると、スプリントゴールが役に⽴たなくなり、複雑さが増し、リスクが⾼まる可能性がある。
スプリントの期間を短くすれば、より多くの学習サイクルを⽣み出し、コストや労⼒のリスクを短い時間枠に収めることができる。
スプリントは短いプロジェクトと考えることもできる。
進捗の⾒通しを⽴てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する。
これらの有⽤性は証明されているが、経験主義の重要性を置き換えるものではない。
複雑な環境下では、何が起きるかわからない。すでに発⽣したことだけが、将来を⾒据えた意思決定に使⽤できる
スプリント
- 目的：スプリント終了時に、顧客やステークホルダーに提供することができる、価値があり達成可能な目標にコミットする。
イベント中に、その成果を達成するために必要な特定のバックログアイテムを選択する。
推奨されるタイムボックスは、スプリントの長さが1週間あたり最大2時間。
- 注意：スプリントプランニングのすべての時間がバックログリファイメントに費やされると、ゆっくりとした非生産的なミーティングになる。
ミーティングの前にできる限りバックログアイテムの内容を明確にして、チームが優先順位付けに集中できるようにし、仕事をどのように終わらせるかを考えられるようにしておく。
必要なもの
成果物
数プリントバックログ
スプリントゴールを達成するための計画
チームのコミットメント
プロセス
ワーキングアグリーメント
スクラムは、チームビルディングからスタートする。
この時には必ず、ワークショップを行うこと。
そのワークショップの一つが、ワーキングアグリーメント。
ワーキングアグリーメントでは、働き方などの決めごとを確認します。
ex) ワーキングアグリーメントの一例
スプリントプランニング
スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。
結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。
プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。
スクラムチームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよい。
スプリントプランニングでは、次の3つの問いに応えられるようにしておく必要がある。
- トピック 1：このスプリントはなぜ価値があるのか？ :
スプリントゴール
プロダクトオーナーは、プロダクトの価値と有⽤性を今回のスプリントでどのように⾼めることができるかを提案する。
次に、スクラムチーム全体が協⼒して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。
スプリントゴールは、スプリントプランニングの終了までに確定する必要がある。
- トピック 2：このスプリントで何ができるのか？ :
どれくらいできるのか? : 稼働時間と能力
開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを
選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバッ
クログアイテムのリファインメントをする場合がある。それによって、チームの理解と⾃信が
⾼まる。
スプリントプランニング
スプリントゴールとスプリントバックログを作成する。
スクラムチームが合意したスプリントゴールを達成するために、
必要となるすべてのPBIを含んでいる必要がある。
スプリントプランニングの進め方は次の通り。
ベロシティのレビューと昨日の天気を更新する
- ex) 昨日の天気46,バッファ5
スクラムチームのゴール。スプリントゴールを決定する
- ex) ベータリリース!
昨日の天気とキャパシティから求められる上限に達するまで、スプリントバックログに「準備完了」の「PBIを追加する
ex)
改善
バッファ
バックログオフィス
Perf Test
受け入れ条件を最終決定する
ex)
- テスト
完成の定義を、全員が同様に理解しているか確認
スプリントゴールの設定
このスプリントレビューでは、何を見せたいかを話す。
デモの内容で決めても良いし、優先順位で決めても良い。
POがゴールを提案し、チームがゴールを達成するバックログアイテムを選ぶ
スクラムチームは、プロ学とバックログの最優先から、完成することができるPBIを選択し、ゴールを決める
受け入れ条件と完成の定義
受け入れ条件とは、バックログアイテムの目的が満たされたことを確認するために、個々のバックログアイテムに適応される。
丸バツ判定ができるレベルで具体的なものでなければならない。
通常はPOがドラフトするが、技術的なPBIはチームが補導する場合が多い。
完成の定義は複数のバックログアイテムに適応される基準。
言い換えれば、バックログアイテムが完成してリリースする際の品質マーク。
完成の定義は具体的なものにすること。
リリース可能である -> ❌
追加した完成の定義
さらに追加できる定義だと、
ドキュメントが整備されている
テストのカバレッジが80%以上
会社や組織が標準の完成の定義を設定していない場合、スクラムチームは独自に定義する必要がある。
なお、チームが成熟していない状態では、完成の定義は少なめに設定しておくとよい。
その後、スプリントを回す中で完成の定義を広げていく。
さらに成熟した完成の定義
デイリースクラム
24時間単位で行う定例で、スクラムにおいて、「検査」と「適応」を行うためのMTG。
開発者はスプリントゴールの達成に向けた進捗状況を検査し、必要に応じてスプリントバックログを調整および再計画する。
特別に技術的な内容を含む場合、パーキングロットを使う。
パーキングロット
議論を掘り下げる必要がある時、タイムボックスから溢れてしまう。
必要なメンバーだけが後に残り、他の人はスプリントバックログの仕事に戻る。
スプリントレビュー
プロダクトのインクリメントを、ステークスホルダーにデモし、
プロD作とバックログに適応できるフィードバックを求める
- スクラムチームは、スプリントゴールとスプリントで作成したインクリメントについて、デモと話し合いを行う
フィードバックを求める
スプリントレビューでの最優先の成果はフィードバックを得ること
スプリントレビューでは、プロダクトを検査するために以下の重点を置く
リリースプランニング
スクラムチームのメンバーとして、リリースプランニングを手助けする必要がある。
動作するプロダクトをエンドユーザーにデリバリーする工程だ。
- リリースバーンダウンチャート
この辺りは、かなり図表が必要となる。
プロダクトを期日通りにデリバリーするかぎ
- 「期日までに終わるだろうか?」
「もしこうだったら」の分析に有用であり、スコープ、ベロシティ、時間のトレードオフの分析に使用する
非合理的な期待をコントロールすることに優れているツール
リリースプランニングの考慮点
スプリント終了後に、リリースに必要な作業を把握する
プロダクトバックログの見積もり（完成の定義に基づく）
Undone作業(完成の定義の外側の、デプロイに必要な作業)
後発的な要求(過去の経験によるデータに基づく)
バックログリファイメント
スプリントプランニングで、PBIの内、「準備完了」となるものを1~3スプリント分用意する
POとの会話を通じて、これから着手するPBIのコンテキストを明確にする
PBIのスプリント内で完成できるサイズに分解し、必要に応じて並び替えを行う
リファイメントとは「洗礼させる」という意味
1. ユーザーストーリーマッピング(PBI)のエピックを分割する
エピックは、長編物語、大きなストーリのこと
次のPBIは「エピック」と呼ばれる単位「マイレージ会員として、航空券の予約を自分向けにカスタマイズしたい。なぜなら時間の節約になるから」
-> これを、分割すること
マイレージ会員として、マイルを使って予約したい。節約できるから
マイレージ会員として、よく使う路線を簡単に予約したい。なぜなら時間の節約になるから
プレミアムマイレージ会員として、ラウンジを予約した。ゴージャスな生活がしたいから
2. 優先順位をつける
ユーザーストーリーマッピングから分割した後、
3. READYなPBI
INVEST
I Immediately 直ちに着手できる
N Negotiable 交渉できる
V Valuable 価値がある
E Estimateable 見積もれる
S Small 小さい
T Testable テスト可能である。
Testable : 受け入れ時要件の作成
バックログアイテムがテスト可能であるためには、完成の基準が必要である。
PIBの条件としては受け入れ条件を定義する
メリットとしては以下の通り。
テスト駆動開発を促進する
過剰品質を避け、必要十分な機能性を実現する
例
title
- 【運用者】従業員情報csvファイルアップロード状況を一覧で確認できる
<ストーリーポイント>
- 3
<理由>
- お客様がまとめて福利厚生サービスを契約した後、csvをアップロードしなければ契約状況を管理するサービスとならない
<受け入れ条件>
- 画像イメージは添付資料のまとめで福利厚生従業員登録情報の通りであること
スプリントレトロスペクティブ
スクラムチームは作業の品質と有効性を高めるためにプロセスを検査する。
レビューでは、デモなどを行いフィードバックを得るのが目的であり、POが主役である。
しかし、スプリントレトロスペクティブではSMが主役となり、生産性向上のためにできることを探す場となる。
スクラムチームは、もっと良くなるために次のスプリントで試してみる一つの改善を特定する。
スクラムチームの長期的な視点でのパフォーマンスのために最も重要なイベント
このイベントの効果的なファシリテートは、スクラムマスターの最優先事項 : なぜなら、チームの生産性の向上に責任を持つのはスクラムマスターの優先事項だから
スプリントレトロスペクティブでは、正しい進め方はない。
ネットでも多くの手法がある（KPTなど）
共通しているのは以下の通り
場を設定する
データを集める
アイデアを出す
次に何をすべきかを決める
一例 :
タイムライン : 今週のスプリントで何が行われたのか?
次のスプリントでは、どこを違うようにやってみるか?
- スプリント レトロスペクティブで出てきた改善点は、必ず優先事項の一番上に追加すること*
幸福指標を図る。
自分のパフォーマンスを1~5で表明する。
あなたの役割についてどう感じるか?
チームについてどう感じるか?
会社についてどう感じるか?
もっと良い感じになるにはどうすればよいか?
内発的なモチベーションを促すことで、仕事の効率をあげることができる。
外発的なモチベーションは、お金や権力や地位のことであるが、持続性は低い。
スクラムマスターにとって、チームの幸福指標は、パフォーマンスの先行指標 である。幸福指標をみれば、チームに何が起きているかわかる。
スクラムにおける3つの役割
POを一人選ぶ
AMを一人選ぶ
そのほかは複数の開発者
面白くてかっこいいチーム名を決める
メンバーの3つの役割
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキル
を備えている。また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチー
ム内で決定する。
スクラムガイドには、プロジェクトマネージャーは出てこない。
その代わり、本来プロジェクトマネージャーが負うべき責任を、3つの役割に分けている。
jk
スクラムマスター
主な役割：ファシリテーション
ディスカッションを遂行し、チームメンバーの意見を引き出す。
メンバー全員の参加
- すべてのメンバーが参加している状態を作る
クラスへの共有
- ディスカッションの結果をクラス全体に発表し、クラス全体の学びを高める
スクラムマスターの役割
開発、ＰＯ、組織のパフォーマンスに責任を持つ
イベントが効果的に行われるように、ファシリテーションする
割り込みから防ぐ
作業を見えるかする
障害物となっている者を取り除き、プロセスを改善する
最終的には、プロセスを改善してゴールを達成させる
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。
スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラム
チームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任
を果たす。
スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。
スクラムマスターは、さまざまな形でスクラムチームを⽀援する。
l ⾃⼰管理型で機能横断型のチームメンバーをコーチする。
l スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できる
よう⽀援する。
l スクラムチームの進捗を妨げる障害物を排除するように働きかける。
l すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックス
の制限が守られるようにする。
l 効果的なプロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀
援する。
l 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解
してもらう。
l 複雑な環境での経験的なプロダクト計画の策定を⽀援する。
l 必要に応じてステークホルダーとのコラボレーションを促進する。
スクラムマスターは、さまざまな形で組織を⽀援する。
l 組織へのスクラムの導⼊を指導・トレーニング・コーチする。
l 組織においてスクラムの実施⽅法を計画・助⾔する。
l 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施しても
らう。
それ以外の作業は以下の通り
対立の解決
仕事の無駄の見えるか
イベント成果物の集中
PO
意思決定
- エクササイズでの優先順位の意思決定
メンバー全員の参加
- すべてのメンバーがバックログアイテムの作成に参加している状況を作る
クラスへの共有
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化すること
の結果に責任を持つ。
いわば、何をに責任を持つ
魅力的なプロダクトビジョンを策定する。
プロダクトゴールを策定し、明⽰的に伝える。
プロダクトバックログアイテムを作成し、明確に伝える。プロダクトバックログとは、やるべきことの仕事のリスト。
- プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。
プロだ黒バックログを集める。
最後に、顧客に価値を届ける
組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。
いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重し
なければならない。これらの決定は、プロダクトバックログの内容や並び順、およびスプリン
トレビューでの検査可能なインクリメントによって⾒える化される。
プロダクトオーナーは 1 ⼈の⼈間であり、委員会ではない。プロダクトオーナーは、多くのス
テークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダー
がプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。
POとSMは「絶対に兼任してはいけない」
そもそも、POとSMは目的が異なる。
POは「プロダクトの価値」に重きを置く
SMは「チームのパフォーマンス」に重きを置く
この二つの目的は対立する場面が多く、一人の人間ではまかなうことができない。
開発者
そのほかのメンバーは開発者となる
開発者は「どのように」に責任を持つ
プロダクトオーナーが定めた「価値」を、どのように濃き役に届けるインクリメントを作成するかのHOWに責任を持つ
毎日の作業計画を適応させ、そのための障害をデイリースクラムで報告し取り除く
完成の定義を忠実に守り、品質を作りこむ
まとめ：開発者とSMとPOでスクラムチーム
それぞれの役割の責任を果たしつつ、お互いに協力し、チーム一丸となってゴールを達成する
スクラムチームが最小単位。サブチームは存在しない
横断的機能：技術単位のチームではなく、仕事を成し遂げるために必要なすべてのスキルを持っている
自己管理：１スプリントにどれだけの仕事ができるか、どのように進めるかを自分らで決める
協力的：全員が協力し、専門分野外でも対応する
少人数：絶対に10人以下
3つの成果物
プロダクトビジョン
プロダクトビジョンは、プロジェクト、プロd買うと、サービスにおいて、「達成したい将来の状態」を要約したもの
顧客が「なぜ」ひつようとするか、から始める
次に顧客が「なに」を望むかを含める
そして常に「だれ」が使うかをかんがる
プロダクトゴール
チームにとっての長期的な目標
プロダクトバックログ
プロダクトバックログアイテム（PBI）
スクラムチームがやりたいことの「最小単位」
ex)
顧客向け機能
チームのインフラ
調査研究
リスク削減策
これは、「技術的な側面」ではなく 「顧客にとっての価値、機能単位」である必要がある。
これらのPBIを探すためには、「直接顧客とはなして、必要な機能をリストアップする」ということが大事である。
ユーザーストーリーマッピング
顧客の行動の流れに沿って左から右へ示す
縦に1列並べるより、2次元の氷河理解しやすい
プロダクトの全体像を把握することができる
MVPを決めるためのよいツールとなる
大きなフィーチャーや、全社的構想にも使用できる
ユーザーストーリーマッピングの、テンプレートはこれ
「役割」として「行動」がしたい。
それは「ビジネス価値」のためだ。
ユーザーストーリーとは
ユーザーストーリーとは顧客がソフトウェアで実現したいと思っているフィーチャーを簡潔に記述したものだ。
記述する媒体は小さい付箋やカードなどで、それの集合がユーザーストーリーの原型となる。(この付箋やカードのことをフィーチャーと呼ぶ）
以下はユーザーストーリーの一例である。
ここで大事なのは、フィーチャーを書く際に製品の本質を捉えるキーワードになりそうなものを書き溜めておくことである。
したがって、フィーチャーは思いついたばかりのものでもよく、本当に必要になるかはまだわからない。要求を事細かに聞き出す必要はない。
だから、ストーリーを書いてすぐの時点では、検討する時間とエネルギーを節約しておこう。
このカードのことをインデックスカード(またはフィーチャー)と呼ぶ
なぜユーザーストーリーなのか？:無駄な工程である文書化を防ぐため
実際のソフトウェアプロジェクトで、重厚な文章が要求を捉える手段として本当にうまく機能したことなんて一度もないと言っていい。
しかも、ソフトウェアへの要求を表現する手段として文書に頼りすぎることの弊害はそれだけではない。
- 変化に対応できない
例）顧客「確かにそう言ったわ！でもそれって半年前のことよ！」
- 顧客の欲しいものに合わせるのではなく、仕様に合わせて作ることになる
例）顧客「こっちがいいわ！」PM「でもそれ仕様と矛盾しますよね」
- 多くの時間を無駄にする
例）上司「この3ヶ月の要件定義書な、変更になったから変えてくれ」
- 言葉で全ては表せない
例）私は彼女がお金を盗んだとは言っていない
この文章は別の文脈になりかねない
私は、彼女がお金を盗んだとは言っていない
私は彼女が、お金を盗んだとは言っていない
結論：文章に頼りすぎてはいけない
文章ではなく、もっと別の何かが必要となる。
それこそがユーザーストーリーなのだ。
良いユーザーストーリーの書き方
ユーザーストーリーがプロジェクトにどんな省エネをもたらすかを把握できたと思う。
次は、どうユーザーストーリを書けば良いのかについて解説する。
良いユーザーストーリーの条件は次の6つだ
顧客にとって何かしらの価値がある
独立している
交渉の余地がある
テストできる
小さく見積もれる
顧客が作成する
良いユーザーストーリの条件1:顧客にとって何かしらの価値がある
良いユーザーストーリーの例
よくできたユーザーストーリーの書き方は以下の通り
このレベルで良い。
悪いユーザーストーリーの例
逆に以下のようなユーザーストーリーは好まれない
ユーザーストーリーを書く際には、顧客にとって何かしらの価値があるかどうか
まずは大事なポイントである。
お客さんがワクワクするようなストーリーを書こう
ユーザーストーリーの条件2:独立している
必ずしもストーリーがお互いに独立させれるわけじゃないが、ストーリーを抽出する時にはできるだけエンドツーエンドの切り口の単位にした方が良い。
なぜならプロジェクトには変化がつきものであるため、大事だった要件がどうでもよくなることがよくある。
独立性を高めることで、必要に応じてスコープを自在に調節できるのもアジャイルのコツだ。
良いサンプルを見てみよう
これらの要件は全て独立している。
ユーザーストーリーの条件3:交渉の余地がある
ストーリーに交渉の余地があった方がいいのは、予算の範囲内に治るかどうかをある程度融通が聞くようにできるからだ。
ユーザーストーリーの条件4:テストできる
テストできるようになっているユーザーストーリーは素晴らしい。
というのも、どのようになっていればきちんと動いているかがわかるからだ。
ユーザーストーリの条件5:小さく見積もれる
完了の状態を「リリース可能な状態」と定義した時、そのユーザーストーリーはどれくらいのイテレーションに収まりそうだろうか？
判断は難しいだろうが、ストーリーを小さくしておけば、1~2週間といったイテレーションの範囲に収まりそうかどうかはわかるはずである。
それぐらいのサイズであれば、見積もりも可能になるはずだ。
ユーザーストーリーの条件6:顧客が作成する
ユーザーストーリーは可能であれば「顧客」のポジションにいるメンバーに書いてもらった方がいい。
少なくとも心構えとしてはあっている。
なぜなら、開発チームが何を作るべきかを本当にわかるのは顧客だけだからだ。
ユーザーストーリーのこつ7:独立しないものは制約と受け止める
次のユーザーストーリーで仲間外れがいる
次回のセール品の一覧
大会の結果の掲載
今後のイベントやサーフィン大会の一覧
ビーチの様子を配信
ウェブサイトはサクサク表示して！
デザインはまじかっこよく
もちろん下の二つだ。
抽象的な言葉で表されているのも違う点だが、それ以上に「独立していない」「テストできない」という点がある。
現場ではこう言った類のストーリーを「制約」と見なすと良い。
制約は毎週届けるユーザーストーリーとは別物だが、これはこれで重要だ。
制約を書き留めておくカードの色は通常のストーリーとは別の色にしておくと良い。
また、可能であればテスト可能な状態にしておいても良い。
サクサク動く→サイトのページはどれも2秒以内に読み込めること
まとめ
ユーザーストーリーがプロジェクトにどんな省エネをもたらすかを把握できたと思う。
また、良いユーザーストーリーの条件は次の6つだ
顧客にとって何かしらの価値がある
独立している
交渉の余地がある
テストできる
小さく見積もれる
顧客が作成する
PBIの見積もり
そもそも見積もりは、「いつこれをお客に届けることができるのか？」を図るためのもの。
ウォーターフォールは、最終的な見積もりは作業を時間で分割し、最終的には合計するが、これには欠点もある。
なぜポイントで見積もるのか?
不確実性のコーン
縦方向は、見積もりの誤差
横方向は、プロジェクトの工程段階
工程の初期段階では、見積もりの誤差は大きい。
開発とテストの段ん買いに近づくほど、誤差は小さくなる。
ウォーターフォールでは、見積もりの誤差が大きい段階で、一回しか見積もれない。
最も見積もりの精度が要求されるのは、国防である。
その際にわかったことは、以下の3つ
時間的見積もりが間違いが最も多く、変動も大きい
逆に、相対的な見積もりを大きさで区分するのが得意だとわかった
専門家は一人で見積もる方が良い
- アンカリングを避けるため
ポイントの見積もりは、正確であり、見積もり自体にかける時間もあまりかからない。
アジャイルな見積もりの戦略
時間を見積らない
バックログアイテムを完成させるための労力を見積もる
スプリントごとに、ベロシティを測定する
リリース計画を導出する
見積もりは実際の作業をする人たちが行う
仕事をやって欲しい側ではない
チームの特定の一人でやるとは想定しない (ドキュメントに基づいて行うものではない。)
プロジェクトの開始前だけでなく期間を通じて常に見積もりを行う
詳細に記述したドキュメントよりも、口頭での会話を用いる
見積もりの手段
人間のプロジェクトでの見積もりはがっかりするほど適当
プロジェクトで最初に出す初期見積もりは常に適当である。
ひどい当てずっぽうに過ぎない。
精度や精密さという意味では何も得るものがない事前見積もりに依存するべきではない。
プロジェクトの見積もりミスによる炎上
見積もりを間違えてしまうこと自体はそこまで問題ではない。
問題は、見積もりから本来ありもしないものを読み取ってしまうこと
つまり、見積もりを未来の正確な予測だと思い込んでしまうことにある。
事実から見積もりを出していたつもりが
見積もりからそれが達成できるように事実を変えようとしてしまう
これが見積もりの問題である。
不確実性コーンとは
プロジェクトに先立って行われる、概算見積もりとは当てずっぽうで、多くの場合楽観的すぎる。
スティーブ・マコネルはこの機能的な不全を「不確実性コーン」と呼んでいる。
つまり、初期段階の見積もりには大きな誤差が存在するということだ。
アジャイルではこの事実に対して次のように対処している：前もって正確に見積もることなんて無理
どうすれば可能な限り正確な見積もりが出せるのか？
人間は絶対的な分量を図ることは苦手としている。
「写真の人物の身長を答えよ」という問の答えは事実とかけ離れる場合が多い。
しかしながら、人間は相対的な分量を図ることは得意としている。
「次のアイスはどちらがどれくらい大きいか」という答えは性格になりやすい
アジャイルでは 「人間は相対的な分量を図ることは得意としている。」という実験結果を元にして見積もりを行う
アジャイルでの見積もり注意点
具体的には次の方法でアジャイル開発の見積もりを行う。
ストーリーをそれぞれ互いに相対的なサイズで見積もる
ポイントを元にして進捗を追跡する
これらが計画を立てる上でどう役立つかを見ていく。
アジャイル開発では日付で見積もってはいけない！
アジャイル手法では見積もりの単位として「ポイント」を採用する。
つまりあるタスクに対してある方法を用いて「どれくらいの負担か？」をポイントをつけるのだ。
仮に日付で見積もったとしよう。
当初の見積もりから実績が1.3倍になったとする。
その際に当初の見積もりで1人日だったものが1.3人日となってしまう。
このような小数点を用いた数値については見積もりがあたかも精密であると錯覚させてしまうことが問題である。
また、日付で単位をつけてしまうことで、マルチタスクが発生しやすくなるのも問題点である。
アジャイル開発では「ポイント」を採用する
アジャイル開発では日付を単位とせず、「ポイント」を単位とする。
さまざまなタスクに対して次のようにポイントをつけていくのだ
1pt:楽勝
3pt:やれないことはない
5pt:ちょっと大変
見積もりの数値にポイントを採用すれば、数値はどうでもよくなる。
大事なのは相対的な大きさの違いだけだ。
アジャイルで「ポイント」を採用することのメリット
アジャイルでポイントを採用することには次のようなメリットがある。
見積もりとは当てずっぽうであることを肝に銘じる
見積もりとは純粋に大きさを図るものだと考えられる
手軽に気軽にシンプルに
アジャイルのポイントを日付に変える
アジャイルのポイントから日付で見積もりに変更する際に、日付とは異なる単位に一度変換することをお勧めする。
その単位とは理想日である。
1理想日とは、全く割り込みがなく、8時間みっちり仕事に集中できるような一日のことだ。
(科学の分野の「理想気体」を参考にしているのだろうか)
アジャイルでの「二つの見積もり方法」
アジャイルの見積もり技法(ポイント性):三角測量編
代表的なストーリーをいくつか基準として選出して、残りのストーリーを基準になるストーリーとの相対サイズで見積もるやり方だ。
- 大、中、小の三つに分ける
一回のイテレーション（1~2週間）に収まりそうなサイズのストーリーから、大中小それぞれ一つを選び出せるのかが望ましい。
- ふるいわける
その後、そのストーリーと同じサイズのものに古い分けていく。
この調子で見積もりをしていたらいつか最見積もりするんじゃないかと心配になるかもしれないが、その通りだ。
だからこそ見積もりに対しては真摯に取り組む必要はなく、体力も時間も温存しておくのだ。
プランニングポーカー
プランニングポーカーは見積もりゲームだと考えるとわかりやすい。
ストーリーの詳細をヒアリングする
ストーリーが大きすぎる場合は分割する
全員で見積もって、各自プランニングポーカーのカードを裏返しに場に出す
全員同時にカードを表にする
チームでそれぞれの意見を聞いて妥当な数字で合意して決める。
特に一番大きい数字と一番小さい数字の意見を聞く
以上の手順を繰り返し踏むことで、見積もりを行う。
ここには次のようなメリットが存在する。
見積もり担当者と実装担当者とのギャップを埋める
一人で見積もりするよりも早く正確に見積もれる
実際にカードを使って見積もるのはプログラマーが中心になると思うが、DBAが参加してもいいし、デザイナーだって参加する必要があると思う。
一人でも多く参加した方が良い結果につながりやすい。
まとめ
アジャイルの見積もりは適当!!!
固定された計画の問題点
アジャイルでないプロジェクトの場合、ガンチャートは大抵いつもぐちゃぐちゃになってしまうものです。
これは未来の変化を予測できないことが原因ですし、信頼のおける計画の立て方が構築できないことも関係者との亀裂を産む原因にもなるでしょう。
そもそもプロジェクトの初期段階でできないことを約束してしまいこともあまりよくありません。
結論:プロジェクトの計画は常にうまくいかないことを、常日頃から顧客に伝えておかなければならないでしょう。
プロジェクトが崩れる原因
チームに変化が...
- ex.主力開発者が他のプロジェクトに引き抜かれてしまった。
プロジェクトがうまく行けば行くほどこの事象は発生するし、最悪なのは代わりの生産性の低いメンバーを入れられることだ。
開発速度が遅かった.
- ex.やれると思っていたことが、実際には全く別の内容であった。
お客さんが自分たちの本当に欲しいものに気がついた。
- ex.プロジェクト開始から4ヶ月目。さまざまなトラブルを乗り越えてここまできたが、お客さんの要件から痛烈な指摘を食らった。
時間がなくなった。
- ex.ビジネス上の要請から、他社のリリースに負けないようにして欲しいと依頼が来た。
アジャイルな計画の利点
アジャイルにプロジェクトを立てられるようになれば、計画はいつも最新とわかっているので心配はなくなります。
プロジェクト内には隠し立てすることもないので、期待のマネジメントも可能になるでしょう。
こうなるとむしろ、変化するのが当たり前のプロジェクトでのスムーズな開発は競争優位性を獲得できるものになり得るのです。
アジャイル用語
アジャイルな開発では通常のプロジェクトと呼び名が異なるキーワードが存在します。
これらは難しものではなく、カッコつけて横文字で読んでいるだけだと思って置いてください。
マスターストーリーリスト
- プロジェクトでこなすべきTodoリストを「マスターストーリーリスト」と呼ぶ
ベロシティ
- ユーザーストーリーを動くソフトウェアに返還する速度
-
- 1週間から2週間での、ユーザーストーリーを動くソフトウェアに返還できるまとまった期間。
これらのキーワードを抑えておくことで、アジャイル開発を進める際の参考になるでしょう。
アジャイルな計画作りの方法:速度を測る
アジャイルな計画作りとは、チームの開発速度を計測して、バックアの速度を元にプロジェクトの完了時期を見通せるようにすること
ここでの速度とは、ユーザーストーリーが動くソフトウェアに返還されるまでの時間のことだ
プロジェクトが完了するまでのイテレーションを知りたければ、次のようにして求めれば良い
イテレーション = 作業量の合計/チームの予想ベロシティ
例えば、1回のイテレーションごとに10ポイント分のストーリーをこなせるチームなら、100ポイントあるストーリーを全て完了するには10イテレーション必要だ。
そしてある程度のユーザーストーリーをまとめてリリースすることで、ソフトウェアは完成する。
アジャイルな計画はいつも当てずっぽう
アジャイルな計画を立案する上で、一つだけ大事なことを注釈しておく。
それは計画は常に当てずっぽうということだ。
プロジェクトの初期では特に、チームのベロシティは不明だ。
なので本当の速度はやってみないとわからないというのが本当のところだ
なので最初の計画を、常に厳密なものとして設定したらそのプロジェクトはほぼ死亡だ
スコープは柔軟なままにしておく
アジャイルな計画を立てた後に、お客さんに強くお願いしておくべきことがある
それは、新しいストーリーを追加するときには、必ずどれか一つ以上のストーリーをマスターストーリーリストから削ってもらうことだ。
こうすることで次のようなメリットが生まれる
「何でもかんでも要求を集めておかなきゃ」とはならなくなる(80-20の法則)
「リリース予定日をづるづる伸ばすのはよくない」という雰囲気が生まれる
マスターストーリーリストには優先順位をつける
いつ何時雷に打たれるかはわからない。
したがって、一番重要なストーリーから順番に実装していこう。
顧客にはビジネスの観点から順位付けしてもらう、そうすれば投資に対して最も価値の高いリターンを得られる。
アジャイルで顧客がゴネ出したら
顧客「どうしてもこの機能を作ってくれないとやだ」
とゴネ出したらどうするか？
その場合は、次の二つの「事実」を使って「それでも本当にやるんですか？」と聞く
- プロジェクトのムダの元凶は、「いらない機能」
キーとなる質問は以下の通り
「その機能は誰がなんのために使うのですか？」
「その機能は1年後も使われていると思いますか？」
「ちょっと考えて欲しいのですが、Microsoft Wordの機能のどれくらいを使ったことがあるのですか？」
「5%か10%か、20%か」
「お客様には本当に重要なことだけに集中してもらいたいです」
「今はまだ無理ですが、2ヶ月後にもう一度ヒアリングさせてください」
アジャイルで顧客の要求をコントロールする方法
顧客の期待をマネジメントするのもPMの仕事の一つだ。
バーンダウンチャートはチームがどれくらいのスピードでストーリーを実装しているかを一眼でわかるようにするツールだ。
また、この先いつ頃プロジェクトが完了しそうなのか見通しを立てるのにも使う。
バーンダウンチャートとは
これがバーンダウンチャートである
縦軸は残っている作業の総量
横軸はイテレーション
を表す。
あとはイテレーションごとの残作業量を記録して、図にプロットしていけば良い。
バーンダウンチャートのメリットとは
次の４つが一目瞭然になるうことである
どれだけ仕事を完了させたのか（期待貯金）
どれだけ仕事が残っているのか（期待に見合う仕事か）
チームのベロシティ（チームへの期待そのもの）
いつ頃完了させれそうか（成果報酬）
チャートの角帯が表しているのは、その時点でのプロジェクトの残作業の送料である。
チームがこれをゼロにした時、プロジェクトが完了になる。
バーンダウンチャートにコメントを書き込む
もしも世界が完璧であれば、ベロシティは常に一定になるはずである。
しかし、現実はそうではない。
/filters:no_upscale()/articles/agile-kanban-boards/ja/resources/Fig4_DailyBurndown.jpg)
https://www.infoq.com/jp/articles/agile-kanban-boards/
上の図はとあるプロジェクトの実際の変異だが、予想の青線と実際の赤線はだいぶ動きが異なる。
バーンダウンチャートはその背後の動きも伝えてくれる。
例えば
タスクを見直したことで計画の見直しを行い、不要と思われる機能を削除した
機能が追加されたことで、残タスクがむしろ増えてしまった！
などなどである。
このように、事実をありのまま、しかもみやすく伝えてくれるバーンダウンチャートを使うことで、利害関係者への説明は楽になる
アフィニティ見積もり
相対的サイズに選別する方法
XS
S
M
L
XL
の5種類に分類し、見積もりを行う。
その後、それぞれのサイズにポイントを振り分ける。
XXS : 1
XS : 2
S : 3
M : 5
L : 21
XL : 55
XXL : 144
これらの数字は、「フィボナッチ数列」と呼ばれ、大きいサイズのものほど、感覚があく という特性がある
時間見積もりは、チームがフラストレーションを感じてしまう。
- 2時間で見積ったのに10時間かかってしまうと、イライラし、プロフェッショナルらしくないと感じてしまう
ポイントに変更すると、この問題はなくなり、さらに見積もりが良くなった
リファレンスストーリー
相対サイズの見積もりとは、これからやろうとする仕事と、よく知っている仕事や経験がある仕事を、大きいか小さいかを比較すること。
様々なサイズのリファレンスストーリーを選び、「ものさし」を作成するのが良い。
リファレンスストーリーが時間の経過とともに古くなったら、チームがよく知っている新しい仕事に置き換え、常に更新する。
アフィニティ見積もり
簡単に出せる
大量のPBIを一気に見積もれる
プランニングポーカー
スプリントの中に入れられる直前のバックログアイテム
中身をよく理解できる
見積もりの重要な点
決して、チーム間で見積もりを標準化しない。
決してチーム間でベロシティを比較しない。
ベロシティではチームは比較できない。
チームごとに、単位は異なるため。
ベロシティの傾向はチーム間で比較できる。
加速したチーム
減速したチーム
変わらないチーム
トレンドを比較することで、スクラムコーチが集中するべき領域が見つけられる
リリースは、MVPの考え方を適応する
フロー管理ツール
トヨタ・ウェイの減速7番で、目に見える管理に重点を置いている
最近は電子ホワイトボードツールを使っている。
miroなどが良い例。
具体例
スプリントボード
スプリントゴール
スプリントバックログ
スプリントバーンダウンチャート
障害物リスト
制約理論と継続的なフロー
理想
ゴール設定
Readyとして、スプリントバックログに追加
インクリメントを出して、DONE
現実には、制約理論が発生する
スウォーミングを導入する手順
上流工程の入力を減らす
ボトルネックとなる箇所に たとえ自分の専門領域外でも 戦力を集中する
入力を少しだけ増やす
2と3を繰り返す
バックログのタスクを早く終わらせるには
一人一人の作業の量、粒どを小さくし、まっている人を少なくする。
しかし、一人一人の作業の粒どを小さくしすぎると、コミュニケーションの面でボトルネックが発生する可能性がある。
ある程度まとまった作業を一人の人間に任せることで、一人のパフォーマンスに当てることができる。
事例: ゲーム開発会社
ボトルねっ解消
Candy Crashの具体例
バリューストリームマッピングとスクラムを適用した結果、プロダクトが劇的に高速化した事例
サムさん
アイデアが出てから世に出るまで
ゲームのアイデアを思いつき、提案書を作る(2時間)
コンセプトプレゼンが、1ヶ月後に4時間かけてプレゼン
しかし、作るゲームは8個、すでにキューが溜まっていた。
6ヶ月後、Lisaがリソースをかけてアサイン
グラフィックデザインに1ヶ月
グランドデザイン6ヶ月
5ヶ月かけて結合&デプロイをした
これらをバリューストリームマッピングをした結果、リードタイムは25ヶ月かかっていた。しかし、実際のプロセスタイムは3.5ヶ月
プロセス効率は 3.5/25 = 14%
ゲームは古くなる
試乗のタイミングを逃す
チームの指揮が下がる
最悪...
その後、
インクリメント
プロダクトに追加される成果物は以下のようなものがある
ソフトウェア
ハードウェア
研究結果
新しいプロセス
インクリメントはプロダクトゴールの達成に向けた具体的な足がかかり、完成の定義を満たす、全ておnバックログアイテムのそうわである。
完成の定義はプロダクトのインクリメントに対する確約
各インクリメントは、以前のすべてのインクリメントに追加された状態
アジャイルでのイテレーションの回し方
今回はアジャイルプロジェクトのイテレーションの回し方について扱う。
プロジェクトマネジメントの背後にある仕掛けやイテレーションを使用した仕事について。
アジャイルのイテレーションの目的:価値ある成果を毎週届ける
アジャイルの計画段階or要件定義段階で作ったユーザーストーリーorインデックスカードがある。
これをリリース可能なちゃんと動くソフトウェアに変換する方法について今回学ぶ。
アジャイルなイテレーションとは、期間を固定したタイムボックス（1~2週間)のことだ
イテレーションのゴールはお客さんにとって価値のあるソフトウェアを届けることだ。
最終的にはイテレーションの期間内にテスト済みのちゃんと動くソフトウェアを実装しなきゃいけないということだ。
イテレーションの途中での変更はNG
優先順位が変わったとか、予期せぬ事態が発生したなら、そのイテレーションが終了した時点で軌道修正する必要がある。
ただし、イテレーションの途中では作業対象のストーリーを変更しないのが普通だ。
アジャイルなイテレーションの回し方
分析して設計する（作業の段取りをする）
開発する（実際に作業する）
テストする（作業の結果を確認する）
アジャイルなイテレーション1:分析と設計
アジャイルでの分析には二つの重要な柱がある
必要な分だけを
必要な時に
つまり分析しすぎてもダメだし、分析しなさすぎてもダメだ
最初はインデックスカードだったものが、次第に1つのページになったりする。
同じ職場で働いているならば、インデックスカードと会話のみで文書は要らないはずだ。
デスクが離れている場合などでも、概要を1ページにまとめた文書や、ストーリーをタスクに分解したリスト、テストの条件一覧などはあってもいいかもしれない
アジャイルの分析のタイミング
アジャイルの分析のタイミングはギリギリで問題ない。
なぜなら
顧客「あ！そのストーリーなんだけど使わなくなったわ！ごめん！」
ということが平気で起こるからだ。
アジャイルの設計書1:フローチャート
手始めにフローチャートを書いてみよう。
目に見える形で、システムの動作や必要な手順をシンプルに示してくれる上に、考慮もれがなくなる。
また、業務フローの観点から把握するべきことに注釈をつけておくこともできる。
アジャイルの設計書2:ペルソナ
システムのユーザーがどんな人たちで、どんなことをしようとするのか、そうしたことへの理解を深めるのにペルソナは役立つ。
ソフトウェアのユーザーを役割ごとに簡単に説明したり、典型的な姿として描いたものがペルソナである。
ペルソナはリアルな人間であり、解決したい課題を抱えている。
彼らの課題に応えることができれば、ニーズに答えたシステムになるはずだ。
アジャイルの設計3:デザイン(ペーパープロトタイピング)
デザインする弾では好き放題で良い。
どんどんプロトタイプを作っていこう
アジャイルの設計4:テスト条件の書き出し
テスト条件はインデックスカードの裏面に書いていく
特に顧客に対して「どうしたらこの機能がうまく動いているってわかりますかね？」と訪ねていく。
補足：アジャイル以外について
備考
title:アジャイル開発における設計書【アジャイルサムライその4】
description:アジャイルの分析のタイミングはギリギリで問題ない。なぜなら。顧客「あ！そのストーリーなんだけど使わなくなったわ！ごめん！」ということが平気で起こるからだ。
img:https://eh-career.com/image/article_hub/40/41/140_01.jpg
category_script:True
スクラムマスターが置かれる状況と、その打開策（ケーススタディ）
スクラムパターン
スクラムマスターが取り入れることができる、ベストプラクティスがスクラムパターン。
あくまでベストプラクティスなので、取り入れるかどうかは自由。
1. どのように始めるのか
Readyのバックログ。
2. 安定したチーム
チームメンバーのパフォーマンスを安定させるためには、以下の二つを意識すること
専任のチーム。可能な限り「兼任」は割けること。この割合を「専従率」と読んでいる。
少人数のチーム。チームの人数は2,3人から6人まで下がるが、10人以上で爆発的に上がる。
これは、コミュニケーションのパスが指数関数的にあがるからである。
n人の人数であれば、(n-1)+(n-2)+(n-3)+...+3+2+1である。
また、新規参入者を追加すれば、人数分のコミュニケーションコストがかかる
3. 昨日の天気
スプリントが完了した後、スクラムマスターは直近のベロシティだけを計測するべきではない。
可能であれば、「直近3スプリント分の平均」を設定するべきである。
また、外部からの期待値をそのまま受け入れて、その通りにPBIを追加してしまうと自分でハードルを上げてしまうことになる。
基本的には「直近3スプリント分の平均」で対応するべきである。
4. スウォーミング
タスクは集中するべし。
同時に複数のサービス調査するべきでないし、同時に複数の昨日の実装をするべきではない。
※スウォーミングとは、「ソフトウェア開発の文脈では，一つのタスクや開発トピックにチームの全員 (全員ではなくても，多人数) で取り組むことを指します．」
スウォーミングのメリットとして、
- 知識の共有をおこない、属人かを防ぐ。
それぞれのメンバーが別々の開発アイテムを勧めていると、知識の共有化ができない、その人間の能力がボトルネックになる
タスクの切り替えの発生による、切り替えのムダ、待ちのムダを防止することができます。
- 課題解決までのリードタイムを短縮する
ソフトウェア開発は課題にぶつかることの連続であり、誰かが知っているということは多いので、わからない→迷う→調べる→悩む→相談する という長いリードタイムよりも、その場に知っている人間が全員揃っていれば、チームの最大速度でアイテムを消化することができます。
5. 割り込みのパターン
予期せぬ事態。計画できない仕事のことを「割り込み」と呼んでいる。
スプリントでは、1週間で計画を建てて実行するため、この「割り込み」は致命的になる。
この「割り込み」が発生するときの対策としては 「割り込みが発生することを見越して、空のバックログを作っておく」 のがよい
名前は「Buffer」と呼ぶ。
割り込みの予測の方法は「過去に発生した割り込み」の平均を出す。
-> POはチームがやることの優先順位をつける責任をもつため、割り込みが発生しそうになった時に優先順位をつけるのは「POがやる」
6. スクラム緊急手術
スプリントの途中で、スプリントが失敗するのが明らかになったとき
工夫 : まずは何か違うやり方がないか、チームの作業方法を更新sるう
肩代わり : 他のチームで対応することができないか
スコープを減らす : プロダクトオーナーと協力してスプリントバックログのスコープを削減する。
スプリントを中止して再計画する
7. ハウスキーピング
欠陥のないプロダクトを作るスクラムパターンが「ハウスキーピング」
バグを直す最高のタイミングは「発見したとき」である。
現在のスプリントでの欠陥は：直すだけである。再見積もりはしない
過去のバグの欠陥の修正は ：POに確認し、チームが労力を言見積もる
振り返りが寡黙なケース
- 条件
委託先の協力パートナー4名
自社3名のチームで
過去に2回失敗している。指揮はとても低い。
- 推定される原因
やらされている間
失敗したので指揮が低い
委託先なので、指揮が低い、
諦めている。
7人いると発言がしずらい
心理的安全性がとても低い状態。
- 考えられる対策方法
3,4人のチームに分けて、議論させる。
スクラムマスターとして、委託の人と1on1して個別に話を聞いてみる。
人数を分ける際の年齢層を、近くして意見を出させやすくする。
アンケートを使って、匿名で幸福度を出す。
ダメなPO
桑名さんは顧客周りで忙しです。
マネージャーは彼女がいない間の代理として吉川を指名した。
吉川は3スプリント続けて、スプリントレビューにエンドユーザーやステークスホルダーを連れてくることができなかった。
吉川は物事を理解することが苦手で、
- どう感じるか?
POはクソだな。
POへの不信感が高まっていく。
- やるべきこと
吉川さん、桑野さんはレビューをするべき場所ではない。
お客さんを連れてくることができない場合、直接役員レベルの人間に交渉してもに言いに行ってもいい可能性が高い。
親会社の方が意思決定力があるのであれば、POは親会社が務めるべきではないか?
ようは、「誰に権力があるのかの見極め」が大事。
意思決定権限表のマトリクスを作っておくと良い。
意思決定をできる人を分割し、
Aさんは OOからxxまでやってください
Bさんは aa~からzzまでやってください
など、
何をするべきなのかの表を作っておくことが大事。
繰り返される持ち越しバックログ
7つのバックログアイテムのうち、3つしか完成できなかった
- 原因
見積もりが甘い
割り込みが考慮できていない
メンバーにとってタスクが重い
完成の定義が多すぎる
上からの圧力で、できない量をやらされている
- ポイントを振り直す
スプリントの計画がうまく行っていない時は、「昨日の天気」をうまく使い、バッファーを作成する
別チームに依頼する
機能を減らす。
POが頑張って割り込みを防ぐ。
スウォーミングを導入する。
スコープの調整
マネジメントを抑えられる人に相談する
フラッシュビルドの実装。
フラッシュビルドの実験として、
サングラスを売るお店で、サングラスを選ぶためのiPadアプリを作成する。
「サングラスを選ぶipadアプリ。
機能は決まっていない。
ユーザーストーリーマッピングの構築
行動やプロセスを知る。
ラフなプロトタイプを見せる作業で、捨てたり変更できたりする。
ペーパープロトタイプを作る。
アナログなやり方でも、Ipadアプリと同じものを作る。
エンジニアはペーパープロトタイプを動かして、
フラッシュビルドを行う。
最終的なアイデアは、サングラスを欠けている写真を比較する。
アプリを横向きに固定する。
このプロジェクトを確認するポイント
プロダクトの価値を高めるために行っていたことは何か?
- 顧客の近くで開発を行うこと
プロダクトをより早く届けるために何をやっていたか?
- エンジニア、セールス、顧客が同じ場所で開発すること。
アジャイルなプロジェクトに途中から変えていく
アジャイルなプロジェクトに変えていく方法はいくつか存在します。
そもそもなぜあなたがアジャイルなプロジェクトに変えたいと思うかといえば、それはおそらく次のいずれかの理由に該当するでしょう
現在のプロジェクトが機能していない
なるべく早く結果を得る必要がある
あなたのプロジェクトの問題が、外部との調整に起因するのであれば、今すぐインセプションデッキを作るべきでしょう。
あるいは全てのデッキを組み上げる必要はなくとも、次の全ての質問に答えられなければなりません。
なぜそこにいるのか
達成しようとしていること
顧客は誰か
動かさなければならない大きな岩は何か
誰が決定権を持っているか
これらの質問について万が一答えられない場合、あなたがやるべきことはインセプションデッキを組み上げることでしょう。
アジャイルでとにかく速度を上げたい
途中からのプロジェクトでアジャイルを導入することで速度を上げたい場合、
あなたは今のプロジェクト計画を捨てるべきである。
そして、新しい計画を、信じることのできる計画を立て直すのだ。
あたかもぜろからアジャイルな計画を立てるように進めよう。
マスターストーリーリストを作って
リストの規模を見極めて
そこに載せているフィーチャに優先順位をつける。
そこまでできたら、最小限の機能でいいからお客さんのところにフィーチャーを届けてみよう。
アジャイルでとにかく進捗を示したい時
もしも当初の計画を覆すことはできない状況下である場合。
プロジェクトが進捗していることを示さなければならないのだとしたら、とにかく何か価値ある成果をあげることに集中することから始めよう。
最初は1つか2つでいいので、お客さんにとって価値のあるフィーチャーを選んで、それを実装する。
この時選んでもらったフィーチャーはちゃんと「完了」させること。
君が成果をあげられる存在であるということをお客さんに示せれば、段々状況も代わりプロジェクトの責任も任せてもらえるだろう
アジャイルでお客さんが新しい要求を発見したら
お客さんがソフトウェアで本当に実現したいことに気づいたら、それを 「本当にやりたいか？」 をまず問立てよう。
（大抵ソフトウェアに追加される機能の80%は必要ないからだ。）
それでも必要な場合は次のステップに映る必要がある。
まずこの話をするときに、君は感情的になる必要はない。
なぜなら、苦渋の決断をするのは君じゃないからだ。
君はただただ、対話をつなぐ存在でありさえすれば良い。
どちらを選んだほうが良い結果になるかを中立的に判断するんだ。
そして顧客の選択肢は主に二つある
期日を伸ばしてもらう
それほど重要でかにストーリーをスコープから外してもらってもいい
（可能であればこの決断を下し、機能の要件を考えた顧客の名前をソフトウェアに刻みたいところだが...）
君の責任は、お客さんに、自分の下した決断の与える影響を自覚してもらうことにすることだ。
アジャイルで思っていたほど進捗がよくないとき
イテレーションを3〜4買いこなしてみたところ、チームのベロシティが思ったほど高くないことが判明した。
この場合は慌てず、お客さんに実績を踏まえて、プロジェクトへの期待をマネジメントする必要がある。
それにこういう事態のために、お客さんにも前もって「最初に立てた計画を過信しないで欲しい」と伝えておいている。
ここで重要なのは
開発速度が上がらないという事実について話し合うこと
お客さんに選択肢を持たせること
この二点だ。
アジャイルでメンバーがいなくなったら
かけがえのないチームメンバーを失ってしまったとき、その影響を測ることは一筋縄ではいきません。
チームにとって大きな打撃になるのはわかっているが、どれくらいの影響なんだろうか？
結論から言うと、影響を正確に測る必要なんてない。（あえて科学的に根拠の基づいた値を伝える必要はない）
なぜならば、プロジェクトメンバーがかけた後に進捗が悪化することなどお客さんであっても目に見えているからだ
したがって期待のマネジメントも問題ないだろう。
しかしながら、2~3イテレーションした後にどれくらいの影響があったかは報告しなければならない。
上司「そうは言っても新しいメンバーは前よりも優秀だから進捗は悪化しないよ！よかったね！」
そうかもしれないが、悪化する要因は確実に一つはある。
それは新しいメンバーに対して次のコストが発生するからだ。
環境構築コスト
プロジェクト把握コスト
設計読み取りコスト
それに、新しいメンバーの履歴書に一才ハッタリがないとは限らない。
一緒に働いてみるまではわからないことを自分に、顧客に命じておく。
page:https://minegishirei.hatenablog.com/entry/2024/04/25/212014
