谷野、というものです。
At 09:48 02/06/18 +0900, you wrote:
>はじめまして。片岡と申します。
はじめまして。
> > 欠陥が多いとXPのように変更を繰り返す
> > と欠陥が欠陥を生んで収拾がつかなくなるおそれがあります。
>
>それを回避するためのテストでは？
>欠陥が欠陥を生むのはむしろ
>
> > 信頼性を高めるためには、可能な限りソフトウェアを変更しないように
> > すべきであり
>
>という従来の考え方だと思います。
でもないと思います。その前提としては、「開発者の能力が「とても」高い」
という前提が隠れていると思います。
なぜなら、変更したら、どのようになるか、というのが分かるのは「とても」高い能力
だと思うからです。
#他の会社は違うのでしょうか。。。
通常、変更したら、信頼性が低くなるのですよ。変更分がどのような影響を及ぼすか
理解できない分だけ。XPは、ある程度仕組みでリスクを抑えようとするだけで、
変更のリスクをなくすわけではありません。
>また「動いているんだから触らないでおこう」という日和見主義では潜在的な欠
>陥は永久に解消されませんが、XPではリファクタリングとテストを適切に実施す
>ることで欠陥が解消される可能性があり、また現状より劇的に悪化することはあ
>りません。
「劇的に」はありませんが、ひとつもバグがあって欲しくない状態の場合は
なかなか堪えるものがあります。
例えば、5日後に納期の場合に、設計の問題が見つかったからと言って
リファクタリングしますか?
微妙だと思います。5日って。1〜2タスクだし。
#前日なら絶対にやらない。
5日が微妙じゃないというなら、2週間前だって、結局は同じことです。
そーゆー場合、ウォーターフォール的にFIXしたほうがいい場合はあると思います。
#要は適材適所だと思います。
>信頼性を高めようとすればコストが発生するというのは、どんな開発手法にも関
>わらず至極当然の話ですね。従来の手法では、そのコストを抑えるために「可能
>な限りソフトウェアを変更しない」という方針を採って信頼性を犠牲にしている
>わけです。
でも、納期の重要性はXPでも否定してないわけで。
近年は、そのバランスをどのように取るかが重要だと思ってます。
#やってると特に。
>XPは「変更はどうせ発生する」という前提において「変化ヲ抱擁セヨ」と主張し
>ているのですから、変更のコストを惜しむとXPの利点は活かせないでしょうね。
でも、ビジネスもあることですし、変更のコストも惜しみますよ。
リーダとしては。
でも、利点はある程度欲しい、ということで悩みどころではあります。
谷野健一(tanino@....jp)