Agileって何?
2013-10-12 Munch
もくじ
おことわり
Question & Introduction
Agile Manifesto
アジャイルソフトウェア開発の12の原則
さいごに
参考文献
おことわり(1/2)
この資料は個人的に作成した資料であり、
所属する組織の見解とは関係ありません。
また、出来る限り出典を明らかにし、引用と
作成者の見解を分けて作成した(つもりの)
ものですが、作成者の偏見・誤解・独断が
混じった箇所もあるかもしれないので
その辺りは原著を調べてみて下さい
(作成者にもフィードバックがあると嬉しいです)
おことわり(2/2)
Brooks氏が「人月の神話」で言っていた様に、
Agileも残念ながら「銀の弾丸」ではないと思います。
ただ、現時点で僕はAgileの考え方よりマシな考え方を
寡聞にして知りません。
個人的にWaterFallよりもAgileな考え方の方が「好き」ですし、
どうしてもそっち寄りの資料になってしまった事も
否めないので、その辺りはさっぴいて見て頂けると幸いです。
要はイチAgile好きが勝手に作った資料だと言うことですww
最後に、この資料は具体的な手法(例えばXPやScrum)には
触れていません(というか、それらについては別に
資料を作成するつもりです。。。多分)
ところで
Question & Introduction(1/3)

あなたは「アジャイル」と聞いて
どんな事を想像しますか?
しんきんぐたいむ
Question & Introduction(2/3)
もしかしたら以下のような話が出たかもしれませんね
「アジャイルは誰でもできる?」
「デキる人じゃないと無理?」
「ドキュメントを書かない?」
「設計はなるべくしない?」
     ・
     ・
     ・
「Agile」という言葉が開発の現場に出てきて10年以上
経っていますが、未だに日本ではこのような質問が
出るのが珍しくありません
(因みに上記質問の回答に興味があれば、参考文献をご覧下さい)
参考文献(※1)(※2)
そこで
Question & Introduction(3/3)
この資料は具体的なプラクティスについての説明ではなく、
今一度原点に立ち返ることを目的に作成しました
具体的なプラクティスやノウハウ(「朝会」や「カンバン」、
「ペアプログラミング」 etc.etc...)はキャッチーで分かりやすく
「これからAgileを始めよう!」という人達には入り口として
良い物なのかもしれません。
ですが、「根っこ」の部分を押さえておかないと早晩
行き詰ったり、「歪んだ」方向に進み、「これなら従来の方法
の方がいいじゃないか!」なんて事にもなるかも
しれません。
それは個人的に非常に残念なので、この資料を
作成しました。
と、いうわけで
Agile Manifesto (1/3)
Agileを語るんだったら、マズはこれ

絵の背景の人々は
2001年初頭ユタ州
に集まった17人の人々
(だと思う)

参考文献(※3)
Agile Manifesto (2/3)
以下、アジャイルソフトウェア開発宣言より引用(※3)
「プロセスやツールよりも個人と対話
個人と
個人 対話を、
動 ソフトウェア
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調
顧客との協調を、
顧客との協調
計画に従うことよりも変化への対応
変化への対応を、
変化への対応
  価値とする。すなわち、左記のことがらに
価値があることを認めながらも、私たちは
右記のことがらにより価値をおく
のことがらにより価値をおく」
右記のことがらにより価値をおく

ここ、重要。左側の事を無視する
なんて一言も言ってない。
でも、誤解されがちな所

参考文献(※3)
Agile Manifesto (3/3)
前述のアジャイルソフトウェア開発宣言は
2001年2月にユタ州スノーバードで開催された
会議で採択されました
⇒ 参加者は1枚目のManifestoに名前が載ってた
   17人の軽量級の開発手法の提唱者の方々
面白い(?)のが、完全に全員の意見が一致したわけではない、というところ。
1.変化に対応する必然性には全員が同意。
2.前述した4つの宣言についても同意。
3.(次に述べる)12の原則について、かろうじて同意。
でも、詳細(具体的) 方法論については同意できない
については同意
4.でも、詳細(具体的)な方法論については同意できない
という結論だったらしい(※4)

参考文献(※4)付録のページより
Agile Manifesto (おまけ 1/7)
私見(というか妄想?)を少々
⇒ Agileが生まれた背景って、当時色々とWaterFallで失敗した現場が
   あって、「もっと他にマシな方法無いのか?」と色々と模索している
   心ある人達の中で色々議論した結果なんじゃないかな、と。
   (と、言いつつWaterFallについての誤解~Royce氏が結構
    迷惑してるんじゃ無い?~という話はまた別の機会に)

Agile vs WaterFall?
⇒ 個人的にはこの考え方には違和感あります。何故ならAgileとは既に
   述べたように「ソフトウェア開発における考え方・態度・思想・哲学(?)」
   の為、具体的な開発プロセスであるWaterFallとの比較は本来無意味
   だと思っています。WaterFall vs XP とか WaterFall vs Scrum
   とかならまだ分かるけど。

