20110924 アジャイル本読書会
申込み
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円
- お題: アジャイルプラクティス読書会
はじめに&自己紹介
はじめての人が二人いたので、自己紹介詳しくしました。
前回の「試してみよう」を確認しよう
○ 申込みサイトすぐ作る → 次の週にはできていた!
× 人を増やしたい → 人は増やせんかった…
× 終ったら割る → 風船わすれちゃった…
? 早くサーバー借りてほしい→欠席のため不明
読書会内容
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 顧客に決断してもらう(未達) ふりかえり 次回の日程