サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
買ってよかったもの
ameblo.jp/daxanya
開発プロセスに対する幻想を破壊する http://www.atmarkit.co.jp/farc/rensai/process01/process01.html ---- 開発プロジェクトにおける開発プロセスとはまさに、登山における最初のルートです。開発チームの経験、技術、関係各社（者）の状況から、最適と思われる開発プロセスを“作る”のです。この開発プロセスを作るときに、毎回ゼロから作るのではなく、基本的な作業の流れと、個々の作業の実施要綱をあらかじめ標準プロセスとして用意しておき、それを適宜修正しながら活用すると、初心者でも忘れ物をしないくらいにはできます。標準プロセスとは、その程度のものと考えるのがよいのです。 ---- ソフトウェア開発における「開発プロセス」とは、個人の作業を規定するもの、という認識が一般的なようだが、ちょっと違和感を感じている。開発プロセス＝開発者を縛るものという
ソフトウェア開発のデスマーチの惨状を聞くと、ほとんど例外なくプログラマが徹夜で頑張っている。逆に言うと、プログラマが徹夜で頑張るしかないプロジェクトほどデスマーチになる確率が高いと言えるだろう。 プログラムを書かなければソフトウェアが完成しないのはその通りだと思うが、遅れた原因はプログラマにだけあるとは思えないのに、なぜプログラマだけが苦行に耐えないといけないのだろうか。 従来の開発方法の場合、原因ははっきりしていて、前工程が遅れて、納期は変わらないから、プログラミングの工程に全てのしわ寄せが来るのである。 やっかいなのはプログラミングの工程自体はスケジュール通りに始まっているというケースである。仕様が確定していないのになぜか並行で工程が進んでしまう。こうなると関係者はスケジュールはやや遅れているが問題ない（平行で動いているので効率的とまで思ってしまう）という認識になりやすい。 クリティカ
ソフトウェア業界においてなんらかのトラブルがあると、トラブルの内容と共に、「きちんとテストしないからだ」「きちんと設計しないからだ」というコメントが報じられる。非常に無意味なコメントのように思う。 まるで関わった人たちの不注意、もしくは故意に失敗させたかのような言い方だが、実際はスキル不足、時間不足、予算不足の複合要因であろうことは想像に難くない。失敗原因を取り除けば成功するのではなくて、何かを足さないとうまくいかないということだ。 例えば、スキルのある人材の投入、スケジュールの延長、予算の追加確保等であるが、どれもプロジェクトの状況に流されていては得ることはできないものばかりである。プロジェクト内のスタッフは出来るだけ与えられたものだけを使って自分達の力だけでなんとかしようとするが、なんともならない場合に失敗という結果になる。 そう考えると、「きちんと○○していたらトラブルは防げた」とい
このページを最初にブックマークしてみませんか？
『それゆけ西表島：デスマーチとはプロジェクトが抱える責任を全てプログラマにおし...』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
