誰でも分かる

アジャイル開発

A研　M1　@h_mku

2012/02/24　M1勉強会用資料

Agenda

!   アジャイル開発とは何か

!   XPとは何か

!   XPチームメンバの構成

!   XPプラクティス集

!   まとめ

2

アジャイル開発

とは何か

あじゃいるって何

？

おいしいの？

あじゃいるって何？

プラクティス（practice）

エクストリーム・プログラミング（XP） スクラム（Scrum）

他にもあるかも…

アジャイル開発手法

4

なぜあじゃいる？

1.  みんな（組織）がハッピーだから

•  柔軟性↑，コスト↓，コミュニケーション↑

2.  個人がハッピーだから

•  納期＜個人的なやりがい

3.  技術的にハッピーだから

•  ペアプロ，テスト駆動開発，継続的インテグレーションとか学べる！

5

どうしたらあじゃいれる？

✕　特定のプロセスに従えばあじゃいれる

◯　アジャイル開発は考え方

!  学習(study)は容易だが，習得(learn)は難しい

例： ✕ 炭水化物抜きダイエット法 ◯ 効率的に痩せる為の方法

あじゃいれている＝

アジャイルマニフェストを満たしている

6

アジャイルマニフェスト

!   ４つの価値と，それを支える１２の原則

1. プロセスやツールよりも， 人と人との交流を重視すること

2. ドキュメントよりも， 動くソフトウェアを重視すること

3. 顧客との交渉よりも， 協調を重視すること

4. 計画に従うよりも， 変化に適応すること

1.  顧客満足が最優先 2.  変更はしゃーない 3.  短いサイクルで納品 4.  毎日働く 5.  やる気ある人をリーダーに 6.  できるだけ直接話す 7.  動かなきゃできたと言えない 8.  無理のないペースで 9.  高度な技術を持て 10. やらなくていいことはするな 11. 自己管理能力の高いチームで 12. PDCAサイクル回せ

7

アジャイル手法の選択

!  今回，アジャイル開発手法としてXPを選択する

!  技術重視だから

!  文献豊富だから

! Exterem=極端な，急激な，極限の？

!  日本語にするのは難しそう

8

XPとは何か

今更XP？

もうすぐ8が出る

よ！

XPの驚くべき特徴

!  要件定義，設計，テストといったフェーズが無い

!  もちろん，そのフェーズ毎のドキュメントも無い

!  開発サイクルが，ありえない程に短期間

!  ウォーターフォール：3~24ヶ月

!  イテレーション：1~3ヶ月単位

同時フェーズで開発を行う

開発サイクルは１週間単位

10

XPの実現(1)

!  計画

!  リリース計画をストーリー（細かい計画）に分割

!  一週間で4~10個のストーリーを納品できることを目標

!  オンサイト顧客（チーム内のビジネスの専門家）が担当

!  できるだけ小さな計画を立てる（計画ゲーム） !  分析（所謂要件定義）

!  オンサイト顧客が考える

11

XPの実現(2)

!   設計・コーディング

!   テスト駆動開発(TDD)

!   ペアプログラミング

!  開発環境の管理（バージョン管理，自動ビルド） !   コーディング標準の策定

!   テスティング

!  検証(Verification)はTDDを行なっているので十分だと考える

!  顧客テスト(Validation)を行う（実機テスト等）

12

XPの実現(3)

!  導入

!  週に一度，イテレーションデモを行う

!  チーム内のステークホルダにソフトウェアをリリースする

!  保守する

13

XPチームメンバ

イカれたメンバー

を

紹介するぜ！

14

XPチーム

!   チームメンバ

!  職務横断的(cross-functional)なチームの構成が必要

!   チーム全体

!  全員がオープンな作業場所に在席

!  各イテレーションの始めにミーティング（2~4時間）

!  毎日ミーティング（5~10分）

!  非公式なミーティング（「ミーティングしようぜ」でできる）

15

人員構成

1.  オンサイト顧客

!  要件を定義する

!  真の顧客でなくても良い

!  複数人必要

!   プログラマ：顧客＝３：２の割合が望ましい

16

2.  プログラマ

3.  テスター

4.  コーチ

オンサイト顧客(1)

!   プロダクトマネージャ

!  管理役 !   ビジョンをドキュメントにし，メンバと共有する

!   リリース計画に優先順位を付ける

!   指示を与える

!   ドメイン専門家

!  相談役 !   ドメイン知識に関する質問に答える

17

オンサイト顧客(2)

!   インタラクションデザイナ

!  UI役

!   ビジネスアナリスト

!  顧客と開発者の間の橋渡しをする

