プログラマの思索

本日行われた第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コミッタとユーザの間で有意義な議論を交換しながら、より良い実践技法を通じて、チケット駆動開発を日本発のソフトウェア開発技法として提唱できたらいいなと思います。

【追記】
丸山さん、岡本さんのスライドはコチラ。

Redmineのブランチ戦略