XP祭り関西2012 に参加
行ってきました。
XP祭り関西2012〜技術指向で行こう！〜
http://www.xpjug.jp/cgi-bin/main_wiki/wiki.cgi?page=XP%BA%D7%A4%EA%B4%D8%C0%BE2012
- 日時：2012年04月07日(土) 10:30〜17:00
- 場所：福島区民センター
- 公式Twitterタグ：#xpfes12
- 当日のつぶやきまとめ：http://togetter.com/li/285031
開会
会場を大きく３つに分けて「やるぞ！」「XP！」「技術志向で！」の3ポーズを行い、最後に全員で決めポーズwww
これが関西のノリかと先行き不安になった。
「アジャイル開発の計画と管理」 by 梅田 弘之さん
- アジャイル開発における計画と管理
- 自己紹介
- 自社はERPパッケージを中心に開発
- 目的
- 請負開発とプロダクト開発/社内開発
- 契約形態
- 一括請負はやりにくい。
- 変更前提なのでスコープが確定しない。
- 場所
- 場所が離れているなら、skype等のネット会議を利用する。
- 一括請負はやりにくい。
- 品質・スコープ・コスト・納期
- プロダクト開発では、スコープを犠牲にする。
- 請負開発では、コストを犠牲にする。
- プロジェクト管理の基本を知っておく
- PMBOKの功績
- プロジェクト管理のモヤモヤを整理した
- 9の知識エリアと5つのプロセス
- 管理の重要さを提案
- QCDの為に何を管理すべきか
- プロジェクト管理のモヤモヤを整理した
- PMBOKの課題
- あくまで知識なので、そのまま現場では使えない
- 個々のプロジェクト管理のみで、組織の管理まではカバーしない。
- 9の知識エリアをバラバラに解説している
- 相互の関連性があるので、そこを押さえないと合理化できない。
- CMMIモデル
- 以降、PMBOKの９つの知識エリアベースで解説(全部ではない)
- 統合管理
- 大きな分類
- プロジェクトの登録
- プロジェクトの変更
- プロジェクトの終結
- レビューの実施と結果記録
- 失敗原因の記録と改善活動
- プロジェクト完了報告書
- 大きな分類
- スコープ管理
- スケジュール管理
- コスト管理
- プロジェクトのコスト
- スコープベース
- 原価見積
- リソースベース
- 作業見積
- スコープベース
- プロジェクトのコスト
- 品質管理
- リソースベースの見積
- 最初の見積は機能ベースで行う。
- リソースベースの見積
- 要員の管理
- まとめ
- アジャイルにしたらプロジェクト管理が手を抜ける
- ということはないなあ。
- アジャイルにしたらプロジェクト管理が手を抜ける
- 自己紹介
会社の経営視点からの、アジャイル開発への取り組みと、アジャイル開発におけるプロジェクト管理方法についてのお話。
- 感想等
アジャイル開発におけるプロジェクト管理の部分って自分でもモヤッとしていて、その辺については勉強しないといけないなと思っている所。アジャイル開発って基本的に開発者寄りなので、作業の管理についてはアジャイルプラクティスでも考慮されているけど、予算の管理に関するプラクティスってあまり聞かない。その辺が以前のAgile Charity Event in Osakaのパネルディスカッションで質問したかった事だったんだなと思ったり。
-
- d:id:youandi:20110429:p2(Agile Charity Event in Osaka)
- d:id:youandi:20110924:p1(関西Kinect勉強会)
- その質問内容について再考している
あと、経営的な話でちょっと気になったのが、「脱Excelによるプロジェクト管理」で梅田さんの会社で開発を行っているプロジェクト管理用のアプリケーションを見ていたのですが、なんかこのツール人事考課にも使えそうというかそういった機能もありそうだなと思ったりもした。
とりあえず、自分に足りないのはPMBOK等のPM系の知識かなぁと思った。最近PMI中部の方では勉強会が活発になってきているようなのでそちらにお邪魔するかもだなー。
1-2 TDDルーム
「TDDサイクルを加速する技術たち」by [twitter:@irof]さん
-
- 技術って何だろう？
- コンテキスト合わせの質問。「最新技術」って何だろう「ツール」か？
- TDDの認識についてディスカッション(5分)
- テーブルの奇数番目の列の人が後ろを向いて最大6名でディスカッション
- 質問：TDDについて、
- 知らない
- 知っている
- テストコードを書いている
- やったことがある
- やっている(なんとか/普通)
- やめた(諦めた/止めた)
- ディスカッション内容
- テスト仕様書を書いている人がいらっしゃり、TDDやるにしてもその準備が必要だし、テスト仕様書まで書いているならそれに加えてTDDをやるというのは、工数が増えるだけになるかもという話をした。
- あとTDDのやり方が分からないって人もいらっしゃったので、三原則の話や、大阪でTDDBCを5〜6月にやる予定ですよと紹介した。
- 解説
- irofさんのイメージするTDDの図を紹介
- TDDの目標
- 「動作するきれいなコード」についてディスカッション(5分)
- きれいなとは？
- きれいだと何が嬉しい？
- まずは、教科書通りの答えを提示して「要求通りの実装が行われていて、リファクタリング済みであるコードの事」そこからディスカッションを始めた。
- 流用コードだったり、他人が書いたコードって読みやすい物と、読みにくいものもありますね。
- 自分が昔書いたコードですら読めないものもある。
- まとめの時間の前にまとまっていたので、アジャイルマインド同人誌って、他の訳書と違って日本人が日本の現場について書いている本ですよと紹介したら、休憩時間に買いに行った人がいたみたい。
- 自分達のまとめ
- テストが書きやすい(テスタビリティ)が意識されたコード。
- 他のテーブルの意見
- シンプルで読みやすい
- 保守しやすい/読みやすい→残業が減る
- 前知識無しで理解出来る(書いた人の思想が分かる)→引き継ぎしやすい
- 解説
- きれいなコード
- 驚きのないコード
- あるべくしてそうなっている
- 短いわけでも巧妙でもない
- コードは読み物
- コードの嫌な臭い
- きれいなコード
- 「動作するきれいなコード」についてディスカッション(5分)
- 「変化に耐えられる物は何か？」でディスカッション(5分)
-
- まずは教科書通りに「テストがあること」という所からディスカッション開始。
- 自分達のまとめ
- シンプルである事(コード量・メソッド数等)
- 設計レベルで機能が分けられている事(ドメイン分け)
- 解説
- 変化し続けるものは変化に強い。
-
- 以降、時間切れでかなりの早口だった。
- オレオレTDD
- 技術って何だろう？
- 感想等
TDDBCの紹介はちょっと違う気がした。主に和田さんの所。和田さんがいないとTDDBCにならないようにも聞こえた。TDDBCの本質って違う所にあると思うんですけど。TDDについての知識を学び、それを体験・実践する流れにあるのかなと。
ちょっとどんな内容になるかイメージ出来てなかったけど、TDDについて知らない人には一端が理解出来たのでは。私個人としてはirofさんの考えるTDDについてのイメージが掴めたかな。それに同意するかどうかは別としてw
2-2 事例発表ルーム
「大規模なゲーム開発をスクラムで」by 田口 昌宏さん([twitter:@masahirotaguchi])
-
- 自己紹介
- http://www.dimps.co.jp勤務
- スト４、メタルスラッグ等の開発に携わった
- ゲーム開発の流れ
- スクラム開発の説明
- 事例紹介
- プロジェクト内容
- ハイエンド(PS3, XBOX360)
- マルチプラットフォーム
- 対戦格闘ゲーム
- チームは100名規模
- ゲーム開発においてもかなりの大規模
- Scrum導入
- ここからは時系列的な説明に
- チーム構成
- チーム構成
- UIチームの追加
- コミュニケーションの問題
- 1日において全く話す機会がない
- 対応
- 朝会を導入
- 15分。他チームの情報も得られるように開始時間をチーム毎にずらした。
- 朝会を導入
- スケジュール管理
- 情報へのアクセスが面倒
- 人によって更新頻度のばらつき
- 対応
- タスクボードを導入
- チーム全員が進捗を更新するように。(タスクは各位で自由に追加)
- 作業の把握が出来るように
- かしこまったミーティングの現象
- 他チームの興味を惹いた
- タスクボードの整備
- 広い場所を確保した
- 自然と人が集まるようになった
- プランニングの導入
- 互いの作業の把握
- 3〜4時間で精度の高いスケジュールが出るようになった
- レビューの拡大
- 各パートのリーダーと興味のある人が参加
- 担当パートを超えた意見交換
- チーム構成
- 2Dアーティストとゲームデザイナーが各チームに参加
- 今までの取り組みが見える化されていたおかげか、あまり抵抗なく参加できた
- 2Dアーティストとゲームデザイナーが各チームに参加
- プロダクトバックログ
- 残作業
- プランニングが効果的に
- ディレクターがプロダクトオーナーの役割を担うようになってきた
- チーム構成
- 10名を超えたのでチームを分割
- バトルUIチーム発足
- スクラムマスター2名体制へ
- チームが増えた事での問題
- 別々のチームで同じタスク
- 別のチームの作業と思い込み、全く手が付けられないタスク
- 対応
- プランニングのスケーリング
- チーム代表でプランニングしてから各チーム毎に
- プランニングポーカーの導入
- プランニングのスケーリング
- キャラクタ制作グループの改善の必要性
- プロジェクト内容
- 運用して分かった事
- 小さく始める
- うまくいかずに止めるにしても無駄にするのは1イテレーション(2週間)で済む。
- 小さく始める
- 挑戦
- これからScrum導入を検討する人へ
- 朝会
- 上長に向かって話さない
- プロジェクトファシリテーション実践編朝会ガイド(PDF)
- タスクボード
- リアルタイム性
- 壁の解像度はとても高い
- タスク完了の定義を決めて共有する事
- 自己紹介
- 感想等
事例発表って結構退屈なものが多かったりしますが、今回のはとても良かった。説明がうまかったのか、流れが良かったのか、その理由について考えてみたけど思いつかない・・・。
「継続的インテグレーション環境を作れ！(Jenkins編)」by 神谷 厚輝さん([twitter:@kami_teru])
-
- 自己紹介
- 最近は勉強会で電源タップ係をやっている
- CIの定義
- http://objectclub.jp/community/XP-jp/xp_relate/cont-j
- ハートと時間
- 最も身近な所から始めよう
- Examples
- devst_naniwa
- github + ant + heroku
- Jenkinsでtopicブランチのマージ
- devst_awaji
- kk-brains.jp
- subversion + ant
- テストが通った場合にのみコミットするのが難しい
- devst_naniwa
- 自己紹介
- 感想等
肝心の事例の部分の説明がなっていなかった。居眠りしてしまうかも？って仰っていたけど、自分も寝たし、隣の人も寝ていた。
事例の部分では処理やデータの流れをちゃんと説明して欲しかった。
LightningTalks
5分間、時計見るの禁止ルール。
[twitter:@Posaune]さん
京都アジャイル勉強会のスタッフ。
京都アジャイル勉強会で行ったプランニングポーカーのワークショップについての紹介だった。LTは途中で時間切れ。
- 感想等
プランニングポーカーのワークショップにはとても興味がありますね。
あとIDの由来が分かった。ドイツ語でトロンボーンの事なのか。
クロージング
拍手で締め。
懇親会
色々と勉強会の予定があってお金無いのでパス。
