Personal tools
You are here: Home ブログ 井上 ソフトウェア開発プロセスのgiant lock
« December 2010 »
Su Mo Tu We Th Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Recent entries
Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23
Herokuの発音 inoue 2010-12-20
雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18
IPA未踏のニュース inoue 2010-12-15
労基法とチキンゲーム inoue 2010-12-06
フロントエンドエンジニア inoue 2010-12-03
ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25
技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24
雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22
RESTの当惑 inoue 2010-11-22
「プログラマのためのUXチートシート」を作りました inoue 2010-11-19
「ビューティフルコード」を読みました inoue 2010-11-16
Categories
カテゴリなし
 
Document Actions

ソフトウェア開発プロセスのgiant lock

少し前ですが、以下を読みました。

Linux(*)のBTSは次のbugzillaです。

今、オープンバグを探すと、たった1546件しかありません。ソフトウェア開発を知らない人は1546件を多いと思うかもしれません。実際には、驚異的に少ない数だと思います。

(*)言うまでも無いですが、GNUをつけないLinuxはカーネルのことです。

論文は、リリースの周期を決めて、そのリリース周期を守れ、と主張します。無計画にリリースがだらだらと延びることを批判しています。長すぎるリリース間隔には悪い点が多いので、短い方が望ましいようです。ただし、リリース間隔を過度に短くすることは主張していません。実際、「7.1.4. Cost Factors Related to Releasing」で、リリースに関わるコストを考察しています。OpenOfficeでは2ヵ月ごとのリリースをやめて、3ヵ月ごとにリリースに延ばしたようです。

リリース間隔を短くするには、ソフトウェアを常にある程度安定した状態に保つ必要があります。「8.2.1 Stability of the Development Tree」に次の4つのプロセスが挙がっています。

  • Branches
  • Peer review
  • Testing
  • Reverting and postponing

注目したいのがBranchesとReverting and postponingです(Peer reviewとTestingは自明なので省略します)。

branchingは、安定化に時間のかかる開発作業はメイン開発ツリーと別のところで作業を行い、安定してからメインツリーに入れるプロセスです。Reverting and postponingのrevertingは、メインツリーに一度入った機能でも、リリース品質に達しない機能はメインツリーから外すプロセスです。postponingはリリース品質に達しない機能は、(例えリリース予定機能であったとしても)リリースに含めないプロセスです。

branchingとrevertingは、言うほど易しくありません。ソフトウェアが適切にモジュール化できていなければ達成できません。このふたつが可能になれば、大規模ソフトウェア開発としてスケールできます。

個人的な開発体制の理想は、ゴールだけ共有して、後は各人が自分のペースでゴールに向けて走りだすことです。ペース配分はひとりで勝手に決めてもいいですし、数人でまとまっても良いです。リリース間隔の整数倍の周期で作業する人がいても良いと思っています。つまり、リリース周期が1ヵ月の場合、2ヵ月や3ヵ月の周期で作業する人がいても構いません。

現実は理想どおりに行きません。なぜかリリース前になると、全員を動員しなければいけない作業が残って、全員の足並みを揃える羽目になります。締切を決めて作業見積りをさせると、なぜか全員にタスクが割り振られる、という結果になります。人数が変化しても、全員必要、という結果に変化はありません。感覚的には、目に見えないgiant lockがあって、全員の作業が同期してしまうイメージです。スケールするために、この目に見えないgiant lockを取り除きたいのです。

以前からこの現象に気づいて、どうにかしたいと思っていました。先行して作業を進めておけば防げるだろうと考えましたが、考えが甘かったことに気づきました。結局、心理的な問題です。どれだけ前倒ししても、使えるリソース(人と時間)は使い切ってしまうのです。

今考えている手は、強制的に別の周期で動く部隊を作ることです。はじめから使えないリソースとして周知させておけば、巻き込まれないで済みます。

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/giant-lock-of-process/tbping

Re:ソフトウェア開発プロセスのgiant lock

Posted by takatsuka at 2007-05-26 00:18
Theory of Constraints ?
Add comment

You can add a comment by filling out the form below. Plain text formatting.

(Required)
(Required)
(Required)
This helps us prevent automated spamming.
Captcha Image


Copyright(C) 2001 - 2006 Ariel Networks, Inc. All rights reserved.