【公開】第6回RxtStudy発表資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ダイジェスト版)」 #RxtStudy
本日の第6回RxtStudy発表資料をCCアトリビューションライセンスで公開します。
【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で公開されるでしょう。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
「パターン言語」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント