Issues駆動開発で すべてがうまく行く理由

@hatajoe

開発が抱える問題

Individualistic Opaqueness is

個々人の不透明性

属人性 Individualistic

不透明性 Opaqueness

属人性 Individualistic

* 俺しかその仕様を知らない

* 俺しかデプロイ権限がない

* 俺しかこの機能は実装出来ない

開発フェーズではそんなに問題にならない。 !運営フェーズで初めて露呈する問題。 一度属人化すると再び共有化するための労力がぱない。

不透明性 Opaqueness

* 俺しか今日の仕事量がわからない

* 俺しか成果物のクオリティがわからない

* 俺しか今のタスクがわからない

開発フェーズで特に問題になる。 !誰が今なにをすべきで 実際何をしているのかを明確にすべき。 それでいてすべきことが無いのであればサッと帰れ。

あるある～ '`,､('∀`) '`,､

あってはイケないんじゃね？

ところで Issues知らない人いますか？

GitLabにもあります。

Issues駆動開発

1 Issueを立ててレビュー

2 Issueに紐づくブランチを切り公開

3 オレオレローカルブランチを切って開発

4 [WIP] マージリクエストを発行してソースレビュー

5 マージリクエストを発行してIssueに紐づくブランチを終了する

6 リリースブランチを切り、QAチェック

7 リリースしてIssueをクローズする

1 Issueを立ててレビュー

* 企画・仕様をベースに実装者がIssueを立てる

* 出来るだけ網羅的に

* 体裁にはこだわらない（まぁmarkdownは最低限使うとしても）

* レビュアーは自分がそれを見て実装可能か目線でレビュー

これが エンジニアにとっての仕様書となります。 これが テスト仕様書にまでなれる可能性を秘めています。

2 Issueに紐づくブランチを切り公開

* ブランチ名の命名規則は feature/issue/{ID} に統一

* 原則として1Issue1Branchという決まり

これは 公開ブランチです。 対象のIssueはこのブランチで開発中と明示します。 こうすることで 後続メンバーがスムーズにブランチ戦略に入ることが出来ます。

3 オレオレローカルブランチを切って開発

* 自分が管理しやすいように好きにブランチを切る

* Issueブランチへのマージリクエスト用

好きなコミット単位で好きに開発して下さい。 ただし 帰宅前に必ずその日の成果を [WIP]としてマージリクエストを発行して下さい。(後述) そうすることで 突然のアクシデントから成果物を確実に保護出来ます。

4 [WIP] マージリクエストを発行してソースレビュー

* WIPとは Work In Progress の略

* 自身のローカルブランチから

Issueブランチに対してマージリクエストを発行

WIPのマージリクエストは

マージリクエストのタイトルに[WIP]と記載します。 このマージリクエストはマージせず最終的には破棄します。 レビュー用です。 対象のIssueブランチが完成するまで このマージリクエスにコミットを重ねます。 !マージリクエストの概要には IssueIDを #1 のような形で記載しておきます。 そうすることで マージリクエストのコミットとIssueが紐づくようになり

Issueに対するコミットを後から参照しやすくなります。

5 マージリクエストを発行してIssueに紐づくブランチを終了する

* 完成版のローカルブランチをIssueブランチにマージします

* Issueの機能が全て実現出来たら

Issueブランチを終了しdevelopにマージします

WIPでないマージリクエストです。

レビュアーは[WIP]を見て

マージして良いのかどうかを簡単に判断します。 Issueブランチにローカルブランチをマージ後

チーム内誰でも良いのでfeatureを終了します。

6 リリースブランチを切り、QAチェック

* リリースブランチを切り公開し テストサーバー上はリリースブランチに切り替えます !

* QAチェック中に発生した不具合は リリースブランチ上で修正します

やっとリリースブランチの 使用価値を見出した瞬間

7 リリースしてIssueをクローズする

* リリースブランチを終了しリリースを行います

コミットコメントに Coses #1 を記載することで自動でIssueがクローズされます。

これを繰り返します。

(・o・)ﾎﾟｶｰﾝ

大事なのは無理しないこと

出来るところからやりましょう。 少なくともIssueを書くことは誰でも出来るはずです。

!チーム内に１人でも理解者が居れば実現可能です。 まずはこのフローに乗っかることこそが最重要です。

最終的にうまくやると...

* Issuesのおかげで仕様書が残る！

* Issuesのおかげで仕様とコードが簡単に紐づく！

* ブランチ戦略がイケてるので途中参加の誰かがリリースまで出来る！

* マージリクエストにより必ずレビューが挟まるので 成果物のクオリティが安定する！ * コーディング規約を守らせることが出来る！

結果... 属人性の排除 不透明性の排除

大事なのでもう一度言っとくと

無理はしない。 まずはフローに乗ること。

真似事でもいい。 必ず出来るようになります。

ご清聴ありがとうございました。