スクラム再入門

1. スクラム再入門横道稔 RightSegment 浅岡陽子 GameTailor 井辺拓男 Smalgo 茅野祥子 Dynalyst 田中正巳 TAO 中村州一朗 GameTailor 二藤部恵理 Amebaリワード本間貴真 CAMP 2015-03-19 株式会社サイバーエージェントアドテクスタジオ「リーン/アジャイル開発プロセスゼミ」

2. 「リーン/アジャイル開発ゼミ」とは？

3. 「リーン/アジャイル開発」ゼミとは ● サイバーエージェントアドテクスタジオ内制度 ● 「スキルアップゼミは、参加自由の勉強会とは異なり、大学のゼミと同様に少数メンバーにて研究を行います。研究の成果を事業に活かすことを目的とします。」

4. 「リーン/アジャイル開発」ゼミとは ● リーンソフトウェア開発、スクラム、XP、カンバン、リーンスタートアップなどのアジャイル手法の原理、原則、本質を学び、現場に活かす（形式知の習得） ● 各現場の開発プロセスパタンの作成などを通じて、暗黙知の形式知化（共有化）に寄与する SECI モデルでいうこのへんをまずやろうとしている。

5. 「アジャイル開発」とは？

6. アジャイル宣言とその経緯 ● 2001年に、軽量ソフトウェア開発手法との分野において名声のある17人がスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法の重要な部分を統合することについて議論した（Wikipedia より） ● 結果、まとまらなかった。 ● しかし、それぞれが推進していた開発手法に共通する価値観を見出した。

7. アジャイルソフトウェア開発宣言 ● プロセスやツールよりも個人と対話を、 ● 包括的なドキュメントよりも動くソフトウェアを、 ● 契約交渉よりも顧客との協調を、 ● 計画に従うことよりも変化への対応を、

8. Don't DO Agile, BE Agile!

9. 近年におけるアジャイル開発（１） ● 「リーン・スタートアップ」の誕生。 ○ リーン/アジャイルを奔流とし、よりビジネスにフォーカス ● アジャイル開発のスケール ○ Scrum of Scrums ○ Spotify での事例（Scaling Agile @ Spotify） ○ リーン開発の現場（スウェーデン国家警察機関） ● エンタープライズアジャイルの本格化 ○ Disciplined Agile Delivery (DAD) ○ Scaled Agile Framework（SAFe）

10. 近年におけるアジャイル開発（２） ● キャズムを超えた？ ● ワードとしての陳腐化している？ ● 手段としてとらえた結果、多くの失敗が生まれている？　今、スクラムを改めて考えてみるときかも

11. Scrum 再入門

12. 1. スクラムオーバービュー 2. ロール：スクラムマスター 3. ロール：プロダクトオーナー 4. ロール：開発チーム ▼ ▼ ▼ Harald Walker https://www.flickr.com/photos/sonicwalker/446331388/

13. スクラムの３つの原則

14. スクラムオーバービュー３つの原則 ● 検査 ○ チームがゴールに向け正しく進捗しているか検査し、検知する ○ 成果の妨げにならないように検査の時間には制限を設ける ● 適応 ○ 検査の結果、プロセスや構成に調整が必要な場合、早急に対応を行う ○ 5つのイベント内で対応を行う ● 透明性 ○ 結果責任を持つ者に対して全て見える化されている ex. 　　　　　　プロセスを指す用語が、関係者全員で共有されてる　　開発チームと PO で「完了の定義」を共有している　　開発チーム内で他のメンバーの作業が見えるようになっている

15. スクラムの３つのフレーム

16. スクラムオーバービュー３つのフレーム 1. 役割（３つのロール） 2. ５つのイベント 3. ４つの成果物 ▼ ▼

17. スクラムオーバービュー３つのフレーム 1. 役割（３つのロール） 2. ５つのイベント 3. ４つの成果物 ▼ ▼

18. スクラムオーバービュー 3つのロール

19. スクラムオーバービュー３つのフレーム 2. ５つのイベント 1．役割（３つのロール） 3. ４つの成果物 ▼ ▼

20. スクラムオーバービュー 5つのイベント

21. スクラムオーバービュー 5つのイベント ① ● スプリント計画スプリントのゴールを設定するプロダクトバックログからスプリントバックログを作成１つのスプリントは２〜４週間

