Index: [Article Count Order] [Thread]

Date:  Wed, 12 Apr 2000 20:50:42 +0900
From:  "MIYAJIMA Masatoshi" <QYI06327@....jp>
Subject:  [XP-jp:00191] RE: XPractices Don't Go Dark
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <002501bfa474$8d861700$483583d2@default>
Posted:  Wed, 12 Apr 2000 20:44:28 +0900
X-Mail-Count: 00191

宮島です。


佃さんコメントありがとうございます。

# 反応が鈍くてすいません。

>佃です。
>
>MIYAJIMA Masatoshi wrote:
>>
>> はじめまして。宮島と申します。
>> "Don't Go Dark" の訳案が出来ました。よろしくお願いします。
>>
>> Don't Go Dark
>> =============
>> # いきなりタイトルでつまづきました。
>> #"遅くまで(暗くなるまで)働くな"で良いのでしょうか?
>>
>
>「暗闇に行くな」という感じではないでしょうか?
>
>ある人にある部分をずっと任せておくと、どんどんわけなからない
>方向(Dark)に進んでいく可能性がある。
>イテレーション期間で終了しなければ、そのまま打ち切り、別の担
>当者の目で再検討する。そうすれば、変な方向に行こうとしていた
>ものを正しい方向に軌道修正できる。

なるほど。これだと全体の主張とマッチしますね。
このまま拝借させていただきます。
この訂正および付け忘れていたコピーライト表記を
付加したものを再度メールします。

引き続きご意見宜しくお願いします。


暗闇に行くな (Don't Go Dark)
==========================

プロジェクトの期間内には何度か、あるチームがあるタスクにとりかかり、
イテレーションの期間内にそのタスクを完了できないことがある。
チームのメンバはそのタスクを完了させることを望み、次の
イテレーションもその作業を続けたいと思う。
これはたいていは失敗に終わる。

もしタスクの見込みが大変悪く、一回のイテレーションで
完了させることが出来ないのであれば、そのタスクについて
理解できていない個所がある可能性が強い。
管理者は多くの場合においてイテレーションが終わる前に
このことに気づくべきである。

問題はそのタスクの内部ではなく外部にある可能性が高い。
そのチームは問題を解決しようとするだろうが、どこかほかの
ところにある不具合が原因で、それはあまりにも困難だ。もっと
大勢であつまってその問題についてCRCカード(セッション)を
行うことを検討しなさい。

(そして)次のイテレーションでは少なくとも一人はチームの
メンバを交代させなさい。

問題はそのタスクの内部ではなく外部にある可能性が高い。
そのチームは問題を解決しようとするだろうが、どこかほかの
ところにある不具合が原因で、それはあまりにも困難だ。もっと
大勢であつまってその問題について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