宮島です。
矢崎さんが作成された XPractice 翻訳プロジェクトの
ページ([XP-jp:00347])を遅ればせながら見てきました。
ご苦労様です。
私の担当部分、なんか一部のパラグラフがダブってる....
と思ったら拙訳からしてすでにおかしかったのですね。
他の個所には手を加えていないので、ちょっと迷ったの
ですが、もう一度全文を流させてください。
暗闇に行くな (Don't Go Dark)
============================
プロジェクトの期間内には何度か、あるチームがあるタスクに
とりかかり、イテレーションの期間内にそのタスクを
完了できないことがある。チームのメンバはそのタスクを
完了させることを望み、次のイテレーションもその作業を
続けたいと思う。これはたいていは失敗に終わる。
もしタスクの見込みが大変悪く、一回のイテレーションで
完了させることが出来ないのであれば、そのタスクについて
理解できていない個所がある可能性が強い。
管理者は多くの場合においてイテレーションが終わる前に
このことに気づくべきである。
問題はそのタスクの内部ではなく外部にある可能性が高い。
そのチームは問題を解決しようとするだろうが、どこかほかの
ところにある不具合が原因で、それはあまりにも困難だ。もっと
大勢であつまってその問題についてCRCカード(セッション)を
行うことを検討しなさい。
(そして)次のイテレーションでは少なくとも一人はチームの
メンバを交代させなさい。
反論
今のチームその問題についてより多くの経験をしている。
それにかれらはもうすぐ解決するかもしれない。かれらに
引き続き取り組ませたほうが良い。
・このプロジェクトおよその他多くのプロジェクトにおける
経験はまったく反対のことを示している:
タスクがうまく進んでいないのであれば、おそらくそれは
誤った方向に進んでいるためであり、やり直しが必要である。
たとえ最終的に動くコードが得られたとしても、
問題は残ったままだ。
・解決策がシステムにうまく適合しない場合は、システムが
間違っているのか、解決策が間違っているのかの
いずれかである。Smalltalkではプロジェクトの後の段階に
なってさえ重大(substantial)なリファクタリングが
可能である。
悪い個所を見つけて修正しなさい。
反論
誰かほかの人にあなたの仕事を引き継がせることで
失敗の存在を明らかにすることは士気を低下させる。
・誰も誰かが失敗したとは宣言しない。
二組の目(two set of eyes)が開発スピードを
高めるのとまったく同じように、新しい目は
泥沼化しているタスクを正常な状態に戻すのに
役立つだろう。
#二組の目(two set of eyes)とは pair programming の
#ことでしょう。
加えて、頻繁にタスクを交代させることはチームの
マンネリ化を防ぐひとつの手段である。
code ownership を実践していなくても、開発者は自分の
作った特定のオブジェクトに対して特に熱中しがちである。
これは多くの場合問題を起こす。
==================================================
オリジナル http://www.xprogramming.com/
Copyright (c) 1999, REJeffries et al. (ronjeffries@....org)
==================================================
宮島雅敏 MIYAJIMA Masatoshi
m_square@....jp
宮島雅敏 MIYAJIMA Masatoshi
m_square@....jp