22. スクラムオーバービュー 5つのイベント ② ● デイリースクラム　　開発チーム全員で、スプリントゴールに対する進捗を確認するMTG 　　朝会　　昨日の作業、今日の予定、現在の障害の共有

23. スクラムオーバービュー 5つのイベント ③ ● スプリントレビュースプリントの成果物のレビューを行うプロダクトの今後についてディスカッションするステークホルダーも参加が可能

24. スクラムオーバービュー 5つのイベント ④ ● スプリント振り返り KPT スプリントレビューが終って、次のスプリント計画が始まる前に行う

25. スクラムオーバービュー 5つのイベント ⑤ ● プロダクト・バックログ・リファインメントプロダクトバックログの内容や優先度をブラッシュアップするスプリント期間の５〜１５％プロダクトオーナと開発チームでアップデート

26. スクラムオーバービュー３つのフレーム３. ４つの成果物 2. ５つのイベント 1. 役割（３つのロール） ▼ ▼

27. スクラムオーバービュー４つの成果物 ● 出荷可能な製品 ○ スプリントごとに作られる ● プロダクトバックログ ○ 今後開発する機能を、優先順位付きで管理する ○ 誰でも参照、追加が出来る（優先順位変更はPOのみ） ○ プロダクトの状況が把握できるもの ● スプリントバックログ ○ プロダクトバックログから1スプリント分を細分化させたもの ● インペディメントリスト（障害リスト） ○ チームの障害になっているもののリスト

28. 認定スクラムマスター研修（2015/03/05,06 アドテクスタジオプライベート研修 by Jim Coplien）より

29. スクラムオーバービュームリ、ムラ、ムダムリムラムダは減らすもの。誰でも減らしたい例えば ● 誰も読まないドキュメントの作成はしない ● ユニットテストはいつでも必ず必要？？ ● 使い辛いツールは使わない ● コードに必要以上にコメント（ドキュメント）は書かないなど改善を繰り返すことでムリムラムダを見つけたらすぐに対応するという意識が大切

30. スクラムオーバービュー場場、雰囲気、環境を大切にする ex 開発メンバーがより働き易いチームを作る良い開発環境を作るすごしやすい社内を作る美味しいコーヒーを用意する。。。ベロシティ（生産性の指標）には成果に直接関わること以外も含める（勉強会、休暇などなど）チームのモチベーションはチームのパフォーマンスに影響する

31. スクラムオーバービュースプリント中止の儀メンバーそれぞれ、外部要因で自分のコミットを台無しにされたらフラストレーションは溜まるもの。。。。。儀式の内容 1. チームメンバー全員で集まる 2. 円を作り、中心に足を向けて仰向けに寝転がる 3. 合図によって、全員で叫んで感情を発散させる　　（ex. せっかく頑張ったのに、納期に間に合わせたのに。。。などなど） 4. へとへとになるまでやって、疲れたら、立ち上がる 5. 気分をすっきりさせて、他の作業に移る開発メンバーのモチベーションを大切にするこの手法から伝わることは開発メンバーをリソースとは考えないという点です

32. スクラムオーバービュー守・破・離の精神元々武道の考え方です。実際にスクラムに当てはめた場合は ● 守 ○ まずは形式に沿ったスクラムを実践してみる ○ ただやるのではなく、それぞれのロール、フレーム、イベントがなぜ必要なのかを理解することが大切である ● 破 ○ 守で形式に沿った事が出来る様になったら、応用してみる ○ 現状に納得出来なければ常に変化させ、試してみる ● 離 ○ 破を繰り返すと、自分チームに合った新しいスクラムの形が見えてくる ○ 自分たちの新しいスクラムを作る ○ 作るためにはメンバーにそれなりの経験を求められる守の状態に固執してしまいがちですが、スクラムとは手段ではないので改善して変化させていくことが自然であり大切である。

33. スクラムのそもそもの発端は「成功率が低く、管理者はいつも不機嫌で、開発者は常にプレッシャーにさらされ、顧客は不満足である」という問題を解消するためにできたものであり最終形態（ベストな状況）というものはありません常に検査と適応を繰り返し関わる人々を含めた環境（場）を改善、進化をし続けることが大切です

34. 2. ロール：スクラムマスター 3. ロール：プロダクトオーナー 4. ロール：開発チーム ▼ ▼ ▼ 1. スクラムオーバービュー

35. スクラムマスター 1. 役割・責務 2. 他のロールとの関わり方 ▼ ▼ 3. イベントとの関わり方

