悩めるSEの雑記です

日々思いつくがままです

XP祭り関西2012

勉強会

XP祭り関西2012行って来ました。

大きなイベントに参加するのは久しぶりで緊張しましたが、
いつもの通り始まると楽しいばかりでした。
ブログを書くまでが勉強会、メモしたことをシェアさせて頂きます。


■基調講演／アジャイル開発の計画と管理／梅田 弘之さん

  • アジャイルでも
    • マネジメントは必要
    • 要件定義、および統合テストはWFと同じ。設計〜結合テストまでをアジャイルでというハイブリッドで
  • マネジメント
    • 大切なこと
      • 組織でルールを決める
        • 例えば規模や開発の種類（新規・保守）などによって成果物、品質レベル、報告頻度などを定めておく
      • ルールを浸透・徹底させる
      • ルール違反を取り締まる
        • チェックリストを作り記録する（見える化）
    • スコープ
      • 成果物スコープ
        • 何を作るか
      • プロジェクトスコープ
        • 何をするか。WBS
    • 進捗管理
      • WFと変わらずガントで
    • ブロジェクト管理と現場の作業管理は分ける
      • ターゲットが違うからかな。見たいものやレベルが違うし
    • 見積もり
      • スコープベース
        • 機能に対して標準的な工数およびコストを積む
      • リソースベース
        • 実際の担当者を想定して工数およびコストを積む
      • 比べる
        • スコープベース＞リソースベース
          • 極端に差がある場合、時間が足りなくなる可能性が高い
        • スコープベース＜リソースベース
          • 極端に差がある場合、赤字になる可能性が高い
    • 振り返り
      • チェックリスト＆記録
        • 実際にやったかチェックできる（見える化）
  • デイリースクラム
    • いわゆる朝会
    • スタンダップ
      • 長くならない
      • 参加意識が高まる
    • １５分程度

ずっとアジャイルでの管理をどうしているのか気になっていたのですが、かなりスッキリしました。皆がこのやり方をしているわけではないと思いますが、実績のある方法として参考にしたいと思います。
また最終的的な品質確保の方法として、要件定義←→統合テストをWF同様に行うというところもやっぱりな感じでした。


■分科室／PivotalとScalaとRuby on Rails／川端 光義さん
●Scala
Androidアプリ開発をした際のお話でした。

  • 大概の事はScalaでも開発できる
  • Javaでやるよりシンプル。ファイル数も１／３程度になった
  • トレイト、暗黙の型変換がイケてる
  • 問題
    • Android API、外部ライブラリを利用した結果、Scalaの恩恵を十分には与かれなかった
    • ビルドが長い（２分）。LLな人たちはビルド時間が耐えられない。
    • Scalaとは関係ないが、アプリ内課金ではAndroid Marketの問題でハマった

●PIVOTAL TRACKER
チケット管理システムです

  • 1000万程度規模の案件なら十分使える
  • 設定項目や仕組みがアジャイル向きになっている（イテレーション、ストーリー、タスクなど）
  • １ポイント１時間の設定で最大８時間の設定でタスクを見積もっている
    • 制約を設けることが大切（８時間）
    • Redmineなどのように自由に設定できると、「１ヶ月」という設定もできる
    • 大きくすればするほどそれは「リスクの塊」となる
  • ベロシティ（速度。ペースだと思う）
    • 実績から自動算出できる。こうすれば小細工できない
  • プライオリティはタスクの並び順（上が高）
    • こうすれば優先度が一目瞭然
    • Redmineなどのように「高・中・低」とすると、「高」が沢山出来て、結果的にどれからやればいいのか決めれなくなることもない。
  • 画面遷移がない
    • Redmineなど画面遷移が多い。遷移中の待ち時間が耐えれないという開発者は多いらしい
  • 検索がよい
  • APIが公開されている
    • cURLコマンドで操作できる。例がいろいろ紹介されていた（英文）
  • 価格
    • 個人は無償。商用は有償
    • プランの段階がゆるやかなのが良い

TiDDでも最初にイテレーション計画やプランニングポーカーをやるそうです。

●Ruby on Rails

  • アメリカでの案件成長率が2500%を超えた！
  • 生産性が高い
  • テスティングフレームが充実している
  • 変化に強い（シンプルなソース）
  • 楽しい（楽しくなる仕掛けが沢山あるそうです）
    • 楽しさ最重要！
      • 楽しさは不可能を可能にする
  • ライブコーディング【rTunes】
    • ３０分で楽曲管理システムを作る
      • 曲を管理する
      • ジャンル別に管理する
      • 曲を再生する

凄いスピード感です。最後は再生だけじゃなく、歌まで披露されました（笑）
PIVOTALの話を聞いているときにも思いましたが、タスク対する見積もり工数のスケールが一桁違う感じ。「凄い」プログラマー達のスピードは全く違います。同じことしてたら全く勝負できない。
それからよく思うのですが、「有りもの」を上手く使わないと生産性は上がらない。デザインもプラットフォームにフィットしたものにする必要があると思う。


■分科室／システム要求の源／猪原 信彦さん
ビジネスモデリングのワークショップを行いました。
一つ一つは理解出来ますが、実際にやるとなると難しいかったです。
何かフレームワークを持って考えるのが良いようです。
【追記】
　何のためにビジネスモデリングをするか。
　→モデリングをすることでビジネスを理解する
　→ビジネスを理解することで、お客様に提案できるようになる。

■ＬＴ大会

  • 梶原さん／Rails Love
    • 川端さんの実演と合わせて、Rubyやるしか無いでしょな気分です
  • 前川さん／プランニングポーカー（資料）
    • 相対的に見積る
    • 前工程の不備が見つかる（前提となる条件・知識がないと揃わない）
    • 京都アジャイル勉強会でまたワークショップする
  • 中村さん／XP祭り2011から2012の狭間で（資料）
    • いかに皆を巻き込むか（私の活動のネタバレになるので伏せておきます）

■懇親会
楽しい話が沢山出来ました


以上です。