[ダイジェスト:2007/09/01]XPまつり2007

名　称　XP祭り2007 ～XPブートキャンプだ！～
開催日　2007年9月01日(土)10:30-17:30 (懇親会 : 18:00～21:00)
会　場　江戸川区総合文化センター

　XPerが「仕事にXPを導入しようとしてブチ当たった壁をどう乗り越えるか」のヒントを得たり、「XPって何だ?」とのぞきに来た人たちを洗脳してXPerにしてしまうおまつり。最近は、「開発手法」そのものよりも、「人間関係」や「コミュニケーションスキル」がトピックの中心になっている傾向がある。新しい技術に関するセミナは、あちらこちらで開かれているけれど、ヒューマンスキルを中心にするものは、まだめずらしい。今年は、MindStormに引かれて、体験講座を選択してみた。

 ちなみに、今回は、飛行機の時間の関係で、開催挨拶の途中から参加。体調不良もあって、ちゃんとしたメモになっていないかも。

開催挨拶(途中から)
------------------
XPの5つの価値
  • Communication
  • Be simple
    • 「システムをシンプルに」だけではなくて、手法もシンプルに。
  • Feedback
    • 自分たちがやろうとしていることが正しいか、見極めるために必要。
  • 勇気
    • 「捨てることに対する勇気」「現実を直視する勇気」...
  • 敬意
    • チーム内でお互いに持つことが大切なもの
Practice
  • Kent Beck氏曰く
    「私は、偉大なプログラマではなく、偉大な習慣を身につけたプログラマ」
原則
  • 「価値とプラクティスだけでは、自分たち用にカスタマイズする時の取捨選択に困るよね」という面で、重要。
  • 原則の例
    • 反復型開発(イテレーション単位)
      • ウォータフォールだと...
        • 中間成果物からは、本当の進捗がわからない。
        • 開発者が多くなると、修正・変更が難しい。
        • ドキュメントとコードが乖離してしまう。
        • テストを後回しにすると、根本的な問題の発見が、遅れてしまう。
    • 人と役割は、なるべく少なく。
      • 少ないほうが、ロス(コミュニケーションコストなど)も少なくなる。
        → これが「XPはも大規模開発には使えない」という話を作り出した。
      • 役割を少なくする手段として、たとえば、
        • Ruby on Rails
        • マネージャもコード書いてしまう「全員一丸開発」とか。(人に頼むより効率良いよね)
取り組み方
  • 守
    • 先人の成功例から学ぶ
  • 破
    • カスタマイズする
  • 離
    • カスタマイズしすぎて、XPから離れてしまったように見えても、エッセンスの部分は残っている状態。

エコポイント[web][資料]
------------
今年の目標はECO
  • 去年、懇親会後に大量のゴミ(タクシーでゴミ袋数個)が発生
  • 「これは、たまらん....」ということで、ECOポイント採用
    • マイ箸、マイカップ、マイ皿....で、ひとり最大5ポイントプレゼント
    • 抽選会で、本があたりやすくなります。
温暖化とシステム開発の類似点
  • 化石燃料大量使用 → 人間大量投入
  • 大量に作って、大量に捨てる価値観 → 使うかどうかわからないけれど、とりあえず全部作っておけ
  • 「きっといつか技術が解決してくれるさ」 → 「新しい技術が解決してくれる」という、淡い期待。
  • 「今までのスタイルを変えるなんてできないよ」 → 「新しい開発スタイルに移行するのは、難しいよ」という気持ち

Agile2007(by 平鍋さん)[web][資料]
----------------------
開催
  • 2007/08/13～17
  • Washington D.C.のホテル
    • 会議室フロアを借り切って、10トラックくらい平行で走る。
    • 90分or180分で1セッション。
    • 参加者数1112名
    • 2003年～2004年の参加者は、300人～400人
    • 新規の参加者が、60%以上。
    • Rubyプログラマが、全体の1/3。
    • スポンサー枠も、あっというまにいっぱい(以前は数社しかいなかったのに。)
  • http://www.agile2007.com/
   

