Developers Summit 2011 行ってきた！

セミナー

ある日突然上司から「デブサミ行く気ない？」と言われたときはデブですいませんと思ったものでしたが締切直前に滑り込みで登録、満席のセッションを目にさらしてアジャイル開発だけに的を絞って登録――というプロセスを経て本日行ってきました。スーツが多かった（感想はそれか）。明日は行く予定がありません……ははは。明日はTDD関連があるからちょっと興味はあるんだけどあえて今日にしたんですよ。ははは。
興奮覚めやらぬうちにとりあえず書いとく。しかしTwitter実況があるから入れなくてもかぶって入れなかったとしても結構普通に内容がわかるのなー。ありがたい時代だ。
http://twitter.com/#!/search?q=%23devsumi
続々と資料うｐられ中。録画動画なども。これ会場行かなくてもいいんじゃね？（んなーこたない

  • 17-B-2:アジャイル開発実戦　→かんそう：うちの上司もその上司もアジャイルに乗り気だからなー品証ていうかISOだけじゃね、問題は
  • Jum Session: G*　→かんそう：うおお空気読めてなかったかもでも面白かったし冊子ありがとうございます！これから読みます（マテ
  • 17-B-5:今そこにあるScrum　→かんそう：やっべえredmineとScrumはすごく相性がよさげなうえにおれTDD大好きだからちょいちょいとできそうなきがするけどScrumよくわかってNEEEEEEE　そしてドヤ顔に吹いた

