Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

スクラム再入門

スクラム再入門

  • Login to see the comments

スクラム再入門

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

×