三島teNet第9回ワークショップ アジャイルな開発とは(公開版)
•
30 likes•3,097 views
三島teNet第9回ワークショップで「アジャイルな開発とは」の講演資料です。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 三島teNet第9回ワークショップ アジャイルな開発とは(公開版)
Similar to 三島teNet第9回ワークショップ アジャイルな開発とは(公開版) (20)
More from Yasui Tsutomu
More from Yasui Tsutomu (20)
Recently uploaded
Recently uploaded (8)
三島teNet第9回ワークショップ アジャイルな開発とは(公開版)
- 1. アジャイルな開発とは アジャイルコーチ 安井 力 2015.7.29 三島teNet 「今回いちばん聞きたいこと」を 書きながらお待ちください Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 2. Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 3. 本日のアジェンダ • ソフトウェア開発における課題とは？ • なぜアジャイルなのか？ • 自己組織化ってどんな感じ？ • スクラムと組み込みの関係は？ Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 4. 一番知りたいことは何ですか？ • テーブルごとに自己紹介してください • 何を聞きに来たか共有してください Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 5. 安井 力 / やっとむ twitter:@yattom https://www.facebook.com/yattom プログラマー Java Python Ruby JavaScript テスト駆動開発 アジャイルコーチ ワークショップ 現場導入 技術支援 コンサルタント モデリング ユーザーストーリー Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 6. Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 7. 宣伝 XP祭り2015「俺も！！」 http://xpjug.com/xp2015/ Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License •開催日：2015年9月12日 (土) 10:00〜19:15 (受付開始：9:45予定) •会 場：早稲田大学理工学部キャンパス(東京都新宿区大久保3丁目4-1)
- 8. ソフトウェア開発の課題 ～アジャイルの背景～ Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 9. 鉄の三角形 スコープ(機能、仕様) 納期 予算 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 10. http://www.slideshare.net/hiranabe/project-facilitation-at-kanazawarb Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 11. 役割分担とサイロ化 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 12. スケジュールのしわ寄せ 仕様 設計 開発 テスト 仕様 設計 開発 テスト 納期 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 13. 鉄の三角形？ 「現実的に無理！」 となれば 調整している スコープ(機能、仕様) 予算期間 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 14. http://www.slideshare.net/hiranabe/project-facilitation-at-kanazawarb 距離と時間を縮める工夫と努力 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 15. 役割分担とサイロ化？ コッソリでも無理してでも話をする 順調なプロジェクトではコミュニケーションも円滑 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 16. 部分ごとに完成する 仕様 設計 開発 テスト 納期 仕様 設計 開発 テスト 仕様 設計 開発 テスト 総合テスト Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 17. ソフトウェアは複雑 • 提供する機能の複雑性 • 内部設計の複雑性 • 構築・保守作業の複雑性 • 関与する人、組織の複雑性 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 18. クネビンフレームワーク 「エッセンシャル・スクラム」Kenneth S. Rubin, 翔泳社 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 19. 複雑な問題への対処 • 方向が正しいか頻繁に確認する • 全体を把握するため常に状況をチェックする • 問題を未然に防ぎ、早期に対処する • 状況に合わせて計画を見直す • 人間同士のコミュニケーションを大事にする • 現場で判断する 「あたりまえ」の工夫 非公式な手段Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 20. うまくいくなら やればいいじゃない Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 21. ユーザーを満足させる 誰かを喜ばす そんなプロダクト 目標は…… vector free http://free-illustrations.gatag.net/2013/08/26/030000.html Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 22. http://www.slideshare.net/hiranabe/project-facilitation-at-kanazawarb Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 23. うまくいく方法 • 優れたメンバーを集めて任せてしまえばいい • そのチームで仕様からテストまで全部やればいい • 作りかけでも顧客に評価してもらえばいい • 顧客と一緒に開発すればいい • 1機能ずつ完成してしまえばいい • 完成したらすぐユーザに提供すればいい • 不具合があればすぐ直せばいい • 必要なドキュメントだけ残せばいい Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 24. 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, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 25. アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 http://agilemanifesto.org/iso/ja/ © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 26. アジャイル宣言の背後にある原則 1. 顧客満足を最優先し、価値のあるソフト ウェアを早く継続的に提供します。 2. 要求の変更はたとえ開発の後期であって も歓迎します。変化を味方につけることに よって、お客様の競争力を引き上げます。 3. 動くソフトウェアを、2-3週間から2- 3ヶ月というできるだけ短い時間間隔でリ リースします。 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 27. アジャイル宣言の背後にある原則 4.ビジネス側の人と開発者は、プロジェクト を通して日々一緒に働かなければなりません。 5.意欲に満ちた人々を集めてプロジェクトを 構成します。環境と支援を与え仕事が無事終 わるまで彼らを信頼します。 6.情報を伝えるもっとも効率的で効果的な方 法はフェイス・トゥ・フェイスで話をするこ とです。 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 28. アジャイル宣言の背後にある原則 7.動くソフトウェアこそが進捗の最も重要 な尺度です。 8.アジャイル･プロセスは持続可能な開発 を促進します。一定のペースを継続的に 維持できるようにしなければなりません。 9.技術的卓越性と優れた設計に対する不断 の注意が機敏さを高めます。 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 29. アジャイル宣言の背後にある原則 10.シンプルさ（ムダなく作れる量を最大 限にすること）が本質です。 11.最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 12.チームがもっと効率を高めることがで きるかを定期的に振り返り、それに基づ いて自分たちのやり方を最適に調整しま す。 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 30. アジャイルとは ～「うまくいく」方法の探究～ Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 31. アジャイルとは • 価値 • 動作するソフトウェア • 期間へのコミット • 改善する • チームに任せる Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 32. 価値 • ユーザーにとっての価値＝使えるプロダクト • 企業にとっての価値＝売れるモノ • プログラマにとっての価値 ＝ 正しく動作すると確認したソフトウェア • QAにとっての価値 ＝ 仕様通りか確認できる成果物 価値がある ＝ 価値があるか判断できる Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 33. 動作するソフトウェア • 動作するソフトウェアを機能単位に作る • 2～4週間ごとに完成する • 完成＝出荷可能な品質に到達する • 使ってみてのフィードバックを得る Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 34. 動作するソフトウェア！？ • 最初からプラットフォームが必要 • テストやQAは毎回おこなう • 毎回使ってもらってフィードバックを要求する • 仕様が変わっても受け入れる • 頻繁に変更や作り直しが発生する • 事前の完全な設計は不可能(変わるから) Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 35. 目指すのはユーザの価値 • ユーザは自分が何を欲しいのか知らない • フィードバックから、本当に目指すものを知る フィードバック ＞ 変更の苦労 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 36. プラクティス • 漸進的設計 • 多能工チーム • 継続的結合(CI)、継続的デリバリー(CD) • テスト駆動開発(TDD) • 受入テスト駆動開発(ATDD) • リグレッションテストの自動化 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 37. 期間へのコミット • 一定の期間の中で最大の成果を出す • 何を作るか、頻繁に確認し変更する • 顧客側に方針や機能の選択権を与える • 期間やコストへの影響も責任を持つ • 都度つど最適な判断を下し、成果を最大化する Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 38. 期間へのコミット！？ • 何ができるか、事前に約束しない • 顧客の判断次第でプロジェクトは失敗する • プロジェクト全体の詳細なWBS、 ガントチャートも作らない(変わるから) Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 39. プランニング・オニオン Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License EMZERO Vol.3(マナスリンク)より引用
- 40. ……もし気ままに計画を変更してい るなら、そうした労力はいくらかムダ になるだろう。ムダを減らすために 最終責任時点で計画しよう。最終責 任時点(Last Responsible Moment) とは、責任を持って判断を下せる最 終的なタイミングのことだ…… 「アート・オブ・アジャイルデベロップメント」James Shore, Shane Warden オライリージャパン Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 41. 将来は正確に予測できない • 複雑な問題は完全な予測に向かない • 組織、業務、市場、すべての環境は変化する • 厳然たる事実を受け入れる • その上での最善策＝常に予測し計画し続ける Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 42. http://www.slideshare.net/hiranabe/project-facilitation-at-kanazawarb Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 43. 計画し続ける 計画から逸脱したら？ 現状を踏まえた再計画 ＞ (昔作った)計画の遵守 • イテレーション(2～4週間)のたびに計画づくりをする • 直近は細密に、中長期はより大まかに • 関係者に現時点の計画と変更を周知する • 何をいつまでに判断すべきかの マネジメントが重要 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 44. プラクティス • プロダクトバックログ • 顧客同席 • イテレーション計画づくり • リリース計画づくり、四半期計画づくり • スタンドアップミーティング • 幅による見積り • リリーストレイン Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 45. 改善する • 問題を見つけて直す 1. 漏れを止める 2. 流れるようにする 3. 新たな流れを作る “3 Faces of Kaizen”原田騎郎 http://www.slideshare.net/kiroh/3-faces-of-kaizen • 全体最適を目指す • 改善し続ける • ふりかえりを定期的に実施(毎週～隔週) Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 46. チームに任せる • 優秀な人材を集め、解くべき問題を与える • 仕事の進め方もルールも任せる • マネージャ、リーダーなどを付けない • 全員ですべての仕事をする • プロダクト定義、分析、品質、開発、顧客折衝など • 個人の領域を限定せず誰もが全体に貢献する Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 47. チームに任せる！？ • 成果はチームの能力に依存 • ベストを出す方法はチーム自身が創る • 失敗は許容し、そこから学んで改善する • 役割は自然発生する • マネージャやリーダーも発生する ―― 必要なら • 誰にでも向くやり方ではない • 組織からの支援は必要 • マネジメントと呼んでもいい • 一人ひとりが全体に寄与する • 「ひとりは万人のために、 万人はひとりのために」(『三銃士』) Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 48. マネジメントゲーム • 実は「自己組織化ゲーム」 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 49. 自己組織化 • ゴールと文化を共有する • メンバー1人1人が自己判断で行動する • 状況に合わせ柔軟に適応する • 問題を解決し改善を重ね強いチームとなる • 唯一絶対の解が存在しない Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 50. サーバントリーダーシップ • チームに“仕える”リーダー • 指示を出さず、支援する • チームの気づきと成長を促す Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 51. 質問・疑問 • 「状況をチェック」ってどうやるの？ → 見える化、情報ラジエータ • サーバントリーダーは、管理部や総務の仕事？ → 雑用を引き受けるのはサーバントリーダーの一部。 チームの様子を見て自覚してない点を指摘、支えるのが だいじ。言ってて自分ができてるか胸が痛みました • 誰でもできるの？優秀じゃないとアジャイルでき ないのでは？ → 向き不向きはあるが、今までの基準とは異なる • やっとむとしての、アジャイルのいい点、悪い点 は？ → 楽しいから好き。組織や文化に合う合わないがある Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 52. 野中郁次郎らの論文 “The New New Product Development Game” ～メーカーとアジャイルの深い関係～ Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 53. Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 54. 新製品開発の「新しい」方法 • 成功した新製品を開発した様子を調査 • 国内メーカーを中心に • 富士ゼロックス、キヤノン、ホンダ、NEC、エプソン、ブラザー • ３M、Xerox、Hewlett Packard (HP) • 6つの特徴を提示 • 組み込まれた不安定さ • 自己組織化するプロジェクトチーム • 重なり合う開発フェーズ • マルチ学習 • 巧妙なコントロール • 組織へ学びを伝達する Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 55. チームが自己組織化する • 自律的 • チームのことはチームで決断する • トップマネジメントの介入は最低限(四半期報告など) • 自己超越性 • 自分の壁を自分で破り続ける • 「高品質、小型、軽量、既存品より30％コストダウン という無茶な目標を与えられ、チャレンジし続けた」 (キヤノン) • 他家受粉(cross fertilization) • 役割を相互に越え、新たな知識を生む • 「プランニング、デザイン、製造、セールス、流通、評 価の担当をすべて1部屋に集めた」(富士ゼロックス) Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 56. 開発のフェーズ “sashimi” https://en.wikipedia.org/wiki/Scrum_%28rugby%29#/media/File:ST_vs_Gloucester_-_Match_-_23.JPG “rugby” Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 57. マルチ学習と学びの伝達 • レベルをまたぐ学習 • 個人、グループ、企業 • 職能や組織をまたぐ学習 • 学んだことをさらに広げる • 別の組織 • 次の世代 • 会社全体 開発の現場で生まれた知識が 拡散・洗練を経て 企業の重大な資産となる Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 58. イノベーションを産み出し続ける組織 SECIモデル http://www.atmarkit.co.jp/aig/04biz/seci.html http://current.ndl.go.jp/ca1518 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 59. Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 60. うまくいくなら やればいいじゃない Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 61. スクラム Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 62. スクラム • ３～9名のチーム • １～４週間のスプリント • スプリントで機能を完成し提供する • Whatに責任を持つプロダクトオーナー • Howに責任を持つ開発チーム • 両者を支援するスクラムマスター • 継続して改善する • スクラムガイドで定義(全17ページ) http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 63. プロダクトインクリメント 開発チーム プロダクトオーナー スクラムマスター プロダクトバックログ デイリースクラム スプリント Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 64. スクラムの価値観 •経験的なプロセス •透明性 •検査と適応 •自己組織化 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 65. スクラムのルーツ • 日本の製造業 • 野中らの論文 • (傍流として)トヨタ生産方式とリーン開発 • 知識の創造と伝達 • パターンとパターン・コミュニティ Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 66. http://d.hatena.ne.jp/wayaguchi/20130217/1361047033 https://speakerdeck.com/kawaguti/kanban-and-scrum Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 67. Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 68. 詳しく知るには Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 69. 参考文献 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 70. 質問・疑問 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 71. 気づきの共有 •2:45まで Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 72. 休憩 (30分間) Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 73. 休憩中 チーム作り 15:15まで • いまのグループでチームになります • チームの「特徴」を探してください • メンバー全員に共通する点がチームの特徴です 例: 「男」「靴が黒」「プログラマ」「住所が同じ市」など • ただし他のチームと異なるようにしてください • 特徴を基にチーム名を決めてください 気付の共有続けてもいいよ 予告: 休憩後「カンバンゲーム」 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 74. 「ただし他のチームと 異なるように」 • 他のチームに聞きに行った人？ • チームに分けた途端に、他の人と話さなくなる • 気をつけよう！ Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 75. カンバンゲーム (別資料) Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 76. ふりかえり Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 77. チームごとに • ゲームから気づいたことを共有 • どうしたら上手くいった？ ↓以下はあとで話すので まずゲームの話に集中 • 現実の仕事にどう使えるか • 現実で起きそうな問題と対策 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 78. シャッフル！ • チームに半分は残り、半分は他のテーブルへ • できるだけバラバラに • これまでの話を共有 • 現実の仕事にどう使えるか議論 • 現実で起きそうな問題と対策を考える Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 79. ツアー • 全員で各テーブルを見物して回りましょう • 「ルール」「枠を越える発想」 • ルールを決めた人はそのへんをウロウロしてる • とりあえず捕まえて聞いてみる 価値の創造 ＞ 決められた仕事 Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 80. さいごに Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License
- 81. 最後のワーク • お礼と挨拶 • バディを見つける • 「1ヶ月後、現状どうか」と連絡する Copyright (C) 2015 やっとむ Creative Commons Attribution 4.0 International License