Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
パリダカのコースが平坦な真っ直ぐの道ばかりでないのと同じように、プロジェクトの進む道も平坦な真っ直ぐの道ばかりではありません。
時には機能の大幅が変更であったり、今までなかった機能を追加しなければいけなかったり、すでに作った機能が突然いらなくなったり．．．といった、カーブや水溜り、くぼんだ道がたくさんあります。
そんな悪路を運転するのに、ずっとハンドルを真っ直ぐに持って、車の向きを正しい方向に向けているだけでは、ダメですよね？アッという間に車はボコボコになって、ゴールに着く前にはもう走れなくなってしまうかも知れません。
こうなってしまったら、１週間徹夜しようが、ものすごいマネージャやプログラマを連れてこようが、もう前には進みません。だってプロジェクトは、とっくに壊れているんですから．．．
悪路を走るには、それなりの走り方があります。
少し走ったらこっち、また少し走ったらあっち、という感じで、少し走っては少しだけハンドルを切る、このような方向修正を繰り返すことが悪路を走るときのコツです。
一気にゴールを目指すことはできませんが、クラッシュする危険性は回避できます。
現実のプロジェクトでこれを適用するには、こんな方法があります。
- リリースまでの期間を短めに何度も取る
- 開発側は、１〜２週間に１回ぐらいの区切りでソフトウェアが動く状態になっているように開発を進めます
- ビジネス側は、２〜４週間に１回ぐらいのペースで実際にソフトウェアが動くことをデモしてもらうようにします
- これをXPでは「短期リリース」と呼んでいます
- 頻繁に結合テストを行う
- 開発側は、リリースの直前で慌てて結合テストを行うのではなく、１日１〜２回以上のペースで結合テストを毎日行うようにします
- このペースでの結合テストを手作業で行うのは厳しいので、結合テストを自動化するように工夫します
- これをXPでは「継続的インテグレーション」と呼んでいます
- 常にシンプルな設計とプログラムを心がける
- 常にシンプルな設計をすることで、変更時の余計な負担を最小限に抑えることができます
- 常にシンプルなプログラムを心がけることで、変更時の余計な負担を最小限に抑えることができます
- これをXPでは「シンプル設計」と呼んでいます。
- 素早く変更を反映する
- 変更はコストがかかるので、できるだけコストのかからない手法を使う必要があります
- プログラムをオブジェクト中心で作っていくことで、この変更のコストを最小限にすることができます
- テストを自動化することで、システムの変更を素早く何回でも負担なく確認でき、安全に変更できます
１歩１歩着実にかつ方向転換（＝変更）があるときは素早く。
ガタガタ道のプロジェクトをできるだけ安全に進むためには、この方法が一番です。
