自己流のアジャイル開発フロー

この記事はとあるチームで使ったアジャイルフローをドキュメント化したもの。

このドキュメントは何か

を記したもの。

アジャイル導入の目的

何は目的”ではないか”

導入にあたっての準備

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

参考 : zenhubとは

運用の前提

運用方針

基本的なタームとルール

運用フロー

agile flow

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

実装 Sprint対象のbacklogに含まれるEpicを優先度順に実装する。

QA issue or epic単位でQAを行う。QAは基本的にチーム内で行う。

リリース Issue or Epic単位でリリースを行う。金曜日は基本的に避ける。リリーススピードを最速にし、バグは叩き出す方針。

効果測定 Epicに測定方法を予め設計しておく。

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

仕様定義 次回Sprintの対象となるEpic+αの仕様が確定している状態にする。EpicをIssueへ分解する with ソフトウェア・エンジニア。

見積もり Issueへ、estimateをつける。 本来は相対的なestimateをつけるものだが、完全な見積もりは不可能なので、ざっくりとリリースまでにかかるhourをestimateとして見積もる。

KPT 目的は「スプリントの進め方についてのKPTを洗い出し、次回スプリントに実施するアクションを決定する」こと。

milestone決定 見積もり・重要度・納期を元にBacklogの上からmilestoneを決定していく(PO)

チームランチ sprint最終日にチームランチを行う。軽い振り返りをしつつ、チームビルディングの場として使う。

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

Q&A

Q/ Daily Scrumは何をするの?

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

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

ソースコードへの修正は伴わず、UIデザインは仕様検討段階で工数が発生する。それは管理するか?という内容。 普通のIssue同様、Estimateを付与する形で定量管理する。振り返りをしやすくするため。具体的にはこれまでにdesign管理してきたhoge-web-design をhoge-webへマージする。

Q/ estimate = 1とは?

A/ 基準となるIssueを1とする。ただし一旦はリリースまでにかかる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の優先順位 = 並び順に従う。

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

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

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

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


本稿が参考になった方はコメント&Kyash投げ銭をお待ちしております。記事へのフィードバックとして糧にします。なお、Kyashは常用していて応援しているプロダクトです。

kyash_qr