18

プログラマ

!  設計者，アーキテクト

!  熟練した設計者，アーキテクトが必要

!   テクニカルスペシャリスト

!  各分野（ネットワーク，DB等）のスペシャリスト

19

テスター

いなくてもいい

20

コーチ

チームは自己組織化しているので，リーダーは必要無いかもしれないが，チームメンバ間のやり取りを円滑化する為に必要な役割

!   プログラマコーチ

!   XPの技術的なプラクティスの実践を支援する

!   プロジェクトマネージャ

!  メンバー間のやり取りを支援する

21

XPプラクティス集

XPプラクティス

37個もあるんだけ

ど！(#･∀･)

22

23 考えること 協力すること リリースすること 計画すること 開発すること

ペア プログラミング

信頼 完全Done ビジョン インクリメンタルな要件

活き活きとした 職場

全員同席 バグ無し リリース計画 顧客テスト

情報満載の 仕事場

真の顧客の参加 バージョン管理 計画ゲーム テスト駆動開発

根本原因分析 ユビキタス言語 10分ビルド リスク管理 リファクタリング

ふりかえり スタンドアップ ミーティング

継続的インテグレーション

イテレーション計画

シンプルな設計

コーディング標準 コードの共有 ゆとり インクリメンタルな設計

イテレーション デモ

ドキュメント ストーリー スパイク ソリューション

報告 見積もり パフォーマンス 最大化

探索的テスト 気になったプラクティスのみ紹介

5.1　ペアプログラミング

!   保守する必要があるものは全てペアで行う

!   構成：ドライバーとナビゲータ

!  一人がコードを書き，一人がどういうコードを書くか考える

!   ドライバーは全体を気にせずに，詳細を考えることができる

!   ナビゲータは詳細を気にせずに，戦略を考える事ができる

!   進め方

!  少なくとも30分毎に役割を交代する

!   できるだけ会話する

24

FAQ

!   どう考えても2人で1人分の仕事しかできないのは無駄

!   コーディングと考える事の役割を分担する事で得られるメリットは計り知れない

!   ずっとペアプロばかりしてる職場って何か気持ち悪い

!  むしろ，保守する必要の無いコードさえもペアで作ってよい（cf.スパイクソリューション）

!  中には繰り返し作業が発生し，本当にペアである必要が無い作業もあるかもしれないが，それはそもそも構造に問題がある

25

FAQ(2)

!   「はーい二人組作ってー」「先生，h_mku君が余っちゃいましたー」状態になるのが怖いです

!  他の役割を与えると良い

!   チームの人数が少ない時，それでもペアを組むべき？

!  そうするのがオススメ

26

6.4　ユビキタス言語

!   メンバ間で使う言語は一つに統一する

!  チームメンバ間の意思疎通を円滑にするため

!   プログラマがドメイン専門家の言語を話すべき

!  できるだけ，ドメイン用語を用いるようにする

27

7.1　完全Done

!   「できた」を一つの意味に統一

!  リリースできる状態

!  完了した仕事がいつでもリリースできることを保証

!  コーディング，テスト，インテグレーション，レビュー，受け入れ…全ての工程を完了させている

!   ストーリーを十分に小さくすることが必要

28

7.4　10分ビルド

!  継続的インテグレーションで返事が返ってくるのは10分以内にする

!  ペアが他の仕事に移ってしまうまでに我慢できる時間の最大値（経験則）だから

!  自動ビルドツールの活用

!   Java：Ant, .NET：Nant，C,C++：make

29

7.5　継続的インテグレーション

!   いつでもコードを出荷できるようにする

!  ソフトウェアの完成と，リリースまでの間に隙間ができてはならない

!  コミットした段階で，pushを自動検知して，ビルドやテストができて，それの結果を明確にできるようにする

30

8.3　計画ゲーム

!   チーム全体の専門知識を寄せ集めて達成可能な最もベストだと考えられる計画を作る

!  ゲーム：プレイヤーが行動を選択し，その報酬は全てプレイヤーの選択に依存する

!  会議，全員参加，ストーリーの作成，見積もり

31

9.7　スパイクソリューション

!   コントロールされた実験をすることで必要な情報を得る

!  スパイク：技術的な調査

!  実験的にスタンドアロンでコードの一部の動作をテストする

32

33

まとめ

アジャイル開発は考え方

　　習得には時間がかかる

XPは短期間でどんどんリリースする

　　1週間単位で動くソフトを

XPはチームワークが大切

　　メンバ構成（特に顧客側）が大事

沢山のプラクティスがある

　　技術的なものだけでなく，観念的なプラクティスも多い