モチベーション
👆を読んだので、今後のアクションに活かすため、また時間が経ってから簡単に振り替えれるようにメモ。
メモ
第Ⅰ部
- スクラム通りに仕事をしたからといって急になにか良くなるわけじゃない。マインドセットが重要。アジャイル宣言の背後の原則とスクラムの価値を受け入れないといけない。
- スクラムとは、組織がスプリント内で価値を提供できるかを確認するシステムインテグレーションテストだ
- 不要な仕事、MTGはやらない
- 経験主義。あるチームでうまくまわっていた方法が別チームでもうまく使えるとは限らない。
- 1つのプロダクトバックログを複数のスクラムチームで共有すると、専門性が出るが連携しづらい。1つのバックログと1人のPO、そして複数の開発チーム、という構成もあり。
- 完成の定義について、「コードレビューされている」「単体テストされている」「受け入れテストされている」等で決めるより、独自の品質やユーザビリティの基準等を決めて運用すべき。なぜならレビューされることが大切なのではなくお客様に価値を届けることが重要だから
第Ⅱ部
- プロジェクトの成功よりプロダクトの成功。満足が先、利益が後。契約やスケジュールから決まるインサイドアウトの考え方でプロダクトを作ってはだめ。
- 新技術の採用とフィーチャーの開発はプロダクトの提供価値向上に必須。これにより別プロダクトを開発する必要性を減らせる。
- 以前は、スケジュールと予算を作り、その通り実行することが成功の鍵とされていたがこれはオール・オア・ナッシングであり危険。完成したところから徐々に出荷するのが良い。その中でも分析ツール、ヒートマップ、A/Bテスト、カウンターなどを使ってうまく改善していくのが良い。
- スクラムマスターは開発チーム内だけではなく、開発チームがやっていることが会社全体として正しい方向を向いているかを気にすべき
- プロダクトオーナーがステークホルダーと開発チームの間に入って、コミュニケーションのボトルネックになってしまうことは避けるべき。もしステークホルダーと開発チームが話して、勝手に機能を作ったとしても、POはスプリントレビューで必ずそれに気づき、それが問題としてRetrospectiveで上がってきて、改善されるはず。スクラムは透明性を提供する。POの最も重要なタスクである優先順位付けをきちんと行えばこれについては問題ないはず。
- POは多くの人と関わるためコミュニケーション戦略を立てないと時間がたりない。例えば以下のようにステークホルダーを分ける。そしてグループごとに目標、連絡手段、連絡内容を考えて効率的にコミュニケーションを設計する
- 常には見なくて良い
- 常に方向する必要がある
- 常に満足させる必要がある
- 緊密に管理する必要がある
第Ⅲ部
- スクラムチームが価値基準（commitment, courage, focus, openness, respect）を取り入れ実践すると、スクラムの柱（透明性、検査、適応）が現実のものとなる。スプリントゴールを達成しようとチーム一丸になることができる。
- 意思決定ロジックの先頭は「顧客」。顧客のために何かを判断する。優先順位は顧客＞会社＞チーム＞個人
- スクラムアンチパターン4つ
- 買いだめ：スプリントプランニングで一人が複数タスクを抱え込む。どれも半端に手を出して結局どれも終わらない。
- 独り占め：一人の開発者のみで作業してしまい、協業できない
- 専門化：各自が得意なものを実装し、問題が最後まで露呈しない。結合が遅いとリスクが高い。
- 一般化：広く浅いスキルの開発者が複数のタスクに手を付け、詰まったら別のタスクを行う。結合が遅く、リスクが高い。
- 上記を解決する方法として、ペアプロ、スウォーミング、モブプロなどがある
- プロダクトバックログ、サブタスク進捗、バーンダウンチャート、ベロシティなどを積極的に公開して透明性を上げる
第Ⅳ部
- プランニングポーカーでは見積もりに使える情報を発信し、聞き、他のタスクと比較する。発信する内容としては、以下のような内容が有益
- 以前チームとしてこれをやった/やってない
- 個人として活かせるスキル/経験がある
- 以前にやったことがない
- ユーザーストーリーの形式を「XとしてYしたい。なぜならZだからだ。」とするのは、以下が理由。セキュリティについて考えるときは、クラッカーのユーザーストーリーを考えることも有益。
- どう作るかよりも何を作るかに集中できる
- ビジネスサイドにも理解されやすい
- 障害とかも含めてなんでもかんでもバグって言うと不快なので気をつける。
- バックログリファインメントでは、詳細化、見積もり、優先順位並び替えをする
- ストーリー分割チートシート
第Ⅴ部
- スプリントにしっかり区切りを持って、達成を祝うようにしないと「無限スプリント」のように感じ、やる気を失う
- スプリントゴールの悪い例/良い例。良いスプリントゴールを設定できると、何のためにこのスプリントを過ごすかを意識でき、モチベーションが上がる。
- [悪]バグを10個修正する
- [悪]7個機能を実装する
- [良]UIとパフォーマンスを改善しカートからの離脱率を30%以下にするこれにより悪い購入体験が売上を減らしている問題を解決する
- [良]ユーザーは簡単に商品を探せるようになる。このうち1つのフィーチャーを追加する。
- [良]40ドル以上で送料無料になるようにする。そうすることで単価が上がるという仮説を検証する
- スプリントゴールを立てるヒント
- スプリントレビューの目的は、フィードバックを得ること。「承認をいただけますか？」ではなく、「さぁ、このプロダクトをより良くするにはどうすれば良いと思いますか？？」と問う。すると参加者はその場の目的を理解しやすい
- デモしてフィードバックをもらうだけではなく、できればデプロイして触ってもらう
第Ⅵ部
- サーバントリーダー：リーダーはまず相手に奉仕し、その後相手を導くものである
- スクラムマスターへの基本的なアドバイス。1. チームに聞け。 2. 自分自身を不要にせよ。
- スクラムマスターはコーチしたり、教えたりはできるが、メンバーを管理する権限はない
- タスクボードや様々なデータを公開するだけでは十分な透明性があるとは言えない。適切な相手と適切な頻度で質の高い会話をすることが重要。
第Ⅶ部
- チーム部屋に前向きな雰囲気を作り出すことで、スクラムにおけるインサイト（アハ体験）を生み出す確率を上げることができ、創造的なアイデアを出すことにつなげられる
- スクラムイベントを生き生きとさせるコツ
- 聞くより話す、読むより書く、座るより動く、長くより短く、同じことより違うこと、言葉より画像。
- 具体的には、
- デイリースクラム：順番を変える、立ってやる。
- スプリントプランニング：付箋を使う
- スプリントレトロスペクティブ：フォーマットを変えてみる
- スプリント：短くする。完成の定義を絵にして壁に飾る
第Ⅷ部
- 人はリソース（ロボット、歯車、機械）ではない
- 改めて、スクラムの価値とは
- 確約：献身ということ。スプリントゴールを達成するために、献身する。
- 集中：役割ごとにうまく説明責任が分けられているため、シンプルなことに集中できる
- 公開：全員が自分のしごとや進捗、学び、問題を明らかにする。またそれが推奨されている。
- 尊敬：他の人のスキルや専門知識を尊重する。意見の違いも尊重する。顧客の心変わりを尊重する。
- 勇気：要件が決して完全ではないと勇気を持って認める。変更の検討にも勇気が必要。経験主義に基づき勇気をもってスクラムの価値を守る。
- 人間味あふれるスクラムマスター5つの特性。共感、謙虚、思いやり、信頼性、寛容。
第Ⅸ部
- スクラムの中に留めるべき（外から口を挟まないべき）こともある。留めることで安全性が上がる。
第Ⅹ部
- スクラムを教育に活かしている例がある。なに、なぜは教員が与え、どうやって、は生徒が決める。
今後のために
- スプリントバックログに積みすぎない（全部消化するというモチベーションが生まれにくい）
- 同じボードを使うけど、チームを分けるという方法も検討する
- 新技術の採用はプロダクトの提供価値向上に貢献しているか？
- 分析ツール、ヒートマップ、A/Bテスト、カウンターなどの導入を検討
- お客様に価値を届けられているかでプロダクトを評価したい
- バックログリファインメント中に優先順位並び替え時間を設ける
- 「スプリントゴールを達成するため」に、昨日のtodo、今日のtodo、困っていることをdaily scrumで伝えているか？
- スプリントレビューのやり方を再考
- スクラムの経験主義によって得られる学びはチームごとに違うはず。ではそれぞれのチームはどんな特性があり、何を得られたのだろうか？
