ウォーターフォール型開発はバージョンの概念が無い
RedmineやTestlinkを運用して気づいたこと。
アジャイル開発の基本構造はまさに、チケット駆動開発(TiDD)なのだ、ということ。
アジャイル開発のスタイルは、短いイテレーションで小刻みにリリースすること。
この時、イテレーションとはシステムのバージョンのことだ。
Redmineならバージョン、Testlinkではビルドに相当する。
つまり、リリースするマイルストーンを指す。
実際の手順は、リリースする時に、Subversionにバージョンというタグを付ける。
すると、チケット駆動開発では、1個のプロジェクトで、たくさんのイテレーション、つまりバージョンが発生し、その単位でリリースすることになる。
そのイテレーションに、実現する機能(ストーリーカード)を作業(タスクカード)に分解して、どれを優先するか、チケットをふるいにかける。
イテレーションの日数とメンバーの人数から、機能を実現できる工数は限られる。
だからこそ、限られた工数内で、チケット(タスクカード)に優先順位を付ける。
この時、バグ修正のチケットが機能追加よりも優先する。
理由は、品質を最優先にするからだ。
バグが多く出れば、機能追加は次のイテレーションに延期するしかない。
BTSのチケット管理は自然に、限られたリソース(工数、人、時間)でやり繰りするようになる。
バージョン履歴こそがプロジェクト管理の要なのだ。
しかし、ウォーターフォール型開発は、リリースが最後の1回だけ。
マイルストーンを区切ったとしても、要件定義が終わった、設計が終わったというだけで、動くシステムは形すらできていないのが普通。
システムのバージョンという発想そのものが欠落している。
その理由は、人月ビジネス、受託開発スタイルにあると思う。
かき集められたプログラマは、リリース後はプロジェクトからいなくなる。
彼らにとって、システムを育てていくという発想がそもそも契約上ないから。
ソフトウェア開発では、バージョンという概念が一番大事。
バージョンUpしながらシステムを育てていく、という発想をチケット駆動開発は支えてくれるはずだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある(2020.12.11)
「Redmine」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
- 若手プロジェクトリーダー向けのRedmine教育資料の構想(2020.12.24)
「Git・構成管理」カテゴリの記事
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
- 第19回Redmine大阪の見所 #redmineosaka(2019.01.26)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
コメント
ウォーターフォールの場合、当初確定した仕様をベースラインとして、その後は変更管理が行われます。おっしゃるようにアジャイルと違い現物主義ではないので、正式リリースは最後の一度かもしれませんが、仕様という意味では複数バージョンが存在し、それが管理されています。
また、アジャイルでも新システムに対する第三者検証、マニュアル作成とか、教育とか、いろいろ必要になると思うので、多くの場合、正式リリースは一度あるいは半年~一年に一度程度だと思うのですが、違いますか?
結局、リリースまでのバージョンが仕様としてあるか、コードとしてあるかの違いだと思います。
投稿: さかば | 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