桜、抹茶、白、日記

名古屋市在住のC++使いのcoderの日記だったもの。

Agile Tour Osaka 2010 に参加

Event Programming

d:id:youandi:20100930:p1
日本初開催のAgile Tourに行ってきました。

Agile Tour Osaka(Japan)
http://at2010.agiletour.org/ja/osaka.html
http://kokucheese.com/event/index/4870/

[IT] Agile Tour Osaka 2010の見どころ解説
http://pub.ne.jp/Under_the_Bridge/?entry_id=3213608

【Event】AgileTourOsaka2010
http://www.xpjug.jp/cgi-bin/main_wiki/wiki.cgi?page=%A1%DAEvent%A1%DBAgileTourOsaka2010

    • イベント運営スタッフによる振り返り

女性の参加者が結構多かった。まあそのうちスタッフの方が多かったみたいですが。それにしても名古屋アジャイル勉強会の状況がおかしいのかな？w


以下、基本スライドをコピペしただけの無意味なメモです。

開会 by 細谷さん([twitter:@yasuohosotani])

今回のAgile Tourが日本で行われるのは初めての試み。Agile Tourはフランスで始まったイベントで毎年10月に世界中で開催されている。今日は、大阪、北京、リオデジャネイロ、ニューデリーで同時開催されている模様。

あと、EM ZERO vol.6が本日印刷所から直送されました。
Share photos on twitter with Twitpic

「日本のアジャイル開発の変遷、現在・過去・未来」 by 長瀬さん

    • 2000年12月：XPブーム
      • XP本は全世界で10万部、日本で3万部
      • XPのプラスティス
        1. 計画ゲーム
        2. コーディング規約
        3. 短期リリース
        4. 全員同席
        5. メタファ
        6. 最適ベース
        7. シンプル設計
        8. 常時結合
        9. TDD
        10. コード共同所有
        11. ユーザーテスト
        12. ペアプログラミング
        13. 設計改善
    • 2001年2月：http://agilemanifesto.org/iso/ja/
    • 2001年3月：XPユーザグループ設立
    • 何をしてきたか
      • 技術的な勉強
      • 小規模プロジェクトでの実験
      • 上司を説得する方法の検討
      • 普及・コミュニティ活動
    • 出来る人達がやってXPで成功。しかしながら出来る人達なのでWFでも成功していた筈。
    • 誰がしてきたか
      • エンジニア
      • 先進的なソフトウェアハウス
      • ベンダーの研究開発部門
    • 開発現場のマネージャーは興味を示さず
    • 開発プロセスの変遷
      • 日本人は駄目なやり方でも頑張ってやり遂げてしまう
日本 アメリカ
ウォーターフォール ウォーターフォール
↓ イテレーティブ(UMLによる繰り返し)
アジャイル(2011年〜) アジャイル(2002年〜)
    • アジャイル適用の問題点
      • 契約
        • 受託契約
      • 派遣法
        • 責任の所在は派遣先会社
      • 教育
      • 品質
        • 人のスキルで品質を確保する。
      • テスト
      • 顧客の同席
        • 日本ではあまり行われていない？
    • 生産性向上
      • ALM(Agile Lifecycle Management)
      • ツールの導入
        • やり方を変えても生産性は変わらない
      • 分散開発
    • 開発で使用するツール
      • 推奨ツールの一覧(マップ)を作成する。
  • 感想

Scrumについては多少かじった程度ですが、XPについては全く勉強していないので、今回初めてどんな物か知りました。
来年あたりに日本ではもっとアジャイル開発が活発になるのではとの事で、どうなるんでしょうね。
事例紹介では、ちょっと気になっていた品証・テストとアジャイルの絡め方については、そもそもプロセスを分離するのかぁというのは意外でした。
「やり方を変えても生産性は変わらない」これはソフトウェア開発での話だと思いますが、その通りだと思いましたね。色々な場で伝えていきたいと思いました。

「チケット駆動開発がAgileになる理由 〜No Ticket, No Commit!〜」 by あきぴーさん

Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法

この本の著者の方によるセッション。

第1部
    • チケットファースト
    • アジャイルの課題
      • 頻繁に変わるタスク
      • ソフトウェアプロダクトラインに似た並行開発
    • TiDD(チケット駆動開発)
      • 障害も仕様変更もチケットとして扱う
      • チケットをXPのタスクカードのように扱う
      • 成果物の変更をチケットで追跡する
        • No Ticket, No Commit!
      • 並行開発をチケット管理
