あまぴょんと申します。
Masayuki Takahashi wrote:
> ペアを組むことにより、確かに品質は向上すると思うのです
> が、ひとつの問題を解決する為に要する時間が増加してしま
> うような気がします。
> 例えば、実際の開発中に「文字化け」が発生したとします。
> ペアを組んでいる片方の人間にしてみれば、その原因は明ら
> かでも、もう片方の人間が「SJIS」や「Unicode」について
> の知識を持ち合わせていなければ、その原因をいくら説明し
> ても理解してもらえないでしょう。かといって、「SJIS」や
> 「Unicode」について語り始めてしまうと、話が拡散してし
> まい、結果として多くの時間が費やされてしまったにもかか
> わらず、結局「文字コード関連の書籍を読んでね」なんてこ
> とになってしまいがちです。
よく、ありそうな話ですね。
私の場合は、Windows環境で構築したServletをLinuxに持っていった
時に、文字化けが発生しました。SJIS(MS932?)とEUC-JPの違い。
二人で書籍やWebを調べて30分程度で問題が分かりました。
高橋さんの場合は、一人が知識があり、もう一人は知識がないという
場合ですが、私の場合は両方とも知識がなかったので、そういう場合は
一人よりも二人でよかったと感じました。
#特にペアプロをしていたわけではありませんが、たまたま一緒に
#作業をしただけです。
> 前述の例は「プロジェクトの開発物の仕様」に直接関係ない
> ので反則かもしれませんが、現実問題としてこのような技術
> 的な問題に直面することも多いでしょう。かといって、教育
> の為の時間をスケジュールに組み込む訳にもいきませんし、
よい？プロジェクト管理が行われていれば、プロジェクト開始時に
リスクや、メンバーに必要となるスキルがリストアップされて、
不足しているスキルについては教育されるのが普通(理想？)の
ようです。
> 「なんで?」と聞かれればその技術的な問題の原因を説明せ
> ざるを得ないでしょうし、時間が過ぎていけばスケジュール
> が気になってくるし、と考えてしまうのですが・・・。この辺り
> はペアの組み方で解決するしかないのでしょうか?
ところで、XPでの要因確保、人員アサインて、どうなってるんですかね？
XPとは関係ない次元の話になるんですかね。
よりよく管理されたプロジェクト内でこそ、XPが力を発揮するような
気がします。