demystifying agile software development

角谷信太郎KAKUTANI Shintaro; Eiwa System Management,Inc.

(株)永和システムマネジメント [email protected]

第6回プログラマーズカンファレンス; 2009-11-13(金)

アジャイルなソフトウェア開発の基本と実践Demystifying Agile Software Development

mailto:[email protected]


角谷信太郎kakutani.com!"!#$"%&'()*+,-./

角谷信太郎! 日本Rubyの会理事! RubyKaigi! Regional RubyKaigi! アジャイル関連技術書翻訳

提　供

情報化技術を通じて社会と共生する

永和システムマネジメント!受託開発の会社です! ゲームは未経験ですが業務システムは得意です :)

!Rubyのお仕事承ります! JRubyでの納品実績もあります

!アジャイルな開発のご支援! 認定Scrumマスターが4人います

http://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%A4%E3%83%B3%E3%83%86%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BC



http://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%A4%E3%83%B3%E3%83%86%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BC%23.E5.8F.97.E8.A8.97.E9.96.8B.E7.99.BA



http://www.amazon.jp/o/ASIN/4274066304/kakutani-22



“5つの世界”!パッケージ!インターナル!組み込み!ゲーム!使い捨て

ゲーム開発のことはさっぱりわからない

The Nature of

Software

http://www.amazon.co.jp/o/ASIN/4048676881/kakutani-22



Nature of Software1.人とソフトウェアのあいだに価値がある

2.“システム”全体を構成する3.変更に対応できることが求められている

人とソフトウェアのあいだに価値がある!使うことで価値が生まれる!使ってみないとわからない!使ったからといってわかるとも限らない

“システム全体”を構成する!ハードウェア!実行環境!ドキュメント!保守・運用プロセス!使う人

変化に対応できることが求められている!実際そうなのかは別として!ソフトウェアは育てるもの! “技術的負債”との格闘! Technical Debt

Nature of Software1.人とソフトウェアのあいだに価値がある

2.“システム”全体を構成する3.変更に対応できることが求められている

最後に出てくるケーススタディがゲーム開発だったり

今日は違いを気にするよりも似てるところや同じところを見つけてもらえるといいなと思ってます。

よろしくお願いします

角谷信太郎KAKUTANI Shintaro; Eiwa System Management,Inc.

(株)永和システムマネジメント [email protected]

第6回プログラマーズカンファレンス; 2009-11-13(金)

アジャイルなソフトウェア開発の基本と実践Demystifying Agile Software Development



あまり一般的な話をしても面白くないと思うので(本に書いてあることは本を読めば良いので)背景にある考え方を話します

! アジャイル開発はソフトウェアの本質に逆らわない

! 人が中心ということを忘れてはいけない

! 名前に惑わされてはいけない

まとめ

The Nature of

Software

Development

http://www.rubyworld-conf.org/ja/program/abstract/a-2/



http://www.codesqueeze.com/the-broken-iron-triangle-is-broken/



鋼鉄の三角形

品質

“いち開発者である自分には企業資産(つまりコードベース全体)の価値を低下させるような権限はない

ーーVenkat & Andy『アジャイルプラクティス』

品質スコープ(フィーチャ、機能)

品質スコープ

リソース

(フィーチャ、機能)

(コスト、予算)

品質スコープ

リソース


(コスト、予算)時間

(スケジュール)

鋼鉄の三角形でリソースと時間は独立して操作可能か?

たとえば思考実験! 3つの頂点のうち、!スコープ・リソース・時間!リソースと時間の2つが“制御可能”なら、

!どうなるだろうか?

思考実験(1)!予算は無限で!すべてのフィーチャを提供!ただし、即日納品

思考実験(2)!予算は1ドルで!すべてのフィーチャを提供!納期はいつでもよい

Martin Fowlersays:

“女の人を9人集めても、赤ん坊を1ヶ月では生めないーーMartin Fowler

リソースと時間は不可分!リソースと時間を完全に分けて考えられるとは思わないほうがよいのでは?

!考える速度!進みすぎる危険

“リソースと時間”

クライアントとしての思い!欲しいもの(スコープ)は、コントロールしたい(当然)

!いくら使うか(リソース)もコントロールしたい(当然)

!でも“リソースと時間”

つまり、こうなる:

品質スコープ

リソース


(コスト、予算)時間

(スケジュール)

