【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ベータ版)」 #47redmine
本日行われた第4回品川Redmine勉強会の発表資料をCCアトリビューションライセンスで公開します。
スタッフの皆さん、参加者の皆さん、お疲れ様でした。
第4回shinagawa.redmine勉強会 : ATND
今僕が考えている「チケット駆動開発をパターン言語で表現できるか」という問題に対して、勉強会のお題「チケットの粒度」「チケットの完了条件」について当てはめると、どれだけ本質に迫れるか、考えた結果を話しました。
内容は完成版でないし、解法は一つではないです。
オープンディスカッションの前座として、どれだけ皆の議論を引き出せるか、という観点で話しました。
オープンディスカッションでは7チームで議論してもらった結果、白熱したチームもあれば、違う議題に行ってしまったチームもあったり、面白かったです。
この2つの質問は、チケット駆動開発を実践する時に必ず通過しなければならない問題なので、勉強会で議論できたことは有意義だったと思います。
また、丸山さんのMercurialのお話、岡本さんのGitとScrumのお話、小久保さんのBacklogsプラグインの運用例のお話もありました。
Redmine界隈では著名な人たちばかりなので、今日の講演は盛り沢山だったかな。
岡本さんと丸山さんの話では、MercurialとGitではブランチの概念が全く違うという意味が、今日の勉強会で一番大きな収穫だったと個人的に思います。
チケット駆動開発の面白さの一つは、単なるタスク管理の上手な使い方だけでなく、構成管理の上手な使い方にも言及している所なので、コミュニティでまだまだ議論できる余地があります。
小久保さんの話では、Backlogsプラグインのカスタマイズで、新規ステータスから作業中ステータスへ変更する時に実績工数を入力しなければエラーとか、別のステータスへ遷移する時にコメント入力を強制させたり、却下ステータスへ移動する時は理由なしならエラーとするなど、ワークフローに関する制御が多くありました。
従来型開発では、ワークフローの制御はリーダーの承認や判子を押すなどの作業を入れたり、Excelなどのドキュメントに書き残してメンバーに強制させる手法でしたが、このやり方では、ワークフローの制御ルールをツールの1機能へ吸収してしまうことによって、開発者が意識しなくてもいいという利点があります。
小久保さんが、ツールの機能に実装されていないルールはメンバーに強制しない、と話された内容は、ワークフローの制御という開発プロセスの業務ロジックはチケット管理ツールの1機能になっているので、メンバーは自然に厳格なルールに従って作業できる利点を意味しています。
ソフトウェア開発のベストプラクティスはツールの1機能で実装してしまえばいい、という見本のような例だと思います。
そして、岡本さんがRedmine Git Branch Hookを紹介して下さったように、チケット駆動開発の基本的なプラクティスである「No Ticket, No Commit」をトピックブランチやストーリーブランチへ適用して、チケット単位にブランチを分岐して修正する場合はチケットにリビジョンの履歴をフックスクリプトで自然に残すという「No Tikcket, No Fork」へ発展させる使い方もあります。
つまり、チケット駆動開発はその時代のツールの最新の使い方を取り入れることによって、更に進化できる余地が沢山あります。
チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索
今後も品川Redmine勉強会というコミュニティの場で、Redmineコミッタとユーザの間で有意義な議論を交換しながら、より良い実践技法を通じて、チケット駆動開発を日本発のソフトウェア開発技法として提唱できたらいいなと思います。
【追記】
丸山さん、岡本さんのスライドはコチラ。
| 固定リンク
« TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine | トップページ | 「貢献したい気持ち」を持つ人達をコミュニティに集めて成果を出す仕組み~モチベーション3.0、アート・オブ・コミュニティ »
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「コミュニティ」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- 『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法の感想 #devboost(2023.12.10)
- 第25回東京Redmine勉強会の感想 #redminet(2023.11.05)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- デブサミ2023の感想(2023.02.11)
「Redmine」カテゴリの記事
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- Redmineで持ち株管理する事例(2024.04.21)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「廃止Mercurial」カテゴリの記事
- GitHubはオープンソースのプロセスを標準化した(2015.06.11)
- 「反復型ソフトウェア開発」はソフトウェア工学の良書(2013.02.09)
- Mercurialに取り込まれたコミュニティ由来の機能一覧(2013.01.12)
- WordやExcelから直接Mercurialへコミットできるアドオンmsofficehg(2012.12.07)
- RedmineでSubversion リポジトリ表示を高速化する方法(2012.11.23)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
「パターン言語」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント