gaball's note

Your awesome Tagline

リアクション(0)

Life is beautiful: スタートダッシュ型仕事術:実践編
 

 【図の解説】この図の一番上のグラフが私が推奨する開発プロセス。最初に思いついたアーキテクチャで8割型動くところまで一気に持って行き、そこで「これで行けるかどうか」の判断をする。「このままでは行けない」と感じたら、あっさりと最初に戻り、次ぎのアーキテクチャで作る。これを繰り返し、納得できるアーキテクチャに到達したところで、後は流す(コードをきれいにする、UIの細部を詰める、徹底的にテストをする、コメントを入れる、など)。

 二番目のグラフが、同じプロセスをラストスパート型でした場合。スタートダッシュ型と比べてやたらに時間がかかるのが分かると思う。

 しかし、実際にはラストスパート型でプロジェクトを進めた場合に陥るのが三番目のグラフのパターン。それなりに時間もかけてしまった、詳細な仕様書も作ってしまった、そのアーキテクチャで行くことの承認も取ってしまった、などの理由で、一度採用したアーキテクチャ・書いてしまったコードを捨てられなくなるのだ。なんとかアーキテクチャの大変更だけは避けようといろいろと工夫をするのだが、バグがバグを呼び、ドツボ(デス・マーチ)にハマるのがこのパターン。

Life is beautiful: スタートダッシュ型仕事術:実践編

   【図の解説】この図の一番上のグラフが私が推奨する開発プロセス。最初に思いついたアーキテクチャで8割型動くところまで一気に持って行き、そこで「これで行けるかどうか」の判断をする。「このままでは行けない」と感じたら、あっさりと最初に戻り、次ぎのアーキテクチャで作る。これを繰り返し、納得できるアーキテクチャに到達したところで、後は流す(コードをきれいにする、UIの細部を詰める、徹底的にテストをする、コメントを入れる、など)。  二番目のグラフが、同じプロセスをラストスパート型でした場合。スタートダッシュ型と比べてやたらに時間がかかるのが分かると思う。  しかし、実際にはラストスパート型でプロジェクトを進めた場合に陥るのが三番目のグラフのパターン。それなりに時間もかけてしまった、詳細な仕様書も作ってしまった、そのアーキテクチャで行くことの承認も取ってしまった、などの理由で、一度採用したアーキテクチャ・書いてしまったコードを捨てられなくなるのだ。なんとかアーキテクチャの大変更だけは避けようといろいろと工夫をするのだが、バグがバグを呼び、ドツボ(デス・マーチ)にハマるのがこのパターン。