36. 『役割』と『責務』 ● チーム全員が共通認識を持てるよう必要に応じて、よく話す。 ● 中立性と客観性を発揮し、チームが問題解決出来るよう導く ● チームの成長を手助けする ● 仕事の妨げとなる障害物を取り除くスクラムマスター

38. プロダクトオーナーとの関係 ● プロダクトオーナーにサポート出来ること ○ プロダクトオーナーはROIに責任がある。 ○ プロダクトオーナーの責任に対して、スクラムマスターは ROIを最適化するプロセスが上手く回るようにする責任がある。スクラムマスター

39. ● プロダクトオーナーに確認すべきことの例 ○ プロダクトバックログは整理されてますか？ ○ 仕様や要件は明確に発信出来てますか？ ○ スクラムチームに不満は抱いていないですか？　※これらは例にすぎませんが、スクラムを進めていくことでチームも成長していくので、チームの成長度によって、スクラムマスターからプロダクトオーナーに確認すべきことは変わっていきます。スクラムマスター

40. 開発チームとの関係 ● 開発チームへサポート出来ること ○ 開発チーム出荷可能な製品として開発する責任がある。 ○ スクラムマスターは開発チームの障害を排除する責任がある。スクラムマスター

41. ● 開発チームに確認すべきことの例 ○ 効率的に協働してますか？ ○ 責任を持って開発してますか？ ○ 当事者意識を持って問題解決してますか？ ○ チームメンバーは疲れていないですか？ ○ 何かショックを受け効率落ちていないですか？ ○ 外部から何か横槍を入れられていないですか？ ○ プロダクトオーナーに不満を抱いていませんか？スクラムマスター

43. ５つのイベント ● スプリント計画 ● デイリースクラム ● スプリントレビュー ● スプリント振り返り ● プロダクトバックログリファインメントスクラムマスター

44. ● スプリント計画 ● イベント概要 ○ プロダクトバックログから次のスプリントの目標と機能を決め、タスク化していく作業 ● スクラムマスターの関わり方 ○ スプリント計画が実施されることを確認する。 ○ プロダクトオーナーと開発チームの会話と作業の場であることに重きを置く。 ○ 客観的なベロシティ値でスプリントの開発項目が、選ばれているか確認する。スクラムマスター

45. ● デイリースクラム ● イベント概要 ○ 開発メンバー同士で各自の状況を共有する ● スクラムマスターの関わり方 ○ 必要以上の議論は止めてあげる ○ 何か難しい問題が共有された場合、デイリースクラムでは解決せず、別の時間に解決するよう促すスクラムマスター

46. ● スプリント振り返り ● イベント概要 ○ 働き方、プロセス改善に関するブレインストーミング&改善アクションの取り決めを行う ● スクラムマスターの関わり方　 ○ 課題の着眼点へのアドバイスや、アクションの妥当性の確認をする。 ○ 障害はインペディメントリストに追加する。スクラムマスター

47. 4. ロール：開発チーム ▼ ▼ ▼ 1. スクラムオーバービュー 3. ロール：プロダクトオーナー 2. ロール：スクラマスター

48. プロダクトオーナー想定する聴衆もちろんプロダクトオーナースクラムマスター・チームの方も ➢ プロダクトオーナーをサポートするために ➢ プロダクトオーナーの役割を理解

49. プロダクトオーナー Overview 1. 役割・責務 2. 管理する成果物 3. スキル 4. 各ロールとの関わり方 5. 参加するイベント ▼ ▼ ▼ ▼

50. 認定スクラムプロダクトオーナー研修フィードバックリーン・キャンバス

51. プロダクトオーナー 1. 役割・責務 2. 管理する成果物 3. スキル 4. 各ロールとの関わり方 5. 参加するイベント ▼ ▼ ▼ ▼

52. プロダクトオーナー 1.『役割』と『責務』 ROI（投資対効果）の最大化チームに何かを作ってもらう＝投資 2. 管理する成果物プロダクトバックログプロダクト・バックログ＝Whatのリストスプリント・バックログ＝Howのリスト PO: 2/5

53. プロダクトオーナー 1.『役割』と『責務』　② やらなきゃならないこと ● プロダクトの機能とフィーチャーを定義し、リリースの内容と日付を決める（『期日』・『予算』・『スコープ』） ● プロダクトの収益性と投資効果の責任者（ ROIの最大化） ● 市場価値をもとに機能の優先順位を決める ● スプリントごとにフィチャー定義や優先順位を変える権利がある ● 作業結果を許可または却下する PO: 2/5

