Agile Scrum at Knowledge Forum 2020
0 likes674 views
2020/7/11 Knowledge forum 2020
Agile Scrum at Knowledge Forum 2020
- 2. 平鍋健児 (株)永和システムマネジメント社⻑ (株)チェンジビジョンCTO (株)Scrum Inc. Japan 取締役 福井で受託開発を続けながら、アジ ャイル開発を推進し、国内外で、モ チベーション中⼼チームづくり、ア ジャイル開発の普及に努める。ソフ トウェアづくりの現場をより⽣産的 に、協調的に、創造的に、そしてな により、楽しく変えたいと考えてい る。アジャイルジャパン初代実⾏委 員⻑。 5
- 4. スクラムマスター （⼤規模向け） エンジニア／ スクラムマスター クラウドアーキテクト クラウドアーキテクト ／スクラムマスター エンジニア スクラムマスター • 経験豊富なアジャイル／クラウド技術者による開発⽀援サービス。コーチングも可能です。 • POCから商⽤サービスの開発まで、幅広い技術領域に対応します。 • リモート開発ならではの効率性と透明性を追求。お客様とワンチームでビジネスを成⻑させます。 Point Agile Studio Fukui： アジャイル/クラウドに特化したエンジニアチームと 福井での共創・共育
- 6. こちらからご覧ください https://scruminc.jp/scrum-consulting-and-coaching/casestudies/tri-ad/
- 8. 14 『アジャイル開発とスクラム』 • 顧客・技術・経営の３者をつなぐ ために、アジャイルと⽇本経営の 接合点を探る • 海兵隊の組織とアジャイル • 知識創造プロセスとアジャイル • 実践知リーダーとアジャイル • 富⼠通・楽天・リクルートの事例 • Jeff Sutherlandインタビュー 平鍋健児＋野中郁次郎著
- 9. なぜ、 アジャイルか?
- 10. 16 市場 ビジネス IT 市場分析 発注 納品リリース 半年から３年 ミッション・リスク分割型ビジネスと ウォーターフォール型開発（従来型）
- 11. 17 従来型の問題＝要求の劣化 システムの機能の利用度 全く使われない 45%ほとんど使われな い 19% たまに使う 16% いつも使う 7% よく使う 13% • Standish group study report in 2000 chaos report
- 16. 28 組織横断 ⼀体チーム 参加 参加 参加 企画 部⾨ 開発 部⾨ 開発 ベンダー 参加 品証 部⾨ アジャイル開発(2) UX 部⾨ 参加 Analysis 部⾨ 営業 部⾨ マーケティング 部⾨
- 17. ITベンダー企業 事業 企業 ITベンダー企業 事業 会社 システム部 ⽶国(現在) 受託 システム開発 プロダクト開発 ITエンジニア システム開発 システム 納品 要件/発注 ⽇本(ユーザ企業/SI 現在) アジャイル開発 ITベンダー企業 事業 企業 ⽇本(ユーザ企業DX) 共創 開発 システム部 システム部 PO PO PO PO プロダクトオーナー アジャイル 拠点 アジャイル開発の形(受託から共創へ) 事業 会社 ⽇本(Webサービス 現在) システム部 PO ITベンダー企業 パートナー参加 プラットフォーム 提供
- 19. 32 プロセスとしてのAgile • 短いサイクルで、分析、設計、実装、テストを並列に⾏う • タイムボックス型、進化型開発 分析 設計 実装 テスト 時間 時間 要求(スコープ) 要求(スコープ)Waterfall Agile Beck 2000Royce 1970 最後に動くものができる 動くものが徐々に できあがり、成⻑する
- 20. 34 スクラムの流れ ふりかえり
- 21. スクラムの3本柱 • 透明性 – プロジェクトが順調か、判断できる情報を標 準化し、関係者全員で正しく共通理解をもつ。 • 検査 – 成果物や進んでいる⽅向がゴールに向かって いるから絶えず確認する。 • 適応 – 何か不備があった場合、ゴールの逸脱を最⼩ 限に抑えるために早期に調整する。 35
- 22. 36 スクラムでの役割
- 23. 37 スクラムのフレームワーク
- 24. 39 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツール よりも 個人と対話を、 包括的なドキュメント よりも 動くソフトウェアを、 契約交渉 よりも 顧客との協調を、 計画に従うこと よりも 変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 重要 超重要!
- 27. アジャイル開発 の現場
- 30. プロジェクトの成功は、 Moving Target 要求 R(t) システム S(t) チーム(t)R(t) S(t) Δ t 不明確かつ 不安定な要 求。 いくらよい計画を立てても、見えていなければ、プロジェクトは成功できない。POINT Δ 基盤技術 T(t) T(t)
- 31. タスクかんばん • 作業の見える化 – ToDo(未実施) Doing(実施中) Done(完了) で管理。 – 各自の作業を指示しなく ても、毎朝自発的に 作業開始。 – フォーマットは徐々に カイゼン。 タスクかんばんの例 ※バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。 作業の見える化は、「タスクかんばん」で行なう。POINT (協力：チェンジビジョンastah* チーム） 56
- 32. 助け合う
- 34. ⽇本からも海外へ発信 59
- 35. “Kanban, Successful Evolutionary Change for Your Technology Business” http://www.agilemanagement.net 60
- 37. アイディアは 現場にある
- 38. バーンダウンチャート • 進捗の見える化 – バーンダウン（下向き） – タスクかんばんと連動 – 中間成果物で は計測しない。 – メールでエクセルシート を配布したり、 サーバに置いたから 見てね、はナシ。 バーンダウンチャートの例 全体進捗は、「バーンダウンチャート」で見える化、繰り返しのリズムづくりPOINT (協力：永和システムマネジメント：チーム角谷） 65
- 39. スルーしない
- 41. p.68 ふりかえり(1) • カイゼンの気づき – Keep(良い点) Problem(悪い点) Try(次回挑戦) を出す。 – 全員で意⾒を出し、 暗黙知の共同化と 形式知化を⾏なう。「名前付け」 – 「課題－解決リスト」、とは違う。 – とにかく、カジュアルな雰囲気で 全員発⾔することで、チームの 安全性を確保する。 – 「問題vs私たち」の構図になるように。 ふりかえりシートの例 カイゼンの「気づき」を「ふりかえり」で得る。POINT 実践編：ふりかえりガイド http://www.ObjectClub.jp/community/pf/
- 43. 70
- 49. 5つの原則 • ⾒える化(Management by Sight) –⽬に⾒えるようにして、⾏動につなげる。 • リズム(Rhythm) –⼈間活動として定期的なリズムを設計する。 • 名前づけ(Name and Conquer) –気づいた概念に名前をつけておく。 • 問題 vs. 私たち (Problem vs. us) –「問題」と「⼈間」を分離する。 • カイゼン（Kaizen) –継続的に、今の⾃分たちにできる、⼩さいことから。
- 51. p.78 リズム • リズムを「デザイン」する – 四半期、⽉、週、⽇ – 会議や成果物のタイミング – ⽇次のテスト – ⽇次の朝会（毎朝１０︓００） – 週次の会議（毎週⾦曜は。。。） • 朝会、ふりかえりのタイミング • リズムが⾏動の「搬送波」 リズム（チームの鼓動）をデザインして、チームを前進させようPOINT リズムがチームのハートビ ート
- 52. p.79 名前付け • 「気づき」をキャッチ • ナレッジを， –定着 –他のチームに伝播 • 例︓ –「今⽇のお仕事」（by 坂⽥さん） –「ぬかどこ」(by 倉貫さ ん) –「にこにこカレンダー」 名前をつけないと，「気づき」が逃げて行っちゃう！POINT 名前は⼤切（写真協⼒︓平塚市博物館）
- 53. p.80 問題対私たち (Problem vs. Us) • ともすると，議論は You vs. Me You vs. Us になりがち． • 「問題」と「⼈」とを分離 • Problem vs. Usにもちこむ。 – ホワイトボードを使う – 座り⽅を替える – ペアプログラミング 不毛なゼロサムゲームから，生産的な議論へ向かうカギ．POINT You vs. Meの構図 You vs. Usの構図 問題 vs. Usの構図 問題 vs. Usの構図
- 54. p.81 カイゼン • ⼤きな改⾰でははじまらな い • ⼩さなカイゼンから • 今の⾃分たちでできること • 来週からできること • よくなっていくことを体感 しよう • ふりかえり、が強⼒な武器 • For the better tomorrow • 明⽇はきっと今⽇よりも、 いい⽇に決まっている 継続的に、今の自分たちでできることからカイゼンを。うまくいったら自分たちをホメよう。POINT
- 55. p.82 要求 タスク タスク タスク タスク 計画 イテレーション開発 ふりかえり 朝会、かんばん バーンダウン あんどんペアボード ふりかえり 色つきUML 全体構成 半日 半日一日の繰り返し １週間 マインドマップ SKMS • ⾒える化 • リズム • 名前づけ • 問題対私たち • カイゼン にこにこカレンダー
- 58. デジタルとアナログ
- 62. Trello - かんばんツール
- 64. Scrumと野中郁次郎
- 66. 最初のスクラムの本 • “Agile Software Development with Scrum” (by Ken Schwaber, Mike Beedle) の最初の⼀ ⾏は次の引⽤で始まっている。 今⽇では新製品開発の動きが速く、競争率の⾼い世界では、速度 と柔軟性がとても重要である。企業は、新製品開発に直線的な 開発⼿法は古く、この⽅法では簡単に仕事を成し遂げることが できないことを徐々に認識し始めている。⽇本やアメリカの企 業では、ラグビーにおいて、チーム内でボールがパスされなが らフィールド上を⼀群となって移動するかのように、全体論的 な⽅法を⽤いている。 -- “The New New Product Development Game”
- 69. Toyota Production System Lean Lean Software Development Kanban Lean Startup Agile Scrum XP The New New Product Development Game Four steps to the epiphany Agile and Lean Startup Patterns Manufacturing Industry in Japan 2013 Yasunobu Kawaguchi 1 2
- 70. http://www.publickey1.jp/blog/11/10_innovation_sprint_2011.html Innovation Sprint 2011 Jeff Sutherland Ikujiro Nonaka me
- 71. 149 出典: So what is the role of Management in Scrum? Management becomes Leadership -- Jeff Sutherland
- 74. Scrum Interaction 2019(2/2) 152 ソフトウェア開発を超えた。 マーケティング改⾰や組織改⾰へ。 事例発表︓ • コカコーラ • MSD(製薬) • 3M
- 75. 野中郁次郎 1 The New New Product Development Game(HBR) Scrum リレーからラグビーへ 2 The Knowledge Creating Company SECIモデル 暗黙知と形式知のスパイラルな 変換活動が、知識創造過程である 3 Managing Flow, The Wise Leadership(HBR) 実践知フロネシス 形式知と暗黙知を繋ぐ、実践知。 U.S. Marine フラクタル組織 どの階層においても、自 己相似形 4
- 84. イギリスの Bar - (パブ) 待ち合わせはパブで。その後食事にいく。 自然と会話を楽しめるセッティング。 見知った仲間がそこにいる。知らない人を 紹介される。 https://www.flickr.com/photos/orangejon/
- 85. ● 「ティール組織」や「ホラクラシー」には場の概念がない。 ● 野中理論は「場」のかたまり。これが Scrum の元に。 という話は、この本に。
- 90. Agile Studio Fukui を作ったノウハウを書きた かった ● ファシリティの設計 ● そこに住む人の設計参加 ● お客さんにもきてもらう、学生にもきてもらう ● AgileJapan 2019 で「ぼくたちのひみつきち」 ● 仲間を集めて、パターンを書こう！ ● ライターズワークショップを8回開催 ● Iba 形式で記述 ● コロナ発生！ ● でも発表 ● ＋リモート開発のパターン
- 99. 当⽇書いていただいたものも含めました ︕ https://clipport.io/invites/ab3cfd6b69db46a62e8f3833890c1ba0
- 112. 191