Index: [Article Count Order] [Thread]

Date:  Tue, 6 Jun 2000 11:49:19 +0900
From:  Komuro Mutsumi <mutsumi@....jp>
Subject:  [XP-jp:00497] 17 Frequent Releases
To:  extremeprogramming-jp@....jp (extremeprogramming-jp ML)
Message-Id:  <393C65B9.E32B4D7A@....jp>
Posted:  Tue, 06 Jun 2000 11:45:14 +0900
X-Mail-Count: 00497

こんにちは、日立ソフトの小室です。

17.Frequent Releases を訳してみました。
(矢崎さんには連絡ずみです。)

コメントあればお願いします。

なお、細かいことですが、
http://www.xprogramming.com/Practices/PracFrequentRelease.htmlでは
章のタイトルが"Frequent Release"になっていて、's'が落ちています。
(上記URLでも落ちてますね。)
多分、'Releases'の間違いだと思いますが、以下では修正していません。


小室

----------------------

Frequent Release

私達の開発チームではソフトウェアを最低一日一回はリリースするというのが典
型です。
そうです。最低でも一日一回です。

私達の経験によれば、開発者がコードを抱える時間が一日を越えるようなときは
トラブルが原因であるのが普通です。
何をすべきか目標がわかっているときは、ほとんどいつでも仕事を分割して、
変更を毎日リリースするようにできます。(すべてのテストが通った状態で) 

これに反して 本当に複雑で、一日ではできないという変更もあります。 

・そう、実際にそういうことがあります。私達もプロジェクトの中でそういう事
態に 
 遭遇しました。それはシステム内の値をどうインタプリトさせるかについて、 
 単純だが非常に基本的な変更を行ったときでした。
 システムを新しいモードで 動くようにするのが信じられないほど困難でし
た。
 それはいくつか修正を施すといった程度の ことではなかったのです。 

・これ以外にも開発者が何日かリリースしないことが何度かありました。 
 これらのどの場合も、統合が難しく、コードが信頼できないという結果に終わ
りました。
 ほとんどどの場合も、できたソフトウェアを捨ててもう一度やり直すことにな
りました。   


一般的な指針として開発者が変更を出し渋る時には、深刻なトラブルの兆候だと
  
とらえて、すぐに対処すべきです。例外もありえますが、あなたが考えるより少
ないのです。 


--------------------------------------------------------------------------------
オリジナル http://www.xprogramming.com/ Copyright (c) 1999, REJeffries
et al. (ronjeffries@....org)