Facebook（メンバーのみ）
https://www.facebook.com/groups/172404826272150/
以下の書籍をターゲットとした読書会なのです。
 | ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド (Object Oriented SELECTION) (2013/06/22) Scott W. Ambler、Mark Lines 他 商品詳細を見る |
通称、DAD本。
以前、DevloveでこのDAD本のイベントがありました。そんとき書いたブログはこちら。
7/16(火) 「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜 」に参加しました http://t.co/Ia1ruGo9pj
— makopi23 (@makopi23) July 17, 2013
このイベントの後に、DAD本の読書会が立ち上がりました。
今回はその第2回目です。（ちなみに初回はお盆で帰省中だったので、残念ながら欠席）
場所は渋谷のキャロルシステム株式会社さんです。
主催の @terahide27 さん、会場提供ありがとーございます！
参加者は6人かな。ディスカッションするにはちょうど良い人数かもしれない。
この日は6～12章の「方向付け」フェーズがターゲットでした。
■会場案内の貼紙
会場ビルの1Fエレベーター前に貼紙が。。。
「ゼロの使い魔」のルイズ！
懐かしい。。。
@terahide27 氏曰く、12章のケーススタディに登場するLouise氏から思いついて取ってきたとのこと。
P.214のLouise氏のセリフ 「それは清書していませんよ！」 とか、ちょとツンの要素あるよね。。。
おバカなこと書いていたら、久々にくぎゅ～したくなったのでポチっとな。。。
・・・気を取り直して。
最初に訳者のお1人、岡 大勝 氏より6～12章の読み方についてレクチャー戴きました。感謝！
ダラダラと個人メモを起こしてみる。
■「6～12章：方向付けフェーズ」読み方レクチャー by 岡さん
■6～12章「方向付けフェーズ」
・6～12章の「方向付けフェーズ」がDADの全てといっても過言ではない。
・方向付けフェーズに本の1/3を割いている。
・受託開発は難しい。このギャップを埋めるエッセンスが「方向付けフェーズ」。
・プロジェクト全体を自己組織化したチームでJIT(Just In TIme)でどう進めるかがDADのテーマ。
・受託なんだけど計画もJITでやりたい、でも全部は無理。じゃあどうやるか？その解がDADの方向付けフェーズ。
■DADの使い方
・DADの細かいところを覚える必要はない。
・DADもJITで使ってください。
・各章のまとめをポインタにして、掘り下げてブレークダウンして読むのが良い。
・DADは、落としどころを探すための辞書として使う。
■10章まとめ
・受託開発については10章のまとめに書いてある。著者のスコット・アンブラーのアドバイス。
・ある程度予測して、マイルストーンを立てておきつつやりましょう。
・推奨は「アジャイル・リリース・プランニング（簡易に予測型）と適応的な計画型を組み合わせること」と書いてある。
・更に先に行くならば、イテレーションじゃなくてリーンになる。
・「リリースのリズムも大事」と書いてある。
・例えばエンタープライズでは、２週間ごとにリリースしても、業務も、運用とか教育も回らない。
・なので「内部リリース」と「外部リリース」に分ける。
・例えば内部リリースは２週間毎。外部リリースは３ヶ月毎とか。
・逆にサービス開発なら毎日リリースもあるかもしれない。
・結合テストは、自動化する前提でイテレーションの最後に毎回やる。内部リリースでも同じ。
■「方向付けフェーズ」の役割
・方向付けフェーズはアジャイルサムライの「インセプションデッキ」と同じ。
・自分が使える武器は限られている。アジャイルサムライと同じやり方になることもある。
・お客さんからの指定がある時は、互いにきちんとすり合わせしましょう。
・「武器が少なくて合わないからアジャイルは適用できない」という文脈が増えてきちゃう。
→ そうじゃなくて、かなりのプロジェクトに適用するための武器を各章に表で一覧に載せている。
・各章にある表は、上の方はNASAとか医療系とか、厳密性が求められる分野に適用する。
・それだけじゃなくて、普通はこういう選択をしてくださいね、というアドバイスも各章に書いてある。
・選択肢を方向付けでざっと考えて、大枠を組み立てて、その枠が標準となる。
・ガバナンスで、中間成果物を途中納品する話は20章に出てくる。
・中間成果物を途中納品するスタイルはアジャイルに向かない。中間成果物がマイルストーンとなったら終わり。
・中間成果物はオンデマンドでリーダーが決めてあげればいい。
→ その方向付けを「方向付けフェーズ」でしましょう。
・方向付けフェーズは「見通しを立てる」という表現がしっくりくる。
・方向付けフェーズは要件定義フェーズに該当し、準委任契約が一般的。
・受託開発の見積もりを作る期間で、Agreeするためのフェーズ。
・DADはスコープも予算も前もってある程度決める。その枠組みを方向付けフェーズで幅を持たせて決める。
■「方向付けフェーズ」のアンチパターン
・P.115に方向付けフェーズのアンチパターンが書いてある。
・方向付けフェーズでやっちゃいけないこととして、「独裁的プロジェクト管理」や「実装に飛び込む」がある。
・アジャイルだと「要件を聞いたらコードを書こう」と思ってしまうが、エンタープライズそれがと大きな手戻り原因になる。
■ウォーターフォール、RUP、DAD
・ウォーターフォールが悪、という文脈で語られることがあるが、必ずしもそうじゃない。
・ウォーターフォールの良いところは、スキルの高低が平準化される点。
・今はオブジェクト指向とかモデリングとかで、横並びの大量生産が減っている。
・でもエンタープライズでは、ある程度の規模を超えた時に平準化が必要になってくる。
・RUP（Rational Unified Process）は細かい定義に走りすぎてて、重い。
・アジャイルはRUPの両極端にある。
・RUPとアジャイルの真ん中を狙うのがDADである。
・エンタープライズの受託開発は、95%くらいはウォーターフォール。
・ウォーターフォールからアジャイルは遠いと思う顧客は多いが、実は隣ぐらいの位置にある。
・プロジェクトの回し方は、ウォーターフォールだと成果物駆動でフェーズを切るが、アジャイルだとタイムボックスのイテレーションでフェーズを切る。
・違いは、フェーズの切り方の角度が90度変わるくらい。
・やるならミニプロジェクトで切っていきましょう。タイムボックスで区切ってやりましょう。
・そのようにやるためには、まず開発側がお客さんに信用してもらわないといけない。
・DADでは、設計書は必要なものは作成する。手書きメモも納品物に入れる。
・設計書は「必要になったら」作る。
・それをできる自由度をタイムボックスに残しておきましょう。
■ディスカッション
岡さんが最初の40分くらいで当初の予定通り退席されたので、その後は残ったメンバでディスカッションです。
ホワイトボードと付箋はこんなカンジ。
以下のようなネタについてディスカッションしました。
■やりすぎない計画って？どうやるの？
■P.104の表6-1に「3週間の方向付けフェーズでのスケジュール例」があるが、これって最初に作れるの？
■エンタープライズだと現行システムの機能を踏襲しながら新システムを開発することが多いよね。
でも、現行機能を踏襲するならウォーターフォールの方が向くんじゃね？
移行開発がウォーターフォールでいいなら、DADって意味ないんじゃ。。。
■P.120で、開発構想書に「プロセスにDADを採用」と書くとあるが、「DAD」とだけじゃ広すぎじゃね？
各章の表で、一番上と一番下のやり方はほとんど別モノだし。。。
■方向付けフェーズで見積りの話が出たけど、イテレーションの中でストーリーをタスクに分解したあと、タスクの見積りってどうやってる？
---
議論は多岐に渡り、なかなか熱いディスカッションになりました。
んで時間が足りずにタイムアップなカンジ。
次回は、話し足りない方向付けフェーズのディスカッションを再度やるか、構築フェーズ（13章～）に入るかはFacebookで別途相談することになりました。
★感想：
「DADの全て」とまで言わしめる方向付けフェーズ、奥深し！
エンタープライズだと、最初により一層しっかりとした「方向付け」が必要なんですね～。
この点については同意です。
具体的に何をどうやればいいかまでDAD本に書いてある点も、頼もしい限りだ。
あとは、書いてある内容をどれだけ自分が理解して、自分の言葉として語れるかが重要になると思う。
本に書いてあるからやりました、じゃ当然通用しないので。。。
主催の @terahide27 さん、読み方レクチャーしてくださった岡さん、参加者のみなさんありがとうございました。
