アカウント名:
パスワード:
そもそも「バグの数=ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか?」は大抵の場合、NOですから。
上流工程の段階から仕様をきちんと煮詰められる(プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる)人間が携わっていれば、そんなにひどいモノはできない気がするんですけどね。
#でもスーツ着て客の前に出るのが面倒だから引きこもり気味の巫女なのでAC#ACの意味がないのは芸風です(言い切った)
それか、間違ったルートに入った時にそれが誰の責任か切り分けてお客さんに説明できる人もね。自分が悪いなら仕方ないが、お客さんの指示が間違ってたために実装が間違っている(=バグ扱い)のに、お客さんと戦わず要求の見込むだけのPMが多すぎで困る。
#自分は絶対戦うけど。#お金がどうこうじゃなくて、#プロジェクトに関わった人が救われないから。
…なんてこと考えると、最近流行の「コミュカ」ってのがやっぱり重要なんだろうね。バグの数とか品質がどうとかは本質的には関係なくて、要求されたものが全て滞りなく動けば問題ないんだから。
#コードレビューが相手のためじゃなくて自分の保身のためってのに似てるな…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
そもそも (スコア:3, 興味深い)
そもそも「バグの数=ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか?」は大抵の場合、NOですから。
上流工程の段階から仕様をきちんと煮詰められる(プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる)人間が携わっていれば、そんなにひどいモノはできない気がするんですけどね。
#でもスーツ着て客の前に出るのが面倒だから引きこもり気味の巫女なのでAC
#ACの意味がないのは芸風です(言い切った)
Re:そもそも (スコア:0)
それか、間違ったルートに入った時にそれが誰の責任か切り分けてお客さんに説明できる人もね。
自分が悪いなら仕方ないが、
お客さんの指示が間違ってたために実装が間違っている(=バグ扱い)のに、
お客さんと戦わず要求の見込むだけのPMが多すぎで困る。
#自分は絶対戦うけど。
#お金がどうこうじゃなくて、
#プロジェクトに関わった人が救われないから。
…なんてこと考えると、
最近流行の「コミュカ」ってのがやっぱり重要なんだろうね。
バグの数とか品質がどうとかは本質的には関係なくて、
要求されたものが全て滞りなく動けば問題ないんだから。
#コードレビューが相手のためじゃなくて自分の保身のためってのに似てるな…。