はじめてのアジャイル

㈱永和システムマネジメント㈱チェンジビジョン平鍋健児はじめてのアジャイル～アジャイルジャパンチュートリアル～ A J gile apan TIS ㈱ SonicGarden 倉貫義人

アジェンダなぜ今 Agile か Agile とは何か海外の状況日本の課題 Agile のはじめ方日本の事例プラクティス紹介

プログラマがあと３人欲しいんです。アジャイルを使ってはどうかね？アジャイルは少数でも生産性が高い、という意味じゃないんです。じゃあ、そういう意味のキーワード教えてくれ。その後で、もう一度来てくれ。

市場ビジネス IT 市場分析発注納品リリース半年から３年ミッション・リスク分割型ビジネスとウォーターフォール型開発（従来型）

従来型の問題＝要求の劣化 Standish group study report in 2000 chaos report

市場 IT ２週間から半年ミッション・リスク共有型ビジネスと Agile 型開発ビジネス市場ビジネスと IT が一体になった「 OneTeam 」を作り、ミッションとリスクを共有する。やってみて、結果から戦略を作りながら進む。

反復・漸進開発＝ Agile 機能 A 機能 B 機能 C 開発サービス開発サービスサービス開発時間軸 : 　２週間～半年単位のリリースを繰り返す機能軸　　重要機能から積み上げる R1 R2 R3 反復 (Iterative) 漸進 (Incremental)

プロセスとしての Agile 短いサイクルで、分析、設計、実装、テストを並列に行うタイムボックス型、進化型開発時間時間要求 ( スコープ ) 要求 ( スコープ ) Waterfall Agile Beck 2000 Royce 1970 分析設計実装テスト

Scrum の例製品バックログスプリントバックログ 1-4 週 24 時間出荷可能ソフトウェア朝会

