DAD本の勉強会に参加してきた

昨日「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜」に参加してきました。

アジャイルてなかなか難しいよね、
特にエンタープライズ業界だと尚更ね、
っていうところに対する手助けをするこちらの本が
翻訳・発売されたので、それに関するお話でした。

ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド (Object Oriented SELECTION)

思想や基本となる部分についてのお話を聞かせていただいたのと、 細かい詳細な部分はiPadより重くてMacBookAirより軽いこの本に書いてあるとのこと。

感想

DAD（ダッド）本って言うらしい。（お父さん本とか言われるのかな・・・）

単語レベルで気になったのは、「JIT」と「BxUF」。

JITはJust in timeの略で、
「必要な時に、必要なものを、必要なだけ」作る、用意するといったニュアンスみたい。

JITと対義語的に扱われてたのが、BxUFで、「Big xxx Up-Front」の略。
「最初にしっかり xxxx する」といった意味。

JITが実践できていれば、余計なものが減るから、
本来の目的であるプロダクトを良くしていく作業に割く時間が増えるよね、的な。

プロジェクトの超初期で「しっかーーーり要件定義」して「しっかーーーーーり見積もり」して、
でも結局あれって何だったんだろてのは往々にしてあるなと。

特にマジメな日本人こそ1個1個を「しっかりやんなきゃ！」ってなるし、
規模が大きくなればなるほどビビって「事前にしっかり」しちゃうから、
その辺は気をつけて「BxUF」にならないようにしましょう。的な感じかなー。

あとは、アジャイルで「お客さんを巻き込むなんて無理だよ」は面白かったｗ
過大な期待をお客さんに押し付けないようにしたうえで、
アジャイルをやって成果出すしかないよね(^q^)的な感じかなー。

主催者の皆様、ありがとうございました。

参考リンク

• 「DAD本の歩き方」SlideShare http://www.slideshare.net/hiromasaoka/dad-24324539
• togetter http://togetter.com/li/534921
• 「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜」に参加してきました。#devlove http://sugiim.hatenablog.com/entry/2013/07/17/011750

以下超適当メモ

書籍は積み本状態。帰ってきてからAmazonの箱から出した。
読まねば・・・と思いつつ重いなぁ(*´∀｀)

Disciplined Agile Delivery
岡 大勝 さん : ゼンアーキテクツ
https://twitter.com/OkaHiromasa

DAD=ダッド（読み方）

USの統計だとエンタープライズ案件の38%はアジャイル
日本は2割くらいじゃね？

成功しているAgileプロジェクトはそれらのうちの59%程度。

プラットフォームとしてのDAD（本）が作られた
DADは知識体系であり本そのもの

Negative: ウォーター・スクラム・フォールの蔓延
・ウォータースクラム＋スクラムフォール
　（時間をかけて着手しない）＋（スクラムするんだけどデリバリーしない。お客様に価値が届かない）

スクラムはコアで余計なものそぎ落としまくったプロセスフレームワーク
・ピュアな環境では提供できるが、仕事では使えない、みたいなチームも目に付く
・流儀に個室して古いものを否定する現場もよく見られる
     ・「ファンクションポイントで見積もりするんですか？」
     ・「要求仕様書なんていまどき作りませんよ？」的なやつ
     ・アジャイルワールドに固執し続け、ウォーターフォールの習慣を頭ごなしに拒否してしまう環境もよくある
・ベンダーやアウトソーサーの怠慢

★大切な言葉「CONTEXT」（コンテキスト）

アジャイルとEnterpriseとのギャップ
     ・予算に合わせなきゃいけない
     ・スケジュールを守らなきゃいけない
          →このへんのギャップを埋めるのにみんな苦労してるよね

XPとかスクラムとか
     ・実際にピュアな環境だと結構うまくいった
     ・でも実際の稼働中の環境（チームとか）に放り込むとギャップを埋めるのが大変
    
この伸びしろや、ギャップを埋めるものがDAD、というわけではない。

★DADとは、EnterpriseのContextのどまんなかにAgileをもってこうぜ！っていう事。

Enterprise Agileは、「Enterprise＋Agile」（エンタープライズにアジャイルを取り入れてみる）というわけではなく、
AgileをEnterpriseのContextのどまんなかに持ってこうってのがDAD。

Waterfallで取り入れられる成果物駆動がEnterpriseにそもそも合わない。
成果物駆動：　要件定義で100点とって（成果物）次へ、設計で100点とって次へ
　　　　　　その間にレビューやルールの強要が行われる
                    本来不要な要求分析とかそういうところに力を入れすぎ

悪い習慣「BxUF（Big XXX Up-Front）　最初にしっかりｘｘする」

BRUF Big Requirements Up-Front
BDUF Big Design Up-Front
BMUF BIg Modeling Up-Front
とかね。

これだけがWaterfallの糞なところで、後は悪くないよ！

Agileな開発とは Agility　ではなく

★JIT Just-In-Time 必要なときに必要なものを（必要な人が）

必要の無いところまで成果物を作ってしまっていないか。
     例）ブロック塀を積む作業をする　→　ブロックの間のモルタルの厚さについて何ミリだ！っていう設計書を書いてるんじゃね

