マーチン・ファウラー氏が、[url=http://pw.tech-arts.co.jp/act2011/]Agile Conference tokyo 2011[/url]で語ったことを纏めた記事を読みました。

　http://www.publickey1.jp/blog/11/21agile_conference_tokyo_2011.html

面白いことが沢山書いてあります。
頭の良い人は、発想が素敵ですね。

[quote]アジャイル開発と計画駆動開発（Plan-Driven）をくらべてみよう。そこには「予想的な計画（Predictive Plannning）」と「適応的な計画（Adaptive Plannning）」、そして「プロセス主導」対「人主導」という違いがある。[/quote]

「プロセス主導」と「人主導」という表現が素敵です。

[quote]要件の安定性に依存するのは不健全だ[/quote]

(；´∀｀)

[quote]土木や建築に由来するのが「計画駆動開発」で、これは最初に計画を立てて設計し、実行する。このプロジェクトの成功の定義は、計画通りにいったかどうかだ。成功は、事前に要件が明確であり、安定していることに依存している。 ソフトウェアの開発では、プロジェクトの途中で要件に大きな変更が起きることはよくある。そのため計画駆動のソフトウェア開発では、成功のために要件をいかに安定させるかということに力を注いでいた。[/quote]

ふむふむ。
あるある。

[quote]しかしアジャイル開発では違うアプローチをとった。要件の安定に依存するのは健全ではない。要件が不安定であってもプロジェクトを前に進めていくプロセスがあるべきだと考えたのだ。 アジャイル開発では 少しだけ計画をし、そこから学習する、ということを小刻みに続け、計画をすることを歯車のように動かし続ける。ユーザーは早い段階で状況を把握でき、次に何が必要かを迅速に判断できるようになる。適応的な計画（Adaptive Planning）、これがアジャイル開発のアプローチだ。[/quote]

そうですね。
要件は安定しない(こともある)ですよ。
「歯車のように動かし続ける」ってのは、大変ですけど必要ですね。

[quote]アジャイル開発は、このやり方に疑問を持った。たとえプロセスがしっかり定義されていても、優秀な人たちがよい関係で仕事をしないとうまくいかないのだ。デドワーズ・デミング氏も「悪いプロセスはいつでも優秀な人を損ねてしまう」と言っている。 アジャイル開発では、まず優秀な人をさがし、チームとして協力できるかを見極め、そのうえで彼ら自身でやりやすい環境やプロセスを作ってもらう。プロセスありきから、人ありきになるのだ。[/quote]

深い・・・。
話の内容が、抽象的で解釈は色々だと思うが、私は同意できる。

続いてこちら。

　http://www.publickey1.jp/blog/11/21agile_conference_tokyo_2011_1.html

[quote]マージは分岐から時間がたつほどに難しくなる、であれば、難しくなる前に、頻繁にマージをすればいい。これを「Continuous Integration」（継続的インテグレーション）と呼んでいる。[/quote]

これは、経験上そう思います。
だから、こまめに行い、必要に応じて自動化する。

[quote]コードが運用環境に対応しているか（プロダクションレディか）を確認するにはテストが必要だ。テストを行えば、コードに問題がないという自信や安心が得られる。しかしテストには時間がかかるため、テストをするほど完成とデリバリが遅れる。そこにはバランスをとる必要がある。[/quote]
[quote]そして、パイプラインのテストは可能な限り自動化すべきだ。いつでもテストができるように完璧に自動テスト化する事をおすすめする。[/quote]

これは、私自身の未知の世界。
飛び込んでみようかしら。

アジャイル開発についての私自身の解釈と理解は、まだまだ浅いですが
こういった新たな用語を用いて解説されると、捉え方も柔軟になり、考え方に幅がでます。

全ての仕事(開発プロジェクト)をこの形に当てはめるのは、強引だしうまく行かないこともあるでしょう。
ただ、こういった考えを理解し、自分の環境にカスタマイズするのも一つだと思うし、組織立って取り組むのも良いのかも。

朝から頭使っちゃった(*´∀`)