Entries

ジョナサン・ラスムッセン『アジャイルサムライ』

アジャイルサムライ−達人開発者への道−アジャイルサムライ−達人開発者への道−
(2011/07/16)
Jonathan Rasmusson

商品詳細を見る

これは素晴らしい。読んでいてとても楽しい本。アジャイルなプロジェクトの進め方について解説した本で、主にスクラムを念頭に置いていると思われる。カンバンの話もちょっと出てくる(p.198f)。アジャイルな開発とは何で、どう進めればいいのかについてとても読みやすく書かれている。読みやすいけれどもポイントはしっかり書かれていて、いつの間にかアジャイルソフトウェア開発宣言が身につくようになっている。ここまで読みやすさと内容の充実さを両立した本もなかなか無いだろう。

ユーザストーリーを小さなカードに書くのは、ストーリーを洗い出した時点では詳細に分析しないためだというポイントが目を引いた(p.105f, 189f)。イテレーションでそのストーリーを取り上げる際には、当初考えていたものとは変わっているかもしれない。そうしたら詳細分析は無駄になってしまう。そのために、物理的に量を書けないように小さなカードにしている。また、アジャイル開発とはそういった確立された手法があるというよりも、常に改善し続けるというやり方そのものだと著者は言う(p.287)。これでいいやと満足して進化をやめてしまったらアジャイルではないのだと。

アジャイル開発を支える、ソフトウェア開発の四つのプラクティスが掲げられているのも好印象(p.32f, 235f, 285)。つまり技術的負債を溜め込まないように、単体テスト、リファクタリング、テスト駆動開発、継続的インテグレーションを行う。これらは別にアジャイルでなくても有効なプラクティスだろう。コードを書く人でも案外に知らない人が多い。

 ここで疑問を抱いた読者がいるかもしれない。プロジェクトの仕事量が、とても開発チームにはこなせないぐらい多いにもかかわらず、スコープを柔軟なものとして扱うことをお客さんから拒まれたらどうすればいいのか、と。
 いい質問だ。このときの選択肢は2つある。
 ひとつは、ごまかし続けることだ。見なかったことにして、古くなってしまった計画に従い続けるんだ--他のみんながよくやっているように。楽観的すぎる見積をしたり、見積もりを水増ししたり、チームのベロシティを無視したりしながら、「最後には何もかもよくなりますように」と祈ってもいいだろう(これは「奇跡によるマネジメント」という有名なマネジメント手法だ)。
 そうじゃくて、事実をありのままに打ち明けるのがもうひとつの道だ。どうなっているかをお客さんに報告して、気まずい沈黙の中で座ってひたすら待ち続けるんだ--どうやら君は諦めなそうだ、とお客さんが折れるまで。うわべだけを取り繕うんじゃない。共犯者になろうとしちゃだめだ--私たちの業界が過去40年にわたって続けてきた、ひどい誤魔化しに加担するんじゃない。私はアジャイルサムライの道が簡単だなんて言ったおぼえはない。(p.154)



スポンサーサイト
この記事にトラックバックする(FC2ブログユーザー)
http://exphenomenologist.blog100.fc2.com/tb.php/543-2ec1a742

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する