第2部 チケット駆動開発がアジャイル開発になる理由
    1. タスク管理
      • チケットをXPのタスクカードのように扱う
      • チケットを集計結果をカンバンのように扱う
    2. 変更管理
    3. 並行開発
第3部 アジャイル開発のアンチパターン
    1. 変化に追いつけない
    2. イテレーションを運用出来ていない
    3. 並行開発出来ていない

上流工程のアジャイル化の流れ

  • 感想

今月発売されたばかりのRedmineでタスク管理する本の著者の方でちょっとビックリ。
アジャイル開発を行っている上で、プロダクトマネージャーやスクラムマスターの負荷を如何に減らすかとう話だなと感じました。カンバン・タスクカード等を運用していくのに時間が取られてしまっては元も子もないですね。

「西日本にだけこっそり教える アジャイルコンサルタントの秘密」 by 牛尾さん([twitter:@sandayuu])

    • 開発プロセスの歴史
      1. カオス型、スクラップ＆ビルド
      2. 計画主導・先導型設計
      3. 適応型/進化型設計
    • アジャイル開発とは
      • eXtreme Programming
      • Scrum
      • FDD(Feature Driven Development:ユーザー機能駆動開発)
      • Crystal Family(The Crystal methodology:Crystal Clear, etc.)
      • DSDM(Dynamic Systems Development Method:反復型開発)
    • 変更に対するコストカーブ
      • 早期に変更する方がコストがかからない
      • 終盤での変更は多大なコストがかかる
    • アジャイルプロセス ベースライン
      1. 全体像の共有(ステークホルダーを含む)
        • プロジェクトの全体像が存在するか？
        • プロジェクトの全体像が共有されているか？
        • アジャイル開発を導入する目的は何か？
      2. ストーリー供給/検証力
        • スプリント実施前までにストーリーを用意でき、検証が出来るか？
      3. タイムボックス
        • タイムボックス中はストーリーの変更なく出来るか？
        • スプリント計画(イテレーション計画)のムダ・ムリ・ムラはないか？
        • アジャイルは結果論として、開発が早くなる
          • 早く出来るからといって、見積もりを短くしない事。
        • プロダクトバックログやコードベースは共有・一本化されているか？
      4. 開発生産性向上
        • スプリントで成果を出す為のムダは排除されているか？
        • 生産性が向上するプラクティスを実践しているか？
      5. 変更の吸収
        • 発生する変更に耐えられるメカニズムが存在するか？
      6. 早期の失敗
        • 失敗がある物として吸収できるメカニズムが機能しているか？
      7. 見える化
        • 伝わるべき人にちゃんと伝わっているか？
    • アジャイル開発 企業導入のポイント
      • 顧客を支援するものはあるのか？
        • 顧客の役割を果たす事は難しい
        • Agile BA(Buisiness Analysis)
    • アジャイル導入の手順
      • アジャイル導入の成績表(Agile Value Chart)
        • 管理力
        • 開発力
        • 人材力
      • スキル
        • マネジメント能力はチームを守るために使う
      • 大切な事
        • 相手を心から信頼する
          • ここが重要とセッション中では仰っていた
        • 相手を理解する
        • 相手の興味がある事について相手の言葉(相手に伝わる言い回しで)で語る
  • 感想

コンサルさんだけあって、話やプレゼンはとてもうまかったですね。
顧客を支援するものについては、自分が開発者の立場であるのであまり気にしていなかった事ですが、よくよく考えると顧客の要求を引き出す作業というのは、本来顧客の方から出されるものであるのに開発側に負担が来ているのかな？と思ったり。

牛島さんってこの本の著者様だったのか。

オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座

オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座

「ユーザーストーリーマッピング」 by 懸田さん

    • ユーザーストーリーとは
      • 利用者から見た実現要求
      • 簡潔に(細かすぎない)
      • 何の為？誰の為？
      • アジャイル開発の実現単位
      • 「ユーザーストーリー＝作業」ではない

ユーザーストーリーは３行で書かれる。

[A] として
[B] したい
それは [C] だからだ

    • ユーザーストーリーマッピング
      • 全体像をユーザーストーリーベースでチーム共有
        • ユーザーストーリーを縦軸：優先度＋横軸：時間の２軸で表現する
    • ユーザーストーリーマッピング
      • 地図を作る過程が重要である
  • 感想