54. プロダクトオーナー 1.『役割』と『責務』　③ やらなきゃならないこと PO: 2/5 プロダクトの旗振り役がたったひとり！

56. プロダクトオーナー 3. 『スキル』　① ビジネススキルの全てを持つ人あるサイトによるとこんな感じの人らしい・・・ PO: 3/5

57. 1. 技術を活用すること技術を理解し、活用の可能性を調べられる力プロダクトオーナー 3. 『スキル』　② PO: 3/5

58. 2. 本当に大事なものだけに集中すること影響力のある社内の人間や客先の声高な要求に屈しない力プロダクトオーナー 3. 『スキル』　③ PO: 3/5

59. プロダクトオーナー 3. 『スキル』　④ その他いっぱい。 3. 時間管理自分のプロジェクトにとって本当に重要な仕事に集中する時間を作り出す力 4. コミュニケーション能力簡潔明瞭な文章を書ける。権威ではなく説得によって人を動かす力 5. ビジネススキル開発チームと社内のその他の人たちとの間の橋渡し役として、財務部門、マーケティング部門、営業部門、経営陣とともに、それぞれの分野の専門用語や考え方を使いながら仕事できる力 PO: 3/5

60. プロダクトオーナー 3. 『スキル』　⑤ そんな人いねーよこのような資質やスキルを持っている人を探し出して、トレーニング、日常的に気軽に助言を受けるためのメンタープログラム、正式な従業員開発プログラムなどを使って、育てることだ　⇒そっかそっかぁ。。って、だからその資質ある人どこにいるんだよ！それゆえにスクラムの弱点になりがち PO: 3/5

61. プロダクトオーナー 3. 『スキル』　⑥ じゃあどうするの？ ⇒育成する ⇒POチームを設ける（その場合も最終決定者は明確にする) ⇒ステークホルダーにサポートしてもらう PO: 3/5

63. プロダクトオーナー 4.『各ロールとの関わり方』　① すべきでないこと ● プロジェクトマネージャとしてふるまう ● チームのやる気を削ぐ ● なにを、いつまでに終わらせなければはらない、と指示する PO: 4/5

64. プロダクトオーナー　すべきでないこと３つの理由 4.『各ロールとの関わり方』　② その壱. プロダクトオーナーはマネージャじゃないリーダーでなくてはならない ! ⇒ リーダーはみんながついていく。　マネージャは管理者 PO: 4/5

65. プロダクトオーナー　すべきでないこと３つの理由 4.『各ロールとの関わり方』　③ その弐. チームは制約条件チームにマイナスなことはしない！じゃあ言いたいことあったらどうするの？ ⇒ 言いたいことはまずＳＭに言え！！ ⇒ 例えチームがヘッポコでポンコツだとしても　そのチームへの投資で最大の効果を得る PO: 4/5

66. プロダクトオーナー　すべきでないこと３つの理由 4.『各ロールとの関わり方』　④ その参. 信頼こそすべて！信頼しなきゃ信頼されない。信頼関係が築けない！ PO: 4/5

67. プロダクトオーナー 4.『各ロールとの関わり方』　⑤ すべきこと ● ビジョンを明確化する ● 最新のビジネス価値をデリバリーする（マクロな視点） ● チームの価値を引き出す（投資に対する効果） ● スプリントを緊急に停止する PO: 4/5

69. プロダクトオーナー 5.『参加するイベント』 1. スプリント計画 2. スプリントレビュー 3. スプリント振り返り 4. プロダクトバックログリファインメント 5. デイリースクラム ※関係がよければ全て出席していい PO: 5/5

70. ▼ ▼ 1. スクラムオーバービュー 2. ロール：スクラマスター ▼ 4. ロール：開発チーム 3. ロール：プロダクトオーナー

71. 1. 開発チームとは 2. 完了の定義 3. 良い開発チーム 4. チームワーク 5. 各イベントへの関わり方 ▼ ▼ ▼ ▼

72. 開発チームとはその『役割』と『責務』とは？・プロダクトバックログを、　出荷可能な製品として実装することに責任を持つ・毎日の「検査」と「適応」で、　ゴールの達成とプロセスの成長を行う

