いつでも発展途上

ITとゲーム漬けのシャチ。とくにブログのテーマはなく、メモ代わりに書いています。休眠気味。

「塹壕よりScrumとXP」読書メモ (3)

前々回前回 にひきつづき「塹壕よりScrumとXP」の読書メモです。自分用ですので全くまとまっていませんし、誤りがあるかもしれません。(まさかこんなに長くなるとは…)

スプリントバックログ(続き)

  • スプリントを始めるたびにきれいなバックログが作られる(紙を張り替える)
  • 重要度の高いストーリーを上に貼る
  • バーンダウンチャート
    • 縦軸にストーリポイント、横軸に日付を取った折れ線グラフ
  • 危険な徴候
    • 線が上にふくれる:見積りより遅い。バックログアイテムを減らす
    • 線が下に下がる:見積りより早い。バックログアイテムを増やす
    • 下のストーリーから終わってる:重要度を間違ってる!
    • 計画外アイテムばかり終わってる:スプリント計画が…!!
      • 計画外アイテムとは、文字通りスプリント計画になかったアイテムのこと。
      • (アイテムって言葉は、ストーリーまたはタスクのことかな?)
  • トレーサビリティはどうなってるんだ!
    • 毎日デジカメで撮る
    • でも、そんなに重要じゃないはず
    • 気になるならホントの価値を見積もってみよう
  • 見積単位
    • 1実効人日=6実効人時
    • (7や8じゃないし、ましてや10や13なんかじゃない!)
    • ストーリーは時ではなく、日単位で見積もっている
    • 0.5が最小

チームの部屋をどう改造するか

  • 設計コーナー
    • のびのびと設計できる(日本じゃ難しそうだ〜)
    • 重要な設計ドキュメント、タスクボードなどを貼る
  • チーム全員同席!!
    • 席を移動するのはめんどい。でも、効果的なチームを作りたいなら他の選択肢はない
    • 大事なこと:声の届きやすさ、目の届きやすさ、隔離されていること
    • 専用の部屋があれば一番良い
    • POはチームと同席すべきじゃない (近くにはいたほうがいい)?
    • マネージャやコーチは、緊密に関わるべきだが、あるときは自律に任せること

どうやってデイリースクラムを実施するか

  • タスクボードの近くで、毎朝、立って話す。ポストイット、バーンダウンチャートを更新する
  • ルールを決めて、それを一貫させること
  • スクラムマスタが全部やるのは非効率
  • (最初に運営ルールをまとめておくのは大事そうだな)
  • 遅刻したら缶にコインを入れる。溜まったお金はチームのイベント等に使う(これ面白い)
  • やることがない人がいたとき
    • タスクボードを流して、考えさせる
    • ペアプロする
    • 終わってないものがないかチームに尋ねる
    • 次のスプリントから追加する (POに知らせること)
    • それでも駄目なら…
    • (なるべく自律的にタスクを発見できるように人を育てるのが大事ぽい…)

スプリントデモをどうやるか

  • デモは、何があってもしなければならない。たとえできていなくても!
  • 厳しいルールだが、得られるものは大きい
    • 目標が毎週達成されるので士気があがる
    • チーム外の人にも結果がわかる。チーム間のやりとりが発生する
    • お客から生のフィードバックがある
    • 確実に作業を「完了」できる (99%の未完より、少ない完了)
  • チェックリスト
    • 成果物がなにかを説明できてるか
    • 準備に時間をかけすぎてないか(派手なプレゼンは不要)
    • 美しくより、手際よく
    • 技術より、ビジネス視点で
    • できれば見ている人に触ってもらう
    • あんまり細かすぎる話はしない
  • 「10000ユーザの負荷テスト」みたいなデモできない話は、テスト結果レポートを見せて説明する、のでもよい

スプリントのふりかえりをどうやってするか

  • 起こったことを明確にする。改善の大切な機会
  • チームの外の部屋ではやらない
  • PO+チームで実施
  • スプリントバックログを見ながら、できごとを一巡りする
  • 見積と実際の速度がちがうところは、要因を分析してみる
  • 次スプリントへむけてのブレスト。良かったこと、もっとよくできそうなもの、改善点 (KPT?)
  • それらにチームで投票し、次にやることを決める
  • チームが得たナレッジは他のチームにも共有した
    • マネージャが非公式に動き、他のチームのふりかえりで広めたりした
  • 問題を明確に認識さえすれば、それは自然と解決していく
    • なにか不平を言うたびに新しいやり方を導入していると、みんな問題をあげるのが嫌になってしまう
  • 典型的なふりかえり事項
    • 「ストーリーをブレイクダウンする機会をもっと増やそう」
      • 問題を認識したことで、次のスプリントでは皆がそう動く
      • 繰り返し起こるならスプリントの期間を長くする
    • 「外部の邪魔が多い」
      • フォーカスファクタを低くする
      • 邪魔する人をメモっておく
      • スクラムマスタかPOを通すよういっておく
      • 持ちまわりで「ゴールキーパ」を設定し、そこに全部の邪魔を流すようにする
    • 「仕事抱えすぎた」
    • 「作業環境がうるさい、汚い」
      • 環境を改善するか、いっそ移動する。上位管理者への働きかけ
      • (これは気にする人と気にしない人の同居がむしろ問題になったなー、自分の場合)