キーノート(1)
  • スーザン・アシュラー(Susan Ershler)
    • 世界七峰を制覇。エベレストに夫婦で登頂成功。
  • テーマ
    • 「ビジネス上のゴール」と「私生活のゴール」を両立させる方法
    • たとえば、日常のトレーニングは、「ビルの34階まで、階段で上る」とか。
    • 大切なことは、「3つのP」
      • Project(ビジョンの投影)
      • Prepare(準備)
      • patience (辛抱強さ)

キーノート(2)
  • エーリッヒ・ガンマ(Erich Gamma)
    • Eclipseプロジェクトな人
  • テーマ
    • Agile in Eclipse
    • メンバーが世界中に散らばっている状態で、どうやって、Agileするか。

セッション概要
  • 今回の主な視点
    • Enterprise
      • 大規模システムに、Agileは使えるのか?
      • USの場合、1000人規模のIT部門(ユーザー企業)が、Agileを使うことが多いという実態の反映か。
      • キーワードとしては、"Distibuted"、"PMI"、「PMのためのAgile」、「オフショア」。
      • Leanが、マネジメントに浸透した影響は大きい。
    • People
      • Leadershipとか、Trust Buildingとか、Educationというキーワードが多い。
    • Test Driven
        • BDDとか、Railsの話題がいっぱい。
  • TDD
    • トピックがいっぱい
    • 「Test Drivenではなくて、Behavior Drivenではないか」という議論
    • 「もっと上流工程にテストを延長できないか」という提案
    • "Test Driven Database Designer"という、(話をしている本人にとっても)どこまで本気かわからないもの
  • SCRUM
    • XPよりもSCRUMという言葉を聞くほうが多かったかも。
    • SCRUMは、XPよりも組織として、扱いやすいからか。
  • Lean
    • 「Value Streamがcashになるまで」というような話に強いので、最近、マネジメント層にインパクトが強い。
    • Agile/Lean
      • 投資効果が得られる
        • 「顧客とともに、ビジネス価値を考えて、作っていく」
      • ちゃんと動く
        • 「仕様が正しい」ではなくて、「実装が動く」が大切。
      • 期待される期間内に提供する
        • プライオリティ付けが重要
        • Timeboxの概念
      • 維持、変更の継続性
        • イテレーションの繰り返し
      • ソフトウェアは、「人が」「人のために」作っている
        • People managementの重要性。
        • "Making connections, Building relationsip"