リソースと時間

スコープ

鋼鉄の一本線

!三角形よりもシンプル :-)!ひとつの視点として!じゃあどうすれば?

“鋼鉄の一本線”

“If you have a good working

relationship with your

client,you can instead,

use Iron Line as a scale...




リソースと時間が固定でかつスコープも固定の場合、品質に影響が出るか、3つのうち1つ以上を守れなくなるリスクがある。


“リソースと時間”は限られているが、スコープは“調整可能”なのであれば、提供するスコープの範囲内については品質を確保できる可能がある


スコープ

リソースと時間

(70%)

アジャイルなソフトウェア開発

!変化する環境に、!適応しながら、!ビジネス価値のある!ソフトウェアを!提供し続けるための作戦

アジャイルな開発とは

アジャイルソフトウェア開発宣言

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Manifesto for

Agile Software Development

アジャイル開発手法! eXtreme Programming(XP)! ムーブメントの先駆けにして最強。今年10周年! 技術とビジネスのあいだに調和をもたらす

! Scrum! プロジェクト運営と心構えのフレームワーク! 北米でアジャイルといえば今はこれ。大流行。

! Lean! ソフトウェアを活用したビジネスのムダをなくす

http://www.amazon.co.jp/o/ASIN/482228350X/kakutani-22



アジャイル開発手法!インクリメンタル! Incremental! 漸進的! 少しずつ積み重ねていく

!イテレーティブ! Iterative! 繰り返し! 2週間～1ヶ月単位でのタイムボックス

インクリメンタル

要求

TDD 受入

フィードバック

イテレーティブ

半年とか1年

要求TDD

受入フィードバック?

要求

TDD


半年とか1年

受入!!!

半年とか1年

アジャイル開発手法!インクリメンタルかつイテレーティブ

!少しずつの積み重ねを繰り返していく

!フィードバック重要

インクリメンタル開発の流れ

バックログ

リリース計画

本番環境

受入テスト

受入テストケース

タスク

テスト

コード


優先順位づけ分解

完了条件

テスト駆動開発

満足条件

統合

実施

検証

デプロイ

2週間でnバックログをこなす

インクリメンタル開発の流れマイルストーン1 マイルストーン2

...

イテレーション

マイルストーン: マイルストーンは契約の単位です。1つのマイルストーンにつき、1回以上リリースするものとします。リリース: リリースプランニングを通じて、リリースに含める内容を優先順位にしたがって各イテレーションに割り当てます。含められる分量は、過去のイテレーション実績をもとに決定します。イテレーション: 1～2週間をタイムボックスとして、リリース計画で割り当てられた作業を実施します。状況の変化に応じて優先順位の変更に適応します。

リリース1 リリース2 リリース31 2 3 4 5 6 7 8 9

リリース4

イテレーションイテレーション10 11 ...イテレーション

アジャイル開発手法!インクリメンタル! Incremental! 漸進的! 少しずつ積み重ねていく

!イテレーティブ! Iterative! 繰り返し! 2週間～1ヶ月単位でのタイムボックス

手法や名前に惑わされてはいけない！！

『Head First ソフトウェア開発』

“プロセスとは、どのような図、文書、テストを実行すべきかに関する形式的な一連の規則というよりも…実は実行すべきことや実行すべきときを表すものにすぎないのです。また、頭文字も必要ありません…適切に機能すればよいのです。

『Head First ソフトウェア開発』

“自分のチームと自分のプロジェクトに役立つプロセスを選び…そのプロセスが生み出した成果物を自分の顧客の要望に合うように調整します。

『アジャイルな見積りと計画づくり』!見積り(Estimating)!計画づくり(Planning)!アジャイルな(Agile)

見積り

見積り! Estimating!見積もること!× 見積(御見積書)!プロセス = 「過程」

計画づくり

計画づくり! Planning!計画を立てること!× 計画(計画書)!プロセス = 「過程」

見積りと計画づくりのいずれもがプロセス、すなわち“それ”を実行することと、それを実行する主体についての話題である。

そしてプロセス、すなわち実行することと、その実行主体(つまり人)は既に遍在し実践され続けている。

つまり“プロセス”とはソフトウェアをつくっている活動そのもの、すなわちソフトウェアづくりである。

アジャイル

形容詞

http://gihyo.jp/dev/serial/01/agile



