第2回 実践アジャイルテスト勉強会

6月15日(水)、名古屋市内某所で行われた「実践アジャイルテスト」の勉強会に参加してきました。
これは「名古屋アジャイル勉強会」 の分科会で、同名の書籍を対象とした読書会という形式です。
今回は2回目ですが、前回(第1回目)と同様に、「ソフトウェアのアジャイル開発におけるテストとは何ぞや?」のような概論ともいうべき内容となっています。具体的な方法論はもう少し後の章で出てきます。
では、今回のテーマであった「第3章 文化的なチャレンジ」と「第4章 チームの運営」についてアウトプットしてみたいと思います。

第3章・第4章のマインドマップ
mindmap_20110615.png

第3章 文化的なチャレンジ/第4章 チームの運営
これらの章は、これまでは従来のウォーターフォール方式による開発しかしてこなかったチームが、いかにしてアジャイルへと変革を遂げるべきかというテーマについて、まとめてあります。主な内容については上のマインドマップのとおりですが、特に私が印象に残ったトピックスは以下のとおりです。
品質を担保することの考え方が違う
従来のウォーターフォール式の開発では、例えば【要件定義】→【設計】→【コーディング】→【テスト】→【リリース】のような工程が定義されていた場合、リリース前の【テスト】工程が品質を担保することになります。一方アジャイル開発では、1つの繰り返し(「イテレーション」という)の中で、コーディングとテストを1つの統合した活動とみなすため開発中から既に品質を担保するという考え方が成り立ちます。(まさに「品質を作りこむ」ですね)
また「人」に着目した場合、従来はいわゆる「品質保証部門」が「品質の番人」として、面倒なルールや規約をアレコレと押し付けがちなのですが、アジャイル開発では開発メンバーひとりひとりが自律的に品質に責任を持つ、という考え方が浸透しています。
顧客との考え方が違う
ソフトウェアの受託開発では、どうしても
 顧客/ユーザ=発注者
 開発側=受注者
という図式が成り立つため、自ずと力関係が生じてしまいます。
ところがアジャイル開発では、「顧客と共同作業する」「発注・受注の関係ではなくパートナーシップ」ということが重視されます。その中でも特に「テスター」と呼ばれる人達は、顧客と開発チームの関係を円滑にする役割が期待されています。(これも従来のテスターとは大分イメージが違います)
過去の経験がかえってジャマをする
アジャイル方式に移行しようとしても、なかなか上手くいかない例をよく見ます。
ひとつはアジャイルの概念を理解するための時間やトレーニングが足りないことと、もうひとつは過去の経験に頼るあまり、従来のやり方に固執しすぎて失敗するようです。
ここで「ミニ・ウォーターフォール化」という言葉が盛んに使われます。
これは、形式だけアジャイルっぽくしてみたものの肝心の理念を理解していないがために、アジャイルとは似て非なるものになってしまった例を表す、非常にわかりやすい表現です。(詳細は本書の「3.2.4 アジャイル概念の理解不足」あたりを参照)
当事者意識が大事
アジャイル開発チームでは、メンバー全員が「オーナーシップ」を持つことが大事とされています。
つまり、どうすれば顧客に最も価値をもたらすかということを、ひとりひとりが意識して自発的に行動せよ、ということですね。よくありがちな、「これは私の役割じゃない」「彼が●●してくれないから作業ができない」という感じで自分の周りに境界線を引くような態度ではアジャイルチームでは通用しない、ということです。
以上です。
ちょっと観念的な内容になってしまいましたが、今後の章ではもう少し具体的な内容になっていくはずです。(;^ω^)
(終)
agile_test_.jpg

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です