ウォーターフォールからアジャイル的な開発にするために - １

アジャイルはメンドクサイ？

多くの現場でまだウォーターフォール(W/F)で開発している現場が多く、そこでスクラムしようぜって言っても、

• 品質・納期・費用でどれを重視するの？納期無視するんでしょ？
• 決まりみたいなのが多くてメンドクサイ。
• 契約で期間が決まっているからできない。

などの言い訳されて実施に至りにくく、どれもそんなことないよって事を自分的にまとめたい。

※ 書籍を読んで、実際にやってみてこうやって進めたらいいんじゃないのか？と思った内容になるので、何とか宣言に沿ってないとか、色々あると思います。

ウォーターフォールは悪なのか？

こういう話が立ち上がると、ウォーターフォールしか経験したことない人が、「やり方が否定されている」＝「俺たちが悪だといわれている」という勘違いをして話をしがちな事に注意したい。
そんな考え方してるから次に進めない人な感じもしますが。

なので、どっちも目標としていることは同じだけど、プロジェクトの性質によって使い分けないと辛くなるんだ。という事を全員で最初に共有したい。

なので、ウォーターフォールは悪くない。（当たり前ですが）

使う場面

ウォーターフォールは最初から最後まで、ほぼ計画通り進む事を前提に話を進める必要があります。なので、計画の確定性が高いプロジェクトには適してます。
例えば、自動車を作るラインとか、パンの加工とかでしょうか。各工程でやる事がかなり明確になっているプロジェクトですね。
ITでいえば、ベースのアプリがあって、決まったカスタマイズをかけて出荷するようなプロジェクト（アプリ）でしょうか。


アジャイルは、計画の確定性が低いプロジェクトに使います。
なにか作業をしている途中で、「やっぱり、それ無しで」、「これにこの機能も足してくれないと仕事につかえない」とか、最初の計画になかったことを言われるプロジェクトですね。
良くありますね・・・。

プロジェクトの途中だし、今更変えれないよ

やる事はほとんど変わりません。

書籍を読むとJeninsやらCircleCIやら、TeamCityやらCIを導入しなさいとか、テスト駆動（TDD）しなさいとかありますが、しなくてもいいです。

したほうがもちろんいいですが、しなくてもいいです。いきなり全部しようとすると、何のためにしているのかわからず、形骸化してやるだけになってしまい、どこが自分たちにマッチしているのかわからなくなってしまって結局使わなくなるからです。

それらの考えが導入された順を追って、導入していけばいいと思います。
アジャイルをやってくうちに、きっと欲しくなってきます。その時に新しい物好きな人を探して導入してもらえばいいと思います。

で、何が違うの？

ほとんどの事が、恐らく普段やっているであろう管理業務の間隔を短くするだけです。

次から一つずつ纏めていこうと思います。

こんな本を読みました

もはや、有名ですね。チームを作るうえで必要な事がほぼ書いてあります。あやふやだった部分を文章化されているので、知識の再認識にもいい。

不確実な事に対してどうやって取り組んで、確実に近づけていくか。その手法について書いてあります。読むだけだと当たり前だよなぁってなりがちだけど、実践すると大変。
知識として入れておくといい。