ほか会場には入れんかったけどTwitter実況(#devsumi)＆TogetterまとめでRedmine チケット駆動開発なんかもざざっと要点は。
http://togetter.com/li/102077

個人的にはScrum面白かったー。あと昼にJum SessionでやってたTDDの聞けばよかったなぁ。なんか面白かったっぽいし。どうせ店混んでるんだからそこだけ聞いて遅れてから行けばよかったとすごく後悔。

Grooveyとか

おれは基本的にJavaを全然書かないひとなので（基本的なのは一応かけるしC#は書くので読めるは読める）あんま使う機会はなさそうだけどちょろちょろとObjective-Cぽいなーとか思ったりした。あの簡潔さ素晴らしい。C++は何かとめんどっちいんだよなー。ガベレージコレクションもねーし。あとJavaってHudsonJenkinsとの連携が良かったりEclipseのプラグインいっぱいあったりとかしてほんとに環境がいいよなー。あとテストの記述量少ないのはいいなぁ（またテストか）。関係ないけどMacbook Airの所持率高杉。

Scrum

まず俺あんまりScrumについて知らないんだけど要点を調べてみると

  • プロダクトオーナー：プロダクト責任者
  • 開発チーム
  • すくらむマスター：開発の支援者（管理者とは微妙に意味合いが違うぽい？PMに近いらしい。関係ないけどひらがなでかくとぽけもんマスターぽい


開発チームのやること：実装とテスト＆みんなで協力して問題を解決する

特色：

  • プロダクトオーナーが持ってきた要求から作業を細分化する
  • 2〜4週間で動くものができる（テストが完了する）ように計画をたてる
  • 短いスパンでの進捗確認＆効率を重視して各人が積極的に仕事をすすめる。進捗確認が終わって問題が特にないならあとは開発に集中。
  • 動くものができたら反省会をして次のスプリント（実装＆テスト）にフィードバックする（←ここ重要

XPとの違いがいまいちわからない……まぁ本質的には同じだという話だったからいいのかな。比較的プロセス側の観点から話してるだけでやること事態は同じなのかも。ちなみにひとつのスプリントに入る前に仕様ドキュメントは完成している必要があるらしい(Wikipediaより)

これはうけた。
「良くない朝会。ボソボソ喋る。チームに対して話さない。多分今日終わるはず・・・。自分でタスクを取れない。メンバーが助けを求めていても知らんぷり。」あるあるｗｗ


うちでやってる中で(Scrumではないけど割と近いことはやってる）できてないことだと、

  • チケットの細分化→これ細分化するのはいいけどちゃんと管理しないとだめだからそこら辺の話はRedmineまとめ参照。
  • タスクを取らない（もしくは自分で取る人が限られている）
  • 朝ミーティングが長い！

あたりだなーとか思いながら聞いた。あとウォーターフォールなのでやっぱり期間が長いですね。実装期間自体はフェーズ分けたりver0.xxとかにしたりして短めにするようになってるから長くても一ヶ月程度だけど、検証含めると二ヶ月はかかる計算だし、基本設計ができるまでは次に行けないしなー。まぁ基本設計と言って曖昧にごまかしている部分はあるんだけども……。

今日の話を聞く限りは作業は一日から二日で終わる粒度にまで細分化されている必要があるような気がする。「多分今日中には…」と朝ミーティングでいっているときはなんで多分…って思うのかということに関して注意が必要？なにか気になることがある、うまくいかないことがある、ボトルネックがある場合は口にしようね、って言ってた。そして周りの人は目を逸らしたりせずに一緒に解決案について考えましょう、とのこと。
朝ミーティングででた懸念事項で短い時間内で解決できない場合は、朝MT後すぐに関係者で話し合う場を設けるってのはやってないなー。ちょいちょいと先延ばしにしたり午後一で…とかになっちゃうけどまぁでもそこら辺は運用の範囲か。

あーRedmine聞けなかったのマジで残念だった……。くそー。

Redmine チケット駆動開発(俺的メモ）

要点まとめ（まとめから見る限りだけど）。後ろの記号はすでにやってるか否かです。
参考はこちら：http://togetter.com/li/102077

  • チケットは作業の漏れをなくすだけでなく，ものづくりをもうちょっと楽しくするもの　？
  • TiDDは開発プロセスの即時性・効率化に寄与する
  • チケット無しに構成管理上の変更をしない　×
  • 変更の議論をチケットとして残しておく　△（啓蒙中）
  • 完全チケット方式 1. チケットがすべての作業を管理する 2. プロセスを変更するので社内調整が必要　×
  • 補完チケット方式 1. 既存の管理は変更しない 2. こっそり始められる　○（グループ内でだけど）
  • チケット駆動による従来課題の解決: コミュニケーションのオンライン化 → 情報はRSSなどで即時に展開　△（プラグインとか必要、でもやっぱりアジャイルなら叩頭コミュニケーションも必要じゃない？）
  • 問題解決支援- チケットによるトレーサビリテイ向上，作業スコープ（今日やること・優先度とか）の明確化．XPのタスクカードのイメージ　△（人に寄るなぁ。ここら辺を意識してる人と単なる工数管理ツールだと思ってる人と）
  • フィーチャーフリーズ、リリーススプリント　（これよくわからない。フィーチャーフリーズはテストが一定値以下だったらソースコードの開発を止めることらしい。リリーススプリントはスクラムのはなし？）
  • 親チケット=ストーリー、子チケット=タスク　○
  • チケットの取捨選択が本来のマネジメント △（キャンセルとか保留とかをちゃんと使わないとですね）

見ていく限り作業の細分化をして適切な粒度のチケットをつくる必要性は感じる。多分感覚的に一日か二日でできる程度の粒度までは下げる必要があるだろうなぁ。でも三時間とかにしちゃうとものによるけど苦しい。
あと、TLで見かけた気がするんだけど、「チケットの定期的な棚卸」が必要とのこと。あるあるｗｗｗｗ

僕が基本的に個人で気をつけていることとしては

  • まず先にチケットをつくってから作業する。突発的な作業が発生したらチケットを作成してから作業する。
  • チケット進捗状況は割とこまめに変える（今どうなっているかを他の人からも分かるようにする）
  • レビュー前に一つの親のレビュー以外のチケットをすべて閉じる→レビュー反映はレビュー作業の一環なのでレビューのチケットにつける
  • ドキュメントはプロセス管理対象なのでいいんだけどコードレビューは口頭でやって指摘がなかった場合はエビデンスが残らないので、レビュー依頼チケットを出す（←New!)

テストに関しては他の人がいろいろと枠組みつくってやっているのでまだ俺はよくわかってないけど、チケット見れば全部わかるようになってるな。実はテストって結構チケット駆動と相性がいいと思うんだよなー。とかとか。