アジャイル開発のインフラを支える三種の神器
「開発インフラの三種の神器といえばSCM, BTS, CI」という言葉から、チケット駆動開発とアジャイル開発、更にはソフトウェア開発の関係についてもう一度考え直してみる。
ラフなメモ書き。
【元ネタ】
金曜日は分散バージョン管理勉強会。大物スピーカーも来るよ! - watawata日記
【1】アジャイル開発は多分ソフトウェア開発をやっている人なら自然に理解できる概念だと思う。
イメージ的には、コーディング、コンパイル、実行を繰り返すプログラミングスタイルを開発プロセスへ抽象化すればいいだけだからだ。
でも、ソフトウェア開発は、プログラミング以外の雑多な作業が結構多い。
開発抽象化レイヤーを担う人: プログラマの思索にも書いたけれど、プログラマがプログラミングに専念してアジャイルに開発するには、雑多な作業を意識しなくても良い開発環境を必要とする。
その開発インフラはBTS、SCM、CIでほぼカバーできると直感している。
アジャイル開発の最大の特徴は小規模リリースだと思っている。
短期間に頻繁にリリースしながら品質を改善し機能を拡張していく開発スタイル。
でも、従来の開発プロセスやプロジェクト管理手法では、短期間に次々にリリースしていくのがとても難しい。
タスク管理、進捗管理、変更管理がその開発速度に追いつけていないからだ。
そして、アジャイル開発を実際に運用出来ていないチームの特徴としては、イテレーションという概念を自分たちで実装できていないことがあるだろう。
つまり、定期的にリリースしていく単位をうまく運用できず、従来のWF型開発のように、ただ1回のビッグバンリリースをやった後にデスマーチに陥る時が多いだろう。
リリースして初めて、ビルドエラーに気付いたり、顧客の要望と違っていた事実が判明するからだ。
更に、アジャイル開発が難しい原因として、繰り返し型開発は並行開発でもある事実を認識出来ていないこともあると思う。
小規模リリースを運用すると、リリースしたモジュールは本番環境で稼働中だが、その裏では開発チームが別のコードラインでガンガン機能追加していく開発スタイルになる。
そして、次のイテレーションでリリースする時、1個前のバージョンのモジュールは廃止されて新しいモジュールに入れ替わり、また裏では最新のコードラインが次のイテレーションに向けて開発されていく。
つまり、アジャイル開発はtrunkとリリースブランチという2本のコードラインを常時保守する並行開発になる。
だが、システムやが大規模になるほど、製品ファミリーが多いほど、並行開発を制御するのは難しい。
アジャイル開発を実現するにはそれなりの開発環境が必要になってくる。
【2】最近はソフトウェア開発をサポートするツールのうち、オープンソースのツールがとても優秀で使い易くなってきた印象がある。
バージョン管理(SCM)はCVSの頃から、SVN、そしてMercurialやGitのように進化している。
SCMがとても使い易くなった理由の一つは、TortoiseSVNのようにSCMクライアントが高機能になって、ユーザへの敷居が低くなったからだろう。
高機能なSCMのおかげで、構成管理パターンが普及して、並行開発を従来よりも楽に運用できるようになっている。
また、XPが提唱した継続的インテグレーション(CI)は、Hudsonという優れたツールが普及している。
Hudsonはビルド結果のレポート出力が充実している。
またプラグインを追加していけば、BTSやSCM、更には他ツールとも連携できる利点がある。
CIのおかげでコードラインは常時リリース可能な品質が保たれる。
そして、BTS自体もITSへ進化して、最近はRedmineやTracのようにアジャイル開発のプロジェクト管理に使う発想が生まれている。
チケット駆動開発はTracのチケット管理から生まれた。(まちゅさんが最初に提唱された)
そのアイデアをアジャイル開発のプロジェクト管理に応用できると気づいた人達が、いろんなアイデアを試している。
チケット駆動開発の発想は、チケットをXPのタスクカードのように扱うこと。
そこから、リアルタイムな進捗管理、成果物とチケットの連携が可能になる。
これによって、変化に強いタスク管理が可能になり、成果物のトレーサビリティも楽になる。
そして、BTSのワークフロー管理を使えば、チケットを通じて厳格な変更管理を透明に行うことが可能になる。
このおかげで、開発者は作業だけに専念すれば、自然に厳格なワークフローに即して作業できるようになる。
【3】チケット駆動開発で改めて理解した概念は「バージョン」だ。
リリース予定バージョンをイテレーションに紐づければ、自然に小規模リリースを実現できる。
更に、イテレーションをリリースモジュールのバージョンに紐づければ、CIツールと自然に連携できる。
これによって、どのモジュールにどんな修正が含まれているか、を簡単に追跡できるようになる。
バージョンを大規模プロジェクトに拡張すれば、アジャイルリリーストレインという概念にもつながる。
つまり、複数チームのイテレーションを同期させることによって、複数のチームの成果物の同期がスムーズになり、開発の遅延の伝播がなくなる。
又、バージョンをイテレーションに同一視すれば、そこから開発のリズムが生まれる。
チームのゴールがイテレーション終了時のリリースだとメンバー全員に通知できるから、メンバーのベクトルが一つに向く。
チームのゴールが分かるからこそ、チームは何をすべきか、自分の役割は何か、が自然に気づくようになる。
そしてリリース後に、BTSに貯められたリリース履歴を見ながらKPTでふりかえりをやると、とても効果的。
Keepとしてあげられた内容は、開発チームの運用ルールやプラクティスとして、次のイテレーションで使える。
Keepはまさにプロセス資産。
Problemとしてあげられた問題は、Tryに是正対策としてまとめられて、次のイテレーションで実験したり試行錯誤するきっかけになる。
その結果が次のイテレーションのふりかえりで評価されて、開発チームの運用ノウハウが溜まっていく。
KPTによるふりかえりは、開発チームの成長のために必要不可欠なプラクティス。
プロジェクトファシリテーションとチケット駆動開発の強い関連性はもっと研究されてもいいと思う。
【4】XPは元々、ソースの共同所有や継続的インテグレーションなどのアイデアで、SCMやCIの重要性は主張していたが、それだけでは物足りない気がしていた。
でも、高機能なBTSを基盤としてチケット駆動開発を運用する手法によって、アジャイル開発の最後のピースが埋まったような気がする。
RedmineやTracによるチケット駆動開発の上で、Scrumなどのアジャイル開発のプロジェクト管理のアイデアは全て実現できるはずと直感している。
【補足】
ITS・SCM・CIを3種の神器と命名した人は、@haru_iidaさんだそうです。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」の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)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- 第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)
コメント