無料ブログはココログ

« [#Agile] アジャイル開発はフロントローディング | トップページ | [#Agile] アジャイル開発はコミュニケーションで価値を実現するオブジェクト指向システム »

[#Agile] アジャイル開発は混乱を避ける

アジャイル開発の特徴の一つは混乱を避ける仕組みがある事です。従来の開発方法では、以下のような混乱要因がありました。

1) 変化(仕様変更、実装方法、環境)の無秩序な受け入れ
2) 品質の問題による手戻り作業の増大
3) 作業者間のコミュニケーション不足

コミュニケーションは内容が多いので、この記事では1と2に対するアジャイルの優位性について書きます。

1. 変化の受け入れとリズム

変化の受け入れ

アジャイル開発の特徴は早めに小さく失敗する事です。イテレーションと呼ばれる開発期間に区切って繰り返し開発を行う事で、変化による影響を小さくする事ができます。例えば実装が完了してから仕様変更や問題が発覚して、もしその手戻りが全体に影響する場合、n回のイテレーションに分けて開発していたなら、最初のイテレーションで発見できれば被害を1/nにする事ができます。このようにアジャイル開発は作ってから分かる変化に強い方法です。

変化には仕様変更、実装方法、環境の3つがあります。仕様変更は使ってみてわかることや社会状況の変化による予見できないものです。実装方法は使い勝手や処理速度など必要とされる内容は明確でも詳細は作ってみないと分からないものです。環境はだいたい分かっていても実装しないと確定しない不安定なものです。これらはハンフリー氏の「ソフトウェアウェアプロセス成熟度の改善」の要求の不安定さび書かれている未知の要求、誤解された要求、不安定な要求に相当します。

「ソフトウェアウェアプロセス成熟度の改善」には、これらの解決策としてプロトタイプの作成と不安定な部分の分離が提唱されています。しかし、プロトタイプには3つの危険性があります。具体的には、(1)完全な実装でないので結果が異なる、(2)作り直しや改造の負担がかかる、(3)テストコードや異常処理の考慮が不十分であってもできていると勘違いしてしまう、という点です。手戻りもあり得ますが、アジャイル開発の様に正式な実装を行う事が有効な場合も多いでしょう。

リズム

変化の受け入れはプロジェクト計画の手戻りも発生させます。従来の開発の様にプロジェクト開始時に詳細な計画を立てていたなら、計画の変更による手戻りは大きいでしょう。また、被害が大きく作業量が増えたなら、人の手配も必要になるかもしれません。それに伴い、開発環境の準備やプロジェクトのレクチャーも必要になるかもしれません。

アジャイル開発ではプロジェクトの変化を、新しいイテレーションの計画時に吸収します。イテレーション中に変更を受け入れるかどうかは開発法により異なりますが、複数のイテレーションを繰り返す事によって、プロジェクトの混乱を避ける事ができます。

このことは木造住宅の壁の溝に例える事ができます。最近はコスト削減のために乾式工法が進んでいますが、昔は左官によって壁が塗られていました。マンションの様に平らな大きな壁は少なく、一定の間隔ごとに溝が作られていました。この溝は木材の伸縮によって生じる壁のヒビを集めるための物です。木造住宅ではヒビの入る事が予想されますが壁の中央にヒビが入ると見た目が悪いので、壁全体を救う目的で予め溝が作られたのです。

開発者は計画に従って作業をしますが、途中で計画に変更が入ると作業に集中できません。変更が予め予想されるので、変化を受け入れる場所を予め作っておきます。さらに、計画変更が入っても手戻りが小さくて済む様に、スコープの決定と詳細な計画は必要なときに行うのです。

2. 品質の維持

品質問題による手戻りの増大は、繰り返し開発によって早めに小さく失敗することで軽減されます。しかし、アジャイル開発はそれだけではありません。バグが発生した際に効率的に除去できる仕組みがあるのです。それは品質の維持です。

トヨタ式開発法の基本は清掃だと言われています。製品を組み立てる際にネジを落としても、きれいな床ならすぐに見つける事ができますが、不要なネジが散らかっている床で見つける事は困難でしょう。「見える化」とは問題が容易に見える様にすることで、常に清掃されていなければ実現できないのです。

アジャイル開発ではペアプロや自動テストによって、一定の品質の完成品が徐々に積み上げられます。もし、それまで動作していたソフトウェアがある日突然動作しなくなったなら、多くの場合は直前の修正が原因で容易に発見できるでしょう。もし、一度に多くの修正が行われていた場合でも、問題なく動作した時点のバージョンに戻した上で少しずつ確認すれば、問題点が容易に分かるでしょう。

このようにアジャイル開発には、常に品質を維持する仕組みによってイテレーション内でも手戻りが減る仕組みがあるのです。また、上記のほか、CIツールで静的解析を実施したり、チケットシステムを導入して変更履歴を関連情報と紐付けて、さらに効率化を図る事もできます。

残るコミュニケーションは、信頼性や仕様変更とともに1980年代からソフトウェア開発の課題とされてきた大きな問題です。時間を見つけて書く予定です。

« [#Agile] アジャイル開発はフロントローディング | トップページ | [#Agile] アジャイル開発はコミュニケーションで価値を実現するオブジェクト指向システム »

私のアジャイル」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« [#Agile] アジャイル開発はフロントローディング | トップページ | [#Agile] アジャイル開発はコミュニケーションで価値を実現するオブジェクト指向システム »