はじめてのアジャイル

4,283 views

Published on

Agile Japan 2010のチュートリアルセッションで使った資料。
前半を平鍋さん、後半を倉貫が話しました。

Published in: Technology
1 Comment
7 Likes
Statistics
Notes
No Downloads
Views
Total views
4,283
On SlideShare
0
From Embeds
0
Number of Embeds
162
Actions
Shares
0
Downloads
181
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation 小さな開発サイクルで動くものを作り、それを繰り返してだんだんと成長させていくのが XP の開発スタイル。 1 回目のリリース以外はすべて保守リリース(バージョンアップ)ということになる。 何度もリリースすることを前提としたアーキテクチャを採用する。
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • XP の本を何度も読んだ チームビルディング 真似してやってみた。ストーリーカードとか。 成功?失敗?
  • メンバ「なぜ考えないといけないのか?」 顧客「アジャイルならなんでも。」押し込まれる
  • http://twitter.com/kuranuki/status/11756628682 Project Facilitation
  • Project Facilitation
  • Project Facilitation これはペアプログラミングの様子です。 私たちの後ろには現在のイテレーションのタスクを書いた摸造紙が貼ってあります。 また、ストーリーカードは「終了」と「 TODO 」にわけて貼り出します。 「 TODO 」のところにあるストーリカードで終了したものは「終了」のところに移動します。 お菓子も手の届くところにちゃんと置いてあります。
  • Project Facilitation
  • Project Facilitation
  • Project Facilitation
  • 「皆さん、改めて見てどうですか?」 無能な上司:よくある光景に見えるが、実は開発者が伝えてない。 両方とも間違っている:コストは価値の裏側 -> お互いにお互いの言葉を語ろうとしていないのではないか? -> 結びつける機会が必要:パラダイムシフトか。 Project Facilitation
  • はじめてのアジャイル

    1. 1. ㈱永和システムマネジメント ㈱チェンジビジョン 平鍋 健児 はじめてのアジャイル ~アジャイルジャパンチュートリアル~ A J gile apan TIS ㈱ SonicGarden 倉貫 義人
    2. 2. アジェンダ <ul><li>なぜ今 Agile か </li></ul><ul><li>Agile とは何か </li></ul><ul><li>海外の状況 </li></ul><ul><li>日本の課題 </li></ul><ul><li>Agile のはじめ方 </li></ul><ul><li>日本の事例 </li></ul><ul><li>プラクティス紹介 </li></ul>
    3. 3. プログラマがあと 3人欲しいんです。 アジャイルを使ってはどうかね? アジャイルは少数でも生産性が高い、という意味じゃないんです。 じゃあ、そういう意味のキーワード教えてくれ。その後で、もう一度来てくれ。
    4. 4. なぜ今 Agile か
    5. 5. 市場 ビジネス IT 市場分析 発注 納品 リリース 半年から3年 ミッション・リスク分割型ビジネスと ウォーターフォール型開発(従来型)
    6. 6. 従来型の問題=要求の劣化 <ul><li>Standish group study report in 2000 chaos report </li></ul>
    7. 7. 市場 IT 2週間から半年 ミッション・リスク共有型ビジネスと Agile 型開発 ビジネス 市場 ビジネスと IT が一体になった 「 OneTeam 」を作り、ミッション とリスクを共有する。 やってみて、結果から戦略を 作りながら進む。
    8. 8. 反復・漸進開発= Agile 機能 A 機能 B 機能 C 開発 サービス 開発 サービス サービス 開発 時間軸 :  2週間~半年単位のリリースを繰り返す 機能軸  重要機能から積み上げる R1 R2 R3 反復 (Iterative) 漸進 (Incremental)
    9. 9. プロセスとしての Agile <ul><li>短いサイクルで、分析、設計、実装、テストを 並列に行う </li></ul><ul><li>タイムボックス型、進化型開発 </li></ul>時間 時間 要求 ( スコープ ) 要求 ( スコープ ) Waterfall Agile Beck 2000 Royce 1970 分析 設計 実装 テスト
    10. 10. Scrum の例 製品 バックログ スプリント バックログ 1-4 週 24 時間 出荷可能 ソフトウェア 朝会
    11. 11. Agile の価値観 私たちは, プロセスとツールよりも ……… 個人と対話に. 包括的なドキュメントよりも ……… 動くソフトウェアに. 契約交渉よりも ……… 顧客との協調に. 計画に沿うことよりも ……… 変化に対応することに. 価値をおく. アジャイル開発宣言 ( http://agilemanifesto.org/iso/ja/ ) 背後にある原則 ( http://agilemanifesto.org/iso/ja/principle.html )
    12. 12. アジャイルの原則 <ul><li>顧客価値の優先 </li></ul><ul><li>変化に対応 </li></ul><ul><li>短期のリリース </li></ul><ul><li>全員同席 </li></ul><ul><li>モチベーションと信頼 </li></ul><ul><li>会話 </li></ul><ul><li>動くソフトウェア </li></ul><ul><li>持続可能なペース </li></ul><ul><li>技術的卓越性 </li></ul><ul><li>シンプル </li></ul><ul><li>自己組織的チーム </li></ul><ul><li>ふりかえりと改善 </li></ul>
    13. 13. アジャイルの実践(例  XP ) <ul><li>計画ゲーム </li></ul><ul><li>小規模リリース </li></ul><ul><li>メタファー </li></ul><ul><li>シンプルデザイン </li></ul><ul><li>テスティング </li></ul><ul><li>リファクタリング </li></ul><ul><li>ペアプログラミング </li></ul><ul><li>共同所有権 </li></ul><ul><li>継続的インテグレーション </li></ul><ul><li>週 40 時間 </li></ul><ul><li>オンサイト顧客 </li></ul><ul><li>コーディング標準 </li></ul>
    14. 14. アジャイルの現在位置 XP 2000 Agile 2002 SCRUM FDD, Crystal, DSDM, ASD 2010 Evo <ul><li>大規模 </li></ul><ul><li>組織改革 </li></ul><ul><li>Lean/Agile </li></ul><ul><li>Agile/UX </li></ul>Lean Software Development Patterns TPS Deming Lean
    15. 15. Agile の海外での状況
    16. 16. Agile 現状調査 <ul><li>VersionOne 社が主催の調査” State of Agile Development” </li></ul><ul><li>2008 年で 3 年目。アジャイルの利用状況についてアンケート調査。 </li></ul><ul><li>Web による全世界 (80 カ国 ) のアジャイルユーザを対象にしたアンケートに、 3061 人が参加。 </li></ul><ul><li>さまざまなサイズの企業が含まれる。 250 名以上の会社が 32% 含まれる。 </li></ul>
    17. 17. Agile の支持層 もはや、開発者レベルではなく、 企業の意思決定レベルに上がってきている 最初の主導者は、組織内のどの役割か?
    18. 18. 使っている Agile 方法論は ? 現在、 Agile というと Scrum がほとんど。 使用している Agile 方法論は ?
    19. 19. 使っているプラクティスは (1)? ふりかえり イテレーション計画 ユニットテスト 朝会 リリース計画 継続統合 自動ビルド バーンダウン リファクタリング コーディング標準
    20. 20. 使っているプラクティスは (2)? ベロシティ (開発速度) タスクボード かんばん テスト駆動開発 オープンな作業場 コード共同所有 オンサイト顧客 ペアプロ 振舞駆動開発
    21. 21. Agile のさらなる採用への障壁 企業風土、カルチャー、 変化への抵抗勢力が大きな障壁
    22. 22. Agile 採用への不安点 初期の計画が不十分 管理不在 ドキュメントが不十分 などなど。。。
    23. 23. 生産性、品質、 TTM 生産性、品質、 TTM 短縮についても、 有意な効果があったとする回答が多い。
    24. 24. リスク、可視性、柔軟性 アジャイル開発の特徴 リスクを初期に下げる。 可視性を常に高く保つ。 変化への対応性をキープする。 リスク 可視性 変化への対応性
    25. 25.
    26. 26. Agile のはじめ方
    27. 27. 規矩作法 守りつくして 破るとも 離るるとても 本を忘るな 千利休 「利休百首」
    28. 28.
    29. 29. プラクティスを忠実に守ってみる “ ふりかえり”で自分たちにあわせる ビジネスにあった開発手法とする
    30. 30. Agile の日本の事例
    31. 31. 私の事例 受託開発 (プライム) 受託開発 (サブプライム) 社内システム (情シス) クラウド (社内ベンチャー) 2002 年 7 月〜 2004 年 8 月〜 2005 年 11 月〜 2008 年 11 月〜 9 名 ( PJ リーダー) 15 〜 30 名 ( PM ) 2 〜 10 名 (管理職) 7 名 (カンパニー長) 金融業界の注文管理 通信業界のサービスオーダー 社内 SNS 社内 SNS, スモール SNS △ × ○ ○
    32. 32. <ul><li>XP のプロジェクトに挑戦! </li></ul><ul><ul><li>期間: 2002 年 7 月〜 2003 年3月 </li></ul></ul><ul><ul><li>人数: 9 名(私は PJ リーダー) </li></ul></ul><ul><ul><li>対象:金融業界の注文管理システム </li></ul></ul><ul><ul><li>技術: Java, SOAP, EJB, WebLogic, C++ </li></ul></ul><ul><ul><li>課題:短納期 , 体制不十分 , 経験不足 , 要件未確定 </li></ul></ul>ペアプログラミング テストファースト リファクタリング コードの共同所有 コーディング標準 ショートリリース ふりかえり 開発技術 < チームビルディング
    33. 33. <ul><li>プロジェクトで XP を実践! </li></ul><ul><ul><li>期間: 2004 年 8 月〜 2005 年 6 月 </li></ul></ul><ul><ul><li>人数: 15 〜 30 名(私はプロマネ) </li></ul></ul><ul><ul><li>対象:通信業界のサービスオーダーシステム </li></ul></ul><ul><ul><li>技術: Java, Web, Spring, Hibernate </li></ul></ul><ul><ul><li>特徴:自分たちなりのプロセスの作成( EnterpriseXP ) </li></ul></ul>受託開発でのアジャイルに疑問 瑕疵担保責任 品質保証 人月コスト パートナー企業 セクショナリズム 要件定義 顧客側の立場 ソフトウェア開発以外の 課題に多数遭遇
    34. 34. 日本の受託開発の課題 ディフェンシブな開発 納品 減価償却 人月 発注 ビジネスに問題があるのではないか? 決められた予算で 出来るのか? 計画通りに作ること が最大の利益
    35. 35. <ul><li>社内システム開発で XP を実践! </li></ul><ul><ul><li>期間: 2005 年 11 月〜 </li></ul></ul><ul><ul><li>人数: 2 〜 10 名(私はプログラマ〜マネージャ) </li></ul></ul><ul><ul><li>対象:社内 SNS </li></ul></ul><ul><ul><li>技術: Ruby on Rails </li></ul></ul><ul><ul><li>特徴:ビジネスオーナーが自分 </li></ul></ul>予算管理+内製だとうまくいく <ul><li>ただし、 </li></ul><ul><li>内製できるスキル </li></ul><ul><li>自分たちでリスクを持つ覚悟 </li></ul><ul><li>が必要 </li></ul>
    36. 36. <ul><li>クラウドビジネスで XP を実践! </li></ul><ul><ul><li>期間: 2008 年 11 月〜 </li></ul></ul><ul><ul><li>人数: 7 名(私はカンパニー長) </li></ul></ul><ul><ul><li>対象:社内 SNS 、他 SaaS </li></ul></ul><ul><ul><li>技術: Ruby on Rails </li></ul></ul><ul><ul><li>特徴:ビジネスオーナーが自分 </li></ul></ul>毎日 毎月 リリーステスト SaaS アップデート OSS リリース 自動テスト TODO 更新 ソース管理 プロデューサー プログラマ 運用担当者 開発工程を全て担当 ユーザ要件を決定 繰り返す
    37. 37. ビジネスにあった開発を選ぶ t t 買った時点が最高品質 Point of Sales Point of Use 構築 償却 利用 すぐに利用開始 利用中が最高品質 (常にアップグレード) q q 買った時点が最高で、そこから陳腐化が始まるもの 常に使っている時点で最高、最新のものを利用できる 製造業 サービス業 受託開発 クラウド &quot;Business Aligned&quot;
    38. 38. プラクティスを忠実に守ってみる “ ふりかえり”で自分たちにあわせる ビジネスにあった開発手法とする 最初から“離”を狙う必要は無い
    39. 39. Agile のはじめ方 <ul><li>よく聞く言葉 </li></ul><ul><ul><li>「受託だから難しい・・・」 </li></ul></ul><ul><ul><li>「契約が・・・営業が・・・」 </li></ul></ul><ul><li>Web 時代の弊害 </li></ul><ul><ul><li>情報が多すぎる </li></ul></ul><ul><ul><li>最初から完璧を求めすぎる </li></ul></ul>完璧でなくても始めるのが Agile では?
    40. 40. プラクティスの紹介
    41. 41. ふりかえり <ul><li>“ KPT” と呼ばれる方式 </li></ul><ul><li>Keep / Problem / Try で共有 </li></ul><ul><ul><li>K= よかったこと / P= 問題点 / T= 次にやってみること </li></ul></ul>改善の意識を生む 個人の持つよかったノウハウや抱えている問題を チームのものとすることができる Keep 良かったこと Practice プラクティス Problem 問題点 Try 次にやる プラクティス化 問題の解決
    42. 42. ペアプログラミング <ul><li>常時コードレビューを実施している状態 </li></ul><ul><li>ソースコードを理解している人間をクラスタ </li></ul>ドキュメントによるコミュニケーションを減らす 引継ぎ・不在時のための情報共有を減らす
    43. 43. ペアプログラミングの様子 イテレーションタスクの模造紙 終了したタスクから横線を 引いて消していく ストーリーカードは「終了」と 「 TODO 」に分けて貼り出す お菓子は必須♪
    44. 44. astah* 開発チームの「朝会」 (stand-up)
    45. 45. 朝会 スタンダップミーティング 必ず 15 分で終わらせる 日直が呼びかけて小話する 定番 時間割表 バーンダウンチャート ふりかえり 結果
    46. 46. 時間割表 2時間ずつ集中して作業 ペアプロは疲れる&休憩重要 長めの休憩時間&チャイム 1日は2時間を3コマ 前日分と当日分 担当者名 独自
    47. 47. バーンダウンチャート 進捗会議が要らなくなる 中期的な進捗管理ができる “ ぱっと見”重要 (プレッシャ重要) その日に起きた出来事なども書き込めば ふりかえり がしやすい 青が見積・目標 赤が実績 定番
    48. 48. バーンダウンチャート <ul><li>進捗の見える化 </li></ul><ul><ul><li>バーンダウン(下向き) </li></ul></ul><ul><ul><li>タスクかんばんと連動 </li></ul></ul><ul><ul><li>中間成果物で は計測しない。 </li></ul></ul><ul><ul><li>メールでエクセルシート を配布したり、 サーバに置いたから 見てね、はナシ。 </li></ul></ul>バーンダウンチャートの例 ( 協力:永和システムマネジメント:チーム角谷)
    49. 49. タスクかんばん <ul><li>作業の見える化 </li></ul><ul><ul><li>ToDo( 未実施 ) Doing( 実施中 ) Done( 完了 ) で管理。 </li></ul></ul><ul><ul><li>各自の作業を指示しなく ても、毎朝自発的に 作業開始。 </li></ul></ul><ul><ul><li>フォーマットは徐々に カイゼン。 </li></ul></ul>タスクかんばんの例 ※ バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。 ( 協力:チェンジビジョン astah* チーム)
    50. 50. タスク・不具合の共有 タスクをポストイットで見える化 しかし、 DRY に反している 改善を実施 Trac Redmine GoogleSpreadsheet
    51. 51. プラクティスを忠実に守ってみる “ ふりかえり”で自分たちにあわせる ビジネスにあった開発手法とする
    52. 52. アジャイル実践の勘所 アジャイルは変化を習慣にすること カイゼン Kent Beck 僕は偉大なプログラマじゃない。 偉大な習慣を身につけたプログラマだ P.F.Drucker 成果をあげるのは才能ではなく、 習慣だ。 どうすれば習慣化できるのか?
    53. 53. 習慣化のためのヒント 小さくすれば、身軽にできる。身軽になれば、習慣にできる。 見えなければ、制御できない。適応できない。カイゼンできない。 見える化 小口化
    54. 54. プログラマがあと 3人欲しいんです。 アジャイルを使ってはどうかね? アジャイルは少数でも生産性が高い、という意味じゃないんです。 じゃあ、そういう意味のキーワード教えてくれ。その後で、もう一度来てくれ。

    ×