SCRUM BOOT CAMP
https://gyazo.com/3e21e8580eff255d7fc103edcd005c0d
基礎編: スクラムって何？
調べてみたら「スクラムはフレームワークなので自分の現場に合わせましょう」と書かれていて途方に暮れる。
wintyo.icon てっきり割と固まっているものだと思っていたけど、結構柔軟性があるんだね
ソフトウェアを作ることの目的
出来上がったソフトウェアを実際に活用することで成果を上げること
ex. 顧客や利用やの課題を解決したり、お金を稼いだ
wintyo.icon ここの意識は結構大事
アジャイル開発手法の根幹となる前提
事前に全てを正確に予測し、計画することはできない
だから細かいサイクルでフィードバックをもらって調整しながら進める
スクラムのルールセット
5つのイベント
スプリント
スプリントプランニング
1ヶ月スプリントの場合は8時間が目安
wintyo.icon 1週間スプリントだと1/4の2時間だけど、結構厳しそう。。
具体的に細かい仕様を詰めるのはリファインメントで行う
時間はスプリント10%以内が望ましい
1週間だと4時間程度
デイリースクラム
スプリントゴールやスプリントバックログの進捗確認
デイリースクラムの形式は特にない
よくある例
昨日やったこと
今日やること
スプリントゴールを達成する上で障害となっていること
スプリントレビュー
1ヶ月スプリントの場合は4時間が目安
1週間だと1/4で1時間が目安になる
スプリントレトロスペクティブ
スプリントの振り返り
3つのロール
プロダクトオーナー（PO）: プロダクトのWhatを担当
プロダクトバックログの管理者
開発チーム: プロダクトのHowを担当
3人〜9人が適切な規模
全員そろえばプロダクトを作る能力が揃う
開発チームは基本的にはプロダクトを作るために必要な全ての作業ができないといけない
wintyo.icon QAの人も開発チームに入る？そうするとQAエンジニアもプログラム書ける必要があるし、逆も然りな気がするけど、それは果たして現実的なのだろうか・・・
開発チーム内では役職やスキルなどの特定の肩書きや役割はない。開発チーム内での仕事の進め方は、開発チームのメンバーの合意のもとで決め、外部から仕事の進め方を指示されることはない、自己組織化を目指す
wintyo.icon 特定のライブラリの導入や技術的な相談とか、どうしても横断したいケースがある気がするけど、それはあくまでチーム内からの要望で外部から依頼している訳じゃないから別な話ってことなのかな🤔
wintyo.icon スキル感によっては普通にタスクを振る人ができちゃっているけど、それを完全に無くすことは本当にできるものなのだろうか🤔 ジュニアだとそういうサポートあって然るべきだと思ってしまう
スクラムマスター: このフレームワーク・仕組みがうまく回るようにする
3つの成果物
プロダクトバックログ
スプリントバックログ
プロダクトバックログを実現するための作業タスクを作る
１タスクは１日以内で終わるサイズが良い
ここで積んだタスクは基本的にはスプリント内で消化するが、必ず達成しなければいけないわけではない
無理に達成しようとすると長時間残業したり、必要な作業を省いてしまう可能性がある
wintyo.icon 分かる😔
インクリメント
実際にプロダクトに今スプリント分の内容を乗せる
正常に動作しておく必要があるため、「完成の定義」が必要
5つの価値基準
確約: それぞれの人がゴールの達成に全力を尽くすことを確約する
勇気: 正しいことをする勇気を持ち、困難な問題に取り組む
集中: 全員がスプリントでの作業やゴールの達成に集中する
公開: 全ての仕事や問題を公開することに合意する
尊敬: お互いを能力ある個人として尊敬する
実践編: どうやれば上手くいくの？
Scene No.00: 開発したいものの概要と人物紹介
よし、始めようか！！
https://gyazo.com/dfb396524bf8b4001d11518e9f28c95b
wintyo.icon 登場人物の作り込みが凄すぎる！！！ペルソナとして完璧じゃないかな🤔
Scene No.01: ロールを現場に当てはめる
プロダクトオーナーは誰だ！？
最も大事なポイントは、そのロールで求められていることに一生懸命取り組んでくれるか
スキル不足は、熱量で補える
wintyo.icon 面倒くさがっている人にお願いしたら大変なことになりそうだよねぇ。。
ロールは、スクラムチームにおいての役割をハッキリさせるためであり、肩書きや役職とは無関係
だから、「要求の決定は企画担当者の仕事だからプロダクトオーナーだ」みたいな決めつけはNG
プロダクトオーナーとスクラムマスターの兼任はNG
プロダクトオーナーの「もっとたくさん作ってほしい、もっと作り込んでほしい」という気持ちとスクラムマスターの「円滑に仕事を進めたい」という気持ちは相反しているため
Scene No.02: どこを目指すのかを理解する
どこに進んでいくの？
スクラムチームに期待されていること
どういうことを実現するのか（ゴール）
ex. 自社の製品はまだまだ魅力が足りないため、ライバル製品と同じような機能は最低限揃えたい
絶対に達成したいことは何か（ミッション）
ex. 半年以内にリリースしないと代替的にアピールするチャンスを失う
wintyo.icon 期限があることは悪いことじゃないのか🤔
インセプションデッキ
何かの開発を始める前に明らかにするために使うツール
10個の質問に答えて整理している
例
エレベーターピッチ
作るものに予算がつくほどの大きな期待がかけられている理由を知るための質問
我々はなぜここにいるのか（なぜチームを作って開発しているのか）
達成しないとスクラムチームの存在意義が失われてしあう理由を明らかにする質問
Scene No.03: プロダクトバックログを作る
いつ頃終わるんだい！？
wintyo.icon これ発注側としては非常に重要なことだけど、実装側としては辛いところだよなぁ
ブロダクトバックログにやりたいことを列挙していく
途中でやることがずれてしまうことは仕方ないが、大枠を押さえておくとある程度のボリュームを掴むことができる
バックログの優先順位はスクラムチームで決める
ステークホルダーに決めて欲しい気持ちもあるが、スクラムチームにとっての開発順序があったりするため、順序づけで考慮すべき情報は自分で取ってきて、最終的に自分達で決める
Scene No.04: 見積もりをしていく
正確に見積もれません！？
見積もり方法はスクラムでは特にルールはなく、好きなやり方でやる
見積もりは素早くやる
Scene No.05: 見積もりをより確実にする
僕なんかでいいですか？
当てずっぽうにベストを尽くす
wintyo.icon 面白い表現だねw
見積もりはどんなに精度を上げても不確実なので、素早く見積もって、実際に作ってフィードバックした方が早い
もし、疑問が解消されず見積もれないなら、無理に数字を入れるのはやめる
「見積もれない」という情報も大事
見積もれない理由が重要な項目なら、時間をかけてでも先に疑問を解消するべき
プランニングポーカーをする理由は、対話のため
もしシニアエンジニアばかりが話している状況であれば良くない兆候
場合によってはその人は見積もりから外れてアドバイザーになる
Scene No.06: この先の計画を立てる
いつ何が手に入るのか？
直近の消化ポイントの平均をとって（ベロシティという）、そこから何スプリントで終わりそうか見積もる
ただし、これはあくまで推測なのである程度バッファは持たせておく
加えて、スクラムに慣れていない場合は慣れるまではベロシティが小さいことも考慮に入れる
リリース作業は慣れていない場合はスクラムと分ける
通常スプリントが終わった後に別途リリース用のスプリントを立てる
スクラムでは、実際に終わらせた結果だけを確実なものだとしている
それ以外は全て予想や推測なため、都度見直していく
計画を見直す手間を考えるなら計画を守るためにベロシティを誤魔化したくなるかもしれないが、それは大悪手
たった1つの確実なものを失ってしまうことになる
Scene No.07: 詳細な計画を立てる
ちゃんと計画できたかな？
スプリントプランニング
このスプリントで何ができるか？
完了の定義もしておく
wintyo.icon これ気持ちは分かるけど、全てのStoryでやるの難しそうだなぁ
どのように達成するのか？
洗い出したタスクと見積もりはスプリントバックログに積む
スプリントバックログは開発チームがやりやすい形になっていたらなんでも良く、他の人が口出しするものではない
スプリントで着手するプロダクトバックログの一つひとつの項目に注目してしまいがちだが、本当に達成すべきなのはスプリントゴール。
ex. このスプリントでは、ユーザーを管理するための最低限必要なことをできるようにしよう
wintyo.icon つまり、プロダクトバックログとスプリントゴールは実際は違う？
1スプリントの計画で扱うプロダクトバックログの項目が多い場合は良くない兆候
スプリントで実現したい項目が多すぎると、確実な計画は立てにくい
確実に達成できるボリュームだけスプリントに乗せる
もしチーム外からの期待の圧によって以下のような誤魔化しをするとベロシティが信用できなくなってしまう
本当は達成できていないのにできたことにしてしまう
やらないといけないテストを少しサボってしまう
wintyo.icon 逆に作業が余ってしまったことを考えたいな🤔
スプリントプランニングは、スクラムチームで達成したいゴールに確実に近づくための活動。
期待されているリリース日や期日までに必要なものを全部揃えることを守るために、逆算した計画を作るのが目的ではない。
Scene No.08: 素早くリスクに対処する
スプリントは順調かな！？
デイリースクラムの目的
開発チームのもので、スプリントゴールを達成できるかを検査するイベント
できるだけ早く問題を見つけて、それを解決する
問題が出たらデイリースクラム後に別途会議を設ける
wintyo.icon でも1週間スプリントってそんなに期間がないから火水で何とかできないと無理そう。逆に言えば、この日のデイリースクラムが重要になるのか🤔
誰かへの進捗報告ではない
報告に意識が向いていると、問題を見つけるのが難しくなる
ありがちな例は、スクラムマスターへの報告
対策: 問題に気付きやすい質問をする
「その作業は後どれくらいで終わるの？」
「スプリントレビューの準備は順調？」
Scene No.09: 状況を上手く把握する
これって間に合うのかな？
スプリントの消化状況はバーンダウンチャートで確認できる
Scene No.10: 何が完成したかを明らかにする
だいたい終わってまーす！！
スプリントレビューは必ず動くものを見せる
動いたものを見せた方が確実にフィードバックを貰える
デモで動いたら一見良さそうに見えるが、開発目線ではまだまだリファクタしたいかもしれなくて、完成の認識にずれがある可能性がある
だから、完成の定義は重要
例
デモ手順の通りに動作する
publicメソッドのテストコードがある
調査した内容はWikiにまとめてある
最新の仕様がWikiにまとめてある
リポジトリからいつでも最新のでも可能でテスト済みのソフトウェアが取得できる
スプリントレビューは完成したものを披露し、フィードバックを得るためのもの
Scene No.11: 先を予測しやすくしておく
あともう１日あれば・・・
タイムボックスは必ず守る
この期間がはっきり決まっているからベロシティの予測が立てられる
間に合わなかったらそのまま次のスプリントに移る
スプリント期間は短いほどよい
短いほどフィードバックを得やすい
短いと作るものが少なくなるが、逆いえばその少ない量にだけ集中することができるので予測が立てやすい
タイムボックスが守れないということは、スクラムチームが未熟なことの表れ
wintyo.icon 手厳しいこと言いますね。。
例: スプリントプランニングが何日もかかる場合は、スクラムチームの実力以上のことを計画している可能性がある
とにかく扱うものを小さくする
例
先のことを詳細に計画するのが大変ならスプリントの期間に収まる分だけを詳細に計画する
リスクも１日分だけ見つける
タイムボックスがあることで、スクラムチームは成長する
守れないなら、以下のようなことを考えていく
準備不足の可能性
このイベントでやるべきことは何か
振り返りは少しずつの改善で良い
100%の解消案ではなく、1%でも前に進めるアイデアを出して、アジャイルと同じようにトライアンドエラーしていく
アクション検討のアイデア、SMART
Specific（具体的な）
Measurable（計測可能な）
Achievable（達成可能な）
Relevant（問題に関連のある）
Timely/Time-bounded（すぐできる／期日のある）
MECEというワードもあるらしい
Scene No.12: 次にやることを明確にする
少し早く終わったぞ！！
早く終わったら次のバックログに着手してOK
もちろんリファクタなど開発都合の整理とかでも良い
プロダクトバックログ自体は誰でも書いて良い
直近着手するものをプロダクトオーナーが整理している分には、下にいくら積まれていても問題ない
Scene No.13: みんなの自立を促していく
全員揃っていないけど・・・
スクラムでは、必ず守ってほしいことだけをスクラムイベントとして定義し、それ以外のことを書くロールへの責務という形で定義している
デイリースクラムの目的を理解して貰って、その上で守り続けてもらうようにスクラムマスターがサポート
Scene No.14:ベロシティを上げていく
もっと早くできないの！？
安定しているベロシティが好まれるのは、先のことを読めるからだけではなく、良いスクラムチームの特徴にもなる
見積もりの誤差やトラブルなどがあっても、安定してタスクを消化できていると考えることができるため
ベロシティを上げようと意識すると、別の悪影響が出る
わざと多めに見積もってしまう
実装を突貫工事のように片付けてしまう
ベロシティを上げたいなら、まずは作業効率をもっと上げられないか考える
Scene No.15: 問題を見つけやすくする
え？POがいないの！？
スクラムイベントで重要な情報を得るため、原則参加する
特にスプリントレビューではPOはいるべき。不参加だと、ステークホルダーの状況を知る機会を逃してしまう
POの仕事を手伝ってでも参加させることを考える
Scene No.16: 意図を明確にしておく
うまく伝わってるのかな？
実現したいことを実際に使う人たちの立場で表現してみる
→ユーザーストーリー
＜どういったユーザーや顧客＞として
＜どんな機能や性能＞が欲しい
それは＜どんなことが達成したい＞ためだ
伝えることで大事なのは機能ではなく達成したいこと
これが共有されることで全てが実現できない時に代案を出せる可能性がある
ただ形式だけなぞっても意味がない
NG例: 「ユーザーとして全ユーザーの一覧が欲しい。それは一度に確認したいからだ」
誰が一覧機能を欲しいのか、何のために必要で、一覧機能でどんなことをしたいのかが分からない
wintyo.icon ただ割と自明なケースだと書くの難しそうだなぁ
OK例: 「外出先の営業マンが今週の訪問予定を空き時間の数分以内で確認するため〜」
最低限実現したいことの意図を書く
Scene No.17: スクラムチームを支援していく
何かがおかしいぞ！？
Scene No.18: より良い状態にしていく
すぐに解決できないよ・・・
問題を発見・解消がしやすくなるようにスクラムマスターがサポートしていく
問題を事前にホワイトボードに貼り出しておくとか
Scene No.19: 先のことをいつも明確にする
今後のことがわからない！？
Scene No.20: 手戻りをなくしていく
本当に着手していいのかな？
実装するもののイメージを掴むために、ペーパープロトタイピングがある
wintyo.icon そもそもFigmaでデザイン起こしたりしないものなのかな・・・？🤔
Scene No.21: ゴールに近づいていく
あれ！？間に合わない・・・
ゴールに近づくために調整できることは、基本的にはスコープのみ
品質
基本的には落とせない
予算
突発的に人員を増やしてもパフォーマンスが上がるかは微妙なのであまり期待できない
期間
展示会など、外せない日程があるとずらすことは不可能
スコープ
削ろうと思えば削れるものはあるはず。そもそも守るべきものはスコープではなくそのソフトウェアを使って達成したいことをするため
目的達成のためであれば簡易実装で良くなる可能性がある
Scene No.22: さまざまな状況に対応する
この作業は苦手です・・・
状況に応じてリーダーシップを発揮する人を変えていく
一人ひとり全員が全てのことをこなせるようにならなくて良い。開発チーム全体でできるようになればOK
ドラッカー風エクササイズと呼ばれる、チームの特徴を掴むための活動
これまでどんな開発をしていて、何が得意なのか
どういうふうに仕事をするタイプなのか
自分が大切に思う価値は何なのか
自分はどうやって貢献できそうか
Scene No.23: より確実な判断をしていく
それぐらいはできるよね！？
コミットメントは、必ず達成するものでも、無理をしてでも守っていくものでもない
自分達がやるべきことにベストを尽くして取り組むためにある
Scene No.24: リリースに必要なことをする
やり残したことはないかい？
リリースに必要な作業は好きなタイミングで実施する
場合によってはリリーススプリントを設けるが、基本的には先にやれることは先にやっていた方が発見が早く対処しやすい
Scene No.25: 実践編で伝えたかったこと
ここからが始まりさ！？
スクラムはあくまで以下のことが提供されているだけで、これを活用しきれるかはスクラムチームメンバー次第
どこが上手くいっていないかを特定しやすい
実際に上手く行っていないことを解消する機会がある
上手く進めるためにやり方を変えられる機会がある
やり方を多少変えても影響が少ないようになっている
実践編であえて書かなかった重要な2点
スプリントレトロスペクティブ
開発をより良くするための会だが、最初は問題解決のイベントになりがちなため、意図して書かなかった
プロダクトの考え方
開発が上手く進んでいるかを考えているが、本来はプロダクトが良くなっているかを考えるべき
スクラムの本質は、チームで学んでいくための仕組みだと筆者は考えている