Enterpriseで成果物駆動はオーバースペック
     ・インフラ構築とかは成果物駆動とかのが向いてると思う
     ・でもエンタープライズにおいてはここ5年で必要なくなった

具体的なギャップ
     ・お見積もり
     ・利害関係
     ・規制・ルール
     ・既存システム
     ・人と組織

これらのJITとの乖離をどうする？
　→★Rhythm（リズム）
          →★３CRythm（スリーシーリズム）

★3C Rhythm
・Coordinate: 調整（見通しを立てる）
・Collaborate：協調（手を動かす）
・Conclude：完成（整える）

●方向付けフェーズで何をするか
　→JITとエンタープライズのギャップを埋める期間だよ
     →プロジェクト全体の大きなざっくりした見通しをたてる
     →アーキテクチャーの指針と実現性確認とか、計画と予算
          →こういう事しとくことで「ひどいやばい」を避けられる。
          →そんな程度のアレやそれ

          →この時に　BxUF　に注意！
          →日本人は特に「しっかり」したもんを出したがるｗ
          →上司にも適当なもん見せるくらいのアレやソレでｗ

★「初期に詳細に要件定義された要求は、詳細に定義された憶測にすぎない。」
     →やりすぎない、作り込み過ぎない、実際に動くものを早く作る。

■DADは7つのプロセスフレームワーク、60のプラクティスを詰め込んでいる。
     →めっちゃ細かいプラクティスがめっちゃ書いてあるぜ　→結果分厚い本にｗ

Agile Modeling / Agile Data / IBM Practice

■DADは37の戦略比較表と195個の戦略が詰め込まれている
     →必要な時に最適な表や戦略をチョイスして使ってみてね☆ミ

12章の方向付けフェーズのケーススタディーは最初に見るとイメージしやすいかもしれない

☆知の道具箱を皆さんの中に作って欲しい　→　引き出しふやそうね的な？
　→そのお手伝いができるよ。そう、DADならね。

★ DAD = Process Decision Framework

★DADの学び方
・Scrumを学ぶ
・JITの志向と行動を習慣付ける
・DADのフェーズを学ぶ
・3CRythmで生活する
・DADのライフサイクルを学ぶ
・属性の違う人（アジャイルじゃない人）とのコミュニケーション
・いろんな道具を手に入れる（知の道具箱を満たしていいく）

★アジャイリストの現実的な心得
・JIT！！　BxUFの誘惑に負けない！！！
・己の力量を知ること　→　リスクが高まるとBxUFにいきがち　→　使い慣れない技術とかに手をだしてBxUFしがち
     →ジョジョに力をつけていく
・こだわりを持ち過ぎない
・アジャイルを良い訳にしない
     →アジャイルだからこれはね〜　みたいなのはあかんよ
・関係者みんなに嬉しい驚きを届けるために

このへんで第1部おわり

第2部はグループディスカッション
・自己紹介
・今回のテーマについてのグループセッション
　・本日のテーマはアジャイルプロセスで開発していたけど、現実を突きつけられた瞬間
     ・その他
          ・グループごとに出てきた話題を話す

QAコーナー
・エンタープライズに対して2回くらい導入してみたんですが、失敗した
     ・でもみんなやりたいと思ってる
     ・大きなシステムになればなるほど腰はひける→しっかり準備したくなる
          →実装から距離をおいてしまう
          →でかくて、失敗するとヤバイから、実装から距離をおいてしまう
     ・解：作れるなら「ぷち」基幹システムを作ってみる
          →最短で作ることで、目安（距離感）がわかる

・エンタープライズって何？
     ・日本的な表現だと　基幹システム　業務システム
     ・この本では、　既存システムとの依存関係が避けられないシステム

     ・会社の中でみんながみんな、アジャイルやりたいと思ってない
     ・会社の中でみんながみんな、アジャイルしってるとは思ってない

      ・そういった事を鑑みる必要がある開発をエンタープライズって定義したりする。

・DAD本はサンプル
     ・アジャイルサムライみたい薄い本の内容だと理解してもらえないメンバーでも、
          DAD本なら詳細にケースが書いてあるので理解・検討ができる

・アジャイルで顧客を巻き込むのは難しいのでは？
     →受託の場合は無理だと思った方がよいｗ
     →「アジャイル」って言わなきゃいいじゃん
     →予算内・期限内によりよいものが出てきたらお客さん喜ぶ
     ・アジャイルで顧客を難しい時は、DADでは内部リリースと外部リリースを分けて考える（14章
          →内部リリースではうちうちでやる
          →外部リリースはお客様と取り決められているβリリースだったり何だったり。

・インセプションデッキいいよね
     →インセプションデッキ無しのプロジェクトはありえない（第7章）
          ・ビジョンを共有しない場合：素早く着手できるけど、構築フェーズでのイテレーションを無駄にしたり、間違った方向にいくかも
               →つまりビジョンは共有しとこうぜ。そのためのインセプションデッキだよ。
書籍
     AgileTesting