読者です 読者をやめる 読者になる 読者になる

日々常々

ふつうのプログラマがあたりまえにしたいこと。

XP祭り関西2013のメモ

イベント

2013/04/26に行われた、XP祭り関西に参加してきました。あたりまえだけど、XP祭り関西2012から一年経ったんですねー。

月日が流れるのは早いものだ(しみじみ


箇条書きでメモったのをだらっと貼っとくます。

アジャイルの夢を現実に! - プラクティス・プラクティス -

さかばさん

  • あれもこれも一度にしない
  • 優先順位を付けてやるのがアジャイル
    • プラクティスの導入もそれでやろう
  • パレートの法則(大きな問題は全体の2割)
    • 小さな労力で大きな効果を生む
  • プラクティス
    • プラクティスが目的ではない
    • よりよくするために……
  • *信頼貯金*
    • 成功するところを見極めて改善する
  • ツール
    • 不安なものを挑戦していれるのは避ける
    • ツールは大きなものほど効果が高い
  • 実現のイメージ
    • このグラフいいなー。
    • 壁を越えるプラクティスは一時的に効果が落ちる
    • 沢山のものを入れないと効果が薄いものもある
アダプタブル・ウォーターフォール

相性の良いプラクティスを紹介

  • 複数リリース
    • リリース後の修正が多い場合に有効
    • 普通の請け負い開発でも有効
  • 変化を受け入れて管理する(ITS)
    • 問題が多い場合
    • Excelでもある程度は上手く行く
    • 急激な変化に対応しづらい
    • 問題が増えたり、人が増えたり
  • リスクベースの計画
    • プロジェクトの炎上に対して有効
    • 開発容易順(手の付けられるところ)ではなく
    • リスクが減少する順序でやる
    • 最終決定時点(リーンの用語)
  • 自立的組織と集中
  • ドキュメントの軽量化
    • ドキュメントの負担が多い問題
    • **予め最初に確認しておくこと**
    • 打ち合わせにはワークシートなど……
      • ネゴをとるのは超重要
  • コミュニケーションと情報共有
    • 何年たってもこれが失敗事由のトップであり続けている
    • お菓子とか良い
  • ツールの導入
  • 難しいプラクティス
    • 常時のペアプロ&TDD: 最初はハードルが高い
    • オンサイト顧客: 場所、時間
    • スコープ変更: 請負→段階契約などで補完する
まとめ
  • 最近は(アジャイルの)時は迫ってる
  • お客さんが言い出した時を逃さない
  • 時に備えて準備する
  • 信頼貯金をためる

チケット駆動開発をパターン言語で読み解く

あきぴーさん

  • ツールの説明を排除
  • プラクティスをパターン言語の形式で表現
  • 原則・価値観・プラクティスでまとめる
TiDDよく聞かれる質問
原則
  • 最初にチケットありき(TicketFirst)
    • *完全チケット方式*
  • 成果物は構成管理に従う

チケットとは何か: なんらかのプロセスを管理するもの

パターンの適用例

チケットの粒度に関する問題

  • 曖昧なチケット
    • チケットってなんなの?
      • 障害管理表の延長
  • 肥満児チケット
    • おおきくても2−3日
    • 当初の見積もりの倍以上かかったもの
  • 放置されたチケット
    • 基本的にはあふれんばかり登録する
    • 期限が「今すぐ」のチケット

これらは複数のプラクティスで解決する必要がある

  • No Ticket, No Work
    • パラダイムシフトが起こる
    • コスト、納期、品質にスコープがはまる
      • チケットで調整する……?
      • チケット=スコープ
      • この取捨選択を行う
      • 変化に強いタスク管理ができる
  • No Ticket, No Commit
    • 重要なのはイテレーションの考え方
      • チケットのグルーピング
      • まとめで閉じるのがこれ
      • アナログだとやり辛い?
  • Iteration is Version
    • イテレーションはバージョンに同一視
    • 小規模リリース(XPの概念)
    • 数えると消化チケット数(Velocity)は安定する
    • リーマンの法則?
      • チームの人数を増やしても生産性は変わらない
開発のリズム

リズミカルに開発出来る。体験しないとわからない。

  • チケットの作業に集中出来る
  • コミットのリズムができる
  • 持続可能な開発チームでしか作業出来ない
  • 定期的なイベントで検査
TiDDは自発的行動を促す
  • 教育的な効果(自己管理する勇気の基盤)
  • リーダーは管理者から支援者に
まとめ
  • みんな色々知ってるはず。
  • その状況に応じたプラクティスを持ち寄って、経験値から本質を取り出したい。
  • プラクティスは複数を組み合わせて効果が出てくる
    • それぞれのプラクティスをどう組み合わせるか?
    • 10個から20個出す必要がある
  • チケット駆動のパターンの勉強会とかやりたい



「初めてのアジャイル開発」- 我々はどのようにアジャイルを実践したか-

きとらさん

なぜAgile
  • 2年経ってるけどまだ完成系がわからない
  • 単純にやってみたかった
  • メンバー的にいけるとおもった

後ろ二つが何気に重要。モチベーションとか特に。
誰もが気に入るわけじゃない。
ランチや飲み会での親交が重要だったりする。一緒にランチ行くようにしてうまく回るところも。

なぜScrumか
スクラムの話
  • インセプションデッキ
    • What: プロジェクト憲章に近い
    • モチベーションの高める方法
      • 三人の石切工の話: さらに高次の解答もあるだろう
    • 意識統一、判断基準
      • ズレた質問をしなくなる
      • 別の提案ができる
  • スプリント計画ミーティング
    • What
      • Part1: 何をするか
      • Part2: タスク分解、見積もり、大雑把な設計
    • Why
      • 意識統一、多方向の視点、レビュー
      • 結果として手戻りを減らせる
    • Knowledge
      • 出来る限り設計の話ができる
      • タスクを分割する。依存関係を確認。
      • 工数は小さい方が見積もり精度は高い。
  • デイリースクラム
    • Why: 問題の早期対応・解決
      • ざっくり確認する場
    • Knowledge
      • 報告会や、言っても言わんでも同じようなものになりがち
        • タスクボードの前で話すのがいい
      • 問題解決は**別の場**でする: ファシリテート重要
        • 関係無い人が興味を失っていく
  • プランニングポーカー
    • 必要であればスプリント計画ミーティング中にやったりもする
    • What: 相対的かつおおざっぱな見積もり
    • Why: 複数人の意見が混ぜられる。見積もりやすい。
    • Knowledge
      • 基準は使い回す: 基準を決めるのは時間がかかる
      • カードはあった方がいい: 出さざるを得なくなる
スプリント内
  • ペアプロ・ペアレビュー
    • 情報共有
    • 生産性(速度+質)向上
      • どちらか一方では生産性と言えない
    • 学習効果: 知識レベルの差が大きい時に効果は特に大きい
    • Knowledge
      • デイリースクラムなどで時間を決める
      • 意識して休憩しないと死ぬ
      • Wikipediaを読みはじめたりしなくなる
  • TDD
    • Why
      • 設計が綺麗になる傾向がある
      • トータルコストの減少: テスタビリティの確保
    • Knowledge
      • テスト名やテストメソッドのコメントに仕様を書く
      • 一つのテストであまり多くを確認しない
  • ふりかえり
    • Why: 生産性の向上
    • Knowledge
      • KPTよりGood/Badを事実ベースで洗い出した方がいい
  • 継続的デリバリー
    • Why
      • 誰でもデプロイできる
        • 割り込みタスクになるから
        • お互い気を使ってやりづらかったりする
      • 早くなる
    • Knowledge
      • 可能な限り早く手をつける
        • 段階的でいい
        • 利益を得られる期間が長くなる
      • アーキテクチャ設計時から考慮するべき
        • 本来するべきでない苦労をするようになる

#京アジャ 春の特別出張編 @ XP祭り関西2013

いつもの #京アジャ を100人でやってました。
http://xn--cck1b7gr48j.net/blog/2013/04/27/xpfes2013/

プラクティスって何だろう。

スクラム道関西

  • スクラム道関西
  • プラクティス
    • 辞書的意味
    • 学ぶだけで考えないのもだめ、考えるだけで学ばないのもだめ
第1部: スクラムマスターの実践事例
  • 仕様が曖昧でPOが問いつめられる
    • POは大変だけど協力は求められる
  • アイテムを分割できるようになろう
  • 作業の計画が細かすぎる
    • 細かすぎて計画に時間がかかる: 粗くする
  • デイリースクラム
    • 報告会を避ける: 寝てしまえばいい
  • スクラムマスターは壁が好き
    • 壁が小さい、字も小さい: ペンを持とう
  • レビュー
    • 「チームが頑張ったのでOK」は無し
    • それ出荷するの?: 冷静に。
  • レトロスペクティブ
    • スクラムマスターが欠席したら険悪なムードになった
      • こまめな喧嘩はした方が良いかも
    • 大切な問題が出ない、対策が適切でない
      • スクラムはチームが改善を選択する
      • 誰にとっての適切?
    • ふりかえり手法も色々ある
      • 555(トリプルニッケルス)
      • ヒーローインタビュー
      • KuboBox: Management3.0
    • 自発的な改善を促す
第2部: 実際のところどうだっけ
  • レトロスペクティブのマンネリ化
    • 過去のを持ってくる: 気分転換
    • やめちゃえば?
      • チームからまた「やろう」と言うのを待つ
      • なるべく疲れないやり方を
  • スクラムのきっかけ
    • 必要に迫られて: 走りながらやるしか無かった
    • 数ヶ月先を読んで計画なんて出来ないから
    • 他に方法が無かった
  • スクラムの感想
    • 「システム作るのってしんどい」
      • アジャイルだと要件定義が一番大変
      • 終わった時には忘れてる
      • レビューやらを都度やらなきゃだから大変
    • 「やっとウチのシステム作ってる気になった」: 実感を伴える
    • 完成した事に驚かれる
    • 情シスの人が「俺達要らないじゃん」とか……
  • どんな手順でスクラムを導入するか?
    • 「私に発注してください」(笑)
    • アジャイルなんて特別なことじゃない
      • 社会人に教えるのは厳しいから「子供に戻す」
      • ワークショップやれば普通の事だと気付く
    • 時間もらってアジャイルの説明をする
    • 外のコミュニティに誘う
  • POをどう助けるか?
    • プロダクトバックログが作れないPO
      • そのままスプリントが始まってしまう?
        • 一つのチームは水着に着替えて遊びに行く
        • もう一つのチームはスキーに行く
      • スクラムは「チームは仕事をしてはいけない」が結論
    • POの仕事は本当に大変
      • わからないのに闇雲に薦めるはしてはいけない
      • 必要ならPOにリソースを割り当てる
    • チームに好きな事をやってもらうスプリントを作る
まとめ
  • 実践し、失敗し、解決する
  • チームが自力で抜け出す
  • 練習する