kiyoka.2010_07_29 RSSPLAIN

Related pages: !kiyoka.blog.list !kiyoka.blog.2010_07
555555555555555555555555555555555555555555
5

[仕事術] 『スタートダッシュ型仕事術』を見習いたい

5
 FpPHju
5
 引用: Life is beautiful: スタートダッシュ型仕事術:実践編EXT
5
   まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェア
5
 の宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」
5
 「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャ
5
 の大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたり
5
 まえ。
5
   ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部
5
 分を一気に作って、早めに(仕様変更が必用かどうかの)見極めをする必用が
5
 ある」という点。特に「作って見なければ分からない」部分の見極めのための
5
 コーディングの時間を惜しんでいては、良いものは作れない。紙の上での設計・
5
 仕様書作り・会議に時間をかければかけるほど、そのかけた時間そのものが足
5
 かせになって柔軟な発想ができなくなる。それよりも、発想が浮かんだ時点で
5
 実際にコードを書いてみて「これで行けるかどうか」の実感をつかむことが大
5
 切。
5

(略)

5
 
5
  この段階で大切なことは、
5
 
5
   * 書いたプログラムを捨てることを恐れないこと
5
   * この段階で仕様書を書くことは時間の無駄と認識すること
5
   * 細かなことを無視して、一番難しい部分を最初に作ること
5
   * できるだけ早く、一気に「見極めが出来るところ」まで持って行くこと
5
   * コードは多少汚くても良いが、モジュール間のインターフェイスだけはキチンと設計すること
5
 
5
 の5つである。とにかく、このプロセスの目的は、「このアーキテクチャのままで製品化できるのかどうか」「想定し
5
 ているユーザーシナリオに合致したものができるかどうか」の「見極め」をすることなので、それ以外のこと(たとえ
5
 ば仕様書を書く、ミーティングに出席する、ユーザーインターフェイスの細部を決めるなど)に時間を使わず、とにか
5
 く一日でも早く「見極め」ができるところまで持って行く。
5

 

5

製品化されるプロジェクトでなくても同じだな...

5

プロジェクトの一番のキモになる部分が自分の想定したイメージ通りかを先に試す必要がある。

5

プライベートのプロジェクトでは自分の時間を投資しているわけだから、キモが実現出来るかどうかを早目に見極めて続けるか/やめるかを速い段階で決断しないといけないわけだし。

5

 

5

この記事を読んで、早速Nendoの開発の優先順位が変わった。

5

define-rulesとかどうでもいいので(誰がいつやっても実装できるに決まっている) 先にRubyとの連携部分をもっと詰めるべきだと思った。

5

 

5

よし。いろんなgemsを使ってみて問題点を洗いだし、先に解決していこう。(そのためにはそれなりに使えるツールを作る必要あり?)

5

SRFIライブラリの充実とかは後でじっくりやればいいのだよな。(util.listだけは普段必要としているので先にポーティングするかも)

5

 

5

...comment disabled...