Yamotty Blog

Make Something People Want

怠惰PMのアジャイルOPS

TOP > プロダクト > プロダクトマネージャー

前置き

  • 1年半くらい前、PMをしていたチームの開発オペレーションのなかで、「進め方」を議論する時間をゼロにしたかった。
  • その時間があるなら「価値」について考えたかった。
  • 穴の掘り方より掘るべき穴の探索に時間を使いたいじゃないですか。
  • そのため初めに「ガッ」とOPSを組んで、進め方は完全なルーティンに落とし込んだ。いわゆるアジャイル。
  • その際に創ったドキュメントを、なぜか今更色んな人から見せてほしいと最近言われたから発掘して公開する。

ちなみに個人的にOPSの最適化は割と得意っぽい。参考になれば。

このドキュメントは何か

  • アジャイルを実施するための方針・運用フロー
  • 導入するツール（Zenhub）と使い方
  • 導入にあたりQ&A

を記したもの。

アジャイル導入の目的

  • ユーザーのストーリー = 問題解決に集中するチームを作ること。
  • 生産性を高めること
    • テンポを作る
    • 迷う時間をなくす
    • 振り返りの習慣

何は目的”ではないか”

  • コードをたくさん書くこと。
  • アジャイルをすること。
  • Zenhubを使うこと。
  • 情報をGithubに集約すること

導入にあたっての準備

知識

  • アジャイルとは何か？についての雑な参考
    • アジャイル開発 -> 用語や役割はこれを見ると一通りOK
    • （書籍）アジャイル・サムライ -> オフィスにあります

導入ツール: Zenhub

  • Github拡張ツール。全ての情報をGithubで管理したい。
  • ブラウザに合わせたextentionをinstallしておく

方針と運用フロー

前提

  • 同じ場所、同じチーム、同じ期間、密なコミュニケーションを前提としている。これはそのままチームにinstallする。
  • 目的はアジャイルの導入ではない。目的をぶらさない。

方針

  • 目的は創造性・生産性の向上。
  • 小さく始めて、慣れたり、最適なスタイルにしていく。

基本的なタームとルール

  • sprint : 開発期間。イテレーションとか呼んだりもする。1サイクルは水曜日から開始し、2週後の水曜日までとする
  • KPT : 運用の振り返りをsprint終了前日の火曜日に実施する
  • Epic : 解決したいユーザーの課題 （ex. 信頼されるtop page UIへ変更する）
  • Issue : epicを達成するために実施すべきタスク。可能な限り細かく分解する。目安は実装者が1日以内に達成できる範囲。
  • estimate : ストーリーポイントとも呼ばれる、相対的な見積もり。基準となるタスクを1としたときに相対的な実装コストを見積もる。
  • Icebox : やりたいこと、をまとめたアイディアリスト。自由に、誰でも起票して良い。Backlogへ
  • Backlog : プロダクトへ対する実施リスト。POは常に順序 = 優先度をメンテする。基本的に実装はBacklog listの上から行う。
  • Daily scrum : いわゆる朝会。毎日やります。

運用フロー

https://in-wiki.s3.amazonaws.com/attachment/5858e35b926808c02339d26d/81475904a4dd7304a9cc22744967ea0c.png

sprint day1-13

実装~リリースに使用できる期間は基本的に9営業日とする。

  1. 実装
    • Sprint対象のbacklogに含まれるEpicを優先度順に実装する。
  2. QA
    • issue or epic単位でQAを行う。QAは基本的にチーム内で行う。
  3. リリース
    • Issue or Epic単位でリリースを行う。金曜日は基本的に避ける。
    • Webなので、リリーススピードを最速にし、バグは叩き出す方針。
  4. 効果測定
  5. Epicに測定方法を予め設計しておく。

sprint day14

基本的に実装などの作業を行わない日を1日設ける。

  1. 仕様定義
    • 次回Sprintの対象となるEpic+αの仕様が確定している状態にする。
    • EpicをIssueへ分解する with ソフトウェア・エンジニア。
  2. 見積もり
    • Issueへ、estimateをつける。
    • （本来は相対的なestimateをつけるものだが）リリースまでにかかるhourをestimateとして見積もる。
  3. KPT
    • 目的は「スプリントの進め方についてのKPTを洗い出し、次回スプリントに実施するアクションを決定する」こと。
  4. milestone決定
    • 見積もり・重要度・納期を元にBacklogの上からmilestoneを決定していく（PO）
  5. チームランチ
    • sprint最終日にチームランチしましょう。
    • 軽い振り返りをしつつ、チームビルディングの場として使う。

sprintに含まれず、随時行うこと

  1. （Anyone）解決したい課題、アイデアをIceboxへepic or Issueとして作成し、適切なラベルを付ける
  2. （PO）Iceboxな中身を精査し、closeする or Backlogへ移動する or Iceboxへ残す のいずれかを実施する
  3. （PO）Backlogの優先順位を決定する
  4. （Team）Issue or epicへ仕様詳細をアウトプットする（必要に応じて内容をTeamと議論する）

Q&A

Q/ Daily Scrumは何をするの？

  • A/ 口頭でさっと以下の情報共有/全員が話す場を持つ、という意図で実施。
    • KPI確認
    • Burndown chart確認
    • 共有事項の確認
    • sprint issueの進捗確認
    • epicの検討状況シェア
    • なんか一言

Q/ デザインのストーリーポイントはどう管理するか？

ソースコードへの修正は伴わず、UIデザインは仕様検討段階で工数が発生する。それは管理するか？という内容。

  1. 普通のIssue同様、Estimateを付与する形で定量管理する。振り返りをしやすくするため。具体的にはこれまでにdesign管理してきたhoge-web-design をhoge-webへマージする。

Q/ estimate = １とは？

  • A/ 基準となるIssueを1とする。
  • A/ 一旦はリリースまでにかかるhourの見積もりとする。見積もり会でつけたestimateは基本的に変更しない。

Q/ day14はなにからやるのか？

  • A/ 仕様定義→見積もり（Issue分解含む）→Milestone決定の順で実施。スケジュールを先に抑える。KPTは順不同で差し込む。

Q/ PRはどうやって管理するのか？

  • A/ 作業用のhoge-serverのrepositoryで作業管理を完結する。

Q/ リファクタ等の「空いた時間にやっていた系」Issueはどうやって管理するのか？

  • A/ 開発主導でやりたいこと、は基本的にBacklogへ直接Issueを作成し、estimateを担当者が手動でつけておく。これまで同様「よしななタイミングで」実施してもらい、Issueをカンバン管理する。

Q/ Issueの優先順位はどう判断したら良い？

  • A/ Epicの優先順位 = 並び順に従う。

Q/ Estimateと実際にかかった時間がずれた場合どうする？

  • A/ Issueに「実際はXだった」とコメントお願いします。一度つけたEstimateは変えない = 見積もり精度をあげていくため。

Q/ 一度立てたepicが不要になった場合はどうする？

  • A/ 不要になった理由をコメントし、milestoneを外してcloseする。