Agile の価値観私たちは，プロセスとツールよりも ……… 個人と対話に．包括的なドキュメントよりも ……… 動くソフトウェアに．契約交渉よりも ……… 顧客との協調に．計画に沿うことよりも ……… 変化に対応することに．価値をおく．アジャイル開発宣言 ( http://agilemanifesto.org/iso/ja/ ) 背後にある原則 ( http://agilemanifesto.org/iso/ja/principle.html )

アジャイルの原則顧客価値の優先変化に対応短期のリリース全員同席モチベーションと信頼会話動くソフトウェア持続可能なペース技術的卓越性シンプル自己組織的チームふりかえりと改善

アジャイルの実践（例　 XP ）計画ゲーム小規模リリースメタファーシンプルデザインテスティングリファクタリングペアプログラミング共同所有権継続的インテグレーション週 40 時間オンサイト顧客コーディング標準

アジャイルの現在位置 XP 2000 Agile 2002 SCRUM FDD, Crystal, DSDM, ASD 2010 Evo 大規模組織改革 Lean/Agile Agile/UX Lean Software Development Patterns TPS Deming Lean

Agile 現状調査 VersionOne 社が主催の調査” State of Agile Development” 2008 年で 3 年目。アジャイルの利用状況についてアンケート調査。 Web による全世界 (80 カ国 ) のアジャイルユーザを対象にしたアンケートに、 3061 人が参加。さまざまなサイズの企業が含まれる。 250 名以上の会社が 32% 含まれる。

Agile の支持層もはや、開発者レベルではなく、企業の意思決定レベルに上がってきている最初の主導者は、組織内のどの役割か？

使っている Agile 方法論は ? 現在、 Agile というと Scrum がほとんど。使用している Agile 方法論は ?

使っているプラクティスは (1)? ふりかえりイテレーション計画ユニットテスト朝会リリース計画継続統合自動ビルドバーンダウンリファクタリングコーディング標準

使っているプラクティスは (2)? ベロシティ（開発速度）タスクボードかんばんテスト駆動開発オープンな作業場コード共同所有オンサイト顧客ペアプロ振舞駆動開発

Agile のさらなる採用への障壁企業風土、カルチャー、変化への抵抗勢力が大きな障壁

Agile 採用への不安点初期の計画が不十分管理不在ドキュメントが不十分などなど。。。

生産性、品質、 TTM 生産性、品質、 TTM 短縮についても、有意な効果があったとする回答が多い。

リスク、可視性、柔軟性アジャイル開発の特徴リスクを初期に下げる。可視性を常に高く保つ。変化への対応性をキープする。リスク可視性変化への対応性

はじめてのアジャイル

規矩作法守りつくして　破るとも離るるとても　本を忘るな千利休　「利休百首」

プラクティスを忠実に守ってみる “ ふりかえり”で自分たちにあわせるビジネスにあった開発手法とする

私の事例受託開発（プライム）受託開発（サブプライム）社内システム（情シス）クラウド（社内ベンチャー） 2002 年 7 月〜 2004 年 8 月〜 2005 年 11 月〜 2008 年 11 月〜 9 名（ PJ リーダー） 15 〜 30 名（ PM ） 2 〜 10 名（管理職） 7 名（カンパニー長）金融業界の注文管理通信業界のサービスオーダー社内 SNS 社内 SNS, スモール SNS △ × ○ ○

XP のプロジェクトに挑戦！期間： 2002 年 7 月〜 2003 年３月人数： 9 名（私は PJ リーダー）対象：金融業界の注文管理システム技術： Java, SOAP, EJB, WebLogic, C++ 課題：短納期 , 体制不十分 , 経験不足 , 要件未確定ペアプログラミングテストファーストリファクタリングコードの共同所有コーディング標準ショートリリースふりかえり開発技術　＜　チームビルディング

プロジェクトで XP を実践！期間： 2004 年 8 月〜 2005 年 6 月人数： 15 〜 30 名（私はプロマネ）対象：通信業界のサービスオーダーシステム技術： Java, Web, Spring, Hibernate 特徴：自分たちなりのプロセスの作成（ EnterpriseXP ）受託開発でのアジャイルに疑問瑕疵担保責任品質保証人月コストパートナー企業セクショナリズム要件定義顧客側の立場ソフトウェア開発以外の課題に多数遭遇

日本の受託開発の課題ディフェンシブな開発納品減価償却人月発注ビジネスに問題があるのではないか？決められた予算で出来るのか？計画通りに作ることが最大の利益

社内システム開発で XP を実践！期間： 2005 年 11 月〜人数： 2 〜 10 名（私はプログラマ〜マネージャ）対象：社内 SNS 技術： Ruby on Rails 特徴：ビジネスオーナーが自分予算管理＋内製だとうまくいくただし、内製できるスキル自分たちでリスクを持つ覚悟が必要

クラウドビジネスで XP を実践！期間： 2008 年 11 月〜人数： 7 名（私はカンパニー長）対象：社内 SNS 、他 SaaS 技術： Ruby on Rails 特徴：ビジネスオーナーが自分毎日毎月リリーステスト SaaS アップデート OSS リリース自動テスト TODO 更新ソース管理プロデューサープログラマ運用担当者開発工程を全て担当ユーザ要件を決定繰り返す

ビジネスにあった開発を選ぶ t t 買った時点が最高品質 Point of Sales Point of Use 構築償却利用すぐに利用開始利用中が最高品質（常にアップグレード） q q 買った時点が最高で、そこから陳腐化が始まるもの常に使っている時点で最高、最新のものを利用できる製造業サービス業受託開発クラウド "Business Aligned"

プラクティスを忠実に守ってみる “ ふりかえり”で自分たちにあわせるビジネスにあった開発手法とする最初から“離”を狙う必要は無い

Agile のはじめ方よく聞く言葉「受託だから難しい・・・」「契約が・・・営業が・・・」 Web 時代の弊害情報が多すぎる最初から完璧を求めすぎる完璧でなくても始めるのが Agile では？

ふりかえり “ KPT” と呼ばれる方式 Keep / Problem / Try で共有 K= よかったこと / P= 問題点 / T= 次にやってみること改善の意識を生む個人の持つよかったノウハウや抱えている問題をチームのものとすることができる Keep 良かったこと Practice プラクティス Problem 問題点 Try 次にやるプラクティス化問題の解決

ペアプログラミング常時コードレビューを実施している状態ソースコードを理解している人間をクラスタドキュメントによるコミュニケーションを減らす引継ぎ・不在時のための情報共有を減らす

ペアプログラミングの様子ｲﾃﾚｰｼｮﾝﾀｽｸの模造紙終了したﾀｽｸから横線を引いて消していくｽﾄｰﾘｰｶｰﾄﾞは「終了」と「 TODO 」に分けて貼り出すお菓子は必須♪

astah* 開発チームの「朝会」 (stand-up)

朝会スタンダップミーティング必ず 15 分で終わらせる日直が呼びかけて小話する定番時間割表バーンダウンチャートふりかえり結果

時間割表２時間ずつ集中して作業ペアプロは疲れる＆休憩重要長めの休憩時間＆チャイム１日は２時間を３コマ前日分と当日分担当者名独自

バーンダウンチャート進捗会議が要らなくなる中期的な進捗管理ができる “ ぱっと見”重要（プレッシャ重要）その日に起きた出来事なども書き込めばふりかえりがしやすい青が見積・目標赤が実績定番

バーンダウンチャート進捗の見える化バーンダウン（下向き）タスクかんばんと連動中間成果物では計測しない。メールでエクセルシートを配布したり、サーバに置いたから見てね、はナシ。バーンダウンチャートの例 ( 協力：永和システムマネジメント：チーム角谷）

タスクかんばん作業の見える化 ToDo( 未実施 ) Doing( 実施中 ) Done( 完了 ) で管理。各自の作業を指示しなくても、毎朝自発的に作業開始。フォーマットは徐々にカイゼン。タスクかんばんの例 ※ バーンダウンチャーなどと共に、とにかく、壁に貼る。「情報発信器」とも呼ばれる。 ( 協力：チェンジビジョン astah* チーム）

タスク・不具合の共有タスクをポストイットで見える化しかし、 DRY に反している改善を実施 Trac Redmine GoogleSpreadsheet

アジャイル実践の勘所アジャイルは変化を習慣にすることカイゼン Kent Beck 僕は偉大なプログラマじゃない。偉大な習慣を身につけたプログラマだ P.F.Drucker 成果をあげるのは才能ではなく、習慣だ。どうすれば習慣化できるのか？

習慣化のためのヒント小さくすれば、身軽にできる。身軽になれば、習慣にできる。見えなければ、制御できない。適応できない。カイゼンできない。見える化小口化

はじめてのアジャイル

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to はじめてのアジャイル (20)

More from Yoshihito Kuranuki (20)

はじめてのアジャイル

Editor's Notes