アジャイル開発を成功に導く26のヒント

作者 Vikas Hazrati , 翻訳者 徳武 聡 投稿日 2009年10月29日

セクション

プロセス/プラクティス

トピック

アジャイル技術 ,

Agile

タグ

Best Practices

原文(投稿日：2009/10/27)へのリンク

Keith Swenson氏は最近、アジャイル開発のための26のヒントを一覧にまとめた。氏は様々なトピックに関する知見を定期的に収集しているようで、この一覧はアジャイル開発について本当に考慮すべき点を抽出したものになっている。

氏の記事に対して、これらのヒントはアジャイルに対してだけ有効なのでははく、より良いソフトウエアの開発と設計に対しても適用できるのではないか、というコメントがあった。氏はこのコメントに対して、熟練のアジャイル実践者にとってはこれらのヒントは当たり前に聞こえるだろうが、こういったアジャイルの知見について全くしらない人もたくさんいる、と答え、次のように付け加えた。

私は日本でいくつかの開発チームと協業しています。チームではとても堅いウォータフォールモデルを採用しています。このチームにとってこれらのヒントの半数は“驚くべき” もので、過激なアドバイスとすら考えているかもしれません。“コードを書く前にテストを書け” や “必要になるまで実装するな” といったことは彼らにとっては、先鋭的な考え方のように思えるのです。チームのメンバは実装の“完全性”に誇りを持っています。しかし、そうした完全性に対する追求が行き過ぎると、顧客不在のユースケースを生み出してしまいます。結果、過剰な実装、つまりある種の無駄が発生するのです。また、テストを書き始めるまで半年かかることもあります。堅いウォータフォールデモルでも実装では、テストは“松葉杖”のようなものであり、正確な仕事をする開発者は必要とするべきではないものなのです。驚きでしょう?

氏がまとめた'それほど一般的ではない'ヒントには下記のようなものがある。

• 1つの作業を完全に終えてから次の作業を開始しなさい。ソフトウエア開発の最大の問題のひとつは平行して複数の作業を始めてしまうことです。複数の作業を平行して行うと捨てなければならない作業が必ず生まれます。結果、無駄が生まれてしまいます。キッチンでの仕事に例えるなら、“目の前にある食事を給仕してから次の料理に取りかかれ“ということです。
• 決定することを恐れるな。そして、以前の決定を変更することを恐れるな。意思決定は可能な限り遅らせて、必要になったらしなさい。新しい情報が現れたら、以前の決定を変更することをためらってはなりません。
• 測定、測定、そして測定。アジャイル開発は、未来に関するはっきりしない状態を取り扱うのに役に立ちます。しかし、過去の出来事には曖昧さを残しておくべきではありません。
• システム中心ではなく人間中心の設計をするべし。開発者が、技術的な面白さに引かれて本来行うべき設計から脱線することは本当によくあることです。しかし、ソフトウエア開発の成功は根本的には、そのソフトウエアを作ることによって人々が効果的に恊働してビジネス価値を生み出すようになるかどうかにかかっています。
• 早すぎる最適化は諸悪の根源。コードを静的に理解しただけでシステム全体の性能について考察しても、その着眼点はほとんど常に間違っています。従って、完成したシステムの振る舞いを計測して性能を検証するべきです。
• 機能を一般化しすぎるな。この考えは、“YAGNI –今必要なことだけをやれ。”としても知られています。
• コードの行数を計測するな。あるテスクを実現するのに必要なコードの行数はプログラマによって大きく異なります。またコーディングのスタイルによっても違いが生まれるでしょう。代わりに、機能毎のユースケースを計測するべきです。
• ソフトウエアはプラスチックだ。物体をそのまま扱う製造業とは違って、ソフトウエアは大幅に変更することも簡単にできます。
• 新しい言語を発明するな。XMLが生まれた結果、専門分野に特化した“スクリプト言語”が作られ続ける傾向にあります。このような言語はソフトウエア開発をより一般的にしてくれると考えられていますが、この考えには欠点があります。というのは、特定の実装の文脈以外で、ある操作の振る舞いを正確に定義することはほとんど不可能だからです。

あなたもすべてヒントを読んで、大事なのが抜けていると思ったらコメントを残してみよう。

• 次へ >