XP祭り関西2013のメモ
2013/04/26に行われた、XP祭り関西に参加してきました。あたりまえだけど、XP祭り関西2012から一年経ったんですねー。
月日が流れるのは早いものだ（しみじみ
箇条書きでメモったのをだらっと貼っとくます。
アジャイルの夢を現実に！ - プラクティス・プラクティス -
さかばさん
- あれもこれも一度にしない
- 優先順位を付けてやるのがアジャイル
- プラクティスの導入もそれでやろう
- パレートの法則(大きな問題は全体の2割)
- 小さな労力で大きな効果を生む
- プラクティス
- プラクティスが目的ではない
- よりよくするために……
- *信頼貯金*
- 成功するところを見極めて改善する
- ツール
- 不安なものを挑戦していれるのは避ける
- ツールは大きなものほど効果が高い
- 実現のイメージ
- このグラフいいなー。
- 壁を越えるプラクティスは一時的に効果が落ちる
- 沢山のものを入れないと効果が薄いものもある
アダプタブル・ウォーターフォール
相性の良いプラクティスを紹介
- 複数リリース
- リリース後の修正が多い場合に有効
- 普通の請け負い開発でも有効
- 変化を受け入れて管理する（ITS）
- 問題が多い場合
- Excelでもある程度は上手く行く
- 急激な変化に対応しづらい
- 問題が増えたり、人が増えたり
- リスクベースの計画
- プロジェクトの炎上に対して有効
- 開発容易順（手の付けられるところ）ではなく
- リスクが減少する順序でやる
- 最終決定時点（リーンの用語）
- 自立的組織と集中
- やらされ感が多いときの
- ボトムアップ見積もり（プランニングポーカー）
- 朝会などで *自分で発言してコミット* する
- サーバントリーダーシップ
- エライヒトとエラソウナヒトは違う
- ワークフロー
- 指示系統の防火壁を作る
- ドキュメントの軽量化
- ドキュメントの負担が多い問題
- **予め最初に確認しておくこと**
- 打ち合わせにはワークシートなど……
- ネゴをとるのは超重要
- コミュニケーションと情報共有
- 何年たってもこれが失敗事由のトップであり続けている
- お菓子とか良い
- ツールの導入
- 我々の仕事はなんだ？（紺屋の白袴）
- 難しいプラクティス
- 常時のペアプロ&TDD: 最初はハードルが高い
- オンサイト顧客: 場所、時間
- スコープ変更: 請負→段階契約などで補完する
まとめ
- 最近は（アジャイルの）時は迫ってる
- お客さんが言い出した時を逃さない
- 時に備えて準備する
- 信頼貯金をためる
チケット駆動開発をパターン言語で読み解く
あきぴーさん
- ツールの説明を排除
- プラクティスをパターン言語の形式で表現
- 原則・価値観・プラクティスでまとめる
原則
- 最初にチケットありき(TicketFirst)
- *完全チケット方式*
- 成果物は構成管理に従う
チケットとは何か: なんらかのプロセスを管理するもの
パターンの適用例
チケットの粒度に関する問題
- 曖昧なチケット
- チケットってなんなの？
- 障害管理表の延長
- チケットってなんなの？
- 肥満児チケット
- おおきくても２−３日
- 当初の見積もりの倍以上かかったもの
- 放置されたチケット
- 基本的にはあふれんばかり登録する
- 期限が「今すぐ」のチケット
これらは複数のプラクティスで解決する必要がある
開発のリズム
リズミカルに開発出来る。体験しないとわからない。
- チケットの作業に集中出来る
- コミットのリズムができる
- 持続可能な開発チームでしか作業出来ない
- 定期的なイベントで検査
TiDDは自発的行動を促す
- 教育的な効果（自己管理する勇気の基盤）
- リーダーは管理者から支援者に
まとめ
- みんな色々知ってるはず。
- その状況に応じたプラクティスを持ち寄って、経験値から本質を取り出したい。
- プラクティスは複数を組み合わせて効果が出てくる
- それぞれのプラクティスをどう組み合わせるか？
- 10個から20個出す必要がある
- チケット駆動のパターンの勉強会とかやりたい
「初めてのアジャイル開発」- 我々はどのようにアジャイルを実践したか-
きとらさん
なぜAgileか
- ２年経ってるけどまだ完成系がわからない
- 単純にやってみたかった
- メンバー的にいけるとおもった
後ろ二つが何気に重要。モチベーションとか特に。
誰もが気に入るわけじゃない。
ランチや飲み会での親交が重要だったりする。一緒にランチ行くようにしてうまく回るところも。
スクラムの話
- インセプションデッキ
- What: プロジェクト憲章に近い
- モチベーションの高める方法
- 三人の石切工の話: さらに高次の解答もあるだろう
- 意識統一、判断基準
- ズレた質問をしなくなる
- 別の提案ができる
- スプリント計画ミーティング
- What
- Part1: 何をするか
- Part2: タスク分解、見積もり、大雑把な設計
- Why
- 意識統一、多方向の視点、レビュー
- 結果として手戻りを減らせる
- Knowledge
- 出来る限り設計の話ができる
- タスクを分割する。依存関係を確認。
- 工数は小さい方が見積もり精度は高い。
- What
- デイリースクラム
- Why: 問題の早期対応・解決
- ざっくり確認する場
- Knowledge
- 報告会や、言っても言わんでも同じようなものになりがち
- タスクボードの前で話すのがいい
- 問題解決は**別の場**でする: ファシリテート重要
- 関係無い人が興味を失っていく
- 報告会や、言っても言わんでも同じようなものになりがち
- Why: 問題の早期対応・解決
- プランニングポーカー
- 必要であればスプリント計画ミーティング中にやったりもする
- What: 相対的かつおおざっぱな見積もり
- Why: 複数人の意見が混ぜられる。見積もりやすい。
- Knowledge
- 基準は使い回す: 基準を決めるのは時間がかかる
- カードはあった方がいい: 出さざるを得なくなる
スプリント内
- ペアプロ・ペアレビュー
- TDD
- Why
- 設計が綺麗になる傾向がある
- トータルコストの減少: テスタビリティの確保
- Knowledge
- テスト名やテストメソッドのコメントに仕様を書く
- 一つのテストであまり多くを確認しない
- Why
- ふりかえり
- Why: 生産性の向上
- Knowledge
- KPTよりGood/Badを事実ベースで洗い出した方がいい
- 継続的デリバリー
- Why
- 誰でもデプロイできる
- 割り込みタスクになるから
- お互い気を使ってやりづらかったりする
- 早くなる
- 誰でもデプロイできる
- Knowledge
- 可能な限り早く手をつける
- 段階的でいい
- 利益を得られる期間が長くなる
- アーキテクチャ設計時から考慮するべき
- 本来するべきでない苦労をするようになる
- 可能な限り早く手をつける
- Why
#京アジャ 春の特別出張編 @ XP祭り関西2013
いつもの #京アジャ を100人でやってました。
→http://xn--cck1b7gr48j.net/blog/2013/04/27/xpfes2013/
プラクティスって何だろう。
スクラム道関西
第1部: スクラムマスターの実践事例
第2部: 実際のところどうだっけ
- レトロスペクティブのマンネリ化
- 過去のを持ってくる: 気分転換
- やめちゃえば？
- チームからまた「やろう」と言うのを待つ
- なるべく疲れないやり方を
- スクラムのきっかけ
- 必要に迫られて: 走りながらやるしか無かった
- 数ヶ月先を読んで計画なんて出来ないから
- 他に方法が無かった
- スクラムの感想
- 「システム作るのってしんどい」
- 非アジャイルだと要件定義が一番大変
- 終わった時には忘れてる
- レビューやらを都度やらなきゃだから大変
- 「やっとウチのシステム作ってる気になった」: 実感を伴える
- 完成した事に驚かれる
- 情シスの人が「俺達要らないじゃん」とか……
- 「システム作るのってしんどい」
- どんな手順でスクラムを導入するか？
- POをどう助けるか？
まとめ
- 実践し、失敗し、解決する
- チームが自力で抜け出す
- 練習する
