Intro toagile2010

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

アジェンダ
なぜ今 Agile か
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 の海外での状況

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

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

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

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

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

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

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

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

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

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

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

Agile の日本の事例

私の事例受託開発（プライム）受託開発（サブプライム）社内システム（情シス）クラウド（社内ベンチャー） 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"

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

よく聞く言葉
「受託だから難しい・・・」
「契約が・・・営業が・・・」
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 成果をあげるのは才能ではなく、習慣だ。どうすれば習慣化できるのか？

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

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

Intro toagile2010

by Yoshihito Kuranuki on Apr 13, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 47

Statistics

Intro toagile2010 — Presentation Transcript