TiDDを実践して気付いたことpart3~繰り返し開発の戦略
Redmineでチケット駆動開発を実践して改めて、アジャイル開発は繰り返し開発であると認識した。
Redmine、Trac、Mantisでチケット駆動開発を経験してみて、繰り返し開発の戦略やコツがあるのがぼんやりと分かってきた。
ロジカルに言い尽くせないけれど、以下メモ書き。
【元ネタ】
変更要求に対する選択肢: プログラマの思索
Subversionコードラインのライフサイクル: プログラマの思索
TiDDを実践して気づいたことpart2~これがアジャイルだ!と気付いた瞬間: プログラマの思索
【1】チケット駆動開発では、タスクを全てチケットに書き起こし、それらチケットをリリース計画に基づいて各バージョンへアサインし、順次リリースしていく。
つまり、XPの小規模リリースとは、2~4週間という短期間でリリースを繰り返す繰り返し開発である。
繰り返し開発(スパイラルモデル)には、インクリメンタル型と反復型の2種類があるのは既に知られている。
インクリメンタル型は、各繰り返し(イテレーション)でどの機能を実現するかを決め、それを1回の繰り返しでリリースする。
反復型は、各繰り返し(イテレーション)でシステム全体の機能を少しずつ作っていき、何度も繰り返して完成させる。
RUPが反復型開発であるのに対し、XPやScrumのようなアジャイル開発は、基本はインクリメンタル型開発だ。
顧客価値を重視する開発スタイルだから、顧客へ早めにリリースすることを優先する。
つまり、XPの小規模リリースとは、小刻みに機能拡張しながらリリースしていくインクリメンタル型開発スタイルを指している。
インクリメンタル型開発の利点は、機能というスコープが小さいのでスコープを制御しやすい点にある。
リリースが最終ゴールだから、スコープが揺れていてはリリースできないからだ。
逆に反復型開発は、スコープを制御しづらい弱点があるように思う。
例えば、工程ごとの繰り返し開発の途中で、度重なる仕様変更を取り込んでしまい、スコープを制御できずに破綻してしまう時は多くないだろうか?
しかし、反復型開発では、システム全体の機能を何度も繰り返しながら作り上げるため、スコープさえ制御できていれば、品質を向上させるために使える。
【2】Redmineでチケット駆動開発を実践すると、自然にインクリメンタル型開発になったけれど、それだけでは品質には不安があった。
だから、TestLinkを導入して、システムテストや受入テストの工程を別のイテレーションで実施し、色んな観点のテストやバグ修正を行って、品質向上を図った。
すると、このイテレーションは、反復型開発に似ているのに気付いた。
つまり、リリースできる品質まで持ってきたが、更なる検証で品質を向上させたい場合、インクリメンタル型開発から反復型開発にチェンジして、複数回のイテレーションでテストを実施する手法だ。
これによって、TestLinkのテスト計画をRedmineのバージョンに見立てて順次テストしていく反復型開発がやりやすくなった。
【3】反復型開発を使う場面は他にもある。
特に、複数のサブチームによる大規模開発、ソフトウェア開発チームとハードウェアチームが連携する組み込み製品開発などが相当するだろう。
例えば、組み込み製品開発では、SWチームは、HWチームから提供されるハードウェアを元に、HWチームの開発サイクルよりも短いイテレーションで順次開発してみる。
理由は、早めにハードウェアとソフトウェアを結合して動作させながら確認したいからだ。
すると、この場合、HWチームの1イテレーションに対し、SWチームは複数のイテレーションをこなしていることになる。
つまり、イテレーションの入れ子構造で反復型開発を行っている。
反復型開発のもう一つの利点は、イテレーションの入れ子構造によって、開発のスケールアップがやりやすい点もあるだろう。
【4】インクリメンタル型開発が難しい理由は、並行開発になってしまう点にあると思う。
例えば、イテレーションで実装した機能をリリースしたら、そのシステムは顧客の前で動き続けるが、裏では開発チームが次のイテレーションの機能を実装し始める。
そして、次のイテレーションの機能をリリースしたら、前のイテレーションのシステムは廃止して、裏で次の次のイテレーションの開発を始める。
つまり、自然に、本番運用と新規開発の2種類のコードラインを常時保守せざるをえないのだ。
但し、並行開発に対する一つの回答は、メインラインモデルという構成管理手法で既に知られている。
つまり、trunkというメインラインからリリースする時は、ブランチを派生させ、常にtrunkが最新の安定した機能となるようにコードラインを保守する手法。
メインラインモデルの手法は、いくつかのバリエーションがある。
おそらく最もよく使われる手法はタスクブランチだ。
例えば、現在、Ver3.0へ向けて開発中で、その次のリリース予定のバージョンは4.0である時に、突然の仕様追加に対応しなくてはならなくなった場合、Ver3.1のタスクブランチを定めて、Ver3.0→Ver3.1→Ver4.0の順にリリースしていくという開発スタイル。
このタスクブランチの手法によって、品質を維持しながら、納期とスコープ、工数のバランスを取ることができる。
チケット駆動開発では分散バージョン管理を使って、更にトピックブランチという開発スタイルも選択できる。
つまり、チケットごとにトピックブランチをローカルに作って開発し、最後にtrunkへプッシュする開発スタイル。
これはタスクブランチを各チケットへ更に分化した場合に相当する。
GitやMercurialを使っていれば、おそらくスムーズに運用できるだろう。
チケット駆動開発による小規模リリースは、インクリメンタル型でも反復型でもどちらの繰り返し開発も運用可能だ。
繰り返し開発では、インクリメンタル型と反復型を故意に使い分ける戦略が重要ではないだろうか?
また、アジャイル開発が難しい理由は、インクリメンタル型と反復型を使い分けるノウハウがなかなか見当たらず、実践しにくい点にあるのではないだろうか?
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「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)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「TestLink」カテゴリの記事
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- TestRailの感想(2021.06.23)
「廃止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」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(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)
この記事へのコメントは終了しました。
コメント