うーん、言葉だけでは分かりにくいんで次のページの
絵を参照
Agile Manifesto (おまけ 2/7)
Agile vs WaterFall 続き

WaterFall
Agile

参考文献(※5)
Agile Manifesto (おまけ 2/7)
Agile vs WaterFall 続き

WaterFall
Agile

無い。敢えて挙げると契約?
ココの比較が
ココの比較が
ひっかかってる
参考文献(※5)
Agile Manifesto (おまけ 2/7)
Agile vs WaterFall 続き

XP
他にも
Crystal
とかもある
けど省略

Scrum
Agile

最近ではLean とかDevOpsとかの
話もありますね(※5)

FDD

WaterFall

とか
その他

無い。敢えて挙げると契約?
ココの比較が
ココの比較が
ひっかかってる
参考文献(※5)
Agile Manifesto (おまけ 2/7)
Agile vs WaterFall 続き

最近ではLean とかDevOpsとかの
話もありますね(※5)

TDD、CI、
SCM 等の
技術的横
串

XP
他にも
Crystal
とかもある
けど省略

Scrum
Agile

FDD

WaterFall

とか
その他

無い。敢えて挙げると契約?
ココの比較が
ココの比較が
ひっかかってる
参考文献(※5)
Agile Manifesto (おまけ 2/7)
Agile vs WaterFall 続き

TDD、CI、
SCM 等の
技術的横
串

ドキュメント
・(テスト)コード
XP

他にも
Crystal
とかもある
けど省略

最近ではLean とかDevOpsとかの
話もありますね(※5)

Scrum
Agile

成果物
(ドキュメント・コード)

FDD

WaterFall

とか
その他

無い。敢えて挙げると契約?
ココの比較が
ココの比較が
ひっかかってる
参考文献(※5)
Agile Manifesto (おまけ 2/7)
Agile vs WaterFall 続き

最近ではLean とかDevOpsとかの
話もありますね(※5)

価値
TDD、CI、
SCM 等の
技術的横
串

ドキュメント
・(テスト)コード
XP

他にも
Crystal
とかもある
けど省略

Scrum
Agile

成果物
(ドキュメント・コード)

FDD

WaterFall

とか
その他

無い。敢えて挙げると契約?
ココの比較が
ココの比較が
ひっかかってる
参考文献(※5)
Agile Manifesto (おまけ 2/7)
Agile vs WaterFall 続き

最近ではLean とかDevOpsとかの
話もありますね(※5)

価値
TDD、CI、
SCM 等の
技術的横
串

ドキュメント
・(テスト)コード
XP

他にも
Crystal
とかもある
けど省略

Scrum
Agile

成果物
(ドキュメント・コード)

FDD

WaterFall

とか
その他

無い。敢えて挙げると契約?
ココの比較が
ココの比較が
ひっかかってる

個人的にはAgileの場合、ベースとして
「人(への尊敬・尊重)」がある気がする

参考文献(※5)
Agile Manifesto (おまけ 3/7)
でも敢えて所謂Agile(的な開発手法)とWaterfallを比較してみると
下記のような比較表とかが出てきますね
⇒ 「なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い」(※6)
    より

参考文献(※6)
突然ですが
ビリヤードのナインボール
というゲームをご存知ですか?
ビリヤードのナインボール
というゲームをご存知ですか?
ビリヤードのナインボール
というゲームをご存知ですか?
Agile Manifesto (おまけ 4/7)
AgileとWaterfallについて、敢えて筆者なりの対比をしてみると・・・
Agile Manifesto (おまけ 4/7)
AgileとWaterfallについて、敢えて筆者なりの対比をしてみると・・・

一発で9番をポケットに
入れようとするのが
Waterfall
Agile Manifesto (おまけ 4/7)
AgileとWaterfallについて、敢えて筆者なりの対比をしてみると・・・

一発で9番をポケットに
入れようとするのが
Waterfall

順番に落としやすい
ボールからポケットに
落としていくのがAgile
Agile Manifesto (おまけ 5/7)
新アジャイルマニフェスト(※7)(※8)
⇒ 元祖(?)アジャイルマニフェストのメンバーの一人でもある
   KentBeckさんが「新アジャイルマニフェスト」というものを
   発表されたらしいです。曰く

個人と対話(やプロセスやツール)よりも
チームのビジョンと規律を
チームのビジョンと規律を、
動くソフトウェア(や包括的なドキュメント)よりも
検証による学習を
による学習
検証による学習を、
顧客との協調(や契約交渉)よりも
顧客の発見を
顧客の発見を、
変化への対応(や計画に従うこと)よりも
変化の提案を
変化の提案を
AgileManifesto自身も変化していってますね
参考文献(※7)(※8)
Agile Manifesto (おまけ 6/7)
日本も負けてられないって事で、日本発の記事をご紹介
「アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは」
(※9)
⇒ 詳細については元記事を参照して頂きたいのですが、結論として
  「アジャイル開発では当初に想定した機能を”全部”つくらない」
