アカウント名:
パスワード:
私の実体験のみに基づいた感覚です。うまく行った、というより、試験に合格するため点数だけ積み上げた、というのに近いと思う。あの有名な絵(タイヤのブランコのやつ。「顧客の説明」とか「営業の約束」とかのアレです)のとおりで、元からして過不足がある、いびつなシステムしか作れていないのでは無いかと思う。
その点、最終的な顧客満足を得るまで何度も調整を繰り返すアジャイルとは目指すゴール自体が違うのかな、とも思う。
つまり、エコは駄目な方針ということですね。
費用対効果を軽く見てる時点で論外。システムが何のために存在してるのか考えたほうがいい。
# もっといえば、ビジネスマンとしての基本感覚が欠如している
「うまくいった」結果しか表に出てこないからではないかと。
タイヤの絵→出来上がったものが「仕様」になる→うまくいった各工程で破綻→デスマ突入で力技→ある日突然「受入合格」判定→うまくいったそれ以外→そんな開発は無かった
# どのパターンも経験したような気がするのでAC
良い品質=上流工程の設計通りに作られてる
ですからね。
これは、ある部分では間違ってないように思えるけど、上流工程の設計通りに作られてることが証明できる必要があるので、下流では、設計にない要素や証明困難な部分は徹底的に切り捨てられます。その結果、予想外の入力に対する耐性とか、処理の最適化とかが、意識的に削られるわけですね。怖いですね。
最初に書いた定義からすれば確かに「高品質」なんだけど、コードの質的にもユーザエクスペリエンス的にも、???なものができあがるのは、どうかと思いますよね。
>コードの質的にもユーザエクスペリエンス的にも、>???なものができあがるのは、どうかと思いますよね。
あるある。
「この機能があると便利」「この部分は操作性に問題があるから、このように変更した方が良い」というのが良くあるんだけど、
「仕様書を変更する許可が下りない」「上司を説得するのが面倒」「検証に時間がかかる」みたいな理由でお蔵入り。
変更と実装にかかる時間よりも、ウォーターフォールが作った無意味な足枷の方がずっと重くて、雁字搦めで身動きが取れなくなってるのが日本の現状。
という定義がそもそも間違ってるし、
下流では、設計にない要素や証明困難な部分は徹底的に切り捨てられます。
予想外の入力に対する耐性とか、処理の最適化とかが、意識的に削られるわけですね。
というのは、あなたの所属していたところがそうだったというだけであって、ウォーターフォールだからそうなるということでは無いですね。 したがって、
コードの質的にもユーザエクスペリエンス的にも、???なものができあがる
これも、ウォーターフォールだからということと関係無いよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
なにをもって「うまくいった」とするのか (スコア:3, 興味深い)
私の実体験のみに基づいた感覚です。
うまく行った、というより、試験に合格するため点数だけ積み上げた、というのに近いと思う。
あの有名な絵(タイヤのブランコのやつ。「顧客の説明」とか「営業の約束」とかのアレです)のとおりで、
元からして過不足がある、いびつなシステムしか作れていないのでは無いかと思う。
その点、最終的な顧客満足を得るまで何度も調整を繰り返すアジャイルとは
目指すゴール自体が違うのかな、とも思う。
Re:なにをもって「うまくいった」とするのか (スコア:1, すばらしい洞察)
ITの本質は「パターン化された」「大量のデータを」「地理的環境に関係なく」「高速に処理し」「2次・3次加工も容易」という部分をどれだけ「長所として」のばせるか、と言う点だと思う。
アジャイルもコストが安い、と言う点よりは長所をどのようにのばせるか、が重要。
コスト削減は2番目か3番目か、4番目か、重要度は落とした方が結果的に会社としては良くなると思う。
そんな私は、経営とは関係ないシタッパーズ & 今はシステム屋でも無し。
Re: (スコア:0)
つまり、エコは駄目な方針ということですね。
Re: (スコア:0)
費用対効果を軽く見てる時点で論外。
システムが何のために存在してるのか考えたほうがいい。
# もっといえば、ビジネスマンとしての基本感覚が欠如している
Re: (スコア:0)
Re: (スコア:0)
「うまくいった」結果しか表に出てこないからではないかと。
タイヤの絵→出来上がったものが「仕様」になる→うまくいった
各工程で破綻→デスマ突入で力技→ある日突然「受入合格」判定→うまくいった
それ以外→そんな開発は無かった
# どのパターンも経験したような気がするのでAC
Re: (スコア:0)
結果としてのコードより、各種書類のほうが色々重要視されたり
しますし。
Re: (スコア:0)
良い品質=上流工程の設計通りに作られてる
ですからね。
これは、ある部分では間違ってないように思えるけど、
上流工程の設計通りに作られてることが証明できる
必要があるので、下流では、設計にない要素や
証明困難な部分は徹底的に切り捨てられます。
その結果、予想外の入力に対する耐性とか、処理の最適化とかが、
意識的に削られるわけですね。怖いですね。
最初に書いた定義からすれば確かに「高品質」なんだけど、
コードの質的にもユーザエクスペリエンス的にも、
???なものができあがるのは、どうかと思いますよね。
Re:なにをもって「うまくいった」とするのか (スコア:2, すばらしい洞察)
>コードの質的にもユーザエクスペリエンス的にも、
>???なものができあがるのは、どうかと思いますよね。
あるある。
「この機能があると便利」
「この部分は操作性に問題があるから、このように変更した方が良い」
というのが良くあるんだけど、
「仕様書を変更する許可が下りない」
「上司を説得するのが面倒」
「検証に時間がかかる」
みたいな理由でお蔵入り。
変更と実装にかかる時間よりも、ウォーターフォールが作った無意味な足枷の方が
ずっと重くて、雁字搦めで身動きが取れなくなってるのが日本の現状。
Re: (スコア:0)
良い品質=上流工程の設計通りに作られてる
という定義がそもそも間違ってるし、
下流では、設計にない要素や証明困難な部分は徹底的に切り捨てられます。
予想外の入力に対する耐性とか、処理の最適化とかが、意識的に削られるわけですね。
というのは、あなたの所属していたところがそうだったというだけであって、ウォーターフォールだからそうなるということでは無いですね。 したがって、
コードの質的にもユーザエクスペリエンス的にも、???なものができあがる
これも、ウォーターフォールだからということと関係無いよ。
Re: (スコア:0)
自分自身が実験体、と空目。
なんとなく、あぁと納得してしまう自分。