【公開】第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で公開されるでしょう。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
「Redmine」カテゴリの記事
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
「ソフトウェア工学」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
「プロジェクトファシリテーション」カテゴリの記事
- トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め(2021.02.13)
- みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない(2021.01.14)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 「チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ」の感想(2020.08.14)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか(2021.02.15)
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
「パターン言語」カテゴリの記事
- 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2(2020.12.31)
- 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1(2020.12.30)
- なぜユーザーストーリーによる要件定義にピンとこなかったのか(2020.12.29)
- AWSクラウドデザインパターンの感想~RDP(Redmine Design Pattarn)の構想(2020.03.01)
- チケット駆動開発のアイデアがRedmineへ与えた影響は何か(2018.12.10)
コメント