View
1.572
Download
1
Category
Tags:
Preview:
DESCRIPTION
2009-11-13, bandainamcogames
Citation preview
角谷 信太郎KAKUTANI Shintaro; Eiwa System Management,Inc.
(株)永和システムマネジメント s-kakutani@esm.co.jp
第6回プログラマーズカンファレンス; 2009-11-13(金)
アジャイルなソフトウェア開発の基本と実践Demystifying Agile Software Development
角谷信太郎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つの世界”!パッケージ!インターナル!組み込み!ゲーム!使い捨て
“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.変更に対応できることが求められている
http://www.amazon.co.jp/o/ASIN/4839924023/kakutani-22
最後に出てくるケーススタディがゲーム開発だったり
今日は違いを気にするよりも似てるところや同じところを見つけてもらえるといいなと思ってます。
よろしくお願いします
角谷 信太郎KAKUTANI Shintaro; Eiwa System Management,Inc.
(株)永和システムマネジメント s-kakutani@esm.co.jp
第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.rubyworld-conf.org/ja/program/abstract/a-2/
http://www.rubyworld-conf.org/ja/program/abstract/a-2/
http://www.codesqueeze.com/the-broken-iron-triangle-is-broken/
鋼鉄の三角形
品質
http://www.amazon.co.jp/o/ASIN/4274066940/kakutani-22
“いち開発者である自分には企業資産(つまりコードベース全体)の価値を低下させるような権限はない
ーーVenkat & Andy『アジャイルプラクティス』
http://www.amazon.co.jp/o/ASIN/4048676881/kakutani-22
品質スコープ(フィーチャ、機能)
品質スコープ
リソース
(フィーチャ、機能)
(コスト、予算)
品質スコープ
リソース
(フィーチャ、機能)
(コスト、予算)時間
(スケジュール)
鋼鉄の三角形でリソースと時間は独立して操作可能か?
たとえば思考実験! 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...
http://www.codesqueeze.com/the-broken-iron-triangle-is-broken/
リソースと時間が固定でかつスコープも固定の場合、品質に影響が出るか、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/4894716852/kakutani-22
http://www.amazon.co.jp/o/ASIN/0321579364/kakutani-22
http://www.amazon.co.jp/o/ASIN/482228350X/kakutani-22
アジャイル開発手法!インクリメンタル! Incremental! 漸進的! 少しずつ積み重ねていく
!イテレーティブ! Iterative! 繰り返し! 2週間～1ヶ月単位でのタイムボックス
インクリメンタル
要求
TDD 受入
フィードバック
要求
TDD 受入
フィードバック
要求
TDD 受入
フィードバック
要求
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ヶ月単位でのタイムボックス
手法や名前に惑わされてはいけない！！
http://www.amazon.co.jp/o/ASIN/487311392X/kakutani-22
『Head First ソフトウェア開発』
“プロセスとは、どのような図、文書、テストを実行すべきかに関する形式的な一連の規則というよりも…実は実行すべきことや実行すべきときを表すものにすぎないのです。また、頭文字も必要ありません…適切に機能すればよいのです。
『Head First ソフトウェア開発』
“自分のチームと自分のプロジェクトに役立つプロセスを選び…そのプロセスが生み出した成果物を自分の顧客の要望に合うように調整します。
http://www.amazon.co.jp/o/ASIN/4839924023/kakutani-22
『アジャイルな 見積りと計画づくり』!見積り(Estimating)!計画づくり(Planning)!アジャイルな(Agile)
見積り
見積り! Estimating!見積もること!× 見積(御見積書)!プロセス = 「過程」
計画づくり
計画づくり! Planning!計画を立てること!× 計画(計画書)!プロセス = 「過程」
見積りと計画づくりのいずれもがプロセス、すなわち“それ”を実行することと、それを実行する主体についての話題である。
そしてプロセス、すなわち実行することと、その実行主体(つまり人)は既に遍在し実践され続けている。
つまり“プロセス”とはソフトウェアをつくっている活動そのもの、すなわちソフトウェアづくりである。
アジャイル
形容詞
http://www.amazon.co.jp/o/ASIN/4274066940/kakutani-22
http://gihyo.jp/dev/serial/01/agile
“アジャイル”とは既に遍在 す る プ ロ セ ス の “ アジャイルさ”を形容するものであり、どれだけ “アジャイルであるか”を示す“度合い”なのだ。
アジャイルなプロセス! プロセス、つまり私たちの“ソフトウェアづくり”の過程がアジャイルであることの度合いを言っている(形容詞)
! “アジャイルプロセス”というモノは無い (名詞)
0123456789:;<=>?@ABCBCDEBFGHIJKLBMNFO
“Agility” is degree.
ー Kakutani Shintaro
アジャイルなプロセスとは何か?
http://www.amazon.co.jp/o/ASIN/4274066940/kakutani-22
開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行い続けることである。
フィードバック
学び
! 2つの知識の獲得!プロダクトに関する知識!なにをつくるのか?!プロジェクトに関する知識!どうやってつくるのか?
フィードバック = 学び
学びとは何か?
http://www.amazon.co.jp/o/ASIN/4873114039/kakutani-22
“学びとは“人に対して”行われることではない。“人が”行うことである。
ー Andy Hunt
だから、アジャイルなソフトウェアづくりの中心にはプロセスの実践主体である “人”が据えられねばならない。
“経験の伴わない、知識のみの習得は、効果がない。ー Andy Hunt
だ か ら 、 イテ レ ーション終了時点までにストーリーを「リリース可能なソフトウェア」へと変換せねばならない。
“目的やフィードバックのない無計画なやり方は、一貫性のない結果を招きがちである。
ー Andy Hunt
だから、安定したフィードバックを継続させるためには計画が必要であり、信頼のおける計画のためには見積りが欠かせない。
そして、信頼のおける見積りを出せるようになるには２つの知識を獲得できるフィードバックが欠かせない。
“見積りのコツは、見積もり続けること。ー Masatoshi SEKI (id:m_seki)
人
人について何を本当に信じているか？
http://www.amazon.co.jp/o/ASIN/482228350X/kakutani-22
リーン活動（ソフトウェア開発をアジャイルにしようとすること）に着手する前に答えるべき最後の問い：
“人について、何を本当に信じているか？ー Mr. & Mrs. Poppendieck
チームの一人ひとりがプロジェクトを通じて学び、うまくなっていけることを本当に信じられますか？本当に？
アジャイルなソフトウェアづくり!見積もるのは人!計画を立てるのは人!開発するのは人!使うのは人
http://www.amazon.co.jp/o/ASIN/4894716852/kakutani-22
XPの5つの価値!コミュニケーション!シンプル!フィードバック!勇気!敬意
http://www.amazon.co.jp/o/ASIN/4873113636/kakutani-22
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://gihyo.jp/dev/serial/01/agile
http://www.amazon.co.jp/o/ASIN/4274066940/kakutani-22
http://www.amazon.co.jp/o/ASIN/4873113636/kakutani-22
http://www.amazon.co.jp/o/ASIN/4839924023/kakutani-22
http://www.amazon.co.jp/o/ASIN/487311392X/kakutani-22
コミュニティ
http://sites.google.com/site/devloveofficial/
http://kokucheese.com/event/index/707/
提 供
情報化技術を通じて社会と共生する
永和システムマネジメント!受託開発の会社です! ゲームは未経験ですが業務システムは得意です :)
!Rubyのお仕事承ります! JRubyでの納品実績もあります
!アジャイルな開発のご支援! 認定Scrumマスターが4人います
0123456789:;<=>?@ABCBCDEBFGHIJKLBMNFO
“Agility” is degree.
ー Kakutani Shintaro
ご清聴ありがとうございました
! アジャイル開発はソフトウェアの本質に逆らわない
! 人が中心ということを忘れてはいけない
! 名前に惑わされてはいけない
まとめ
Recommended