発表者
  • アリスタ・コバーン(Alistair Cockburn)
    • 発表はひとつだけ。
    • 「一対一のコミュニケーションをとる」ために、マッサージをしてまわっていた。
      • でも、マッサージの相手は、女性のほうが多いのは、なぜ?
  • ダイアナ・ラーセン(Diana Larsen)
    • Trust Building
  • ジーン・タベーカ (Jean Tabaka)
    • I don't like mondays
    • 「私は、月曜日が嫌い。だって、会議があるから」というわけで、「XPは、ミーティングが多いね」という話。
    • なぜ、ミーティングが嫌になるか
      • 同じ内容が話される
      • 同じ人が話す
      • 結論が出ても、何度も同じ提案がされる
      • 決定が、ミーティング外で行われている。
      • 人が多すぎる/少なすぎる
      • ミーティングより、コードを書きたい。
    • 大切なのは、ミーティング開始直後の「苦しみの時間(Groanzone)」
      • つらいけれど、この部分をちゃんとやらないと、ミーティングが嫌になる。
    • ミーティングのカイゼンのためには、
      • 目的や、アジェンダを紙に書いて貼る
      • 権限を持っている人が、別の話にそらそうとしたときは、
      • ファシリテータがそのメモをして、話を脱線させない。(「話がズレている」という切捨てはしない。)
  • 平鍋さん
    • Mary Poppendieckさんと、一緒に180分のセッション
    • 前夜、ジョークを考えていて、一睡もできず。
    • トピックは、「Toyota生産方式って、XPに似てません?」という話。
      • トヨタ織機Type Gの「縦糸が切れたら、すぐに機械を止めるセンサー」は、Test Drivenに似てる。
      • 「すべての部品を、自分の周囲に集めて、一人でひとつの製品を完成させる」屋台方式は、Agileっぽい。
      • Agileがやっているのは、実は、昔の再発見ではないのか?
      • 大野耐一さんの本には、「現場標準」という言葉がある。
        • 現場で、考えること
        • 現場の変化を継続させること。
  • リンダ・ライジング(Linda Rising)
    • 2002年に沖縄でやったワークショップで、平鍋さんがリンダさんに会って、それが元でXPするようになったという、因縁の人物。
    • テーマは、Introducing Pattern
      • 組織に、新しい概念を持ち込むときの方法論
        • エバンジェリストとイノベータの大切さ
        • 食事を一緒にすることで、信頼感醸造
        • Early adapter, early majority
        • just say "Thanks"
        • 組織には、新しい概念を受け入れられる人も、受け入れにくい人もいる。
          • 受け入れられない人の話を聞くこと
          • 相手に安心感を与えることの重要性
          • 多くの場合、抵抗勢力には、「組織の中で話を聞いてもらえない」という意識が高い。
          • 「良い」とか「悪い」とかいう判断はせずに、ひたすら聞いて、メモする。


XP体験 ～レゴロボットでXP！？～[写真とmovie]
-------------------------------
3名～4名のグループでペアプロを始めとするXPな作業を体験する3時間半。
他人と一緒に作業することが少ない僕には、刺激的な体験。
表向きは、「ファシリテーションの観察」だったけれど、本心は「Lego MindStorm楽しい」で参加決定。
「Mind Storm講座ではない。XPを体験してね」といわれても、やっぱり気になるMindStorm。

で、ぼくのグループは、4名。XP経験者と未経験者が混ざった構成。
第一イテレーション
　サンプルとして提示されたプログラムは、コースが曲がっているとコースアウトしてしまう。最初の作業は、これを何とかすること。
　原因は「センサーの感度を調整していないから」とわかっているから、普段なら、エイヤっで何とかするところだけれど、今回は、MindStormに慣れていないし、ちゃんとXPを体験しなくてはならないので、始める前にいろいろと準備。

　話し合いの結果、第一イテレーションでは、「コースアウトしないように、サンプルプログラムを修正」「8の字を描く」「左右どちらに曲がっているコースでも、ちゃんと走るようにする」に挑戦することに。

  　「さて、始めるか」という段階になって、「javaの開発環境のバージョンが違～う」とか「USBタワー(Legoにプログラムを転送するのに必要)を認識しな～い」とか「LANの調子が悪～い」とかいう問題があって、みんな、ちょっと焦る。

　トラブルなしで進んだのは、「模造紙の上に、マジックでコースを描く」ことだけ。わはは。
　これも、ほかのチームを見るともずいぶん太いコースを描いている。自分で作業しておきながら、「いいのか、これで」と不安になる。

　PC持ち込み組が、悩んでいる間、他の2名は、Lego Carの動作確認や、コース上でセンサーが返してくる値と、コースアウトしたときの値を測定。
　これがまた、黒い線(コース)の上の値とコースアウトしたときの値が、似てるんだな。全然違う値が返ってくると思ってたのに。