AEP本ではユーザーストーリーの作成方法というか洗い出し方についてはあまり触れられていないので、１つのやり方としては参考になりましたね。

LightningTalk

チケット駆動開発ネタ by [twitter:@kami_teru]さん

Redmine Code Reviewプラグインを使ったり、Redmineを小さく導入していった話。

    1. ToDo管理ツールとしてRedmine導入・運用
    2. Redmine Code Reviewプラグイン導入・運用・強制化
    3. 工数管理導入・運用・強制化
ネーミングについて

マーケティング視点とエンジニア視点の双方で様々なネーミングを考えましょうという話だった。

ネーミングの掟と極意 (エンジニア道場)

ネーミングの掟と極意 (エンジニア道場)

リーン開発のソフトウェア適用

自社開発のシステムのムダを排除する為に、プログラムにフラッグシステムを導入したお話。今後はTOC理論(theory of constraints:制約条件の理論)も組み込みたいとの事。

アジャイル開発ツール by [twitter:@Sean_SF]さん

ATLASSIAN社([twitter:@AtlassianJapan])の方によるLT。日本支社の社員はこの方お一人のみの模様。
まずはタスク管理においてどのアプリを使っているか？という統計で、Excelが65%位。JIRAでTrac/Redmineを置き換えるのではなく、Excelの領域をJIRAに限らずその他のタスク管理ツールで置き換えていきたいと仰っていた。
それから、gitでいう所のgithubにあたる、ATLASSIAN社が(買収して)提供するMercurialのフリーリポジトリであるbitbucketの紹介。

http://www.atlassian.com/hosted/bitbucket/

ATLASSIAN社が買収した事により、10月より無料利用範囲が増えた。

    1. OSS
    2. 5ユーザーまで

因みに無料利用でもプライベートリポジトリ(非公開のリポジトリ)を１つ持てる。やっぱりMercurialだよね。

事例紹介コンテキスト記述と開発とリリースの分離

「こういう開発だから〜である」という紹介のし方が望ましい。

閉会 by 前川さん

アジャイルをネイティブな発音で、という事で皆で「ハ〜〜ジャ〜〜イル」って叫んだのは覚えている。

懇親会

今回のイベント名古屋から参加しているのは自分を含めて２人だったので、アウェー感バリバリ。
たまたま隣に居合わせたKNKさんが気さくなお方で、色々と話相手になって下さりボッチは回避出来ました。ありがとうございます。
会場入り口近辺だったので、スタッフの方が多く、細谷さんともお話する事が出来ました。またKNKさんはXP祭りの懇親会の席で長瀬さんと向かい合わせだったとの事で、懇親会の終了間際には長瀬さんともお話をする事が出来ました！これまたありがとうございます。

また、懇親会の参加者向けに後援頂いた技術評論社・翔泳社から書籍のプレゼントがありました。懇親会参加者が40数名に対し、書籍の数は30冊ちょっと！凄い確率で本が頂けました。自分はジャンケン弱いのですが何とかゲットしました。

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

Googleを支える技術 ……巨大システムの内側の世界：書籍案内｜技術評論社
過去2回のHadoopの入門セッションで紹介していたGoogleのシステムについての解説本は実は持っていないのでこちらの本を頂きました！ありがとうございます。


帰りの特急列車で隣に座った人が大イビキをかいていたのにはビックリした。自分も寝ている時にイビキをかいているのではないかと心配になりました。

感想等

AEP本を読んでいて疑問に思っている、アジャイルな見積をすると従来の見積比べると金額的に多くなってしまうのではないか？という事については、払拭出来なかった。契約的な話が行われるイベントに参加するべきなのかな。

あと、今年アジャイルを勉強してきて最近思っているのは、「アジャイル開発＝良い事」って言い過ぎじゃね？と思っていて、TiDDがアジャイル開発になると言われても、あまりピンと来なかったり。
アジャイルの暗黒面というか、プロセスを理解している人が必要であるとか、暗にスーパーマンが一人は要求されたりとか、イテレーションを回していく為の準備であるとか、アジャイル開発を成功させるには必要となるものについて、今後アジャイル開発を広めていく上ではもっと強調しても良いんじゃないかなと思ったり。

今回も(プロジェクト)ファシリテーションの話が出てきたけど、やっぱりアジャイルにはファシの理解も必要なのかなと再認識したり。

あと、別の視点・別の立場で物事をみる事について、顧客を支援するものという話が牛尾さんのセッションであったけど、今回のその話をきいてハッとしましたね。