74. 完了の定義とは？ ● スプリントバックログの各作業について、どこまで作業をしたら「完了」とするかを決める ● 開発チームが主体で決め、POと合意する（例）「各作業について、スプリント内で必ずユニットテストとコードレビューはやろう」 ↓ 完了の定義は「ユニットテストとコードレビューが完了していること」になる。

75. 完了の定義 Done List ● 成果物を「リリース」するために必要な作業をリストアップする ● その中から「各スプリント内でどこまでやるか」、を抜き出したものが「完了の定義」（Done Listの例） ● コードレビュー ● 単体テスト ● 結合テスト ● パフォーマンステスト ● ステージングにデプロイ開発チーム「コードレビューと単体テストはスプリント内で必ずやろう」 “完了の定義”に含める項目

76. 完了の定義 Undone Work ● 完了の定義に入らなかったDone Listの残作業 ● 通常のスプリントとは別に、リリーススプリントを別途実施してリリースする（Done Listの例） ● コードレビュー ● 単体テスト ● 結合テスト ● パフォーマンステスト ● ステージングにデプロイ開発チーム「結合テスト以降は、リリーススプリントで対応しよう」 “Undone Work”

77. 完了の定義完了の拡張そもそも、リリーススプリントはムダ！もし「完了の定義」にDone Listの項目がすべて含まれていれば、各スプリント毎に成果物をデリバリー出来るはず。例えば、今は完了の定義の項目は下記のように２つだが、、、 Done List ● コードレビュー ● 単体テスト ● 結合テスト ● パフォーマンステスト ● ステージングにデプロイ完了の定義

78. チームの成長とともに、「完了の定義」を拡張していく Done List ● コードレビュー ● 単体テスト ● 結合テスト ● パフォーマンステスト ● ステージングにデプロイ完了の定義完了の拡張完了の拡張！！「完了の定義」の項目が１つ増えた。 ● 自動化などによって「完了の定義」の項目を増やしていく ● チームの成長につれて増やしていく ● 最終的にはスプリント内でいつでもリリース！ ○ リリーススプリントが必要無くなる⇒ムダが減る

80. ● 自己組織化されている ○ チームの問題はチーム自身が解決する ● クロスファンクショナルである ○ チーム全員がチームのすべての個人を助ける ○ 開発チームは多様性を持つ ● 長期安定 ○ 長期間にわたって安定したベロシティを目指す ○ チームがお互いに信頼を育み、良いチームになる良い開発チーム

82. チームワーク「群がる」すなわち、チームワーク ○ クロストレーニングを強制することで、チームは共同作業の方法を学ぶ “1度にバーンダウンさせるバックログアイテムは1つだけ！”

83. チームワーク ● 分散・並列作業ではなく、チームで「群がって」問題を解決していく ● 人と人の重なり合い ”SASHIMI” by James O. Coplien Albert Lynn

85. 各イベントへの関わり方「ロール：開発チーム」が主体になるものを抜粋してご紹介

86. イベントへの関わり方スプリント計画 ● スプリントバックログ作成 ○ 開発チームが見積もりを実施する見積もり手法「プランニングポーカー」 ● 見積の違いを見える化する ○ メンバーそれぞれが認識している仕様に、齟齬がないか確認できる ● 合意を促進する ● 全員が見積もりに参加できる Joel Bez

87. イベントへの関わり方デイリースクラム開発チームが主体となって実施する ⇒「スクラムマスターへの報告」ではない！ ● 透明性 ○ 問題が共有される ○ 『That's information!!』James O. Coplien ⇒「問題を共有してくれてありがとう！！」 ● 明らかになった問題をチームで解決する ○ チームがチームを助ける ⇒「群がる」「SASHIMI 」「検査・適応」

88. イベントへの関わり方スプリント振り返りスクラムマスターが主催 ⇒「検査・適応」していくのは開発チーム自身 ● プロセスを振り返る ● 開発チーム自身が改善策を特定する ○ 検査、適応

89. 「ロール：開発チーム」まとめ大事そうなキーワードをいくつか抜粋して「まとめ」とします。 ● 出荷可能な製品 ○ 完了の定義 ● チームワーク ○ 群がる、“SASHIMI” ● 検査・適応 ● 透明性 ○ “That's Information!”

90. アドテクスタジオでは一緒にスクラムなチームになるエンジニアを募集しています http://adtech.cyberagent.io/

スクラム再入門

Minoru Yokomichi

Transcript