アジャイル開発では当初 想定した機能を 全部”
開発では当初に
した機能
  という事が、Agile と WaterFall の最大の違いである、と倉貫さんは述べられています
また、合わせて読んでおいてもらいたい記事に

「アジャイルの「ライトウィング」と「レフトウィング」」(※10)
⇒ 「Agile」について話をする場合、何か上手く噛み合わない場合があります。
   と、いうのも単に「Agile」と言ってしまうと、技術的な話からチームビルディングまで、
   幅広く深い要素を含んでいるので、、、という事を整理されている記事です
   

参考文献(※9)(※10)
Agile Manifesto (おまけ 7/7)
そろそろまとまりが付かなくなってきたんで、最後に
1歩どころか10歩20歩先を行ってる海外の方では、、、
という記事をご紹介。
「アジャイルの衰退と凋落」(※11)
 ⇒ 詳細については元記事を読んで頂きたいのですが、個人的には見た目に
    わかりやすいプラクティスや形式に走ってしまって、Agile Manifestoや
    それが生まれた背景なんかを置き去りにした事が原因の一つではないか
    と個人的には考えています。
    (あ、お前にAgileの何が分かってるんだ!というマサカリがアッチコッチから
     飛んできた。イタイ、イタイ。。。)
    そうそう、どうやら上記記事の原文は「ローマ帝国衰亡史」が
    下敷きにあるそうなので、「アジャイル衰亡史」の方が
    いいなぁという事を関西の某スクラムマスタが仰ってました(^^)
参考文献(※11)
次に
アジャイルソフトウェア開発の12の原則(1/3)
次は「アジャイルソフトウェア開発の12の原則(※12)」について
⇒ 先の Agile Manifesto をもう一段噛み砕いたものになります
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

参考文献(※12)
アジャイルソフトウェア開発の12の原則(2/3)
アジャイルソフトウェア開発の12の原則について(続き)
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
アジャイルソフトウェア開発の12の原則(3/3)
アジャイルソフトウェア開発の12の原則について
⇒ 一つずつ語りだすとまた「おまけ」の方が長くなって
   しまうので、1冊だけ良書をお勧めしておきます。
「アジャイルサムライ -達人開発者への道-」(※13)
これから「アジャイル」について学ぼうとする人だけでなく
ある程度「アジャイル」について知っている人にとっても
十分に読み応えのある内容になっています。

参考文献(※13)
さいごに
2つだけ問いかけをして終わりにしたいと思います

「あなたはなぜAgileを選んだ(選ぼうとした)のでしょう?」
⇒ あなたはAgileに何を期待したり、求めているのでしょうか?

「Agileには欠点がないのでしょうか?」
⇒ Waterfall ではダメなんでしょうか?何時いかなる場面でも
   AgileはWaterfallより優れた考え方なのでしょうか?

以上、最期までお付き合い頂き、有難うございました。
参考文献(その1)
(※1)「アジャイル勘違い集 」http://bit.ly/17cvNOr
(※2)「アジャイル開発の勘違い」http://bit.ly/1bLUWo5
(※3)「Agile Manifesto」 http://bit.ly/190BFNB
 ⇒ 日本語版はこちら http://bit.ly/1cc8bwr
(※4)「アジャイルソフトウェア開発」(書籍) (ピアソンからの本なので絶版・・・残念)
(※5)「高度12000フィートからのAgileとLean
高度12000フィートからのAgileと
高度12000フィートからのAgile Lean」http://bit.ly/167ZPlU
(※6)「なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い」
http://slidesha.re/19Ja3ka
(※7)「新アジャイルマニフェスト」http://bit.ly/1bc6jsN
(※8)「Kent Beck talks beyond agile programming」http://bit.ly/GDCuCY
(※9)「アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは」
http://bit.ly/19lJnFy
(※10) アジャイルの「ライトウィング」と「レフトウィング」http://bit.ly/SLJY9Z
(※11)「アジャイルの衰退と凋落」http://bit.ly/18RCi9R
(※12)「アジャイルソフトウェア開発の12の原則」 http://bit.ly/1b3GWVT
 ⇒ 日本語版はこちら http://bit.ly/14iWXDe
(※13)「アジャイルサムライ-達人開発者への道-」 http://amzn.to/ZaVoYo
参考文献(その2)
以下は直接的には本編で紹介しませんでしたが、興味のある方の参考に
なりそうな資料を紹介させて頂きます
(※)「非ウォーターフォール型(アジャイル)開発 の動向と課題」http://bit.ly/1hMX3cb
(※)「ウォーターフォールモデルの起源に関する考察 ウォーターフォールに関する誤
解を解く」http://bit.ly/1ftLp9n
(※)「アジャイルとウォーターフォールについて本気出して考えてみる」
http://bit.ly/GULgxy
(※)「いま、できるアジャイル」http://slidesha.re/18ZcI6q

(公開用)Agileについて