あまぴょんと申します。
Hirohide Yazaki wrote:
>> もう、一年以上もあっていないような感じです。
>> お元気でしたか？
>
> そういえば、もうそれくらいになるかもしれませんね。
> JXXXPも、今年は去年ほどは集まりがありませんし。。
めんそーれがあるから控えているんですかね？
>> でも、この２つ、難しい関係ですよね。
>> 「早くつくる」ことは、「変化ヲ抱擁スル」ことではないし、
>> 「変化ヲ抱擁スル」ことのために、「早くつくる」ができない
>> ケースの方が多いようだし。
>
>
> いえ、もしかしたらそうとも言えなくて、「早くつくること」が
> 「変化ヲ抱擁スル」ための有効な手段かもしれませんよね。
> 仮説を立てそれを検証（実装と稼動）する、検証がうまくいかなかった
> ら、仮説を立て直し、またそれを検証（実装と稼動）する。
> この１サイクル（仮説、検証、フィードバック）は短ければ短いほど、
> 実行可能で、１サイクルするのに何ヶ月もあるいは何年もかかる
> ようだと、モチベーションや予算の点で、とても何度も回すことは
> できない、という場合もあるような気がします。
「早くつくること」に一票です。
フィードバックを早くするために何をするかということではと思います。
変な例えですが、おんぼろの湯沸し器を考えます。
希望の温度に設定しようとすると、なかなかお湯になりません。
もう少しつまみを高温に設定します。
まだ、お湯になりません。
さらに大きくつまみを高温に設定します。
今度は、急にやけどしそうなくらい熱くなり、低温につまみを回します。
すると今度は冷たくなりすぎてつまみを高温に・・・
最新鋭の？湯沸し器ならば、つまみを回せば瞬時にほぼその設定温度に
なると思います。
おんぼろ湯沸し器と、最新鋭の湯沸しの違いはフィードバックの速さなの
では思います。
話を元に戻します。
サイクルの中にある「遅れ」が原因でよからぬことが起きるので、それを
取り除こうとする活動がXPの中心のような気がします。
オンサイトカスタマー
カスタマーとコミュニケーションが密ならば、開発側の「ここはこう思って
いるはずだ」という勝手な憶測で行動し、無駄な作業をしてしまうというこ
とを無くすことができるでしょう。
ペアプログラミング
自分のソースコードに自信がないや。次のコードレビューでいろいろ指摘さ
れそうだから、今の分はあまり進めるのはやめておこう・・・
なんて事を避けられそうです。
コードの共同所有
他人のコードを修正したいけど、作成者に頼むと時間がかかるな・・・
あっちのバグを自分のところで吸収してやるか・・・
なんて事を避けられそうです。
YAGNI
目先のことが見えているので、それに忠実に従っていけば余計なことは
しなくて済むでしょう。
# 苦しい解釈だ・・・