　持ち込みPCのうち、一方のPCでコンパイルがうまくいかないので、ペアプロ * 2組をあきらめて、2台のPCを、プログラム1組、ドキュメント1組という体制に変更。
　プログラム組が手をつけた「センサーの値を修正」は、とてもうまくいって、壁に貼ったTodoリストの位置が一気に変わる。
　「もしかして、遅れを取り戻せるかも」という期待を負って、「コースが左右どちらに曲がっていても、コースアウトしない」バージョンの開発を開始。
　これは、「8の字より、こっちの方が簡単そうだ」と僕が言ったから。で、ちょっとやったところで、僕が、何の裏づけも無く、口先提案をしていたことが露呈。そんなに面倒ではなさそうなんだけど、焦ってるから、なかなかアイディアがまとまらないってのが問題だと思うんだけど。
　というわけで、大慌てで計画変更して、「8の字走行」に挑戦。

　「円走行を完成させて、これを逆方向にも回るようにすれば8の字に」という考えで、円走行に挑戦。
　「車の方向を変える → 少し進む」を繰り返すことで、なんとかなるだろう...とコードを書く。
　ちゃんと覚えてないけど、こんな感じのコード(↓)

        for ( int i = 0; i < 1000; i++ ){
            左タイヤを動かす
            sleep ( 1000 );
        }
        for ( int i = 0; i < 1000; i++ ){
            左右タイヤを動かす
            sleep ( 1000 );
        }

　時間に追われていて(これは、僕のいいわけ)、「ま、こんなので、試してみましょ」ということにしたら、当然のごとく、失敗。しくしく。
　よ～く考えれば、sleep()はm秒単位なので、
　「1000秒間方向を変えて、1000秒間前進」というプログラムを書いていたわけだ。
　ちなみに、「とりあえず、1000でいいんじゃね?」と無責任な発言をしたのは、僕だ。すまん。(気づけよ >> ぢぶん)

　ここで、時間になったので、メンバー交代。
　ループとsleepの引数を適当に変更したら....、おお、ちゃんと回るし。
　ただ、惜しいことに、微妙に1周しない。むむう。
　さらに適当に...いや、適切に変更したら、ほぼきれいに1周。人間の勘は、あなどれない。
　さて、「8の字」と思ったところで、時間切れ。

1回目のふりかえり(KPT)
　「早めに軌道修正ができた」というプラスの面があった一方で、「作業後にTodoリストの付箋を移動させるのを忘れた。」とか、「時間管理が難しかった」という問題点が。
　実のことを言うと、Todoリストが更新されていても、自分たちの作業で手いっぱいで、ほかの人たちが何をしているのかまで見渡す余裕がないのが実態。もっと時間が欲しいなぁ。
　時間管理については、第二イテレーションでは、ドキュメント組がタイムキーパーをすることで再発を防ぐことになった。

 　本当は、「ファシリテータがどんなアドバイスをするか」とか、「どのように、アドバイスをするか」を観察するつもりだったのに、このときの僕は、工程を消化するだけで手一杯。
　「さすが、良いところで、声をかけるなぁ」と感心したのは覚えているのだけれど、メモひとつとっていない体たらく。使えないぞ、オレ。

第二イテレーション
　新しい課題に挑戦しても良かったのだけれど、「8の字」にこだわることに。
　「せっかくなので、subversionでバージョン管理も」とトライするも、LANが不調でIP取得に失敗し、何度かトライしたものの、失敗。
　「なに、円が描けたのだから、同じことをやれば8の字に」という下心あり。
　動かしてみたら、なんか、微妙に違う...。紙からはみ出すと、摩擦係数が変わってしまうので、モーターのON/OFF時間だけでは、回転角が正確に測れないっぽい。
　もしかして、左右のタイヤのサイズが微妙に違って、まっすぐに走っていないっぽい。このほかにも、電池が足りなくなると、いろいろ、あるらしい。おしいなぁ。
    で、プログラム組は、よりきれいな円を描けるように、パラメータの調整に入る。
    ドキュメント組は、発表用の資料作成。

ふりかえりとまとめ
時間が押せ押せになってしまって、大慌てでふりかえりを。

