チケット駆動開発が進むべき道part1~ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する
最近は、yuguiさんや色んな人のつぶやきに触れて、励まされたり、ハッとしたりする時が多い。
「Redmineによるタスクマネジメント実践技法」を出版してから、チケット駆動開発が今後進むべき道について再考してみた。
ラフなメモ書き。
Redmineを触ってみて、まちゅさんによるチケット駆動開発のアイデアに触れて、チケット駆動開発に従来のソフトウェア開発を大きく変える可能性をすごく感じている。
RedmineだけでなくTracやMantis等のBTSでチケット駆動開発も運用した経験を通じて、チケット駆動開発には下記4つの大きな特徴があると思う。
1・ロードマップで長期と短期のリリース計画を使い分ける
2・ワークフロー管理を透過的にサポートする
3・成果物のトレーサビリティを実現する
4・進捗報告をチケット集計機能で自動化する
1番目は、ロードマップがチケット駆動開発で最も重要な計画プロセスの成果物であることを意味している。
つまり、ロードマップに示された複数のリリース予定バージョンが長期のリリース計画であり、一つのリリース予定バージョンには、短期の観点であるイテレーション計画が含まれている。
更に、ロードマップが将来に向けたリリース計画であり、リリースされたロードマップは自然にリリース履歴として残される。
2番目は、チケットの種類をワークフローで識別することによって、チケット管理が変更管理プロセスになることを意味している。
一つのチケットを終了する過程で、レビューアとレビューイ、開発者とテスター、開発者と設計者などのように複数人が一つの成果物を作ってチェックすることによって、品質を確保するだけでなく、お互いにより深くシステムを知るきっかけになるし、信頼関係が醸成される。
3番目は、要件や仕様からソース、設計書、ビルドモジュール、テスト仕様書などの成果物へのトレーサビリティをチケットを経由して実現出来ること。
RedmineやTrac、TortoiseSVNでは、コミットログにチケットNoを書けば、リビジョンとチケットが自動的にリンクされる機能が付いている。
更に、RedmineのSubtasking機能を使えば、チケットの親子関係が使えるので、ストーリーカードとタスクカードを紐付けて要件からタスクまで簡単にトレースできるようになる。
トレーサビリティによる利点は、仕様変更が来た時の影響範囲を調べやすくなることやソースから仕様をリバースエンジニアリングしやすくなることがあげられる。
システム監査における監査証跡としても扱えるかもしれない。
4番目は、BTSに一括管理されたチケットを集計すれば、進捗や品質、コストなどの情報をいつでも簡単に取り出せるようになることを意味している。
チケット管理の運用ルールさえ徹底できれば、開発者は進捗報告を逐一報告する必要もないし、管理者はリアルタイムに進捗や品質の情報をモニタリングできる。
従来のプロジェクト管理では、上記4つの作業を散在したExcelや大量の紙媒体で管理していたから、メンバーも運用に慣れるのが大変だし、プロジェクトリーダーもプロジェクトの状態を把握するのが困難だった。
Redmineによるチケット駆動開発なら、上記4つの作業を全てRedmineで一括管理できるし、一括管理できるからこそ、他ツールと連携して更に価値を高めることができる。
一言で言えば、ソフトウェア開発をサポートする道具がようやく時代に追いついた気がする。
と言うのも、開発プロセスやソフトウェア開発のノウハウは既に出し尽くされている気がするからだ。
CMMI、Agile、Scrum、XP、RUP、PMBOK、ITIL、テスト管理、品質管理など各種の技法や開発プロセスは2000年以前に既に提唱されており、その運用ノウハウやベストプラクティス、アンチパターンも、その界隈では既に知られていた。
だが、それらの知識を経験していない人にとっては、それらの技法やノウハウは高嶺の花だった。
でも今は違う。
RedmineやTrac、TestLink、Subversion、Git、Wikiなど優れたOSSのツールが普及し、誰もが簡単に構築して運用できるようになってきている。
ツールが揃ってきている今だからこそ、それら開発プロセスの実装、運用ノウハウを皆が知りたがっているのだ。
それら抽象論は既に聴き飽きた人が多いのではないかと思う。
そんな状況にある今、チケット駆動開発というアイデアでやってみたいことは、ソフトウェア開発のベストプラクティスをオープンソースのツールで実現してみることだ。
ツールの機能やプラグインにソフトウェア開発のベストプラクティスを実装すれば、その機能に慣れるだけで、自然に良い習慣が身につく。
そうすれば、ソフトウェア開発をチームで開発する経験が少ない若手にとって、良いお手本になるだろうと思う。
更に、ソフトウェア開発のベストプラクティスを「オープンソース」のツールで実現する点も重要だ。
MSやIBMのツールは確かに優れているかもしれないが、高価だし、ソースの中身を見ることもできないから、自分たちで機能拡張もできない。
もっと重要な点は、オープンソースという場を通じて、ツールを使うユーザとツールを開発するコミッタが有意義な議論を深めることによって、ツールの機能を拡張しながら、ソフトウェア開発の新しいプラクティスを実現する可能性を秘めていることだ。
実際、Redmine本家のフォーラムやチケットの議論を眺めていると、Redmineはアジャイル開発のプロジェクト管理と相性が良いことに気づいた人達が、アジャイル開発のアイデアをRedmineの機能へ注入するだけでなく、アジャイル開発そのものをブラッシュアップしようとする気概が見受けられる。
チケット駆動開発を運用できるツールによって、ソフトウェア開発のベストプラクティスを誰もが簡単に経験できるようになれば、ソフトウェア開発はもっと楽しくなるだろうと思っている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「チケット駆動開発」カテゴリの記事
- 第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)
コメント