【公開】第6回RxtStudy発表資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ダイジェスト版)」 #RxtStudy

本日の第6回RxtStudy発表資料をCCアトリビューションライセンスで公開します。

第6回RxtStudy発表資料　チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ダイジェスト版)」 from akipii Oga

【1】最初に断っておくと、本資料は完成版ではない。
TiDDを原則・価値・プラクティスなどで体系化した場合、どのように表現できるか、作業仮説として作成している。
だから、説明不足や不整合の部分もある。
特に、発表時間が25分枠だったため、言いたいことをかなり濃縮しているので、行間を読み取ってもらえると嬉しい。

体系化の方針としては、ツールに依存しないように説明することと、プラクティスをパターン言語で表現することに注力した。
TiDDはRedmineでもアナログでも運用可能であるし、そのような事例も既にある。
だから、ツールに依存しないように抽象化した概念でより普遍的に説明できないかと思っている。
また、プラクティスを特定の状況の問題に対する解決法として提示することによって、Aさんの現場では通用したプラクティスがBさんの現場では通用しない、という理由を綺麗に説明できるはずと思っている。

【2】TiDDの原則として「最初にチケットありき」「成果物は構成管理に従う」の2つをあげた。
TiDDはチケットとバージョン管理ツールが必須であり、その2つを前提として価値やプラクティスを展開しようと思っている。

チケットがツールやアナログによらない概念とすれば、それは一体どのように定義されるのか？
チケットは「プロセス」だと思う。
チケットは「タスク」「課題」「障害」などで種類分けされるが、それらはソフトウェアの変更に関わる対象プロセスと言える。

すると、プロセスには必ず「作業中」「完了」というステータスが現れ、それは状態遷移を形成し、それはワークフローと呼ばれる。
つまり、「チケットはワークフローに従う」。

従って、チケットはプロセスであるからには、チケットは成果物や仕様ではない。
成果物や仕様は、その変更履歴が重要であり、バージョン管理すべき対象のものだ。
つまり、「成果物は構成管理に従う」。

【3】構成管理とは一体何なのか？
この疑問はIT業界に入ってからずっと考えてきた。
何となく、構成管理がソフトウェア開発プロセスの本質に触れるような気がしていたから。

今は、構成管理はソフトウェアという資産を管理する仕組みだと思っている。

構成管理が資産を管理する仕組みならば、その資産の増減を記録する必要がある。
例えば、倉庫で在庫になっている製品や商品は、その資産の増減は商品有高帳で記録される。
ソフトウェアの変更はすべて記録する必要があり、「成果物は構成管理に従う」という原則になる。

また、資産は定期的にラベル付けされて、スナップショットが取得されて保存される。
例えば、在庫対象の製品や商品は、月次で締められて棚卸資産として計上されて、貸借対照表へ出力される。
リリース可能なソフトウェアになれば、リリースタグが付与されて、価値あるものとして顧客へ提供される。
つまり、「Iteration is Version」というプラクティスが出てくる。

構成管理は特にここ数年、ツールの進化が最も激しい部分であり、今皆が試行錯誤しながら新しい使い方を試そうとしている。
今流布しているプラクティスも、ツールの進化に合わせて、有効でない場面が増えたりしているし、逆に新しいプラクティスが生まれたりしている。
その部分の話は今日はできなかったけれど、またどこかで話そうと思っている。

【4】他にも書いたけれども、まだ作成中の部分が多い。
そして、西さんや他の人からも、フィードバックを受けた。
このアイデアをもっと成長させていこうと思ってる。

【追記】
第6回RxtStudyのTwitterログが以下で公開されている。

2012/10/20 第6回 RxTstudy まとめ #RxTstudy - Togetter

今後発表資料は、RxTstudyで公開されるでしょう。