繰り返し開発の罠
萩本さんがアジャイル開発と反復開発について記事を書かれていたのでメモ。
#以下はあくまでもメモ書きです。
【元ネタ】
アジャイル開発と反復開発の落とし穴 - @IT自分戦略研究所
「現状のソフトウェア開発は間違っていないか?」(プロセス編) - @IT自分戦略研究所
TiDDを実践して気付いたことpart3~繰り返し開発の戦略: プログラマの思索
Mercurialによるチケット駆動開発は強力だ!: プログラマの思索
「反復開発は、管理重視型開発」「アジャイル開発は、価値重視型開発」と書かれていて、なるほどと参考になったのと同時に違和感があった。
確かにその傾向はあるけれど、本質はそこだけでは無い気がする。
RUPのような反復開発は、アーキテクチャや品質を作り込むためにプロセスを反復する。
しかし、1回の反復だけではリリースできるレベルまで開発できないし、リリースは普通最後の1回だけだから、結局ウォーターフォール開発と何ら変わらない感覚がある。
アジャイル開発は漸進型開発であり、小規模リリースを基本とする。
1回のイテレーションでリリース出来る機能を実装しながら、小刻みにリリースしていく。
だから、アジャイル開発ではリリース計画やイテレーション計画を作るのが非常に重要になってくる。
その意味では、アジャイル開発はリリース計画駆動と言ってもいい。
でも、僕がチケット駆動開発を実践してみて、小規模リリースの戦略だけでは不足していると経験した。
やはり、品質を作り込むイテレーションが別途必要な状況が存在するのだ。
例えば、複数のサブチームが並行して、イテレーションを繰り返してモジュールをリリースしていき、最後にそれらを結合する場合、結合テストのようなイテレーションが必要だ。
この状況が発生するのは、組み込み製品でソフトウェア部隊とハードウェア部隊が連携する場合や、大規模プロジェクトで複数のモジュールを結合する場合が相当する。
この時、TestLinkを使って、結合テストやシステムテストを行い、品質を作り込む。
その手法は、反復開発に切り替えているのだ。
つまり、繰り返し開発は漸進型開発と反復開発を切り替える戦略が重要だと思う。
そして、繰り返し開発を使いこなすには、並行開発のインフラが必要になってくる。
つまり、「塹壕よりScrumとXP」にもあるように、ブランチを上手に使いこなす必要がある。
漸進型開発であれ、反復開発であれ、繰り返し開発を行うと、必ずブランチが発生する。
漸進型開発ならば、リリースしたソースは本番ブランチとして、次のメジャーバージョンまで生き続ける。
反復開発ならば、検証中のソースはタスクブランチとして、trunkへコミットされるまで生き続ける。
すると、ブランチとtrunk間のマージ作業が発生し、並行する複数のブランチをどのタイミングでマージするか、難しくなる。
デグレが起きないようにマージするのは、たとえチケット駆動開発であろうとも簡単ではない。
ブランチとtrunk間のマージ作業の問題に対する一つの解決方法として、MercurialやGitのような分散バージョン管理を上手に使いこなすのがあげられる。
そのやり方は、Mercurialによるチケット駆動開発は強力だ!: プログラマの思索に書いた。
つまり、繰り返し開発が難しい理由は、漸進型開発と反復開発を切り替える戦略が無いこと、そして、並行開発を制御する構成管理のインフラがないことにあるのだと思う。
繰り返し開発は試行錯誤しながら問題を解決する仕組みだとすれば、別にソフトウェア開発だけの代物ではないし、どんな人でもその利点は理解できる。
しかし、繰り返し開発に関するソフトウェア開発特有の問題を認識していないから難しいのではないか、と思ったりする。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
「廃止Mercurial」カテゴリの記事
- GitHubはオープンソースのプロセスを標準化した(2015.06.11)
- 「反復型ソフトウェア開発」はソフトウェア工学の良書(2013.02.09)
- Mercurialに取り込まれたコミュニティ由来の機能一覧(2013.01.12)
- WordやExcelから直接Mercurialへコミットできるアドオンmsofficehg(2012.12.07)
- RedmineでSubversion リポジトリ表示を高速化する方法(2012.11.23)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
コメント