「塹壕よりScrumとXP」読書メモ (3)
前々回、前回 にひきつづき「塹壕よりScrumとXP」の読書メモです。自分用ですので全くまとまっていませんし、誤りがあるかもしれません。（まさかこんなに長くなるとは…）
スプリントバックログ（続き）
- スプリントを始めるたびにきれいなバックログが作られる（紙を張り替える）
- 重要度の高いストーリーを上に貼る
- バーンダウンチャート
- 縦軸にストーリポイント、横軸に日付を取った折れ線グラフ
- 危険な徴候
- トレーサビリティはどうなってるんだ！
- 毎日デジカメで撮る
- でも、そんなに重要じゃないはず
- 気になるならホントの価値を見積もってみよう
- 見積単位
- 1実効人日＝6実効人時
- (7や8じゃないし、ましてや10や13なんかじゃない!)
- ストーリーは時ではなく、日単位で見積もっている
- 0.5が最小
チームの部屋をどう改造するか
- 設計コーナー
- のびのびと設計できる（日本じゃ難しそうだ〜）
- 重要な設計ドキュメント、タスクボードなどを貼る
- チーム全員同席!!
- 席を移動するのはめんどい。でも、効果的なチームを作りたいなら他の選択肢はない
- 大事なこと：声の届きやすさ、目の届きやすさ、隔離されていること
- 専用の部屋があれば一番良い
- POはチームと同席すべきじゃない （近くにはいたほうがいい）？
- マネージャやコーチは、緊密に関わるべきだが、あるときは自律に任せること
どうやってデイリースクラムを実施するか
スプリントデモをどうやるか
- デモは、何があってもしなければならない。たとえできていなくても！
- 厳しいルールだが、得られるものは大きい
- 目標が毎週達成されるので士気があがる
- チーム外の人にも結果がわかる。チーム間のやりとりが発生する
- お客から生のフィードバックがある
- 確実に作業を「完了」できる (99%の未完より、少ない完了)
- チェックリスト
- 成果物がなにかを説明できてるか
- 準備に時間をかけすぎてないか（派手なプレゼンは不要）
- 美しくより、手際よく
- 技術より、ビジネス視点で
- できれば見ている人に触ってもらう
- あんまり細かすぎる話はしない
- 「10000ユーザの負荷テスト」みたいなデモできない話は、テスト結果レポートを見せて説明する、のでもよい
スプリントのふりかえりをどうやってするか
- 起こったことを明確にする。改善の大切な機会
- チームの外の部屋ではやらない
- PO＋チームで実施
- スプリントバックログを見ながら、できごとを一巡りする
- 見積と実際の速度がちがうところは、要因を分析してみる
- 次スプリントへむけてのブレスト。良かったこと、もっとよくできそうなもの、改善点 (KPT?)
- それらにチームで投票し、次にやることを決める
- チームが得たナレッジは他のチームにも共有した
- マネージャが非公式に動き、他のチームのふりかえりで広めたりした
- 問題を明確に認識さえすれば、それは自然と解決していく
- なにか不平を言うたびに新しいやり方を導入していると、みんな問題をあげるのが嫌になってしまう
- 典型的なふりかえり事項
- 「ストーリーをブレイクダウンする機会をもっと増やそう」
- 問題を認識したことで、次のスプリントでは皆がそう動く
- 繰り返し起こるならスプリントの期間を長くする
- 「外部の邪魔が多い」
- フォーカスファクタを低くする
- 邪魔する人をメモっておく
- スクラムマスタかPOを通すよういっておく
- 持ちまわりで「ゴールキーパ」を設定し、そこに全部の邪魔を流すようにする
- 「仕事抱えすぎた」
- 「作業環境がうるさい、汚い」
- 環境を改善するか、いっそ移動する。上位管理者への働きかけ
- （これは気にする人と気にしない人の同居がむしろ問題になったなー、自分の場合）
- 「ストーリーをブレイクダウンする機会をもっと増やそう」
スプリント中の休憩期間
- 休まないと死ぬる
- スプリント間に休憩期間がまったくないと、チームもPOも情報を整理する期間がなくなってしまう
- スプリント振り返りとスプリント計画はちがう日にする
- 「自由研究日」を設ける (Googleみたく)
リリースの計画と価格確定させた契約をどうするか
- この質問に答えるよう試みる：「この新しいリリースバージョン 1.0 を、最も遅い場合、いつ納品できるのか」
- 価格確定された契約の場合、最終的になにを納品すべきか判別するために、重要度に「しきい値」を設ける
- 例：重要度100以上のアイテムは1.0に含めないと死刑に処される。
- 例：50〜99は含めるべきだが、速やかな追加リリースでもいいかもしれない。
- 例：etc...
- 重要度の高いアイテムは、あらかじめ見積もっておく必要がある
- 正確さのため、チームに見積もらせること
- あまり時間をかけすぎないこと
- 見積は確定したものではないことを理解すること
- フォーカスファクタを決め、チームのスプリント速度を見積もる
- ここまでできたら、最終的な納品日までの期間に、ストーリーを重要度順におさめていく
- 現実はそのとおりにはいかない。スプリントごとにお客さんと調整しよう
- 真剣に学びたいなら「アジャイルな見積と計画づくり」を読もう (うう、買ったけど未読…)
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本（ソフトカバー）
- 購入: 74人 クリック: 764回
- この商品を含むブログ (225件) を見る
ScrumとXPの結合
- XPはプログラミングに、Scrumはマネジメントと組織に、それぞれフォーカスしている
- かぶってるプラクティスはScrumに従った
- ペアプログラミング
- コードの品質が高まる
- 相互チェック「おいおい、この機能はほんとにこのスプリントに必要かい？」
- 非常に疲れるので常にやるのは無理
- 知識がすごい早さで共有される
- ペアプロがあわない人もいる
- コードレビューも兼ねられる
- 強制はしないこと
- TDD
- インクリメンタルな設計
- 最初からぜんぶ設計するより、あとからリファクタリングする
- CI
- CIサーバは審判
- チェックイン→ビルド→失敗するとメールが来る
- 仕組みをつくるのは手間がかかるけど、その価値はある
- コードの共同所有
- 情報満載の仕事場
- コーディング規約
- 安定したペース、活気ある作業
- すぎた残業は、生産性と品質を犠牲にする
テスト
- 受け入れテストは避けられない!
- チームのコード品質をあげることで期間短縮はできる
- テスタをチームに入れる
- テスタは「完了」を通知してくれる。デモにも最適
- まだテストするものがないときは、環境づくりをする
- スプリントの作業量を減らし、受け入れテストサイクルを短くする
- 次のスプリントで、受け入れテストチームが発見した前のスプリントのリリースのバグを直すはめになる
- 混乱する
- うまい解決策はあるのか？
- １：古い機能が未完成であるうちは、新しい機能に手を付けない
- ２：新しい機能に手をつけてもいいが、古い未完成の機能を優先する
- スプリントの間に長さ不明なリリース期間を設けるのは、スプリントのリズムを崩すのでお薦めしない
- 受け入れテストから戻ってくるバグフィックスを考慮にいれてスプリント計画を立てる
- 良いテストツールや自動テストを使おう
複数のScrumチームを運営する
- 大きすぎる少数のチーム ＞ 小さな分割されたチーム
- バーチャルチームの存在
- チーム分割は本当に難しい
- 最適なチーム規模は 3-8 人
- 複数チームのスプリント期間は同期させたほうが効率的
- チーム割り当て
- 最初だけえらい人が決めて、あとは自律的な解決にまかせる
- コンポーネント（DB, フロント等) に特化したチームはうまくない
- チームを再編成するときは、それが一体化を壊す可能性を意識する
- 「一時的なチームメンバ」を入れることはよくない
- ("客先常駐"の商売とは相性が悪い考えですな)
- Scrum of Scrum
- (この項、あまり理解できていない)
- だいたいは報告の場になる。大抵の人は情報に飢えている
- デイリースクラムを同時に行わないことで、POやマネージャが参加しやすくする
- 火消しチームにScrumチームを守らせる
- 複数チームがいる場合も、POとバックログは１つ
地理的に離れたメンバーがいる場合
- Webカメラ、ヘッドセット、会議マイク、デスクトップ共有などのツールを駆使する
- 別の拠点につながる「遠隔ウィンドウ」をつくる
- 定期的にお互いを尋ねる（物理的に）
- オフショア開発
- 離れたチームではなく、離れたチームメンバからはじめた
- 最終的には、離れたチームに行き着くだろう
- (あまのりょーさんの MY JOB WENT TO VIETNAM? を思い出しました)
- 在宅勤務
Scrumマスタチェックリスト
ここまで。明日のCSMが楽しみ！
大切な事は、自分の仕事の現場で最良な方法をつねに模索し続けることだと理解しますた。
