「アジャイル」の入り口に立つ / Entrance for "Agile"

2022-06-17 に非公開の勉強会で行った講演のスライドです。

アジャイルマニフェスト https://agilemanifesto.org
アジャイルマニフェストはどう生まれたのか https://kawaguti.hateblo.jp/entry/20110213/1297531229
50分でふりかえるアジャイルムーブメントの歴史 2017年版https://www.slideshare.net/fkino/brief-history-of-agile-movement-2017
Modern Agile https://modernagile.org/
アジャイルの「ライトウィング」と「レフトウィング」https://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
『More Effective Agile』 https://amzn.to/3mwuWIQ
スクラムガイド https://scrumguides.org/
スクラムは抽象クラス https://www.ryuzee.com/contents/blog/7131
『スクラム実践者が知るべき97のこと』https://amzn.to/3NAAFJL
Scrum.org によるスクラムの一枚絵 https://www.scrum.org/resources/scrum-framework-poster

Transcript

1. 「アジャイル」の入り口に立つ Takuya Murakami (むらみん) 2022/06/17
2. 話すこと、期待 • 小規模チームによるソフトウェア開発を行っている開発者・リーダーが開発プロセス について検討・実践をする際に抜け漏れなく考えるための「思考の出発点」を手に 入れている。 • アジャイルなエンジニアリング手法やプロセスフレームワークについて、適切な情報 を主体的に探索・取得することができる。 • スクラムフレームワークの概要を理解し、スクラムに対する「適切な期待値」を理解 する。 ◦ スクラムの詳細までは話さないよ
3. 「アジャイル」はどう生まれたか
4. https://agilemanifesto.org
5. 2001 in Snowbird • それ以前から「軽量ソフトウェア開発手法」とカテゴライズされていた 手法の提唱者・実践者17名 ◦ 当時のデファクトな開発手法に対する問題意識 ◦ 「当時のデファクトな開発手法」 = おおよそ「ウォーターフォール」という理解で充分 • 様々な手法・背景からやってきた人々が共通して持つ価値観を探る ◦ 集まった人々のバックグラウンド : XP, Scrum, Crystal, FDD, ASD, … • 参考: 50分でふりかえるアジャイルムーブメントの歴史
6. アジャイルマニフェストは何であり、何でないか • Snowbirdに集まった人々による、考え方の宣言である。 ◦ 一人称で語っている。 ◦ 「アジャイルとはこうでなければならない」を宣言したものではない。 ◦ 方法論の提示ではない。 • 2001年に「現在進行形で」書かれたものである。 ◦ ”We are uncovering better ways of developing software …” ◦ 令和の時代に見ると「？」となるものもある。 ◦ 大切なことは変わっていないが、実現するための方法は変わっている。 ◦ 当時との環境の違いを想像せよ。 AWS, Slack, Zoom, Jenkins (Hudson), …
7. Modern Agile (2016)
8. アジャイルのレフトウィング・ライトウィング (2012)
9. 知ってほしいこと • 正解はない : すべて「今」「私たちの」最適解を模索した結果 ◦ 「一人称」「現在進行形」で語るもの ◦ 状況、時代、文脈、… などの様々なものに左右される。 ◦ 実践しながら自分なりに考える、解釈する、アウトプットすることが大事
10. スクラムを知る いきなり「アジャイルを実践する」と言われても困る？ では、スクラムから始めましょう
11. スクラム • アジャイルの源流にある方法論のひとつ • アジャイルの理解の出発点として適切 (と言う人が多い, 異論は認める) ◦ スクラムはアジャイルアプローチの中でも最も規律的である。書籍、トレーニングコース、ツールが 最も揃っているのはスクラムであり、うまくいくことも実証済みである。 (『More Effective Agile』より) ◦ 「規律的」なので、規律に従うことから始められる。「守破離の ”守”」 • Ken Schwaber による 1995年 の論文が始まり ◦ (`SCRUM Development Process`)
12. スクラムは軽量なプロセスフレームワークである • プロセスフレームワーク ◦ プロセス = 配役 + 時間枠の設け方 + イベントの置き方 + 入出力定義 に従う ◦ アジャイルの「レフトウィング」の一部 • 軽量: 従うべきルールや方法が少ない。簡単に始められる。 ◦ 簡単に始められる…?? → アジャイル前史との比較 ◦ 『スクラムは抽象クラス 』という比喩がある ◦ スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な 部分のみが定義されている。 (スクラムガイド2020)
13. ScrumGuide を読もう • https://scrumguides.org/ • スクラムをフレームワークとして確立させたKen SchwaberとJeff Sutherlandが書 いている。 • スクラムの定義が書かれている。 ◦ ここに書かれていないものは、定義上はスクラムの範疇ではない。 • 2020年に更新された最新版A4で17ページ (目次やあとがき含む)。 サクッと読め る。 • 数年に1回アップデートされる。 ◦ どんどん薄くなっていく傾向にある。
14. スクラムの意図は「現状を把握するための情報流通」 • 「問題」の把握ではない。問題が何か、スクラムは教えてくれない。 • なにかを「解決」してくれない。「把握」するだけ。 • 問題が何で、どう改善すればよいかを考えるのは自分たちの責務 ◦ スクラムガイド上「不完全」な部分の実装を変えるのか？ ◦ レフトウィングのスクラム外の部分を補強するのか？ ◦ ライトウィングを見直すのか？ ◦ スクラムを「破」するのか？ ◦ 等…
15. スクラムガイドに書かれていること あえてスクラムガイドとは違う順番で説明します
16. スクラムの3本の柱 • 「透明性」「検査」「適応」がスクラムの3本の柱 ◦ Transparency / Inspection / Adaptation ◦ 透明性を高めた上で、目標への到達状況を検査し、プロセスや生成物の適応を行う。 • このあと説明するパーツは、この3つのうちの1つ以上を実現するために設けられて いる ◦ というか、実現できるように運営するべき
17. スプリント • 「1ヶ月以下の固定された長さ」でスプリントを設ける。 ◦ 昔は「1週間から4週間」って言ってたけど、近年「 1day sprint」の実践者等が現れた • 他のスクラムイベント (後述) はすべてスプリント内に行われる • 1つのスプリントが終わり次第、すぐに次のスプリントを始める
18. スクラムの What を定める • 「何を解決するために、何を生み出すか」を決める ◦ 「プロダクト」という。 ◦ スプリントごとにプロダクトに加える変更のことを「 インクリメント」という。 • プロダクトが目指す将来の状態目標を設ける。 ◦ 「プロダクト・ゴール」という。 • プロダクトに必要な変更を一覧にする。 ◦ プロダクトバックログ (PBL) という ◦ プロダクトバックログの項目 1つずつをプロダクトバックログアイテム (PBI) という。 ◦ 広義 (スクラムガイド上の説明 ) にはプロダクトゴールまでを含めて PBL とする。 • プロダクトバックログの内容に責任を持つことでプロダクトチームのROIを最大化す るのが プロダクトオーナー (P.O.)
19. スクラムで What を生み出す • スプリントの開始時に計画を立てる。 ◦ プロダクトゴールに近づくための スプリントゴールを定める。 ◦ スプリントゴールの達成のために取り組むプロダクトバックログアイテムはどれか選ぶ。 ◦ ここまでが スプリントプランニング というイベントの前半に当たる。 • 開発者 がインクリメントを生み出す。 ◦ インクリメントは 完了の定義 を満たさねばならない。 • スプリントの終了時に、生み出したインクリメントを評価する ◦ スプリントレビューという。 ◦ プロダクトオーナーがステークホルダーに向けて行う (POに向けてのデモではない )。 ◦ プロダクトバックログの更新までを行う。
20. Scrum の How の部分 • スプリントプランニングの後半では、前半で決めたスプリントゴール (why) と取り組 むPBI (what) を満たすための How を決める ◦ ここで決める実行可能な計画を (狭義の) スプリントバックログ という。 ◦ 広義の「スプリントバックログ」はスプリントゴール、取り組む PBIリスト, 作業リストの3つで構成され る。 (スクラムガイド上はこっち ) • スプリントゴール達成のために計画の見直しが必要かどうかを毎日確認する ◦ デイリースクラム という。 ◦ 報告の場ではなく、再計画の場である。 • 次スプリント以降の生産性や品質を向上させるための計画について、スプリントの 最後に考える ◦ スプリント・レトロスペクティブ という。 (いわゆる 振り返り) ◦ スプリント・レビューの内容も踏まえるので、スプリントの一番最後に行う。 ◦ 次スプリントの計画に影響するため、当該スプリント内で行う。
21. 1枚絵でスクラムのプロセスを眺める https://www.scrum.org/resources/scrum-framework-poster
22. スクラムの価値基準 (Scrum Values) • スクラムが成功するには、人々が「確約 commitment」「集中 focus」「公開 openness」「尊敬 respect」「勇気 courage」の価値観を共有している事が重要 だ、と言っている節。 • スクラムガイドでは「3本柱」の次に言及されている。 ◦ つまりかなり序盤。それだけ大事なこと。 ◦ だが、スクラムの解説でこの節が飛ばされることもしばしばある。 ◦ 自分も、初めてスクラムガイドを読んだときには「ここだけ急にエモい」と思って戸惑った。 • 今の自分の解釈: スクラムの提供するプロセスに従ってみたもののチームやプロダ クトが活き活きとしていないと感じたときに立ち戻ってみると良い。 ◦ 5つの価値基準のどれかが欠けているからかもしれない。
23. スクラム・マスター • スクラムガイドに書かれた「スクラムの定義」に沿ったスクラムが実践される責務を もつのがスクラム・マスター (S.M.) ◦ プロジェクトマネージャーやピープルマネージャーではない。 • S.M. の仕事は「最終的にスクラムマスターが不要なチームを目指すこと」と言われ る ◦ スクラムの理解を促す ◦ チームの自己組織化を促す ◦ チームの障害を取り除く手助けをする ◦ 等…
24. スクラムの話 まとめ • 透明性 → 検査 → 適応 が大事 • what と how の両面について、従うべき規律を提供してくれる • わからないことがあったらまずスクラムガイドを読む • スクラムは片翼 (left wing)。反対側 (right wing) ももちろん重要。
25. links • アジャイルマニフェスト https://agilemanifesto.org • アジャイルマニフェストはどう生まれたのか https://kawaguti.hateblo.jp/entry/20110213/1297531229 • 50分でふりかえるアジャイルムーブメントの歴史 2017年版 https://www.slideshare.net/fkino/brief-history-of-agile-movement-2017 • Modern Agile https://modernagile.org/ • アジャイルの「ライトウィング」と「レフトウィング」 https://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html • 『More Effective Agile』 https://amzn.to/3mwuWIQ • スクラムガイド https://scrumguides.org/ • スクラムは抽象クラス https://www.ryuzee.com/contents/blog/7131 • 『スクラム実践者が知るべき97のこと』https://amzn.to/3NAAFJL • Scrum.org によるスクラムの一枚絵 https://www.scrum.org/resources/scrum-framework-poster