アジャイル・スクラム再入門

 アジャイル・スクラム再入門

社内勉強会用資料

B1727a509c179b68f5d3f452b29b1bf7?s=128

Yoshiki Iida

April 15, 2018
Tweet

Transcript

  1. アジャイル・スクラム 再入門 RSGT2018, CSM研修を踏まえてパフォーマンスをあげる 開発プロセスについて考えてみる 2018/04/12 yo-iida

  2. 今日のゴール • アジャイルとかスクラムについて多少知っていて実践もして いる人向け • アジャイル、スクラムの原点から知ることで再入門する • 根底にある考え方を知ることで今後の実践の質を高めるよ うになる

  3. なぜ根底にある考え方を伝えたいか • プラクティスを説明している書籍や資料は多いが、根底にあ る考え方を理解できるものは少ない • プラクティスを実践するだけでは本質的に使えているのか 形骸化しているのかわかりにくい • 開発プロセスのパフォーマンスをもっと上げられる.. 可能性があるかも?

  4. ※プラクティスにはほぼ触れません

  5. まだ勉強中の内容でもあり、間違いやあいまいな点があると思います 気づいた点があれば付箋にメモしてください あとで議論の時間をとります では早速 →

  6. こんな疑問ない? • アジャイルってなに? • スクラムってなに? • なぜアジャイルなの? • なぜスクラムなの? •

    どこから生まれたの? • なんのためにやるの? • そうでない場合と比べてどう変わるの? • どういう関係があるの?
  7. アジャイルとは?

  8. > agile • ag・ile /ˈædʒəl/ • (動きが)機敏な,はしっこい; 〔…に〕機敏で,はしっこくて 〔in〕. •

    頭の回転の早い,機敏な,明敏な. https://ejje.weblio.jp/content/agile
  9. agileは形容詞 • × do agile. • ◦ be agile. →

    状態を表す。
  10. アジャイルソフトウェア開発 • 反復型 • 短いイテレーション • イテレーションごとに動くソフトウェアをリリースする

  11. [対比] ウォーターフォール開発 • 最後に動くソフトウェアがリリースされる • 計画主義

  12. スクラムの原典 The New New Product Development Game (1986) by Hirotaka

    Takeuchi and Ikujiro Nonaka https://hbr.org/1986/01/the-new-new-product-development-game • 製造業における新製品開発手法の論文 • ラグビーのスクラムチームのように折り重なって製品開発を 進めていくという概念を打ち出した
  13. その後・・ • Jeff Sutherlandによる最初のスクラム ◦ 論文を読んで参考になると考えソフトウェア開発に適応して実践した • Kent BeckによるXP •

    その他いろいろな手法が考案された → 当時は総称して軽量ソフトウェア開発と呼ばれていた
  14. そして2001年のある日 その界隈の17人が集まってユタ州スノーバードで合宿した そしてお互いのやっていることの共通点を整理して言語化した それが、、

  15. アジャイルソフトウェア開発宣言

  16. まとめると • アジャイルとして整理されるよりも前にスクラムの原型は作 られていた • アジャイル開発という広い概念の中にスクラムやXPが具体 的な手法として存在するが、それぞれの哲学はすこしずつ 異なる

  17. アジャイルとスクラムの関係 • スクラムができて、そのほかの似ている手法も合わせて共 通概念を言語化したのがアジャイル • アジャイル開発のうちのひとつがスクラムと言われるが、ア ジャイルが言っていることはスクラムの一部でしかない

  18. [余談]The New New Product Development Gameの解説 スクラムチームの特徴 • 不安定な状態を保つ •

    プロジェクトチームは自ら組織化する • 開発フェーズを重複させる • マルチ学習 • 柔らかなマネジメント • 学びを組織で共有する
  19. [参考文献]アジャイル開発とスクラム https://www.amazon.co.jp/dp/B00DIM66P0

  20. アジャイルに影響を与えている もの

  21. さらに過去に遡る • トヨタ生産方式 • → リーン生産方式 • → リーンソフトウェア開発 無駄を徹底的になくす

    アジャイル手法の開発者はリーンソフトウェア開発から少なから ず影響を受けている ※リーンスタートアップとは別
  22. スクラムとは?

  23. スクラムとは何か? • プロダクトマネジメントのフレームワーク • 自己組織化 • 経験主義 • 理解するのは容易だが実践するのは難しい

  24. なぜスクラムをやるのか 早期に不確実性へ対応するため 経験から学び確実性の高い動くソフトウェアを少しずつリリースし ていくため

  25. スクラムの基本コンセプト • 透明性 • 検査 • 適応 課題を見える化し、検査と適応を短いサイクルで繰り返していくこ とで不確実性を減らしていく

  26. スクラムの構成要素 • 3つのロール • 4つのイベント • 4つの生成物

  27. 3つのロールの責務 • プロダクトオーナー ◦ プロダクトのROIに責任を持つ • スクラムマスター ◦ プロセスに責任を持つ •

    開発チーム ◦ 動くソフトウェアに責任を持つ プロダクトはこれだけで開発できる マネージャーはいらない
  28. イベントと生成物 • 4つだったり5つだったり • 細かいことはプラクティスの本を読んでください

  29. スクラムマスター

  30. 要素 • サーバントリーダー • ファシリテーター • マネージャー • コーチ •

    メンター • ティーチャー • 妨害を取り除く人 • チェンジエージェント https://www.scrum.org/resources/8-stances-scrum-master
  31. やること • プロダクトオーナーと開発チームの関係を円滑にする ◦ 相互のリスペクトを生む • 完了の定義を管理する • チームの集中を保つ •

    チームに挑戦する ◦ 挑戦を促す、高い目標を目指す方向に意識を向ける ◦ 失敗させる、失敗から学ばせる ※CSM研修の資料から
  32. やってはいけないこと • 指示や命令 • 具体的な解決

  33. 靴紐の例 子供「お父さん靴紐結んで!」 → A: 結んであげる → B: 結び方を教えてあげる

  34. Controlledな失敗 たとえば、 「スプリント内にバーンダウンできそうにない」 → スプリントの途中で介入はしない → 失敗させたあとふりかえりを促す ・ストーリーの精度が悪かった? ・割り込みがあった? ・見積もりが甘かった?

  35. プロセス改善のサマリ • 検査と適応 • 自己組織化を活用 • 宗教にならない: 信頼し、信頼される • なんでもやる

    • 真剣に取り組むが、深刻にならない ※CSM研修の資料から
  36. パフォーマンス向上のために意 識したいこと

  37. MTGの質を気にする • 全員参加しているか? ◦ participateしてるか?いるだけは participateではない • 透明化されているか ◦ 議論の前提で情報格差がないか

    ◦ 自分しか知らないことがないか • 言える化 ◦ 「言ったら面倒なことになりそうだから言わないでおくか・・」 とならないような場作り • 改善のアクションに繋がっているか ◦ SMART Goalsの意識
  38. 自己組織化できているか • 不確実性を減らすための行動をチームができているか ◦ 「ストーリーの受け入れ条件が決まってないから来週ですね〜」 だと進まない ◦ 優先順位などの意思決定は POだが、何をどう作るかは開発チームが 決める

    • それぞれがオーナーシップを発揮しつつ機能横断的に動け ているか ◦ 得意な分野がうまく重なってチームのパフォーマンスが最大化するよ うに動く • 群がって仕事をする ◦ ひとつの場所に集まって仕事を進める (swarming)ことで自己組織化 を推進できる
  39. 機能横断的なチームとは Aさん Bさん Cさん Dさん Eさん チームで達成 したいこと それぞれの領域がチームで達成したいことをカバーできていない

  40. 機能横断的なチームとは Aさん Bさん Cさん Dさん Eさん チームで達成 したいこと それぞれの領域がチームで達成したいことをカバーできているが、 接続にコミュニケーションが必要

  41. 機能横断的なチームとは Aさん Bさん Cさん Dさん Eさん チームで達成 したいこと それぞれの領域がチームで達成したいことをカバーできており、 お互いがお互いのやっていることを把握している

  42. サーバントリーダーシップ • 自己組織化の文脈でそれぞれがオーナーシップを持つこと と同時にサーバントリーダーであるか ◦ チームに考えてもらう ◦ チームからバランスよく意見を集める ◦ チームに対してもフィードバックし、自分へのフィードバックもチームに

    求める
  43. まとめ

  44. まとめ • アジャイル、スクラムの成り立ち、誰がどういう考えで作り上 げたのかを知るとプラクティスの理解が深まる • 基本を理解して実践すると、守破離の破と離も実行できるよ うになる • アジャイルとかスクラムとか意識しなくても自然に改善し続 ける状態がベスト。

    目的でも手段でもなく、結果的にそうなることを目指したい。
  45. 参考になりそうなもの

  46. • 「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程 完結で全体観点で改善する - https://qiita.com/kitfactory/items/37b42c0716e1ff1efb28 • 文献紹介: The New

    New Product Development Game https://www.slideshare.net/tnoda/the-new-new-product-development-game • がんばれスクラムマスター https://speakerdeck.com/kazuhideinano/ganbaresukuramumasuta 参考になりそうなもの
  47. 質疑・議論