ウォーターフォール型開発はバージョンの概念が無い
RedmineやTestlinkを運用して気づいたこと。
アジャイル開発の基本構造はまさに、チケット駆動開発(TiDD)なのだ、ということ。
アジャイル開発のスタイルは、短いイテレーションで小刻みにリリースすること。
この時、イテレーションとはシステムのバージョンのことだ。
Redmineならバージョン、Testlinkではビルドに相当する。
つまり、リリースするマイルストーンを指す。
実際の手順は、リリースする時に、Subversionにバージョンというタグを付ける。
すると、チケット駆動開発では、1個のプロジェクトで、たくさんのイテレーション、つまりバージョンが発生し、その単位でリリースすることになる。
そのイテレーションに、実現する機能(ストーリーカード)を作業(タスクカード)に分解して、どれを優先するか、チケットをふるいにかける。
イテレーションの日数とメンバーの人数から、機能を実現できる工数は限られる。
だからこそ、限られた工数内で、チケット(タスクカード)に優先順位を付ける。
この時、バグ修正のチケットが機能追加よりも優先する。
理由は、品質を最優先にするからだ。
バグが多く出れば、機能追加は次のイテレーションに延期するしかない。
BTSのチケット管理は自然に、限られたリソース(工数、人、時間)でやり繰りするようになる。
バージョン履歴こそがプロジェクト管理の要なのだ。
しかし、ウォーターフォール型開発は、リリースが最後の1回だけ。
マイルストーンを区切ったとしても、要件定義が終わった、設計が終わったというだけで、動くシステムは形すらできていないのが普通。
システムのバージョンという発想そのものが欠落している。
その理由は、人月ビジネス、受託開発スタイルにあると思う。
かき集められたプログラマは、リリース後はプロジェクトからいなくなる。
彼らにとって、システムを育てていくという発想がそもそも契約上ないから。
ソフトウェア開発では、バージョンという概念が一番大事。
バージョンUpしながらシステムを育てていく、という発想をチケット駆動開発は支えてくれるはずだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント
ウォーターフォールの場合、当初確定した仕様をベースラインとして、その後は変更管理が行われます。おっしゃるようにアジャイルと違い現物主義ではないので、正式リリースは最後の一度かもしれませんが、仕様という意味では複数バージョンが存在し、それが管理されています。
また、アジャイルでも新システムに対する第三者検証、マニュアル作成とか、教育とか、いろいろ必要になると思うので、多くの場合、正式リリースは一度あるいは半年~一年に一度程度だと思うのですが、違いますか?
結局、リリースまでのバージョンが仕様としてあるか、コードとしてあるかの違いだと思います。
投稿: さかば | 2008/06/09 00:18
◆さかばさん
非常に参考になります。
ウォーターフォール型開発でも、仕様はバージョン管理されているということですね。
他プロジェクトはよく知りませんが、Webシステムの場合、正式リリースは長くても6ヶ月以内でしょう。
Webシステムはビルド&リリースしやすい特徴があるので、正式リリース後は、1ヶ月に最低1回のペースでバグ修正や機能追加していくのが最近の流れだと思います。
だからこそ、プロジェクト管理の敷居が高くなっているように思います。
投稿: あきぴー | 2008/06/09 20:45
不具合対応を入れれば、ウォータフォールでも致命的な場合はマメに更新すると思います。ウォータフォールでいう(つまり仕様の)バージョンアップはそんなにないのではないでしょうか?
でも、自動テストが可能なので、デグレテストは(アジャイル手法ではなく)アジャイル環境の方がリリース間隔は短くできるかもしれませんね。
もし、管理が難しいなら、機能追加してもユーザにはリリースしないという方法もあるかもしれませんね。
投稿: さかば | 2008/06/09 21:47
◆さかばさん
バグ修正と機能追加のバージョン管理の使い分けは今模索中です。
機能追加の頻度は少なくても、最近はリリース間隔が非常に短くなっています。
一つの解決策としては、リリースブランチでバグ修正しながら裏では、trunkで機能追加しながら品質を確保する2系統戦略があります。
例えば、奇数バージョンが保守ブランチ、偶数バージョンが大幅機能追加のブランチのような戦略です。
2つのバージョン管理とマージ作業、それらに伴うプロジェクト管理の手法は、Redmineのようにプロジェクト管理機能を持つBTSでないと、もはやプロジェクトを運営できなくなっているように思います。
投稿: あきぴー | 2008/06/11 22:20