“アジャイル”とは既に遍在するプロセスの “ アジャイルさ”を形容するものであり、どれだけ “アジャイルであるか”を示す“度合い”なのだ。

アジャイルなプロセス! プロセス、つまり私たちの“ソフトウェアづくり”の過程がアジャイルであることの度合いを言っている(形容詞)

! “アジャイルプロセス”というモノは無い (名詞)

0123456789:;<=>?@ABCBCDEBFGHIJKLBMNFO

“Agility” is degree.

ー Kakutani Shintaro

アジャイルなプロセスとは何か?

開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行い続けることである。

学び

! 2つの知識の獲得!プロダクトに関する知識!なにをつくるのか?!プロジェクトに関する知識!どうやってつくるのか?

フィードバック = 学び

学びとは何か?

“学びとは“人に対して”行われることではない。“人が”行うことである。

ー Andy Hunt

だから、アジャイルなソフトウェアづくりの中心にはプロセスの実践主体である “人”が据えられねばならない。

“経験の伴わない、知識のみの習得は、効果がない。ー Andy Hunt

だから、イテレーション終了時点までにストーリーを「リリース可能なソフトウェア」へと変換せねばならない。

“目的やフィードバックのない無計画なやり方は、一貫性のない結果を招きがちである。

ー Andy Hunt

だから、安定したフィードバックを継続させるためには計画が必要であり、信頼のおける計画のためには見積りが欠かせない。

そして、信頼のおける見積りを出せるようになるには２つの知識を獲得できるフィードバックが欠かせない。

“見積りのコツは、見積もり続けること。ー Masatoshi SEKI (id:m_seki)

人について何を本当に信じているか？

リーン活動（ソフトウェア開発をアジャイルにしようとすること）に着手する前に答えるべき最後の問い：

“人について、何を本当に信じているか？ー Mr. & Mrs. Poppendieck

チームの一人ひとりがプロジェクトを通じて学び、うまくなっていけることを本当に信じられますか？本当に？

アジャイルなソフトウェアづくり!見積もるのは人!計画を立てるのは人!開発するのは人!使うのは人

XPの5つの価値!コミュニケーション!シンプル!フィードバック!勇気!敬意

XPのプラクティスの数

1.ペアプログラミング2.活き活きとした仕事3.情報満載の仕事場4.根本原因分析5.ふりかえり6.信頼7.全員同席8.真の顧客の参加9.ユビキタス言語10. スタンドアップミーティング11.コーディング標準12.イテレーションデモ13.報告14.「完全Done」

15. バグなし16. バージョン管理17. 10分ビルド18. 継続的インテグレーション19. コードの共同所有20. ドキュメント21. ビジョン22. リリース計画23. 計画ゲーム24. リスク管理25. イテレーション管理26.ゆとり27.ストーリー28.見積り

29. インクリメンタルな要件30.顧客テスト31.テスト駆動開発32.リファクタリング33.シンプルな設計34.インクリメンタルな設計とアーキテクチャ35.スパイクソリューション36.パフォーマンスの最適化37.探索的テスト

開発風景

インクリメンタル開発の流れ

バックログ

リリース計画

本番環境

受入テスト

受入テストケース

タスク

テスト

コード


優先順位づけ分解

完了条件

テスト駆動開発

満足条件

統合

実施

検証

デプロイ

2週間でnバックログをこなす

見積り

ストーリーカード

スタンドアップミーティング(朝会)

ペアプログラミング

バーンダウンチャート

ふりかえり

まとめ

参考文献

コミュニティ

http://objectclub.jp/

http://objectclub.jp

http://objectclub.jp

http://sites.google.com/site/devloveofficial/



http://kokucheese.com/event/index/707/



提　供

情報化技術を通じて社会と共生する

永和システムマネジメント!受託開発の会社です! ゲームは未経験ですが業務システムは得意です :)

!Rubyのお仕事承ります! JRubyでの納品実績もあります

!アジャイルな開発のご支援! 認定Scrumマスターが4人います

0123456789:;<=>?@ABCBCDEBFGHIJKLBMNFO

“Agility” is degree.

ー Kakutani Shintaro

ご清聴ありがとうございました




まとめ

demystifying agile software development

Business

eiwa system

iron

ja

asin4839924023kakutani

codesqueeze

wikipedia

asin487311392xkakutani

orgjaprogramabstract