アイスランドクローネ日記帳

音楽のこと、旅行のこと、ふと思ったこと、全く思っていないこと等を書きます。

ディシプリンド・アジャイル・デリバリー [Scott W.Ambler / Mark Lines (著)] (翔泳社)

やー、読みましたよ、アジャイル。
開発プロセスって正解のない世界だしケースバイケースだし、
結局のところ経験を積んで感触でつかむしかない気がするので、
教科書的な本を読んで分かったつもりになるのは避けていました。
が、そうはいっても言葉の意味とかは知っておかないと人と話せないなと思い、
図書館にあった本を手に取ってみました。

言葉だけ知っててふわふわしてる感のあったアジャイル。
無計画でいい加減に進めていながら「アジャイルだから」と言えばなんとなく専門的に聞こえるあれですね。
本来の使い方はそんなんじゃないはずなので読んでみました。

ひととおり読んで分かったのは、これはこれで大変だということ。当たり前ですが。
2週間ごとにリリースするって簡単に言うけどムリだよなと思いました。
行き当たりばったりになった状態がアジャイルじゃないということは分かってよかったです。

ディシプリンド・アジャイル・デリバリー(DAD)は、
いろんなアジャイルの手法を組み合わせつつ、
通常のアジャイルよりフェーズをはっきり分けて
「方向付け」「構築」「移行」と3段階にしたことが特徴です。
ケーススタディが方向付けフェーズ1週間でびびりまくりました。

他にもいくつか思ったことを簡単に書きます。


まず大きいのは、ユーザーの代表者的な人がチームにいる必要があるということ。
これは確かに大事だ。
これがこの本で一番大事なんじゃないかというくらい。
開発しかいないのにアジャイルやっても意味ない。

「リーンの原則」の「決定を遅らせる」はすごい。
確かにそれで結果的に無駄なことしなくて済む場合もあるけど、
ここまで悪びれずに書かれるとびっくりする。
決定遅いとみんな困るよ!

スクラムはいわゆるみんながイメージするアジャイルで、非常に分かりやすい。

XPはいろいろ書いてあるけど細かい話が多くて全体像がつかめず。
XPってウィンドウズですか?という気持ちが最後まで消えず。

データベースはアジャイルは大変だろうなぁと思う。

チームの組織は楽しく読めた。
同じ作業場所で全員そのプロジェクト専念がいい。
言われなくても分かるし猛烈に同感。
「個室でイヤホンつけて仕事したいエンジニアが多いと反発を食らうかもしれない」みたいな
説明文には文化の違いを感じますね。
壁いっぱいのホワイトボード楽しい。

方向付けフェーズはこの本の中で最大の謎。
予算確保とかスケジュール決定とかさらっと書いてあるけど、
仕様がちゃんとない状態でどうやってやるんだろう。
非機能要求もこの段階で決めるらしい。難しい気がするけど。
全部は決めないって割り切るんだろうな。

コスト見積りのプランニングポーカーすごい。
全部相対値だし、チームメンバー各自の直感でポーカーみたいにカード出して
なんとなく決めていく大胆さがすごい。
このプロジェクトのコストは相対値で1000です、って言われても何もわからない!
他のチームの1000とは全く違うらしいし。

でもファンクションポイント法は実際は違うのに科学的に導出されているように見えてしまう、
っていう指摘はすごく正しい。
それくらいならポーカーで相対値で出して、これは相対値ですよ、って開き直る方が
確かに現実とのギャップは小さいのかもしれない。
勇気がいるけど(笑)。

ドキュメントを構築フェーズの2週間のイテレーションの中で書いていくの無理っぽい。
重厚な仕様書ではないとはいえ、ユーザーマニュアルだって大変だ。

チームが1回のイテレーションで出せる成果であるベロシティーも怪しい。
安定させるの難しそう。

日時調整ミーティングは大事。確かに。
テスト駆動開発(TDD)は簡単じゃないけど目指すべき。確かに。

移行フェーズの説明は「これは構築フェーズのうちから準備しておくべきである」
みたいな後出しが多い。
結局構築フェーズがプロジェクトのメインパートだし、そこでやるべきことが多すぎる。
そこらへんは結局ドタバタしそう。

ケーススタディが海外ドラマみたいでおもしろい。
Louiseは最初態度悪かったのになんであんなに急に協力的になったのか謎。
スケジュールが遅れるとヒステリックになるDeanもおもしろい。
結局最初の予定を全部こなせないところは現実的でよい。

なんというか、海外ドラマってあの業界独自の文化があるせいでああなってるんだと思ってたけど、
それとは全く別のはずのソフトウェア開発プロセスの本でもこうなってしまうっていうのは
海外ドラマのなんらかの普遍性を示しているんだろうか。

テストとかモデリングとか、それぞれの項目に対していろんな手法が選択肢として比較されているんだけど、
いちいち最後に「何もしない」みたいな選択肢があって、
「プロジェクトが失敗してもよいならいい選択だろう」みたいな脅しがあるのがウケる。

というわけで読み応えのある本でした。
もしアジャイルやることになったらまた借りよう。
  1. 2016/09/19(月) 02:30:01|
  2. | トラックバック:0
  3. | コメント:0
<<Javaの鉄則 [ピーター・ハガー(著)] (ピアソン・エデュケーション) | ホーム | シグナル&ノイズ - 天才データアナリストの「予測学」 [ネイト・シルバー(著) 川渕節子(訳)] (日経BP社)>>

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://myumbrella.blog42.fc2.com/tb.php/320-4b678036
この記事にトラックバックする(FC2ブログユーザー)