2日間Issue駆動開発をしてみた感想

捗る、気がする。

概要

• Issueに作業を書く
• CommitでIssueを解決する

要点

• 1つのIssueは1つのCommitで解決できるほど小さな単位である
  • 1回のCommitは作業時間が最大3時間を目安とする
    • 頻繁にアウトプットできる
      • 方針転換や品質向上がこまめにできる
• いつ、何をして、どうなったか、がIssueやCommitとして記録される
  • モチベを維持向上しやすい
    • 作業を俯瞰しやすい
      • 作業を思い出しやすい
  • 作業が捗りやすい
    • 進捗を確認しやすい
      • 次の作業を決めやすい
        • 過去の作業がみれる

他の開発方法と比較

駆動開発	説明	欠点
妄想	頭の中に思い描く	頭の中だけにしかないから概要もモチベも忘れてしまい続かない
メモ帳	妄想を書き出す	実際に動くコードを書かないから妄想テキストで終わる
ファイラ	ローカルでコードを書く	小さい規模なら成果を出せる。大規模なら作業やモチベを忘れて破綻する。
ブログ	作業を書き出す	何をしたか思い出せる。
公開	成果物を公開する	実際に動くコードを書くから成果になる。1リポジトリ1成果。
Issue	Commitで解決する作業を書き出す	具体的なコードに紐づくので計画と実績が紐づく。1Issue1成果。

IssueにしないでCommitをするときもある。ReadMeの誤記修正など。

気になったこと

• 「どう運用していくか」というメタな内容までIssueにし、文書化してCommitした
• 運用を自動化することをIssueにし、スクリプトを書いてCommitした

「自動化しないと面倒になって続かない」というメタ問題がある。

メタ問題をとらえる好機

運用するために自動化は必須。しかし自動化環境は自分で作るしかない。それすらIssueにして解決していく。

問題の原因をさぐりメタ問題を考えているうちに何をしていたのかわからなくなる。活動履歴が残っていれば経緯を把握できる。自分の活動を客観視できるから。

Issueはブログの作業履歴よりも小さい単位だし具体的なコードに紐付いている点が良い。問題の解決をコードで論理化するときには適した方法か。

所感

作業を小分けにする。記録される。定量化される。Issueの数＝成果数。成果がどんどん増えていくので楽しくなる。いつまで続くやら。