はじめに
私のプロジェクトでスクラムを実施するうえで参考になった資料・記事・書籍をまめておきます。
以下の項目に分けてまとめておきます。
- アジャイル
- スクラム全般
- スプリントレビュー
- モブプログラミング
- インセプションデッキ
- おまけ
1. アジャイル
Jonathan Rasmusson，「アジャイルサムライ−達人開発者への道−」，オーム社，2011
重要なことは、次の4つだと思った。
- 早くフィードバックを得る
- 仕事は小さくする
- QCDではなくスコープを調整する
- 共有と協力
平鍋健児，「初歩から学ぶアジャイル開発入門」，ET/IoT 2016 SEC先端技術入門ゼミ，2016
@Koki_jp，「アジャイルかウォーターフォールか、どちらが品質を「保証」できるのか -トヨタの自工程完結に学ぶソフトウェア開発-」
スクラムでいうと、スプリントを工程と位置づけるのは良さそう。工程間流出欠陥=スプリント間流出欠陥。
スプリント間流出欠陥をきっかけとした改善をし続ければ、チーム・プロセスの能力が早く継続的に向上していき、その効果も見やすそう。
qakink，「きょん、やっとむ、Ryuzeeらと語るアジャイル開発の本質」参加レポート，2018
鈴木雄介，「アジャイルがダメだと思う7つの理由」，2013
牛尾剛，「「Be Lazy」を極めるためには残業をしてはいけない」，2016
平鍋健児，「データモデリングなきアジャイル開発は危ういか？」，2012
平鍋健児，「テストの役割（進捗管理その２）」，2005
「1個流し」という興味深いワードが登場。
我々の業務は、可能な限り「1個流し」を実践したい。結構実践できていると思うけど。更に意識的に「1個流し」を実践したい。
2. スクラム全般
「スクラムガイド™」，2017
当時は2017年版のスクラムガイドを参照していた。
@nh321，「スクラムとは何か？〜Certified ScrumMaster 研修を受けて〜」
「プロダクトの成功」よりも「チームの成長」
「プロダクトの成功」だけに価値を置くと「限界」が早期に訪れる
「チームの成長」の先に「プロダクトの成功」があるという考え方が望ましい「時間をかけた成功」よりも「スピーディーな失敗」
「情報収集」にはそれほど価値は無い
「今ある情報で、すぐ作れるプロダクト」から得られた「フィードバックを重ねる」ことが大事
スクラムの実施報告みたいなことをすると、みんなどうしても開発の成功に目を向けやすいです。スクラムの考え方からしたら、チームの成長が観測できれば、スクラム導入の価値があったと判断して良い気がします。
デンソークリエイトで山路厚さんが「それで人は育つのか？育ったのか？」とおっしゃっていました。古畑慶次さんが「トヨタ生産方式は、自他の成長を促進させる人材育成のシステム」とおっしゃっていました。
Pete Deemer，徳武聡，「マネージャ 2.0: スクラムでのマネージャの役割」，2010
スクラムを実施しているプロジェクトのマネージャーをしていて思ったことが、記事に書いてありました。
「"マネージャ（プロジェクトマネージャ）"要らないなぁ、外から見守るだけだなぁ」と感じていましたが、やはりそうでした。
厳密には「要らない」ではなく「役割を変えなければいけない」でしたが。
3. スプリントレビュー
永瀬美穂，「そのスプリントレビューは、機能してますか？」，2017
スプリントレビューを、昔勘違いしてました。
開発チームの成果をプロダクトオーナーに、レビューしてもらう場のように勘違いしてました。
- スプリトンレビューは、プロダクトオーナーに説明する場じゃないですね。どちらかというと、プロダクトオーナーが説明する場ですね。
- 開発チーム含めた全ステークホルダが、レビューアになりますね。レビューイはいませんね。
- 当たり前ですが、完成していないものは、レビューしちゃだめですね。
Ryutaro YOSHIBA，「スプリントレビューの進め方」，2018
4. モブプログラミング
TAKAKING22，「モブプログラミングを導入するときに考えていること」，2019
TAKAKING22さんの以下の見解好きです。「モブプログラミングを通してチームの問題に早く気づく」という考え方は、うちのチームでも、うまく活用したいです。
そもそもモブプログラミングをしているときに発生する問題のほとんどは、モブプログラミング＝進め方とは関係ないことばかりです。たいていはそのチームが現在抱えている問題が顕在化しただけです。