■

Agile失敗パターン三部作
http://d.hatena.ne.jp/masayang/20090227/1235782899

未知の技術を採用したり、未知の領域のアプリを開発したりするような場合には、プロジェクトはそれなりの(把握できない)リスクを抱える事になる。
だとしても、プロジェクト終盤で問題が発覚することが多いウォーターフォール型開発よりは、比較的早い段階で問題を把握できるAgileの方が有利ではある。

ウォーターフォール大好き人間達にいつも言われたことは
「リスクと問題点は全て洗い出して解決しなきゃいかんのです。
　随時解決するなんてリスクはとれませんよ」
よくよく思えばやり始めていきなりわかるほうが対策が打てる分有利だよなとしみじみ思った。

ただしそれも、「問題が起きている」ということを把握できる実力がAgileチームにあれば、の話である。

いかな方法にも実力は大事。納得。

[雑感]考えることを放棄した人々の行うアホ極まりないこと。

人々を教育して「デキル」人材を育てるという難しいことをするよりも、
底辺に合わせるっつー無謀なことをして「安定化を計る」と理由をつけてる。

「安定化」それなりに耳に心地よさそうな言葉だけに、
前提がとてつもなくアホなことでも、ちょっと考えればわかることでも
考えないから心地よい言葉に飛びついちゃうんだな。

[効率化模索]TDD

テストケースが爆発してってよりも、DBのデータをあわせておくのがかったるくなってやめてしまった経験があるのだけれども、
やりかたがまずいんだよな。
なんかほれ。
全部テスト作って〜っとめんどくさく思ったけど、必要なとこだけ作って必要なだけテストする気持ちでいれば
分量に萎えなくてすんだかもしれない。
まだまだだなとおもた。がんばろ。