ソフトウェア開発: いつ起きてもおかしくない交通渋滞

作者 Amr Elssamadisy , 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年8月15日

セクション

プロセス/プラクティス

トピック

アジャイル技術 ,

変化 ,

Agile

タグ

Risk ,

Scrum

Ken DeLong氏(リンク)が、なぜソフトウェア開発が特に難しいと思うのかについて述べた。

ソフトウェアを書くことは難しいとみんな知っています。でも、私はなぜソフトウェア開発が難しいのかについて話したいと思います。

ソフトウェア開発は、様々な性質によって苦しいものになります。それらは、ソフトウェア開発を複雑な適応ステムの域に押し込むのです。そして、しばしば混乱状態 (またはそれに近いもの) になります。これらの性質は、以下の通りです。

• 非線形性
• フィードバック
• 時間の遅れ
• 変化

これは新しい意見ではない。しかしながら、この分野にいると、この事実を忘れた人たちに出会うことが多い。おそらく私たちの何人かはこれを聞いたことがあるが、何を意味するのか完全には理解していなかったのだ。そこでKen氏のプログのエントリが特に参考になる。

ラッシュアワーの間、道路は混んでいて、みんなかなり急いで運転しているかもしれません。でも、そのとき、誰かがよそみをして、ほんの数秒、時速30マイルに速度を落とします。その結果は?ひどい渋滞です。大交通渋滞にはまって、突然時速70マイルに加速しますか?それでどうなりますか?そこには事故や他に明らかな原因もないのに、なぜ大渋滞が起きたのでしょう?これに先立って、変化がいくつかありました。誰かがよそみをしました。線形性が崩れ、渋滞になりました。これらの複雑なシステムの多くは自動的に継続する傾向があり、交通渋滞はこれらのうちの一つであると思われます。結局、それは解消されていくけれども、誰かが直感で予想するよりもずっとずっとゆっくりなのです。

ひとりの男が速度を落としたために起きたことで、まったく事故がないにもかかわらず、この一切の混乱が起きた!
それでは何がポイントか?ソフトウェアは難しく危険なものであり、ちょっとしたことで混乱してしまう。他には?

交通量が限られている高速道路で巨大な交通渋滞を避ける方法の一つは、測定ライトを使うことです。それは、通常の変化の量が無制限に増えることのないレベルでシステムの量を一定に保ちます。これは、私たちがプロダクションサーバのCPU利用率を30%かそれ以下に保つのと同様の方法です。これによって、サーバに負荷をかけずにトラフィックのスパイクを処理できます。

その結果、ダウンすることなく変化を処理できるようにシステムになんらかのフィードバックがあるはずである。

アジャイルでは、一つのスプリントで受け入れられるストーリーのポイントの数は、調整されます。だから、そのスプリントのすべては、スプリント中にDoneの状態になれるのです。測定ライト。

アジャイルソフトウェア開発で、この調整を考える別の方法、測定ライトについて、10 Principles of Agile Project Time Management(リンク)の中でJurgen Appelo氏が述べている。

1.  「Done」の定義を使う

2. 作業を管理するタイムボックスを使う

3. タスクの見積もりに余裕を持たせない

4. 決定を遅らせる

5. サイクル時間を減らす

6. パイプラインを短く細くする

7. 原則を守る

 8. タスクの交換を制限する

9. 常時残業するのを避ける

10. 緊急なことを重要なことから分離する

Jurgen氏はこれらの10原則の各々詳細を述べ、さらに詳細な読み物として参照先を挙げている。ソフトウェア開発は難しい。主な理由の一つは、それが複雑な適応システムであることだ。アジャイルは、正しく適用されるとき、安定したフィードバックをうまい具合に提供するようである。

原文はこちらです：http://www.infoq.com/news/2008/08/sd-traffic-jam

• 次へ >