スプリント中の休憩期間

  • 休まないと死ぬる
  • スプリント間に休憩期間がまったくないと、チームもPOも情報を整理する期間がなくなってしまう
  • スプリント振り返りとスプリント計画はちがう日にする
  • 「自由研究日」を設ける (Googleみたく)

リリースの計画と価格確定させた契約をどうするか

  • この質問に答えるよう試みる:「この新しいリリースバージョン 1.0 を、最も遅い場合、いつ納品できるのか」
  • 価格確定された契約の場合、最終的になにを納品すべきか判別するために、重要度に「しきい値」を設ける
    • 例:重要度100以上のアイテムは1.0に含めないと死刑に処される。
    • 例:50〜99は含めるべきだが、速やかな追加リリースでもいいかもしれない。
    • 例:etc...
  • 重要度の高いアイテムは、あらかじめ見積もっておく必要がある
    • 正確さのため、チームに見積もらせること
    • あまり時間をかけすぎないこと
    • 見積は確定したものではないことを理解すること
  • フォーカスファクタを決め、チームのスプリント速度を見積もる
  • ここまでできたら、最終的な納品日までの期間に、ストーリーを重要度順におさめていく
  • 現実はそのとおりにはいかない。スプリントごとにお客さんと調整しよう
  • 真剣に学びたいなら「アジャイルな見積と計画づくり」を読もう (うう、買ったけど未読…)

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

ScrumとXPの結合

  • XPはプログラミングに、Scrumはマネジメントと組織に、それぞれフォーカスしている
  • かぶってるプラクティスはScrumに従った
  • ペアプログラミング
    • コードの品質が高まる
    • 相互チェック「おいおい、この機能はほんとにこのスプリントに必要かい?」
    • 非常に疲れるので常にやるのは無理
    • 知識がすごい早さで共有される
    • ペアプロがあわない人もいる
    • コードレビューも兼ねられる
    • 強制はしないこと
  • TDD
    • 難しい。習得に時間がかかる
    • ペアプロで習得するのが効率的
    • 設計によい影響をあたえる
    • 新しく立ち上げたチームで始めるには時間がかかる
    • しかし、得られるものは大きい
    • 既存の(TDDでない)システムでTDDするのはとても大変
    • 手動の回帰テストを楽にする方法を先に考えること。TDDはそのあとでもよい
  • インクリメンタルな設計
  • CI
    • CIサーバは審判
    • チェックイン→ビルド→失敗するとメールが来る
    • 仕組みをつくるのは手間がかかるけど、その価値はある
  • コードの共同所有
  • 情報満載の仕事場
  • コーディング規約
  • 安定したペース、活気ある作業
    • すぎた残業は、生産性と品質を犠牲にする

テスト

  • 受け入れテストは避けられない!
  • チームのコード品質をあげることで期間短縮はできる
  • テスタをチームに入れる
    • テスタは「完了」を通知してくれる。デモにも最適
    • まだテストするものがないときは、環境づくりをする
  • スプリントの作業量を減らし、受け入れテストサイクルを短くする
  • 次のスプリントで、受け入れテストチームが発見した前のスプリントのリリースのバグを直すはめになる
    • 混乱する
    • うまい解決策はあるのか?
    • 1:古い機能が未完成であるうちは、新しい機能に手を付けない
    • 2:新しい機能に手をつけてもいいが、古い未完成の機能を優先する
    • スプリントの間に長さ不明なリリース期間を設けるのは、スプリントのリズムを崩すのでお薦めしない
  • 受け入れテストから戻ってくるバグフィックスを考慮にいれてスプリント計画を立てる
  • 良いテストツールや自動テストを使おう

複数のScrumチームを運営する

  • 大きすぎる少数のチーム > 小さな分割されたチーム
  • バーチャルチームの存在
  • チーム分割は本当に難しい
  • 最適なチーム規模は 3-8 人
  • 複数チームのスプリント期間は同期させたほうが効率的
  • チーム割り当て
    • 最初だけえらい人が決めて、あとは自律的な解決にまかせる
  • コンポーネント(DB, フロント等) に特化したチームはうまくない
  • チームを再編成するときは、それが一体化を壊す可能性を意識する
  • 「一時的なチームメンバ」を入れることはよくない
    • ("客先常駐"の商売とは相性が悪い考えですな)
  • Scrum of Scrum
  • (この項、あまり理解できていない)
    • だいたいは報告の場になる。大抵の人は情報に飢えている
    • デイリースクラムを同時に行わないことで、POやマネージャが参加しやすくする
    • 火消しチームにScrumチームを守らせる
  • 複数チームがいる場合も、POとバックログは1つ

地理的に離れたメンバーがいる場合

  • Webカメラ、ヘッドセット、会議マイク、デスクトップ共有などのツールを駆使する
  • 別の拠点につながる「遠隔ウィンドウ」をつくる
  • 定期的にお互いを尋ねる(物理的に)
  • オフショア開発
    • 離れたチームではなく、離れたチームメンバからはじめた
    • 最終的には、離れたチームに行き着くだろう
    • (あまのりょーさんの MY JOB WENT TO VIETNAM? を思い出しました)
  • 在宅勤務
    • 全員同席プラクティスとの兼ね合い
    • Skypeでデイリースクラムに参加
    • 特定の日だけ在宅にするとか
    • (チームによって適切な方法はかわりそう)

Scrumマスタチェックリスト

ここまで。明日のCSMが楽しみ!
大切な事は、自分の仕事の現場で最良な方法をつねに模索し続けることだと理解しますた。