アジャイルごっこ
「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」で指摘した「アジャイルごっこ」についてメモ書き。
【元ネタ】
続・書評『アジャイルな見積りと計画づくり』 - TECH-moratorium : テクモラトリアム
DeclineAndFallOfAgile - アジャイルの衰退と凋落
【1】「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」の訳者あとがきに、こんな一節がある。
XPを代表とするアジャイル開発の技術的プラクティスは、開発現場の日々の作業を明らかに改善してくれる。
しかし、その効果はいずれ限界が来る。
結局、プロジェクトのスコープとスケジュールが固定されている状況では、最終的に開発者に様々なしわ寄せが来る。
このように、開発者だけがアジャイルなプラクティスを導入している状況を、木下さん(レビューワー)は「アジャイルごっこ」と呼んだ。
この指摘はあまりにも痛烈だ。
僕が今実践しているチケット駆動開発は、SW開発のどのプロジェクトでも適用できるし、実際の開発プロセスを大きく改善してくれることを経験している。
少なくとも、プログラマの受けは非常に良い。
彼らは、チケットを自分たちのToDoやリスクとして登録してくれるし、何よりもソースとチケットの紐づけによって、自分たちで変更管理のプロセスを発見してくれる。
プロジェクトリーダーにとっても、Redmineロードマップを見ながら、イテレーション計画を実施することで、プロジェクトのスコープとスケジュールを開発の現実と調和するように軌道修正できる。
このおかげで、アジャイル開発の最大の利点であるイテレーティブな開発プロセス、更には短いサイクルで小刻みにバージョンアップする小規模リリースを実現できる。
しかしながら、顧客を含めた開発体制がアジャイル開発にマッチしなければ、壁にぶち当たる。
特に大規模開発で複数の開発チームが存在する場合、一つの開発チームがスコープとスケジュールを調整できる範囲は限られる。
チケット駆動開発は開発現場の状況をリアルタイムに見える化するため、溢れたタスクや品質の悪さを常に公衆の面前にさらす。
タスクが溢れすぎてチーム自身で制御不能な場合は、もはや意味を成さない。
スコープとスケジュールを調整可能にして初めて、価値あるソフトウェアを育てていく開発を実現できるはず。
【2】かと言って、エンジニアリング無しのアジャイル開発もありえない。
「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」の訳者あとがきには、こんなことが書かれている。
「アジャイルの衰退と凋落」の記事のように、ビジネスの要請に基づいて、短いイテレーションと頻繁な計画作りだけを導入しても、プロジェクトを疲弊させるだけだ、と。
XPが提唱する技術的プラクティスは、実はSW構成管理に関する内容が多いというのは注目に値すると思う。
ソースの共同所有、テスト駆動開発、継続的インテグレーションなどのプラクティスがあるおかげで、メインラインモデルのように、複数のコードラインによる並行開発を運用可能にする。
つまり、アジャイル開発は高度なSW構成管理を必要とする事実を、XPは示唆した。
一部では、Gitなどのような分散バージョン管理も普及し始めている。
ソース管理という最も基本的な技術は、まだ技術革新の途上にある。
【3】「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」には、イテレーション計画の作り方とその基盤を与える見積もりについて有用なノウハウがたくさん書かれている。
アジャイル開発を実践しないプロジェクトリーダーであっても、バッファの取り方などは参考になるはずだ。
RedmineのScrumプラグインを入れると、「StoryPoint」(規模の大きさ)、「Velocity」(開発速度)の概念が具現化される。
この概念を使えば、イテレーション計画の精度は高くなるはずだ。
特に、見積もりとは平均の開発速度でありコミットメントではない、という指摘は僕は凄いと感じた。
アジャイル開発は、品質・コスト・納期の三角形からコスト・納期・スコープの三角形へプロジェクトマネジメントのパラダイムシフトをもたらした。
このパラダイムシフトを理解し、実践できなければ、アジャイル開発とは言えない。
技術とビジネスをいかに調和させるか?
チケット駆動開発に、開発速度やストーリーポイントなどの概念を注入して、アジャイル開発を更に強化できないか?
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- Redmineで持ち株管理する事例(2024.04.21)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「チケット駆動開発」カテゴリの記事
- 第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)
コメント