More Related Content
What's hot (20)
Similar to スクラム再入门 (20)
スクラム再入门
- 1. スクラム 再入門 横道 稔 RightSegment 浅岡 陽子 GameTailor 井辺 拓男 Smalgo 茅野 祥子 Dynalyst 田中 正巳 TAO 中村 州一朗 GameTailor 二藤部 恵理 Amebaリワード 本間 貴真 CAMP 2015-03-19 株式会社サイバーエージェント アドテクスタジオ「リーン/アジャイル開発プロセス ゼミ」
- 3. 「リーン/アジャイル開発」ゼミとは ● サイバーエージェント アドテクスタジオ内制度 ● 「スキルアップゼミは、参加自由の勉強会とは異なり、大学 のゼミと同様に少数メンバーにて研究を行います。研究の 成果を事業に活かすことを目的とします。」
- 4. 「リーン/アジャイル開発」ゼミとは ● リーンソフトウェア開発、スクラム、XP、カンバン、リーンス タートアップなどのアジャイル手法の原理、原則、本質を学 び、現場に活かす（形式知の習得） ● 各現場の開発プロセスパタンの作成などを通じて、暗黙知 の形式知化（共有化）に寄与する SECI モデルでいうこのへん をまずやろうとしている。
- 5. 「アジャイル开発」とは？
- 6. アジャイル宣言とその経緯 ● 2001年に、軽量ソフトウェア開発手法との分野において名 声のある17人がスキーリゾートに会し、彼らがそれぞれ別 個に提唱していた開発手法の重要な部分を統合することに ついて議論した （Wikipedia より） ● 結果、まとまらなかった。 ● しかし、それぞれが推進していた開発手法に 共通する価値観を見出した。
- 9. Don't DO Agile, BE Agile!
- 10. 近年におけるアジャイル開発（１） ● 「リーン?スタートアップ」の誕生。 ○ リーン/アジャイルを奔流とし、よりビジネスにフォーカス ● アジャイル開発のスケール ○ Scrum of Scrums ○ Spotify での事例（Scaling Agile @ Spotify） ○ リーン開発の現場（スウェーデン国家警察機関） ● エンタープライズアジャイルの本格化 ○ Disciplined Agile Delivery (DAD) ○ Scaled Agile Framework（SAFe）
- 11. 近年におけるアジャイル開発（２） ● キャズムを超えた？ ● ワードとしての陳腐化している？ ● 手段としてとらえた結果、多くの失敗が生まれている？ 今、スクラムを改めて考えてみるときかも
- 12. Scrum 再入門
- 13. 注意（スライド公開において） ● 当スライドでは、発表時にスクラムを全くしらない方への短 時間での説明を勘案した結果、各訳語をスクラムガイドと合 わせておりません。スクラムガイドをすでにお読みの方は、 以下に読み替えてください。 ○ スプリント計画 → スプリントプランニング ○ スプリント振り返り → スプリントレトロスペクティブ ○ 出荷可能な製品 → インクリメント
- 14. 1. スクラムオーバービュー 2. ロール：スクラムマスター 3. ロール：プロダクトオーナー 4. ロール：開発チーム ▼ ▼ ▼ Harald Walker https://www.flickr.com/photos/sonicwalker/446331388/
- 15. スクラムの３つの原则
- 16. スクラムオーバービュー ３つの原則 ● 検査 ○ チームがゴールに向け正しく進捗しているか検査し、検知する ○ 成果の妨げにならないように検査の時間には制限を設ける ● 適応 ○ 検査の結果、プロセスや構成に調整が必要な場合、早急に対応を行う ○ 5つのイベント内で対応を行う ● 透明性 ○ 結果責任を持つ者に対して全て見える化されている ex. プロセスを指す用語が、関係者全員で共有されてる 開発チームと PO で「完了の定義」を共有している 開発チーム内で他のメンバーの作業が見えるようになっている
- 17. スクラムの３つのフレーム
- 18. スクラムオーバービュー ３つのフレーム 1. 役割（３つのロール） 2. ５つのイベント 3. ４つの成果物 ▼ ▼
- 19. スクラムオーバービュー ３つのフレーム 1. 役割（３つのロール） 2. ５つのイベント 3. ４つの成果物 ▼ ▼
- 28. スクラムオーバービュー ３つのフレーム ３. ４つの成果物 2. ５つのイベント 1. 役割（３つのロール） ▼ ▼
- 29. スクラムオーバービュー ４つの成果物 ● 出荷可能な製品 ○ スプリントごとに作られる ● プロダクトバックログ ○ 今後開発する機能を、優先順位付きで管理する ○ 誰でも参照、追加が出来る（優先順位変更はPOのみ） ○ プロダクトの状況が把握できるもの ● スプリントバックログ ○ プロダクトバックログから1スプリント分を細分化させたもの ● インペディメントリスト （障害リスト） ○ チームの障害になっているもののリスト
- 30. 認定スクラムマスター研修 （2015/03/05,06 アドテクスタジオ プライベート研修 by Jim Coplien） より
- 31. スクラムオーバービュー ムリ、ムラ、ムダ ムリムラムダ は 減らすもの。誰でも減らしたい 例えば ● 誰も読まないドキュメントの作成はしない ● ユニットテストはいつでも必ず必要？？ ● 使い辛いツールは使わない ● コードに必要以上にコメント（ドキュメント）は書かない など 改善を繰り返すことで ムリムラムダを見つけたらすぐに対応するという 意識が大切
- 33. スクラムオーバービュー スプリント中止の儀 メンバーそれぞれ、外部要因で自分のコミットを台無しにされたら フラストレーションは溜まるもの。。。。。 儀式の内容 1. チームメンバー全員で集まる 2. 円を作り、中心に足を向けて仰向けに寝転がる 3. 合図によって、全員で叫んで感情を発散させる （ex. せっかく頑張ったのに、納期に間に合わせたのに。。。などなど） 4. へとへとになるまでやって、疲れたら、立ち上がる 5. 気分をすっきりさせて、他の作業に移る 開発メンバーのモチベーションを大切にするこの手法から伝わることは 開発メンバーをリソースとは考えないという点です
- 34. スクラムオーバービュー 守?破?離の精神 元々武道の考え方です。実際にスクラムに当てはめた場合は ● 守 ○ まずは形式に沿ったスクラムを実践してみる ○ ただやるのではなく、それぞれのロール、フレーム、イベントがなぜ必要なのかを 理解することが大切である ● 破 ○ 守で形式に沿った事が出来る様になったら、応用してみる ○ 現状に納得出来なければ常に変化させ、試してみる ● 離 ○ 破を繰り返すと、自分チームに合った新しいスクラムの形が見えてくる ○ 自分たちの新しいスクラムを作る ○ 作るためにはメンバーにそれなりの経験を求められる 守の状態に固執してしまいがちですが、スクラムとは手段ではないので 改善して変化させていくことが自然であり大切である。
- 36. 2. ロール：スクラムマスター 3. ロール：プロダクトオーナー 4. ロール：開発チーム ▼ ▼ ▼ 1. スクラムオーバービュー
- 37. スクラムマスター 1. 役割?責務 2. 他のロールとの関わり方 ▼ ▼ 3. イベントとの関わり方
- 38. 『役割』と『責務』 ● チーム全員が共通認識を持てるよう必 要に応じて、よく話す。 ● 中立性と客観性を発揮し、チームが問 題解決出来るよう導く ● チームの成長を手助けする ● 仕事の妨げとなる障害物を取り除く スクラムマスター
- 39. スクラムマスター 1. 役割?責務 2. 他のロールとの関わり方 ▼ ▼ 3. イベントとの関わり方
- 40. プロダクトオーナーとの関係 ● プロダクトオーナーにサポート出来ること ○ プロダクトオーナーはROIに責任がある。 ○ プロダクトオーナーの責任に対して、スクラムマスターは ROIを最適化するプロセスが上手く回るようにす る責任がある。 スクラムマスター
- 41. ● プロダクトオーナーに確認すべきことの例 ○ プロダクトバックログは整理されてますか？ ○ 仕様や要件は明確に発信出来てますか？ ○ スクラムチームに不満は抱いていないですか？ ※これらは例にすぎませんが、スクラムを進めていくことでチームも成長していくの で、チームの成長度によって、スクラムマスターからプロダクトオーナーに確認すべき ことは変わっていきます。 スクラムマスター
- 42. 開発チームとの関係 ● 開発チームへサポート出来ること ○ 開発チーム出荷可能な製品として開発する責任 がある。 ○ スクラムマスターは開発チームの障害を排除する責 任がある。 スクラムマスター
- 43. ● 開発チームに確認すべきことの例 ○ 効率的に協働してますか？ ○ 責任を持って開発してますか？ ○ 当事者意識を持って問題解決してますか？ ○ チームメンバーは疲れていないですか？ ○ 何かショックを受け効率落ちていないですか？ ○ 外部から何か横槍を入れられていないですか？ ○ プロダクトオーナーに不満を抱いていませんか？ スクラムマスター
- 44. スクラムマスター 1. 役割?責務 2. 他のロールとの関わり方 ▼ ▼ 3. イベントとの関わり方
- 45. ５つのイベント ● スプリント計画 ● デイリースクラム ● スプリントレビュー ● スプリント振り返り ● プロダクトバックログリファインメント スクラムマスター
- 46. ● スプリント計画 ● イベント概要 ○ プロダクトバックログから次のスプリントの目標と機能を 決め、タスク化していく作業 ● スクラムマスターの関わり方 ○ スプリント計画が実施されることを確認する。 ○ プロダクトオーナーと開発チームの会話と作業の場であ ることに重きを置く。 ○ 客観的なベロシティ値でスプリントの開発項目が、 選ばれているか確認する。 スクラムマスター
- 47. ● デイリースクラム ● イベント概要 ○ 開発メンバー同士で各自の状況を共有する ● スクラムマスターの関わり方 ○ 必要以上の議論は止めてあげる ○ 何か難しい問題が共有された場合、デイリースクラムで は解決せず、別の時間に解決するよう促す スクラムマスター
- 48. ● スプリント振り返り ● イベント概要 ○ 働き方、プロセス改善に関するブレインストーミング&改 善アクションの取り決めを行う ● スクラムマスターの関わり方 ○ 課題の着眼点へのアドバイスや、アクションの妥当 性の確認をする。 ○ 障害はインペディメントリストに追加する。 スクラムマスター
- 49. 4. ロール：開発チーム ▼ ▼ ▼ 1. スクラムオーバービュー 3. ロール：プロダクトオーナー 2. ロール：スクラマスター
- 51. プロダクトオーナー Overview 1. 役割?責務 2. 管理する成果物 3. スキル 4. 各ロールとの関わり方 5. 参加するイベント ▼ ▼ ▼ ▼
- 53. プロダクトオーナー 1. 役割?責務 2. 管理する成果物 3. スキル 4. 各ロールとの関わり方 5. 参加するイベント ▼ ▼ ▼ ▼
- 55. プロダクトオーナー 1.『役割』と『責務』 ② やらなきゃならないこと ● プロダクトの機能とフィーチャーを定義し、 リリースの内容と日付を決める （『期日』?『予算』?『スコープ』） ● プロダクトの収益性と投資効果の責任者（ ROIの最大化） ● 市場価値をもとに機能の 優先順位を決める ● スプリントごとにフィチャー定義や優先順位を変える権利がある ● 作業結果を許可または却下する PO: 2/5
- 57. プロダクトオーナー 1. 役割?責務 2. 管理する成果物 3. スキル 4. 各ロールとの関わり方 5. 参加するイベント ▼ ▼ ▼ ▼
- 61. プロダクトオーナー 3. 『スキル』 ④ その他 いっぱい。 3. 時間管理 自分のプロジェクトにとって本当に重要な仕事に集中する時間を作り出す力 4. コミュニケーション能力 簡潔明瞭な文章を書ける。権威ではなく説得によって人を動かす力 5. ビジネススキル 開発チームと社内のその他の人たちとの間の橋渡し役として、財務部門、マーケティング部門、営業部門、 経営陣とともに、それぞれの分野の専門用語や考え方を使いながら仕事できる力 PO: 3/5
- 64. プロダクトオーナー 1. 役割?責務 2. 管理する成果物 3. スキル 4. 各ロールとの関わり方 5. 参加するイベント ▼ ▼ ▼ ▼
- 65. プロダクトオーナー 4.『各ロールとの関わり方』 ① すべきでないこと ● プロジェクトマネージャとしてふるまう ● チームのやる気を削ぐ ● なにを、いつまでに終わらせなければはらな い、と指示する PO: 4/5
- 66. プロダクトオーナー すべきでないこと３つの理由 4.『各ロールとの関わり方』 ② その壱. プロダクトオーナーはマネージャじゃない リーダーでなくてはならない ! ? リーダーはみんながついていく。 マネージャは管理者 PO: 4/5
- 67. プロダクトオーナー すべきでないこと３つの理由 4.『各ロールとの関わり方』 ③ その弐. チームは制約条件 チームにマイナスなことはしない！ じゃあ言いたいことあったらどうするの？ ? 言いたいことはまずＳＭに言え！！ ? 例えチームがヘッポコでポンコツだとしても そのチームへの投資で最大の効果を得る PO: 4/5
- 69. プロダクトオーナー 4.『各ロールとの関わり方』 ⑤ すべきこと ● ビジョンを明確化する ● 最新のビジネス価値をデリバリーする（マクロな視点） ● チームの価値を引き出す（投資に対する効果） ● スプリントを緊急に停止する PO: 4/5
- 70. プロダクトオーナー 1. 役割?責務 2. 管理する成果物 3. スキル 4. 各ロールとの関わり方 5. 参加するイベント ▼ ▼ ▼ ▼
- 71. プロダクトオーナー 5.『参加するイベント』 1. スプリント計画 2. スプリントレビュー 3. スプリント振り返り 4. プロダクトバックログ リファインメント 5. デイリースクラム ※関係がよければ全て出席していい PO: 5/5
- 72. ▼ ▼ 1. スクラムオーバービュー 2. ロール：スクラマスター ▼ 4. ロール：開発チーム 3. ロール：プロダクトオーナー
- 73. 1. 開発チームとは 2. 完了の定義 3. 良い開発チーム 4. チームワーク 5. 各イベントへの関わり方 ▼ ▼ ▼ ▼
- 75. 1. 開発チームとは 2. 完了の定義 3. 良い開発チーム 4. チームワーク 5. 各イベントへの関わり方 ▼ ▼ ▼ ▼
- 77. 完了の定義 Done List ● 成果物を「リリース」するために必要な作業を リストアップする ● その中から「各スプリント内でどこまでやるか」、 を抜き出したものが「完了の定義」 （Done Listの例） ● コードレビュー ● 単体テスト ● 結合テスト ● パフォーマンステスト ● ステージングにデプロイ 開発チーム 「コードレビューと単体テストはスプ リント内で必ずやろう」 “完了の定義”に含める項目
- 78. 完了の定義 Undone Work ● 完了の定義に入らなかったDone Listの残作業 ● 通常のスプリントとは別に、 リリーススプリントを別途実施してリリースする （Done Listの例） ● コードレビュー ● 単体テスト ● 結合テスト ● パフォーマンステスト ● ステージングにデプロイ 開発チーム 「結合テスト以降は、 リリーススプリントで対応しよう」 “Undone Work”
- 79. 完了の定義 完了の拡張 そもそも、リリーススプリントはムダ！ もし「完了の定義」にDone Listの項目がすべて含まれていれば、 各スプリント毎に成果物をデリバリー出来るはず。 例えば、今は完了の定義の項目は下記のように２つだが、、、 Done List ● コードレビュー ● 単体テスト ● 結合テスト ● パフォーマンステスト ● ステージングにデプロイ 完了の定義
- 80. チームの成長とともに、「完了の定義」を拡張していく Done List ● コードレビュー ● 単体テスト ● 結合テスト ● パフォーマンステスト ● ステージングにデプロイ 完了の定義 完了の拡張 完了の拡張！！ 「完了の定義」の 項目が１つ増えた。 ● 自動化などによって「完了の定義」の項目を増やしていく ● チームの成長につれて増やしていく ● 最終的にはスプリント内でいつでもリリース！ ○ リリーススプリントが必要無くなる?ムダが減る
- 81. 1. 開発チームとは 2. 完了の定義 3. 良い開発チーム 4. チームワーク 5. 各イベントへの関わり方 ▼ ▼ ▼ ▼
- 82. ● 自己組織化されている ○ チームの問題はチーム自身が解決する ● クロスファンクショナルである ○ チーム全員がチームのすべての個人を助ける ○ 開発チームは多様性を持つ ● 長期安定 ○ 長期間にわたって安定したベロシティを目指す ○ チームがお互いに信頼を育み、良いチームになる 良い開発チーム
- 83. 1. 開発チームとは 2. 完了の定義 3. 良い開発チーム 4. チームワーク 5. 各イベントへの関わり方 ▼ ▼ ▼ ▼
- 85. チームワーク ● 分散?並列作業ではなく、 チームで「群がって」問題を解決していく ● 人と人の重なり合い ”SASHIMI” by James O. Coplien Albert Lynn
- 86. 1. 開発チームとは 2. 完了の定義 3. 良い開発チーム 4. チームワーク 5. 各イベントへの関わり方 ▼ ▼ ▼ ▼
- 88. イベントへの関わり方 スプリント計画 ● スプリントバックログ作成 ○ 開発チームが見積もりを実施する 見積もり手法「プランニングポーカー」 ● 見積の違いを見える化する ○ メンバーそれぞれが認識している仕様に、齟齬がないか確認できる ● 合意を促進する ● 全員が見積もりに参加できる Joel Bez
- 89. イベントへの関わり方 デイリースクラム 開発チームが主体となって実施する ?「スクラムマスターへの報告」ではない！ ● 透明性 ○ 問題が共有される ○ 『That's information!!』James O. Coplien ?「問題を共有してくれてありがとう！！」 ● 明らかになった問題をチームで解決する ○ チームがチームを助ける ?「群がる」「SASHIMI 」「検査?適応」
- 91. 「ロール：開発チーム」まとめ 大事そうなキーワードをいくつか抜粋して「まとめ」とします。 ● 出荷可能な製品 ○ 完了の定義 ● チームワーク ○ 群がる、“SASHIMI” ● 検査?適応 ● 透明性 ○ “That's Information!”