アジャイルとスクラムとは 原則、価値、プラクティス
•
198 j'aime•23,161 vues
アジャイルな開発の基本となる考え方である価値、原則、プラクティスの話から、アジャイルに向くマインドセットと組織について。 BSIA 第75回例会での発表資料です。 https://bsia.or.jp/corporate/reikai_75_171219/
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à アジャイルとスクラムとは 原則、価値、プラクティス
Similaire à アジャイルとスクラムとは 原則、価値、プラクティス (20)
Plus de Yasui Tsutomu
Plus de Yasui Tsutomu (20)
アジャイルとスクラムとは 原則、価値、プラクティス
- 1. デジタルトランスフォーメーションに求められる システム開発手法 アジャイルとスクラムとは ～価値、原則、プラクティス～ 安井 力 (アジャイルコーチ、フリーランス) Copyright© 2017 by 安井力 / やっとむ tsutomu.yasui@gmail.com
- 2. デジタルトランスフォーメーションに求められる システム開発手法 アジャイルとスクラムとは ～価値、原則、プラクティス～ 安井 力 (アジャイルコーチ、フリーランス) Copyright© 2017 by 安井力 / やっとむ tsutomu.yasui@gmail.com 事業開発手法
- 3. 安井 力 / やっとむ twitter:@yattom https://www.facebook.com/yattom プログラマー Java Python Ruby JavaScript テスト駆動開発 アジャイルコーチ ワークショップ 現場導入 技術支援 ファシリテーター 会議 チームワーク 仕事改善
- 5. 今日の内容 • アジャイルな企業の例 • アジャイルとはなんなのか？ • アジャイルの価値・原則・プラクティスとは？ • アジャイルに向き不向きはあるの？ • アジャイルをやってみるには？ 質問歓迎します！
- 6. ある 変わった企業 の話
- 11. 顧客による計画おりがみ
- 13. 自律的な進捗管理
- 16. ペアプログラミング
- 33. 実験？
- 47. http://agilemanifesto.org/iso/ja/ 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
- 48. アジャイルとは
- 49. Alistair Cockburn “Heart of Agile” http://alistair.cockburn.us/HeartOfAgile 2014年
- 50. https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/ Joshua Kerievsky “Modern Agile” 2016年
- 52. 1999 1995 2003 2001 参考: 1991 - Linux 1996 - Java 1.0 2001 – Windows XP 2002 - .NET Framework 1.0 1986 1994 (GoF)
- 53. アジャイルな開発の特徴 • ルール、プロセス、手法が常に変わり続けている • 結果を重視している • 「そこにいる人びと」ならでは、になっている • 顧客やステークホルダーの信頼を得ている • 市場競争力を維持している • 自主性があり、いきいきして、学び続けている
- 54. アジャイルは形容詞 agi・le [形] 素早い、敏捷、しなやかな • Be Agile, not Do Agile • アジャイル「を」やる ⇒ できない！ • アジャイル「を」使う ⇒ 誤り • アジャイル「に」開発する • アジャイル「な」態度 • 「もっと」アジャイル
- 55. 形容詞「アジャい」 • アジャい開発 • 「うちのチーム、結構アジャいんですよ」 • 我が社でもアジャイルを導入する → 我が社もアジャいくなる • 「アジャイルをやるのに必須のツールです」 → 「今よりアジャいくなるのに、お勧めツールです」 ※誰も言ってません。流行ったらいいな
- 57. 価値 • メンローイノベーションズ • 喜び • ソニックガーデン • 一生プログラマ • アジャイル • 個人と対話、動くソフトウェア、 顧客との協調、変化への対応 • スクラム • フォーカス、コミット、オープン、勇気、尊重 • XP (エクストリームプログラミング) • コミュニケーション、シンプル、フィードバック、 勇気、尊重
- 60. お仕事 頑張ってますか？
- 63. 何のため＝価値 • 価値とは ほしいもの • ただでは手に入らない
- 66. B AD 価値が大きく 早くできるものから C 1 2 3 4
- 70. B AD 大価値短期間＝高ROI C 1 2 3 4
- 71. A A A A A
- 72. 価値とはほしいもの • 顧客価値 • 情報、リスク対策 • 生産性
- 74. 簡単 ですね♪
- 75. 簡単な わけがない 💀
- 77. お仕事 頑張ってますか？
- 80. コミュニケーション
- 81. 情報帯域
- 83. 伝言ゲームと 情報劣化
- 85. 簡単な わけがない 💀
- 86. 手戻り
- 87. 技術的負債
- 88. 機能追加とコスト 時間 価値
- 90. 技術的負債 • 一時的なメリットを与える(レバレッジ) • 開発したソフトウェアに内在する • 開発の作業効率を悪化させる • 除去作業をしないと取り除けない • 放置すると増殖する
- 91. 技術的負債 • 不適切なエンジニアリングで発生する • 能力不足 • 圧力、プレッシャー • 考慮不足 • 将来は本質的に予測できない • 「考慮不足」は不可避 • 「キレイ」な状態を 維持するための作業 = リファクタリング • 負債をためすぎないうちに返済する • 将来予測 → 変更容易
- 92. 変更容易性 • 設計がシンプル • 変更箇所と内容が自明 • 依存関係が少ない • 特に隠れた依存関係 • 実装もシンプル • 誰でも安心して変更できる • 自動化したテスト • リグレッション • 常にこの状態を維持する • 厳しい規律 • だんだん難しくなる
- 93. 品質と規律
- 94. 簡単な わけがない 💀
- 95. 人
- 97. モチベーション3.0 • 自律 • 熟達 • 目的 好きなことに集中することで より上手になり、できることも広がり そうして大きな目標を目指せれば モチベーションが上がる
- 100. チームによる学習
- 102. 学習する組織 • システム思考 – 全体を考える • メンタルモデルへ意識を向け見直す • 共有ビジョン ― 「自分たちはなにを創造したいのか？」 • チーム学習とアラインメント(合致) • 経営者を含むマネジメント全体の意識変革 『学習する組織』ピーター・M・センゲ
- 104. 簡単な わけがない 💀
- 106. 価値とは…… • 製品のユーザーが何を 望んでいるか知りたい • ワクチンの効率的配送 サービスを実現する • 会社の資金が底をつきそう • 製品が遅い • 開発スピードが遅い • 猫の画像でにっこりさせたい → 情報 → 人命 → 会社存続 → 実行速度 → 開発速度 → しあわせ
- 109. プラクティス •Practice = 練習 実践 •HOW •なぜやるのか、なんのためにやるのか • ノウハウではない • 必須でもない 必要性から要請される •実験の対象 • うまくいくかどうか やってみて改善 • 実際のやり方はみな違う
- 110. 朝会 / デイリースタンドアップ • チーム全員 • 毎日、同じ場所、同じ時間で • 状況と問題を共有する • 立ってやる • 現状を踏まえて計画を見直す https://www.slideshare.net/yattom/project-facilitation-from-hiranabe
- 111. プランニング、計画ゲーム • イテレーション(1～4週間)にやることを決める • 優先順位の高いものを取る • 作業タスクを洗い出してできる範囲を判断する • 顧客やプロダクトオーナーと開発チームが一緒
- 112. ふりかえり / レトロスペクティブ • チーム全員 • 仕事のやりかたを見直す • 改善アクションを出す • チームが自分自身で実験する
- 113. XPのプラクティス
- 114. スクラムのプラクティス • 3つの役割 • プロダクトオーナー、開発チーム、スクラムマスター • スプリント • 5つのイベント • スプリントプランニング、スプリントレビュー、 デイリースクラム、レトロスペクティブ、 リファインメント • 3つの作成物 • プロダクトバックログ、スプリントバックログ、 プロダクトインクリメント
- 115. スクラムの3つの役割
- 117. 事例はあとから • 人の事例は役に立たない • 状況が違う • 人も違う • 事例は「いい話」
- 118. 事例はあとから • 自分でやってみる • 実験する • まずやってみる • 結果を分析する • 「うちはこうだったけど、おたくはどう？」 • 次の実験へのヒントに • 人を説得する材料にはなる • 実際には、あまりならない
- 119. アジャイルと○○ • アジャイル vs. ウォーターフォール • 適応型 vs. 計画主導 • 個人依存 vs. 平準化・標準化 • アジャイル vs. DevOps • アジャイル vs. UX • など……
- 120. アジャイルを “やってみる”
- 121. Unlearn 脱学習
- 122. アジャイルの向き不向き • 効果が期待できるプロジェクト、プロダクト • 能力を発揮する個人の性向 • チームや組織の文化
- 123. カオス 複雑 込み入った シンプル
- 127. On Pioneers, Settlers, Town Planners and Theft. by Simon Wardley http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html
- 128. マインドセット • Fixed • 固定的、変化を嫌う、失敗を避ける • Agile / Growth / Effort • 成長的、変化する、挑戦する
- 130. Fixed vs. Agile 能力 – 不変、背の高さなど ゴール – 良く見られる 挑戦 – 避ける 失敗 - 個人的な問題 努力 - 能力がない人がやる 困難に直面すると – 無力 能力 – 成長、筋肉など ゴール – 学ぶ 挑戦 – 受け入れる 失敗 – 情報を得られる 努力 – 熟達への道 困難に直面すると – 回復力(レジリエント)
- 140. Fixed vs. Agile 能力 – 不変、背の高さなど ゴール – 良く見られる 挑戦 – 避ける 失敗 - 個人的な問題 努力 - 能力がない人がやる 困難に直面すると – 無力 能力 – 成長、筋肉など ゴール – 学ぶ 挑戦 – 受け入れる 失敗 – 情報を得られる 努力 – 熟達への道 困難に直面すると – 回復力(レジリエント)
- 144. 自分ごと • 「対象＋実験(手法)＋観察者」を系とした科学 • 自身の経験を通じて学ぶ • Participating Consciousness ― 自分自身を世界の一部と認識する • Tacit Knowledge ― 身体を通じた経験から体得する知
- 146. 品質の作り込み
- 147. 品質の作り込み
- 148. 品質の作り込み • ペアプログラミング • コード共同所有 • テストエンジニアが一緒に開発する • テスト駆動開発(TDD) • テスト自動化 • 継続的インテグレーション(CI) • 継続的デリバリー(CD) • モニタリング
- 149. • TDD • Test Driven Development • テスト駆動開発
- 151. • 動作するきれいなコード
- 152. • 動作する
- 153. • きれい
- 155. テスト駆動開発
- 156. • 1. テストを書く • 2. 実行して失敗させる • 3. テストが通る実装を書く • 4. テストを成功させる • 5. テストが通る状態のままリファクタリングする
- 160. • 自信と安心
- 161. テストファースト
- 164. テスト駆動開発の効果 IBM ドライバ Microsoft Windows Microsoft MSN Microsoft VisualStudio チーム人数 9 6 5-7 7 コード量 (KLOC) 41.0 6.0 26.0 155.2 開発規模(人月) 119 24 46 20 欠陥数 (TDD未使用に 対する) 61% 38% 24% 9% 開発時間の増加 (管理者の見積) 15～ 20％ 25～35％ 15％ 20～25％ Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, Laurie Williams “Realizing quality improvement through test driven development: results and experiences of four industrial teams” 2008 http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf
- 165. 保守性への影響 生産性 (行数/工数) 保守性 ※1 (工数/変更件数) プロジェクトA (非TDD) 2.3 84 プロジェクトB (非TDD) 2.5 80 プロジェクトC (TDD) 1.8 59 ※1 保守期間(260日間)中、変更要求の対応にかかった工数の平均 "The effectiveness of test-driven development: an industrial case study" (Tomazˇ Dogsˇa • David Baticˇ , Software Qual J (2011))
- 166. TDDの効果の研究をまとめた研究 "Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies" Simo Makinen and Jurgen Munch, 2013 • 既存の実証研究を調査し、10の内部・外部品質評価項目で、各研究 の結論を整理した • TDDは欠陥の作り込み(introduced defects)を減らし、メンテナン スしやすいコードを産む • TDDで実装されたコードは、部分的に、サイズが小さく、複雑度が低 い場合がある • メンテナンスがしやすくなるものの、初期開発では時間がかかる
- 170. • テスティング Testing • チェッキング Checking
- 171. アジャイルテスト 高品質を追求するアジャイルチームにおけるテストの視点 増田聡 Developer Summit 2010 http://www.slideshare.net/satoshimasuda/ss-3241717
- 173. JaSST’11 Tokyo 新しいTDDアプローチ http://togetter.com/li/93719
- 174. テスト自動化のメリット • 回帰テスト • 追加/変更が容易、安心 • 品質管理しやすい、品質向上 • 機能横断と多能工 • 依存性排除 • 他にもたくさん！
- 175. • システムテスト自動化標準ガイド
- 176. • ソフトウェアテスト技法ドリル
- 177. テスト書きたい？
- 178. • TDD×テスト自動化
- 179. 品質とは 誰かにとっての価値 ― G. M. Weinberg
- 180. ～さいごに～ なぜアジャイル？
- 181. なぜアジャイル？ • アジャイルプラクティスが便利だから？ • アジャイルだと生産性が良さそうだから？ • アジャイルだとお客さんやユーザーの 満足度が高まるから？ • 競合に勝てるアジリティを身に付けたいから？ • アジャイルの価値を追求したいから？ • 自分たちの価値を追求するのに、 アジャイルな態度が必要だから？ • 自分たちの価値とアジャイルの価値が 親和性が高く、同じことを目指すから？
- 182. おすすめ書籍など • 『アジャイル開発とスクラム』平鍋健児 野中郁次郎 https://is.gd/3VXy43 • アジャイル開発やスクラムの概要や全体像、 企業から見てどういうメリットがあるのか • 『アジャイルサムライ』Jonathan Rasmusson https://is.gd/K9zZf4 • アジャイル開発を実際に始める方法 • 『スクラムブートキャンプTHE BOOK』西村、永瀬、吉羽 https://is.gd/VVfMw7 • スクラムの実際のやりかたについてお気楽に学べる • 『アジャイルな見積りと計画づくり』Mike Cohn https://is.gd/lBZ6aN • 価値を生み出す計画をアジャイルに作り、進める方法 • 『塹壕より ＳｃｒｕｍとＸＰ』 Henrik Kniberg https://is.gd/jaPSty • 無料ＰＤＦ。アジャイルの実例と工夫 • 『テスト駆動開発による組み込みプログラミング』 James W. Grenning https://is.gd/qW1yMX • C言語による組み込み開発向けのTDD手法を基本から