「せっかく作ったプロジェクトページが使われなかった」「ツールの使い方を知らなさすぎた」(「若者と作業するときは、昔ながらのコンパイルコマンドとmakeではいかん」と実感。「IDEの使い方くらいは、予習しておかなくちゃ」ってことだ。)などなど、反省点も多かったものの、目標はひとつづつクリアしたし、最後は8の字走行できたしで、まずまずといった感じ。
　「それにしても、もっと時間が欲しいね」が全員の感想。ただ、1日いっぱいXP体験にしてしまうと、「XPまつり」ではなくなってしまうのが困ったところ。

　ちなみに、ファシリテータからは、「8割は、顧客のための作業。残り2割をリファクタリングやドキュメント作業などのチーム作業に使うと、良い感じ」というお話あり。
　「そうだよなぁ」と感心しながらも、その「2割」の時間を作れないのが、僕が仕事ができない理由。要努力。

　ちなみに、僕たちのグループのファシリテータは、あのt-wadaさんだったのでした。あんなすごい方にアドバイスいただけるなんて...。サインもらってくれば良かった...。

他のチームの作業
    かるあ のメモ    http://karua.at.webry.info/200709/article_1.html


Lightning Talk
　「XP体験」で、ちょっとヘロヘロだったので、メモを見ても、なんだか、よくわからん...。


○ 伊藤さん[資料]
ロックとXPは、似ている。
音楽に、多くの音はいらない。XPに必要なものも、3つだけ」をはじめとして、いくつかの共通点あり。

○ 渋川さん
「プレゼン資料、ちゃんと届かなかったようで」と、話だけのLT。みんなが唖然とする中、淡々と話をされる。
あまりにびっくりしたので、これしかメモしてない...。
すごく面白い話だったのは覚えてるんだけど、なんだったっけ....。

○ 福重さん[web]
SCRUM + XPの実践レポート。

○ あまのりょーさん[web][資料]
「今日は、出版社の回し者」ということで、『アジャイルレトロスペクティブズ』の宣伝を。
国際ふりかえり学会( mixi://view_community.pl?id=759652 )の紹介も。

○ 高橋さん
sayori.NETというORマッパのお話。最年少共演者登場!すげぇ。

○ 五十嵐さん[web][資料]
「思いやり駆動」と「ベアプロ」のお話。「わはは」っていう感じだけど、「声に出して説明することで、頭の中で整理される」は、正しいなぁ。

○ 木下さん[資料]
        「僕らのカンバン方式」というタイトルで、タスクカードから感じ取る「不吉な気配」について。


○ 角谷さん
TDD10ヶ条
  1. インタフェースに対してプログラミングしているか?
  2. Singletonやstaticなメソッドの扱いは、適切か?
  3. privateに、思い入れを持っていないか?
  4. コンストラクタ引数に、コラボレータを渡したい気持ちになるか?
  5. 小さいメソッドが好きか?
  6. 仕事を引き継いだ時は、コメントよりテストコードを探すか?
  7. 自分の書いたコードの最初のユーザーは、自分か?
  8. 「最適化」を言い出すのは、テストをそろえてからか?
  9. テスト全体の実行速度に気を配っているか?
  10. 依存関係を少なくすることに気を配っているか?

○ 角野さん
 「ぼやき」は、とても大切。
 ぼやき続けると、そのうち、「これじゃあ、だめだ。どうするか、考えよう」という気持ちになる。
 で、その実践として、上司がいない間にフロアレイアウトを勝手に変えてみた。
え～っ!

文書履歴

    2007/09/03 : Version 1.0

このページの扱いについて

イベント参加時のメモを元に作成しました。内容については、まちがいが無いように努力していますが、 誤解、聞き違い、表現能力、勉強不足などにより、事実と違う場合があるかもしれません。 もし、まちがいと思われる部分がありましたら、指摘いただけると幸いです。
なお、内容については、必要に応じて訂正されたり削除されることがあります。

Published 2007年9月4日 17:43 投稿者 takuya
タグ: , ,

コメント

コメントはありません