アジャイル開発のスケールアップはアジャイルリリーストレインが鍵を握る
「アジャイル開発をスケールアップさせるには何が必要か?」という思索を深めている時に、とてもぴったり来た本が「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」だった。
「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」の本をざっくり読んでみて、考えたことをメモ。
【元ネタ】
Developers Summit 2010:CodeZine(コードジン)
Jazz 日本ユーザコミュニティ - デブサミ2010参加レポート「Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス」
Developers Summit 2010:CodeZine(コードジン)
steps to phantasien(2010-02-20)
19-B-2 Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス/玉川憲 - しあわせプログラマ
「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」の中で最も重要な概念は「アジャイルリリーストレイン」と「スクラムオブスクラム」だと思う。
アジャイルリリーストレインは、複数のサブチームのイテレーションの同期を取りながら、全コンポーネントを小規模リリースしていくこと。
まさに、複数の列車が同じ時刻表に従って同期しながら、同じタイミングで発車するイメージ。
スクラムオブスクラムは、複数のサブチームがある時、開発チームのリーダーであるスクラムマスターを集めたチーム。
スクラムオブスクラムはデイリースクラムと同様、各サブチームの状況や課題を報告し、サポートする。
この会議PMBOKのCCB、ITILのCABに似ている。
つまり、サブチームのリーダーが集まって、各チームの課題を棚卸する場に近い。
この2つが重要だと思う理由は、複数のアジャイルなチームを制御するには、お互いのイテレーション計画を同期して、サブチーム内で解決できない問題はもう一つ上の層で解決する仕組みが必要だからだ。
各サブチームのイテレーション計画がバラバラで統制が取れない場合、一つのチームの生産性が良くても、一番効率の悪いチームに巻き込まれてしまうから。
又、自チームで解決できない問題が出た時に、複数のサブチームのリーダーが互いに協力しあう場がなければ、すぐにチームは混乱するだろうから。
特にアジャイルリリーストレインが重要だと思うのは、組み込み製品の開発やパッケージ製品の開発でも、イテレーション計画の同期を取る状況がよく現れるからだ。
組み込み製品の開発では、HW開発チームとSW開発チームで、お互いにHWとSWを結合しながらテストしていくしかないが、その時に同期が取れないと、品質は安定しない。
パッケージ製品の開発でも、コンポーネント単位に開発チームが存在するから、全チームのコンポーネントの同期を取る時に、ビッグバンという結合テストでいつも大きな障害が発生しやすい。
だから、イテレーションの同期を取るのは非常に高度な技だと思う。
「塹壕よりScrumとXP」でも、スプリントの同期を取ることの重要性を述べている。
Redmineによるチケット駆動開発を導入すれば、更にアジャイル開発のスケールアップを支援できると思う。
僕なら、Redmineの複数プロジェクト機能を使って、各サブチーム単位で、タスク管理と課題管理の各プロジェクトをRedmineに作る。
日々の作業はタスク管理のプロジェクトで管理する。
チーム内で生じた問題や質問などは課題管理のプロジェクトにまとめて、チーム内で基本は処理するが、解決できない場合は、CCBやCABのような課題管理会議の場で、複数のサブチームのリーダーが議論して棚卸しする。
つまり、スクラムオブスクラムを実施して、一つの大規模プロジェクト内部で発生した各サブチームの課題を解決していく。
そして、Redmineのバージョン継承機能を使って、全チームへ同期すべきイテレーションを継承して、全チームに意識させる。チーム内では、同期すべきイテレーションよりも短いサイクルでイテレーションを回しても良い。
これによって、アジャイルリリーストレインを浸透させることができる。
最後に、RedmineのSubtasking機能を使って、ストーリーカードとタスクカードに親子関係を導入する。
ストーリーカードは顧客へ提供する価値の観点で集計できるし、タスクカードは開発チーム内部の詳細な進捗管理として集計できる。
これらの機能を使えば、大規模プロジェクトにアジャイル開発を適用させやすくなるだろう。
Redmineのエンタープライズ機能はアジャイル開発のスケールアップを強力に支援してくれるはず。
IBMの記事を読む限り、アジャイル開発のスケールアップに関してかなりのノウハウを持っているように思われる。
色々追いかけてみたい。
| 固定リンク
「Redmine」カテゴリの記事
- 第25回東京Redmine勉強会の感想 #redminet(2023.11.05)
- 第24回redmine.tokyo勉強会の感想 #redmineT(2023.06.03)
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
「ソフトウェア工学」カテゴリの記事
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
- パッケージ原則とクラス原則の違いは何なのか(2023.10.14)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
コメント