チケット駆動開発にGTDの概念を導入する

yusuke-kokuboさんのつぶやきに惹かれたのでメモ。

【元ネタ】
Twitter / yusuke-kokubo: ビジョンを説く・「プロジェクトの管理者と作業者をシームレスにつなげたい」・「プロジェクト管理にかかる無駄工数を極限まで少なくしたい」・「管理者は管理の本質に集中できて作業者は自分の作業だけに集中できる環境を作りたい」

Twitter / yusuke-kokubo: そのための手段として・「Redmineを使ってプロジェクト管理をシステム化する」・「RedmineAirを使って個々のタスクとRedmineを連動させる」

Twitter / yusuke-kokubo: RedmineAirはどうあるべきか？・「作業者が普段メモをとる感覚で使えないといけない」・「WebブラウザがなくともPCを立ち上げればRedmineのチケットが勝手に表示される」 →よくある付箋紙アプリがRedmineのチケットを結びついたら面白そう

ソフトウェア開発では、プロジェクト管理の工数が実は大きい。
ソフトウェア開発は流れ作業ではなく、新技術を使いこなしながら、顧客の曖昧な要求から試行錯誤しながらシステムを作り込む。

頻繁な要求の変更、タスクの変更、優先順位の変更は当たり前。
全ての作業はUnixのコマンドのように、パイプラインでつながっている。
一つの作業が遅れると、後続の作業は全て遅れてしまう。
つまり、一つの作業の遅延はクリティカルパス上のタスクに影響をもたらす。
しかも、クリティカルパス上の作業は状況によっては、毎日変わってしまう。

Redmineによるチケット駆動開発は、アジャイル開発のようにタスクの変化を取り込んで作業が可能。
パイプライン上の作業に変更が生じたら、イテレーションの範囲内で作業順序を変えればいい。
リリースの優先順位まで変わってしまったら、そのタスクをイテレーションから外してしまえばいい。

つまり、日々で頻繁に変化するタスクを見える化することによって、マネジメントを見える化しているのだ。
ある意味では、GTDに似た構造を持っていると言えるだろう。

チケット駆動開発とGTDについても考えてみたい。