チケット駆動開発の理想と現実
知人と話しながら、チケット駆動開発の理想と現実について気づいたことをメモ。
あくまでもメモであり、主張はない。
【1】Redmineを導入したならば、チケット駆動開発で運用するのが普通だと僕は思っていた。
しかし、実際の数多くの現場はそうではないですよ、と。
丁度、日本のソフトウェア開発の現場では、アジャイル開発ではなくWF型開発が主流であるのと同じように、と。
【1-1】チケット駆動開発はXPに影響を受けすぎているのでは?、と。
世間のアジャイル開発のイメージは、XPよりもScrumの方が有名だ。
Scrumのプロセスフレームワークの中で、タスクカードがチケットとして使われる場合が多いでしょう。
全ての作業をチケットにして作業をはじめる「チケット駆動」は特殊でしょう。
WF型開発の現場では、そうではない。
チケットの入力結果は、ガントチャートで確認する方が普通ですよ、と。
【1-2】チケット駆動開発のプラクティスは実際の現場では使いづらい時がある、と。
たとえば、No Ticket, No Workは確かに理想だけれども、実際は、チケット管理の対象は進捗管理だけでない。
また、Redmineというツールに頼りすぎるのも問題だ、という認識が現場にはある。
たとえば、No Ticket, No Commitもプログラマにとって評判は良くない時がある。
コミットログに逐一チケットNoを書くのが億劫だ。
また、ちょっとしたリファクタリングのコミットにもチケットNoを紐付けるべきなのか。
頻繁にコミットする場合、チケット一覧のコミット履歴が多すぎて、結局あまり使えない、と。
特に、GitHubのようなプルリクが使えないのもいまいちだね、と。
【2】僕が思っているチケット駆動開発は、理想にすぎないのかな。
「ソフトウェア開発の基本原理は、XPの小規模リリースと同じ」「頻繁にバージョンアップしながら、品質も機能も向上させていくのがソフトウェア開発の王道」と僕は思っているけど、違うのかな。
日本のソフトウェア開発は、製造業の成功体験を引きずりすぎていて、一度決めたら進路変更できない計画主導の開発プロセスにこだわり過ぎている、と思っているのは違うのかな。
僕の考えでは、チケット駆動開発は、アジャイル開発を実装する一プロセスであり、最も自然にアジャイル開発を実践できるプロセスの一つと思っているけど、そうではないのかな。
【3】チケット駆動開発は、フロー型プロセスでもあり、ストック型プロセスでもある二面性が利点を増幅させていると思っている。
チケットはカンバンでもあり、作業指示書や障害管理票のような記録できる帳票の二面性を持つ。
その部分の相互作用がすごく面白い。
Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索
【3-1】「Issue」を「チケット」と訳したRedmineは偉いと思う。
チケットはメタな概念。
「Issue」を「問題」「課題」に訳してしまったら、タスク管理に使う発想は無かっただろう。
Redmineを障害管理やタスク管理だけでなく、ヘルプデスク管理、インシデント管理、台帳管理、議事録の管理、農作業の予実管理などに使おうという発想すら出現しなかっただろう。
【3-2】ソースそのものに修正履歴を残すのではなく、コミットログやチケットに記録することで、ソースは常に最新で綺麗な形に残せる。
そして、コミットログやチケットというメタな概念に修正履歴や変更理由が残るので、メタな開発プロセスをチケット上に実現できる。
さらには、蓄積されたコミットログやチケットを集計したり検索することで、エンピリカルなソフトウェア工学の知見を適用して、メトリクスの採集による傾向分析ができる。
さらには統計学やビッグデータを適用して、仮説に基づくプロセス検証ではなく、データ主導によるプロセス検証もできるかもしれない。
【3-3】チケット駆動開発のもう一つの側面として、パッチ駆動開発の顔もある。
パッチをチケットに添付して、コードレビューのやり取りをする。
Redmineによるチケット駆動開発はパッチ駆動開発と同じ: プログラマの思索
パッチ駆動が重要である理由は、「ソフトウェア開発は頻繁なバージョンアップで品質も機能も改善していく」手法が基本原理ならば、変更管理や構成管理が非常に重要になるからだ。
でも、この開発プロセスは、GitHubのプルリクエストが普及した現在、正直古くなっている部分もある。
RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索
RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索
チケット駆動開発にGitの良さも組み込んで、もっとアジャイルな開発基盤にしてしまいたい妄想を今後も考えてみる。
| 固定リンク
「Redmine」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
「構成管理・Git」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
- 第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある(2021.11.28)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
コメント