Author: mumumu
Date: Fri Apr 11 14:28:34 2008
New Revision: 1451
Log:
- Translated "Planning Releases" section.
Modified:
trunk/ja/ch07.xml
Modified: trunk/ja/ch07.xml
==============================================================================
--- trunk/ja/ch07.xml (original)
+++ trunk/ja/ch07.xml Fri Apr 11 14:28:34 2008
@@ -3233,15 +3233,18 @@
それぞれのコミットを論理的な変更単位に分割するのが望ましいのは、
もちろんリリースブランチを安定させるためだけではありません。
心理的にも、意味がまとまっているコミットはレビューしやすく、
- 必要な時に元に戻しやすいということもあります。
- (バージョン管理システムによっては、変更を元に戻すことで、特殊なマージを行うものもあります)
+ 必要な時に元に戻しやすい (バージョン管理システムによっては、変更を元に戻すことで、特殊なマージを行うものもあります) ということもあります。
前もって皆が規律をちょっと守っておけば、プロジェクトが後に頭痛の種を多く抱えずに済むのです。
</para>
<!-- ======================== subsection ============================== -->
<sect2 id="planning">
+<!--
<title>Planning Releases</title>
+-->
+<title>リリースの計画を立てる</title>
+<!--
<para>One area where open source projects have historically differed
from proprietary projects is in release planning. Proprietary
projects usually have firmer deadlines. Sometimes it's because
@@ -3254,7 +3257,25 @@
most literal sense: they were written for the love of it. No one felt
the need to ship before all the features were ready, and why should
they? It wasn't as if anyone's job was on the line.</para>
+-->
+<para>
+ オープンソースプロジェクトが、歴史的にプロプラエタリなプロジェクトと異なる点は、
+ リリースの計画に関するものです。
+ プロプラエタリなプロジェクトでは、確固とした〆切があるのが普通です。
+ その理由は、顧客にある時点でアップグレードを提供すると約束している場合もあれば、
+ 新しいリリースをマーケティング上の理由から他の仕事と連携させる必要があったりとか、
+ プロジェクトにお金を出しているベンチャーキャピタルの人が、
+ さらに投資をする前に成果を見る必要がある場合もあります。
+ 一方、フリーソフトウェアプロジェクトでは、
+ ほとんど文字通りの意味での「道楽」が最近までほとんどの動機付けとなってきました。:
+ つまり、好きだからコードを書いてきたのです。
+ 全ての機能が揃う前にリリースする必要性を感じる人はいませんし、
+ そもそもなぜそうすべきなのでしょう？
+ フリーソフトウェアプロジェクトでは、皆の仕事がひとつの生産ラインに乗っているわけではないのです。
+</para>
+
+<!--
<para>Nowadays, many open source projects are funded by corporations,
and are correspondingly more and more influenced by deadline-conscious
corporate culture. This is in many ways a good thing, but it can
@@ -3267,7 +3288,22 @@
agendas—perhaps features they want to complete, or some testing
they want to have done—that they feel the release should wait
on.</para>
+-->
+<para>
+ 最近では、多くのオープンソースプロジェクトが企業からお金を出してもらうようになり、
+ それに伴って企業の〆切文化の影響をより多く受けるようになってきています。
+ これは多くの点では良いことなのですが、
+ お金を貰って雇われている開発者とボランティアの開発者の間で、
+ 優先順位の衝突が起きる可能性があります。
+ こうした衝突はリリーススケジュールをいつ、どのようにするかという問題でよく発生します。
+ プレッシャーが強い雇われ開発者は、当然リリースする日程を決めたがりますが、
+ ボランティアの開発者は他の問題意識の方が強いかもしれません —
+ それは自分たちが求める機能や、仕上げておきたいテストであったりします —
+ よって、ボランティアの開発者達はリリースを待つべきだと感じることになります。
+</para>
+
+<!--
<para>There is no general solution to this problem except discussion
and compromise, of course. But you can minimize the frequency and
degree of friction caused, by decoupling the proposed
@@ -3282,10 +3318,11 @@
Exploring the Impact of Release Management</citetitle>
(<ulink url="http://www.cyrius.com/publications/michlmayr-phd.html"/>).
It is about using time-based release processes, as opposed to
-feature-based, in large free software projects. Michlmayr also gave a
+feature-based, in large free software projects. Michlmayr also gave a
talk at Google on the subject, available on Google Video at
<ulink url="http://video.google.com/videoplay?docid=-5503858974016723264";
-/>.</para></footnote>. By nailing down feature sets early, you reduce
+/>.</para></footnote>.
+ By nailing down feature sets early, you reduce
the complexity of the discussion centered on any individual release,
and therefore improve predictability. This also creates a kind of
inertial bias against anyone who proposes to expand the definition of
@@ -3293,7 +3330,32 @@
release's contents are fairly well defined, the onus is on the
proposer to justify the expansion, even though the date of the release
may not have been set yet.</para>
+-->
+<para>
+ もちろんこの問題については、議論し、妥協する以外に一般的な解決策はありません。
+ しかし、提案されているリリースの <emphasis>存在</emphasis> から、
+ 日付を切り離すことで、衝突の頻度や度合いを最小限にすることができます。
+ つまり、はじめはざっくりとした見積り<footnote><para>別のアプローチとして、
+ Martin Michlmayr の Ph.D論文 <citetitle>Quality Improvement in Volunteer Free
and Open Source Software Projects: Exploring the Impact of Release
Management</citetitle> (<ulink
url="http://www.cyrius.com/publications/michlmayr-phd.html"/>) を読むとよいかもしれません。
+ これは巨大なソフトウェアプロジェクトにおいて、
+ 機能ベースのリリースプロセスとは正反対の、
+ 時間軸をベースとしたリリースプロセスを採用することに関する論文です。
+ Michlmayr は、Google でこれを題材にした講演も行っています。Google Video で視聴可能です。<ulink
url="http://video.google.com/videoplay?docid=-5503858974016723264"/>
+ </para></footnote> 以外は日付について触れず、
+ 直近から中期的な段階で、プロジェクトはどういった形のリリースができるか、
+ そしてそのリリースにどんな機能を含めるのか、という方向に議論を誘導してみるのです。
+ 機能について早期に確定しておくことで、
+ 個々のリリースに関する議論が複雑になる度合いを減らすことができ、
+ 予測可能性を高めることができます。
+ また、新機能や他の複雑なことをリリースに追加することで、
+ リリースの定義を拡大解釈する提案に反対させるある種の先入観を植え付けることができます。
+ たとえリリースの日取りが決まっていなくても、
+ その内容がうまく決まっていれば、
+ リリースの内容を拡大するのを正当化するのはそれを提案する人の責任になります。
+</para>
+
+<!--
<para>In his multi-volume biography of Thomas Jefferson,
<citetitle>Jefferson and His Time</citetitle>, Dumas Malone tells the
story of how Jefferson handled the first meeting held to decide the
@@ -3305,7 +3367,7 @@
made sure to show up with meticulously prepared architectural
drawings, detailed budgets for construction and operation, a proposed
curriculum, and the names of specific faculty he wanted to import from
-Europe. No one else in the room was even remotely as prepared; the
+Europe. No one else in the room was even remotely as prepared; the
group essentially had to capitulate to Jefferson's vision, and the
University was eventually founded more or less in accordance with his
plans. The facts that construction went far over budget, and that
@@ -3316,7 +3378,28 @@
simply proposing modifications to it, so that the overall shape, and
therefore schedule, of the project would be roughly as he
wanted.</para>
+-->
+
+<para>
+ トマス・ジェファーソン の伝記 <citetitle>Jefferson and His Time</citetitle> では、
+ Dumas Malone が、バージニア大学の組織を決めるための初ミーティングを彼がどのように進めたかについて語っています。
+ 大学を設立するというアイディアはもともとジェファーソンのアイディアでしたが、
+ (オープンソースプロジェクトに限らず、どこででもあることですが)
+ 他の多くの関係者が、自分たちの興味があることや議題を持って会議に乗り込んできたのです。
+ 彼らがミーティングに集まってそれらを徹底的に議論していると、
+ ジェファーソンは周到に準備した建築図面や、その予算や実作業、提案されているカリキュラム、
+ そして自分がヨーロッパから輸入したいと考えていた特別な学部の名前を示して見せたのです。
+ 会議室にいた人の中に、彼以外でそうした議題についてほんのわずかでも準備にした人はいませんでした。
+ つまり、彼らはそうした議題についてはジェファーソンのビジョンに従わざるを得ません。結局、
+ バージニア大学設立は多かれ少なかれ彼の計画通りに進んだのです。
+ 建築費が予算をオーバーしていたり、彼のアイディアの多くは様々な理由で実現しなかったりしましたが、
+ ジェファーソンはそれらすべてが起こることをあらかじめ完全に予想していたのでしょう。
+ 彼の狙いは戦略的でした。ミーティングで他の人が修正を提案せざるをえないような現実的な路線を提示するようにしたのです。
+ その結果、全体の枠組み、そしてプロジェクトのスケジュールも、だいたい彼が望むものになったのです。
+</para>
+
+<!--
<para>In the case of a free software project, there is no single
"meeting", but instead a series of small proposals made mostly by
means of the issue tracker. But if you have some credibility in the
@@ -3326,7 +3409,19 @@
with you. Once you've got things laid out more or less as you want
them, the conversations about actual release
<emphasis>dates</emphasis> will go much more smoothly.</para>
+-->
+
+<para>
+ フリーソフトウェアプロジェクトの場合、"ミーティング" はありませんが、
+ 小さな提案の積み重ねは、そのほとんどがバグ追跡システムで行われます。
+ プロジェクトであなたがちょっと信頼されていて、
+ いろいろな新機能や改善やバグ修正をターゲットとなるリリースに割り当てはじめれば、
+ アナウンスした全体のプランに従って、人々はあなたについてくるでしょう。
+ いったんそれらが多かれ少なかれあなたの思い通りに進めば、
+ 実際のリリース <emphasis>時期</emphasis> に関する議論もより進みやすくなるでしょう。
+</para>
+<!--
<para>It is crucial, of course, to never present any individual
decision as written in stone. In the comments associated with each
assignment of an issue to a specific future release, invite
@@ -3338,7 +3433,20 @@
<xref linkend="managing-volunteers"/></phrase>), the easier it
will be to persuade them to share your priorities on the issues that
really count for you.</para>
+-->
+
+<para>
+ もちろん、個々の決定をまるで文書で確定したかのように示さないのが重要です。
+ 特定のリリースで問題の解決をすると決めるときには、
+ コメントで議論に参加してもらい、反対意見を述べてもらったりし、、
+ 可能な時はいつでも、真摯に説得に応じましょう。
+ 単に権力を行使するために、力を振りかざしてはいけません。
+ リリース計画を立てる過程で他の人が議論に参加すればするほど
+ (<phrase output="printed"> の <xref
linkend="managing-volunteers"/></phrase> <xref linkend="share-management"/>
を参照してください) 、
+ 自分が本当に重視している問題の優先度を高めることに賛同するよう説得することも容易になるのです。
+</para>
+<!--
<para>The other way the project can lower tensions around release
planning is to make releases fairly often. When there's a long time
between releases, the importance of any individual release is
@@ -3349,6 +3457,18 @@
and six months is usually about the right gap between releases, though
maintenance lines may put out micro releases a bit faster, if there is
demand for them.</para>
+-->
+
+<para>
+ リリース計画を立てるときに緊張を緩める別の方法として、
+ リリースを頻繁に行うことがあります。リリースする間隔が長期間空くと、
+ それぞれのリリースの重要性がメンバーの中で増してしまいます。
+ つまり、自分たちのコードが取り込まれなかったときのショックが大きくなってしまうのです。
+ なぜなら、次に取り込まれるチャンスまでどれくらい時間がかかるかがわかってしまうからです。
+ リリースプロセスの複雑さと、プロジェクトの性質にもよりますが、
+ 3ヶ月から6ヶ月の間くらいが、普通は適切なリリース間隔です。しかし、
+ 安定版のリリースラインは、もうすこし早い間隔でマイクロリリースを出した方がよいかもしれません。
+</para>
</sect2>
_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators
