う～む。(^-^;
これを読んで思いだたことがあります。通常、ソフトウェアを作成する場合は、トップダウンか、ボトムアップで作成することになるだろう。 普通だったら、仕様をもとに、トップダウンで作成していくのが正当なやり方だろう。 ところが現実は、そうではない。第一線のプログラマはトップダウンとボトムアップの両面から同時に作っていくのだそうだ。 何故かって？それは、クライアントからの仕様変更に対応するためなのだそうです。ある程度まではトップダウンで作るが、それ以降はボトムアップで、機能に必要と思われる下請けルーチンをどんどん作っておくのだそうです。 こうしないと、納期と仕様を満足できなくなると言うことでした。 走りながら考える典型だなぁ～と思ったしだいでした。
ソフトウェア開発においても、なににおいても「走りながら考える」とは経験や理論から方針を導き出せない場合になるのではないかな？「時間がないから」とは、裏を返せば「今この時点で方針決定できない（力が無い?)ので、状況をみて決める」ということになるかと。「時間がないから」が本当に時間が無いという状況であるならば、それはとっても致命的。
韓国では「始めてしまえば半分終わり」ということわざがあるそうな。。。
> 機能に必要と思われる下請けルーチンを> どんどん作っておくのだそうです。それって、いわゆる「既に頭の中で動いている・頭の中で出来ている」状態だと思うので、ある程度かもしれませんが考えてから走っているのだと思います。
> 韓国では「始めてしまえば半分終わり」という> ことわざがあるそうな。。。おー。これも深いなぁ。いろいろ課題があるときに、課題管理表みたいなものを作るけど、「発生」で進捗0%「着手」で進捗30%とか50%などの取り決めをする場合がありますよね。��着手するって言うのは、担当のアサインが済んで、��しかもやることが明確だから出来るので��あながち、いい加減ではないかとも思います。
う～む。(^-^;
返信削除これを読んで思いだたことがあります。
返信削除通常、ソフトウェアを作成する場合は、トップダウンか、ボトムアップで作成することになるだろう。
普通だったら、仕様をもとに、トップダウンで作成していくのが正当なやり方だろう。
ところが現実は、そうではない。第一線のプログラマはトップダウンとボトムアップの両面から同時に作っていくのだそうだ。
何故かって？それは、クライアントからの仕様変更に対応するためなのだそうです。ある程度まではトップダウンで作るが、それ以降はボトムアップで、機能に必要と思われる下請けルーチンをどんどん作っておくのだそうです。
こうしないと、納期と仕様を満足できなくなると言うことでした。
走りながら考える典型だなぁ～と思ったしだいでした。
ソフトウェア開発においても、なににおいても「走りながら考える」とは経験や理論から
返信削除方針を導き出せない場合になるのではないかな？「時間がないから」とは、裏を返せば「今この時点で方針決定できない（力が無い?)ので、状況をみて決める」ということになるかと。
「時間がないから」が本当に時間が無いという状況であるならば、それはとっても致命的。
韓国では「始めてしまえば半分終わり」ということわざがあるそうな。。。
返信削除> 機能に必要と思われる下請けルーチンを
返信削除> どんどん作っておくのだそうです。
それって、いわゆる
「既に頭の中で動いている・頭の中で出来ている」
状態だと思うので、ある程度かもしれませんが
考えてから走っているのだと思います。
> 韓国では「始めてしまえば半分終わり」という
返信削除> ことわざがあるそうな。。。
おー。これも深いなぁ。
いろいろ課題があるときに、課題管理表みたいなものを
作るけど、
「発生」で進捗0%
「着手」で進捗30%とか50%
などの取り決めをする場合がありますよね。
��着手するって言うのは、担当のアサインが済んで、
��しかもやることが明確だから出来るので
��あながち、いい加減ではないかとも思います。