申込み

http://kokucheese.com/event/index/16778/ より 先着10名(もっと増えたら増やすのも可)

開催概要

  • 日時: 2011/09/24 10:00-12:10
  • 参加者: @ramusara, @kkd, 他1名(全三名)
  • 場所: COMS 会議室1-1 (3F)
  • 参加料: 一人300円(会場代として)
  • 会計報告: 場所代:2120円 - 参加費:900円 = 赤字:-1220円
  • お題: アジャイルプラクティス読書会

はじめに&自己紹介

はじめての人が二人いたので、自己紹介詳しくしました。

前回の「試してみよう」を確認しよう

image1

○ 申込みサイトすぐ作る → 次の週にはできていた！

× 人を増やしたい → 人は増やせんかった…

× 終ったら割る → 風船わすれちゃった…

？ 早くサーバー借りてほしい→欠席のため不明

読書会内容

3章 7. 時が来たら習慣を捨てる から続き。
ベロシティを上げるために、この会でやりたい章を列挙しておこう...

一つ30分以内ですすめよう。司会は@ramusaraさんにおねがい。

7 時が来たら習慣を捨てる

  ベテランからすると「真空管からトランジスタへの以降より後の技術革新は誤差だ」といっていた。

  C言語ひきづりながらやっている気がする。仕事でC、PrivateでPython,関数型。
  大学でC→仕事でJavaはなかなか難しい。
  「全部Publicじゃないの?」「なぜPrivateが必要なのか?」

  自分でつくったほうがいい?
    昔はORマッパとかも自分で作っていた。今はそんなことしないよね。
    フレームワークを使うことしか知らなくて、作ることができない、というのはちょっと...と感じることはある。
    結局、基盤とする技術の基礎をしっかりみにつけることが大事なのかな。

  書籍の中のエピソード:なぜJ2EEからPHPに移行したのかな?
    拡張や変更をしようとして、にっちもさっちもいかなくなって、エイヤで全体リプレースする話はよくあるね。
    システムのリプレースは思うよりずっと大変だよ。
      ドキュメントがある場合→undocumentな実装がたくさんあって役に立たないとか
      ドキュメントがない場合→ソースを読み込まないといけなくて全体像が捕みにくいとか        
      経験上、既存の実装指針が、フレームワークの設計指針に合わない場合大変だなぁ(Railsとか洗練されているものほど)

  開発マシンは早い方がいいよね。
    この本の例では、ビルドマシンの話だね。     
    この本の事例では、恐らく、ビルドマシンがないため、インテグレーションする環境が整っておらず、開発マシンでできたといってるソースをリリース直前でインテグレーションしたら、不具合が大量に見つかった、という例だろう。
    アジャイルのプラクティスで「継続的インテグレーション(CI)」があるが、これは大事。
    ビルドマシンは最強にしたほうがいい。ビルドやテスト実行に何時間もかけるようだと、問題が累積しやすい。

  開発環境は何つかってる?
    CなのでEmacsを使っている(@ramusara)
    JavaなのでEclipse使っている    
    昔はJavaはエディタ+Makeでやってたねぇ(@kkd)
    Antがでてきて、萌えた→Mavenへ(@kkd)
    Eclipseを使いはじめてから、Emacsをすてたなぁ(@kkd)
      リファクタリング機能が素敵すぎた。

  Vimは若い人、Emacsは年寄(30以上?)というのが最近の傾向だと感じている(@kkd)
  宗教戦争勃発。はたからみてるとおもろしろいよ。
    決着が付かないw

  Emacsの思想(Emacs自体がLispによる拡張の集合体、様々な点で拡張可能)は、ある意味Eclipseにも受け継がれている
    Eclipse自体がプラグインの集合体。実装はより洗練されているが、思想は似ている。

  古いのを捨てるというか、とりあえず脇に置いておいて、新しいことを取り入れるという感じじゃないかなぁ(@kkd)
    必要があれば、取り出せばいい。固執するものじゃない、ということ。

8 わかるまで質問する

  「The Fifth Discipline: The Art and Practice of the Learning Organization」→「学習する組織」
  邦訳でてるよ。アジャイルの背景にある考えが書いてある。大事。若いうちに読んでおいてほしい。
    → いきなり読むと重すぎるから、イントロ向けのWebのリソースとかを教えます(@kkd)
       
  なぜを問いつづけてますか?
    あまり問いつづけてないね。
    「そうすることが当たり前」としていることが多い。
    「なぜそう決まっているのですか?」と問うてみると、その理由が見えてくるかもしれない。
     最初にルールや標準を決めた人には明確な意図があったはず。それは尊重すべき。ただそれが現在でも通用するかは分けて考える。

  あまり「なぜですか?」と聞くとウザいよね。
    好戦的に聞くのはNGだよね。    
    素朴な疑問風に聞けばいいのでは?
    人の意見が出た時に「なぜそのような意見に至ったのですか?」と聞くことをよくする。

  一休さんの「どちてぼうや」

9 リズムに乗る

  タイムボックスは大事だよね。
  ここでは、リズム(一定周期)とタイムボックス(固定)の話をしている。

  スタンドアップミーティングが「とりあえずやっているように見える」と言われる
    「必要な時にやる」になると、そもそも必要な時の判断が個人任せになる→手遅れ、人によってバラツキがあり効果が薄れる
    リズムを刻んでやるのがまず大事。

  チケット駆動をやっているが、締切がかけてないのがある。終わらない。
    タイムボックスはタスクひとつひとつの締切というより、「これ全部を、ここまでに終わらせる」というスタイル。

  タイムボックってピンとくる? → 終わらなかったらどうするの?
    タイムボックはコミットメントではない。チェックポイントに近い。
    もちろん「全部終わらせようと最善は尽す」けれど、もし終わらなかったらその結果を受け止めて、結果を踏まえて次のタイムボックスの計画を考える。

第4章 ユーザが求めるものを提供する

  仮想的敵ってつくったことある?
    忙しい時に変更要求してくる人。
    プロジェクト中にはいない。

  Us vs Themという形ではなく、Problem vs Us、という形にどうやってもっていくかが鍵。
  誰かを敵視している状態は、なにかよくない傾向。

10 顧客に決断してもらう(未達)


ふりかえり

次回の日程