Rational Team Concertによるアジャイルな組込みプロダクトライン開発

アジャイルの成功ストーリーは、ITの領域ではもはや当たり前の話になっていますが、組込み系プロダクトライン・システムにおけるアジリティについてはあまり公に語られてはいません。ここではHarry Koehnemannが、IBM Rational Team Concertを採用してアジャイル・エンジニアリング・プラクティス(実践法)を支えていこうとするある組込み製品部門について深く探ろうと試みます。321 Gang社のHarry Koehnemannは、その会社のハードウェア、ソフトウェア、そして製品を管理するチームがいかに協調しているか、そこでのアジャイル・テクニックの使用、そして、Rational Team Concertへの移行について説明します。彼らがどんな課題に直面したのか、彼らの助けになったプラクティスやツールの変更とは、そして更なるチャレンジは何かといったことがわかると思います。

Harry E. Koehnemann (harry@321gang.com), 技術ディレクター, 321 Gang

Harry Koehnemannは、インテル社でキャリアをスタートし、オペレーティングシステムやコンパイラの開発に従事しました。1990年代のほとんどは、ソフトウェア中心システムのための組織への大規模向けコンサルティング・トレーニングに費やし、そして.comバブルのときは、まだ調子のよかったインターネット・スタートアップで4番目の社員としてJavaエンタープライズ・システムの開発をアジャイル・プラクティスを用いて行っていました。バブルがはじけた後、Harryはコンサルティングに戻り、航空防衛、自動車、電気、医療そして金融などの産業分野のたくさんのFortune 500企業に対して、エンジニアリングやソフトウェアのライフサイクルのためのプラクティスとともに支援してきました。現在は、IBM Rationalのプレミアム・ビジネス・パートナーである321 Gang社の技術ディレクターとして、さまざまな組織の大規模、複雑システム開発を成功に導くために情熱をもって取り組み続けています。また、Harryは10年以上にわたりアリゾナ州立大学の非常勤教授として分散コンピューティング、システム・モデリング、組込みソフトウェアの領域で教鞭と取りました。



2013年 10月 04日

概観

過去10年以上、ソフトウェア・コミュニティにおいては、かなり多くのアジャイル・プラクティス(実践法)の採用が見て取れます。これらのプラクティスは、ソフトウェア開発における従来のウォーターフォール型のプロセスがもつ欠点を受けての動きとして出てきました。

デリバリーの遅さ
ウォーターフォールのアプローチをとると、実行可能な(そしてレビューに使える)システムを作るのに何ヶ月も(ともすれば何年も)かかり、利害関係者たちがフィードバックをする機会を少なくし、ビジネス上の柔軟性を限定してしまいます。
 
早すぎる決定
レビューしたり意見を言う機会が限られることで、利害関係者たちはシステムの成功にとって重要な特性についての判断を早い時期にしなければなりません。
 
適応のための限られた機会
長期的で固定的な計画により、技術的に新しく見つかるようなことやビジネス上の変化の両方に関する新しい状況にうまく適応することが難しくなります。

対照的に、アジャイル・プラクティスは、継続的に小さなシステムの変更を統合してゆき、継続的にレビューを行う環境を提供します。それは、大きなプロジェクトを比較的小さなユーザストーリーやタスクに分解し、そしてそれらを継続的インテグレーションやビルド・プロセスの中で統合していきます。変化を継続的に取り込んでいくことで、エラーを早めに明らかにし、早めのシステム検証を可能にします。また、より頻繁なレビューができ、早めの妥当性の評価が行えます。

典型的なスクラム・プロセスでは、利害関係者(製品オーナー)が製品バックログ中の作業リスト(ユーザストーリー)の優先順位付けをします。各イテレーションの最初で、製品オーナーは製品バックログから最も優先度の高い幾つかのワークアイテムを選択し、開発チームとともにそれらの詳細について議論します。次に開発チームは、それらのストーリーを、これからの2週から4週にわたるスプリント(イテレーション)にて完了すべきタスクに分解します。スプリントの最中、開発チームは継続的に会話し(日次スクラム・ミーティング)、継続的に変更を取り込んでいきます。スプリントの最後に開発チームは製品オーナーに対して、最新のビルドで出来上がっている新しいケーパビリティのデモンストレーションを行います。

初期のアジャイルの成功ストーリーの多くには共通の性質があります。それらは、小規模なチーム、一箇所に集まって作業、比較的シンプルなIT型ウェブ・アプリケーションあるいはデータベース・アプリケーションの開発、といったものです。しかしながら、複雑なシステムの開発でも、アジャイルの価値、例えば、より早いデリバリー、できるだけ後での決定、継続的インテグレーション、早めのフィードバック、適応型の計画策定、といった価値の恩恵を受けることができますし、事実そうなります。

この記事では、仮想のある遠距離通信業者が組込み型部品のプロダクトラインを提供するのを例として取り上げます。そして、その業者が用いるアジャイル・プラクティス、彼らが今使っている開発インフラストラクチャーにおいて直面した課題、そしてIBM Rational Team Concertコラボレーション・ソフトウェアへと移行する中でこれらの課題にどのように取り組んだか、といったことを考えてみることにします。


プロジェクトの背景設定

ある携帯電話業界向けの遠距離通信機器サプライヤーが携帯電話部品を提供しています。この会社のチームは、ハードウェア担当チーム、ファームウェア(ソフトウェア)担当チーム、テスト担当チーム、そして開発ツールやテストベンチを作り出しかつ顧客からの問題に対応するアプリケーションサポートチームに組織化されています。カスタマー製品リーダー(Customer Product Lead – 略してCPL)は、顧客とのリレーションシップを管理し、機能拡張要求や障害レポートを顧客からエンジニアリング・チームに引き渡します。CPLは、スクラム・プロジェクト管理における製品オーナーに似た役割をします。

以前は、CPLはスプレッドシートを使い作業の進捗を確認していました。開発の優先順付けは、スプレッドシートの行を上にやったり下にやったりして絶え間なく管理されていました。エンジニアリング・チームは、これとは独立した、社内で開発されたシステムを用いて、テストで発見された障害や顧客により報告された障害への対応確認をしていました。エンジニアリング・マネージャは、この課題追跡システムからのデータを集めるMicrosoft Excelのビジュアルベーシック(VB)マクロを書くことでメトリクスを集めました。また、構成管理(Configuration Management - CM)は、既存の、ブランチをベースとしたツールを使って行いました。

図 1. プロジェクトにおける組織構造
プロジェクトにおける組織構造

ビジネスの拡大

2000年代後半の景気の下降は、彼らのビジネスにとって顧客基盤を拡大する機会を表していました。それぞれの顧客は固有の要求や追加ハードウェアのニーズを持っていました。最初単一ハードウェア・プラットフォーム上の単一製品だったものは、4つのハードウェア・プラットフォームに渡る18以上の派生製品へと成長しました。図2は、単一の製品Aが複数のハードウェア・プラットフォームの複数のバリアントへと成長する様子の一部を表しています。それぞれのストリームは製品のバリアントを表しており、矢印は変更があった場合バリアントの間でどのように波及するかを表しています。

図 2. 製品のソフトウェアおよびハードウェアの派生の流れ
製品のソフトウェアおよびハードウェアの派生の流れ

携帯電話通信業界は、非常にダイナミックでアジャイルです。製造業者は、問題を早く明らかにし進歩を示すために、サプライヤーからの部品の新しいバリエーションを取り入れてフィードバックをする、ということを繰り返します。それゆえ、サプライヤーは、そのフィードバックに対して、頻繁に、時には月に数回も、新しいバージョンを提供するように求められます。CPLは、ひっきりなしに製造業者と対話して次のデリバリーにおいてどの変更を取り込むかということを決定していきます。これらの会話を通して、CPLはファームウェア・チームのリーダーと週2回計画の見直し(アジャイルで言えば週二のスプリント)を行います。

顧客を拡大するということは、ファームウェア・チームに幾つかの理由で大きなチャレンジを突きつけます。それぞれの顧客は普通それぞれ固有の拡張要求を持っています。それぞれの顧客へのバリアントに対して全ての変更(拡張であったり障害修正)を反映させるわけではありません。これは、そのフィーチャーにかかるコスト、ハードウェア・プラットフォーム、余剰メモリ量、といったような要因により変わってきます。顧客ごとに変更を受け入れる順番が変わってくるとさらに状況は悪くなります。図3に示す例では、顧客Aは先行する2つの変更を含まずにある変更を受け入れようとしています。これらの先行する変更が将来には顧客Aによって受け入れられるどうかは何ともいえません。

図 3. 順序が不規則な顧客Aの変更の受入
順序が不規則な顧客Aの変更の受入

エンジニアリングやアジリティへの挑戦

顧客基盤を拡大するということは、エンジニアリング活動に対して、特定のバリエーションと新しい顧客のスケジュールとを合わせるというチャレンジを突きつけました。この環境で変更を管理するのは複雑です。なぜなら、全ての変更が全ての製品バリアントに取り込まれるわけではなく、取り込まれるとしても順序は異なるといった理由のためです。作業を確認するため追跡するにしても、図4に示すように、それぞれの顧客向けのバリアントはそれぞれにおいて優先付けされた作業のバックログを持っています。ここで、これらのバックログ全てを消化していくのは、ファームウェア・チームである単一の開発チームであるということを、特に言及しておきます。

図 4. 製品バリアントの間の作業の追跡
製品バリアントの間の作業の追跡

新規顧客が追加されるに連れ、それらの顧客ごとの作業バックログがExcelスプレッドシートの新しいタブに記録されました。作業(障害またはユーザストーリーという形での拡張要求)を表す行は、特定の顧客が特定の変更に関心があるということを記録するために、タブからタブへとコピーされました。しかし、スプレッドシート上では、図5に示すような同じ作業を関連付ける方法がありません。ある変更に対して、どの製品バリアントがそれを含んでいて、いつ取り込まれるかといったことを示すことができませんでした。

顧客基盤を拡大することは、彼らのレガシーな構成管理システムへもチャレンジを突きつけました。ブランチをベースとした構成管理システムでは、変更されたそれぞれのファイルは図5のように、別のブランチに置かれます。ある一つの変更で、5つ、10、あるいは100以上のファイルが変わるかもしれません。そして、ファームウェア・エンジニアはそれぞれのファイルごとに適切なブランチを作ることを求められます。

図 5. 製品バリアントを統合する変更管理の既存のアプローチ
製品バリアントを統合する変更管理の既存のアプローチ

この環境におけるほとんどのマージ作業は複雑です。なぜなら、全ての変更がある特定の顧客向けに取り込まれるとは限らないとか、更に悪い場合は、全然違う順序で取り込まれるといったことがあるからです。ブランチ・ベースの構成管理システムでの複雑なマージは間違えやすいものです。なぜなら、構成管理システムは、それぞれのファイルのバリアントは管理しますが、変更を管理するものではないからです。マージを行うエンジニアは、特定の変更に対してどのファイルが関わっていて、それらのファイルがどのブランチに置かれ、それらがどこでマージされるかについて理解することに責任を負います。これは、時間がかかり間違えやすいプロセスです。

マージのエラーは、場所を特定するのが難しく高くつきます。このような複雑さと潜在的なコストにより、ファームウェア・チームはインテグレーターという役割を置くことにしました。インテグレーターのみが顧客のブランチに対して変更のマージができるものとしました。残念なことに、インテグレーターはプロセスの中でのボトルネックとなり、月のなかで何回かデリバリーされるべきリリースに対してフィーチャーや障害修正を取り込むのに何度か遅延を引き起こしました。

明示的に「アジャイル」とは呼ばないまでも、この会社もそうしているように、携帯電話通信業界の会社は、いろいろなアジャイル原則を使おうとしています。頻繁に、場合によってはサプライヤーをまたいで、月に何回も、変更を取り込みます(継続的インテグレーション)。そして、顧客との頻繁な会話から学習したことに基づき、継続的に製品バックログの優先順位を再考します(適応型計画策定)。この例の組織では、それは週2回行われました。

作業の小分け、適応型計画策定、継続的インテグレーションといったアジャイル・プラクティスは、こういう変化を受け止める準備のできていない組織にとっては圧倒させられるようなものでしょう。彼らの使っていたツールは、今日では見受けられるような頻繁な変更や統合を扱えるようには設計されていませんでした。組織の変更プロセスが、システム中の変更よりももっと時間がかかるというケースを最近では多く見かけます。この変更プロセスにおけるオーバヘッドは、しばしば変更管理ツールの欠陥といえます。今回の例では、それは古い構成管理システム、ExcelそしてVBマクロによるものでした。

まとめると、このエンジニアリング部門は、3つの重要なチャレンジに直面していました。

  • Excelは計画策定やプロダクトラインにまたがる作業の追跡には不十分であった。そのプロセスは、複数のプロダクトラインにまたがる変更を管理して優先順位付けようとし、そしてどの変更がどのバリアントに対してなされたのか、ある特定の変更が特定のバリアントになされたのはいつだったかということを理解しようとしたとき、そのプロセスはバラバラでうまく機能しなかった。
  • ブランチ・ベースの構成管理ソフトウェアは、アジャイルな継続的インテグレーションのニーズには十分に答えられなかった。コードへの変更を作業タスクへと簡単に対応付ける方法がなく、以前の幾つかの製品バリアントに誰がどんな変更をしたのかを理解するのは困難であった。彼らの構成管理ツールは、複雑なマージをする上で助けにならず、その結果、マージを受け持つインテグレーターという役割を必要とするに至った。インテグレーターはボトルネックとなり、変更のデリバリーを遅延させた。
  • エンジニアリング・マネージャは、ExcelスプレッドシートにVBマクロをつくり開発用のリポジトリーに状況情報を連携させるのに無駄な時間を費やすことになった。

Rational Team Concertを使ったアジャイルの採用

このチームは、これらのチャレンジに取り組むためにRational Team Concertを採用することにしました。この組織は主に3つのニーズを持っていました。

  • より強力な構成管理ツール
    彼らは、ある変更をある製品バリアントに含めるよう選択したときに、マージすべき全てのファイルのバリアントをより簡単に特定するのを助けるソリューションを求めていた。それにより変更を取り込むのがより簡単になり、インテグレーターの役割を必要としないことを目指した。この構成管理ソフトウェアは、Excelスプレッドシートのタスクとコードへの変更との関連性をサポートし、その変更が別の製品バリアントに再度適用される際にどういったコードへの変更がなされるのかをよりよく理解できるようにすることが求められた。
  • プロダクトラインにまたがる単純化された計画策定
    彼らは、複数の製品バリアントにまたがり適用されるある一つの共通の変更に対して、別々ではあるが関連づけられている幾つかのタスクを生成し、それらのタスクを独立に管理し優先順位付けできるようにしたかった。これらの作業タスクは関連付けられ、その結果CPLは、その障害あるいは拡張要求がどのプロダクトラインに反映されているかを説明でき、開発チームは、その障害あるいは拡張要求のためのコードの変更の場所を特定できることを目指した。そして、あるプロダクトライン中あるいはプロダクトラインをまたぐ作業を容易にスケジュールできるようにする必要があった。
  • より簡単でより良い開発状況のリアルタイム可視性
    エンジニアリング・マネージャはVBマクロを作り変えたり開発プロセスの状況を得るために実行したりするのにうんざりしていた。

より強力な構成管理ソリューション

このセクションでは、このチームがいかにRational Team Concertを使って構成管理に関する彼らのチャレンジに取り組んだのかについて説明します。

コードの変更を作業に関連付けること

この最初のニーズに取り組むため、Rational Team Concertは、「ワークアイテム」への自動的な関連付けをできるようにしています。ソフトウェア開発者は、簡単に一連のコードへの変更をそれに割り当てられている作業タスクと関連付けることができます。図6にある画面の断片は、ワークアイテムと関連付けられたファイルへの変更を示しています。これにより開発者は、別のプロダクトラインにはどのような変更がなされたのかということを、迅速にコードのブランチを見ることなく容易に見つけ出すことができます。Rational Team Concertを使う前は、エンジニアはコードのブランチを見て、他の誰かがもう一つの製品に何をしたかを探す必要がありました。今では、簡単に作業タスクを探し当て、全ての関連付けられた変更セットをみることができます。

更に、開発者はRational Team Concertを使って、同じワークスペースの中で、複数の変更に対して同時に作業をすることができます。彼らは、ソースコードリポジトリのコピーをローカルに複数作ってどのコピーがどの変更に対応するかといったことを気にする必要はありません。開発者は、単純にワークアイテムを選んで中断または再開と指定し、そうするとRational Team Concertが、変更を保持したローカルなサンドボックスを自動的に構成してくれます。

図 6. Rational Team Concert中での複数の変更作業
Rational Team Concert中での複数の変更作業

ストリーム・ベースの構成管理

Rational Team Concertのストリーム・ベースの構成管理は、より簡単でより強力なプロダクトラインへの変更を管理するアプローチを提供します。図5は、個々の変更を選んで関連する全てのファイルを見つけてマージすることのチャレンジを示していました。Rational Team Concertは、ストリーム(製品バリアント)にマージしなければならない全てのファイルの変更を自動的に特定してくれます。

図 7. Rational Team Concertのストリームを使ったプロダクトラインへの変更の統合
Rational Team Concertのストリームを使ったプロダクトラインへの変更の統合

一つの制限といえるのは、Rational Team Concertが、変更セットをばらばらな順序で取り込まねばならない場合は「パッチ」という方法を使う点です。パッチ機構の課題といえる点は、共通な変更へのトレーサビリティを失ってしまうことです。(ただ、この制限に対するソリューションはこの記事のあとのほうで示されます。)Rational Team Concert開発チームは、より良いソリューションが必要であることは理解しており、この問題に取り組むための幾つかの作業項目が、Rational Team Concert開発のバックログの中に存在しています。より詳しくはRational Team Concertのワークアイテム番号 128329 (US)を見てください。

複雑なマージへの手助け

Rational Team Concertは、複雑なマージへの対応を幾つかの方法で提供します。まずは、ある新しいストリーム(製品バリアント)へある変更をマージするために必要な全ての要素のビューを提供します。これで、どのファイルのマージが必要かということで間違えることがなくなります。Rational Team Concertは、それぞれの変更セットに対するファイルをリストし、このマージでどこに衝突の可能性があるかを提示します。

図 8. Rational Team Concertでのマージ
Rational Team Concertでのマージ

開発者は、複雑なマージの前に各自のワークスペースのスナップショットをとることもできます。マージの最中に、Rational Team Concertは、マージに関連した全ての変更を、区別された変更セットの中に自動的に保存します。もしマージがうまくいかない場合は、開発者はその変更セットを中断または破棄し、スナップショットの状態に戻ることができます。

図 9. ワークスペースのスナップショット
ワークスペースのスナップショット

プロダクトラインをまたぐ作業のためのリンクされた複数のタスク

開発者は、基のワークアイテムへの参照をもつ独立したコピーであるワークアイテムを「複製」できます。複製ワークアイテムは、ファームウェア・チームにとって、複数のプロダクトラインにまたがって行われる作業を生成するのに役に立ちます。独立した(しかしリンクされた)ワークアイテムは、別々に計画され具体的に取り組んでいくことになります。基になるワークアイテム上でこれらのリンク群をすばやく確認し、他のどのバリアントがこの変更を対象としており、既に変更を適用されたのかどうかといったことを見て取ることができます。

図10では、ストーリー174が、ストーリー57の複製として作られています。開発者が、ストーリー174にて作業を開始し、(ストーリー174で強調表示されている)ストーリー57へのリンクをたどっていくことができます。そして、(ストーリー57で強調表示され赤く表示された変更セットである)ストーリー57の変更セットを自分のワークスペースに受理できます。このストーリーの変更セットを受理すると、開発者のワークスペースへ全ての差分が自動的に置かれることになります。図に示されるように、マージに必要となる新しい変更が新しい変更セット中に自動的に置かれ、ストーリー174に関連付けられます。

図 10. Rational Team Concert中でのプロダクトラインをまたぐ作業のリンク
Rational Team Concert中でのプロダクトラインをまたぐ作業のリンク

プロセス支援

ファームウェア・チームは、Rational Team Concertのプロセス・コントロールを使うこともできます。ビルドの失敗は、継続的インテグレーション・プラクティスを使うアジャイル・チームにとって劇的に進行を遅らせることになります。Rational Team Concertは、様々なチームがストリームへのデリバリーをするのを容易にコントロールできるようにし、それによって、ある顧客へのリリースのために現在計画されている作業のみがデリバリーを可能とするようにすることができます。動作できているソフトウェアなら何でもイテレーション中で提出してもよいだろうと考える方もいるかもしれませんが、組込みソフトウェアは時間的空間的な問題に対して敏感であり、現行のイテレーションにて計画されていないソフトウェアは、来るべきリリースから逸れていってビルドの失敗を招いてしまうかもしれません。

一方でファームウェア・チームは、エンジニア同士が協調しながら将来に向けたソリューションの実現を追及していくようにもしたかったわけです。そこで取った方策は、顧客ストリームに対しては厳格なデリバリー・ポリシーを強制し、Rational Team Concertの「サンドボックス」チームというのを作って、そのチームではもっと緩やかなデリバリールールを置くというものでした。このサンドボックス・チームのメンバーである開発者は、協調するために制限がより少ない追加のストリームをつくってもよいことになっていました。

プロダクトラインを跨る簡単化された計画策定

スプレッドシートによる計画策定は、たくさんの限界を露呈します。プロダクトラインにまたがった複製作業を管理し追跡するのは困難ですし、優先順位付けを再考するのも困難です。その中で作業項目を詳細化するのは、作ったり移動したりが非常に大変なので気が引けるものです。結果として、ある変更に関連付けられるたくさんの作業タスク(ハードウェア・テストベンチへの更新、開発ツールへの変更)は、うまく追跡できずどこかに失われてしまうかもしれません。

子ワークアイテム

Rational Team Concertは、ワークアイテム間の関連性を単純化する最初の問題トラッキング・システムの一つでした。このソフトウェアは、関連性をつくり、後でたどったり問い合わせたりすることを簡単にできます。組込みシステム開発は、ファームウェアの変更がなされると、さらに下流工程の作業を必要とするかもしれません。それらは、テストワークベンチ、顧客向け開発ツール、ユーザ・ドキュメントそれぞれへの更新といったものです。もちろん、それらのタスクを紛失するわけにはいきません。

これらのタスクはスプレッドシートによる計画策定では出てこないかもしれません。その結果忘れ去られてしまう恐れがあります。Rational Team Concertのワークアイテム間の関連は、エンジニアがこの追加作業を定義し、それがデリバリー前に完了していることを確実にするために追跡するということを可能にします。

プロダクトラインをまたぐ計画策定

複数のプロダクトラインをまたぐ計画策定は、スプレッドシートを長く大きくしてしまいました。CPLとファームウェア・チームは、どのイテレーションにてどの作業が計画され、イテレーション間で作業を簡単に移動できる仕組みを必要としていました。

Rational Team Concertのアジャイル計画策定ケーパビリティは、これらのたくさんの課題への解を与えました。作業はたくさんのカスタマイズされた計画モードで見ることができ、CPL(製品オーナー)が単一のプロダクトラインについて作業を見渡すことを可能にしました。Rational Team Concertがインストールされた次の週から、CPLとファームウェア・チームのリーダーは、スプレッドシートではなく、この計画策定ツールを使い、週二の計画策定ミーティングをうまく回すことができました。

図 11. スプレッドシートとRational Team Concertの計画策定の比較
スプレッドシートとRational Team Concertの計画策定の比較

Rational Team Concertの使用は成功であったのですが、複数のタイムラインをまたいだ計画策定では幾つかの課題があります。その計画策定はアジャイル原則に基づいています。タイムラインは、入れ子になったイテレーションの中に分解されていき、どのレベルでも一つのイテレーションのみが現行のものということになります。(リリース2.1のスプリント3という具合です。)アジャイル・チームは、単一のタイムラインに対して作業します。これらのアジャイル・プラクティスをサポートするために、計画は、単一のチーム(あるいはチーム群から成るチーム)と計画策定や作業の追跡に関する単一のイテレーション(リリースかスプリント)に対応付けられます。プロダクトライン・システムでは、単一のチームは複数のプロダクトラインに対し作業をしており、それぞれごとにスケジュールが決まっています。

ここで問題となるのは、単一のチーム(ファームウェア)が、顧客バリアントそれぞれに対して一つの、全体としては複数のバックログに対して作業をしている状況です。異なる顧客のための作業を理解するために、ファームウェア・チームは、その計画の「計画対象(Planned For)」プロパティを絶えず変更することが必要になります。あるアジャイルの支持者は、CPLたちは顧客をまたがって内部的に作業の優先順位をつけ、単一の統一されたバックログをファームウェア・チームに提示すべきである、と主張するかもしれません。しかし、それは道理にかなった要求ではありません。Rational Team Concertへの機能拡張要求で、「単一の計画で複数のタイムラインが選択できること」に関するものがあります。(詳しくは、Rational Team Concertのワークアイテム番号 94056 (US)を見てください。)

この組織はCPLたちが別々のタイムラインで作業を追跡すると決めました。アジャイル・チームらがそれぞれの作業をみるときは、彼らの計画がどのタイムラインを参照するのかを切り替えます。理想的な策ではないのですが、計画のタイムラインを変えるというのはよい代替策でした。そして全体としてスプレッドシートよりは、かなり良い方法となっています。

より簡単でより良い開発状況のリアルタイムな可視化

エンジニアリング活動の状況と実施を報告するために、エンジニアリング・マネージャは以前の課題トラッキング・システムからデータを引き出すExcelのVisual Basicスクリプトを作成していました。Rational Team Concertのワークアイテム・クエリやダッシュボードは進捗を追跡する労力不要のソリューションを提供してくれました。このエンジニアリング・マネージャはRational Team Concertが使用可能になった最初の週から自分のダッシュボードを構成することを始めました。

図 12. Project visibility in Rational Team Concert
Screen captures of graphs and reports

まとめ

この記事は、組込み機器を複数のプロダクトラインにまたがって開発しているある遠隔通信機器サプライヤーが、アジャイル・プラクティスをどのように適用しているかを説明しています。ビジネスが顧客基盤を成長させようとするにつれ、ファームウェア・チームは幾つかの要因の組合せによる、デリバリーのスケジュールを守ることへのチャレンジに直面しました。

  • Excelは計画策定やプロダクトラインにまたがる作業の追跡には不十分であった。そのプロセスは、複数のプロダクトラインにまたがる変更を管理して優先順位付けようとし、そしてどの変更がどのバリアントに対してなされたのか、ある特定の変更が特定のバリアントになされたのはいつだったかということを理解しようとしたとき、そのプロセスはバラバラでうまく機能しなかった。
  • ブランチ・ベースの構成管理ソフトウェアは、アジャイルな継続的インテグレーションのニーズには十分に答えられなかった。コードへの変更を作業タスクへと簡単に対応付ける方法がなく、以前の幾つかの製品バリアントに誰がどんな変更をしたのかを理解するのは困難であった。彼らの構成管理ツールは、複雑なマージをする上で助けにならず、その結果、マージを受け持つインテグレーターという役割を必要とするに至った。インテグレーターはボトルネックとなり、変更のデリバリーを遅延させた。
  • エンジニアリング・マネージャは、ExcelスプレッドシートにVBマクロをつくり開発用のリポジトリーに状況情報を連携させるのに無駄な時間を費やすことになった。

Rational Team Concertは、以下の表にあるような変更によりほとんど全てのこれらの問題を解決することができました。

表 1. Rational Team Concertにより解決できた変更
変更の種別事前事後
計画策定 Microsoft Excel スプレッドシート Rational Team Concertアジャイル計画
複製された作業をプロダクトラインをまたいで追跡すること スプレッドシートの複数のタブの間で特定しようとする 関連するワークアイテム同士をリンクする
製品バリアントのためのコードを管理すること 構成管理ツールのブランチ バリアントごとのRational Team Concertストリーム
以前の製品バージョン中の作業を特定すること 構成管理ツールで適切なブランチを見つける Rational Team Concertワークアイテムに関連付けられた変更セットを見る
誰がコードを統合したか 特別なインテグレーター 全員
複雑なマージをすること 間違えやすいブランチ・ベースのマージ・プロセス 顧客ストリームへの変更セットの提出によりRational Team Concertがマージに必要なファイルを特定する
テストベンチや顧客向け開発ツールにまつわる追加作業 ファームウェア・チームが気に留めておくこと Rational Team Concert の子ワークアイテム
状況確認 ExcelのVBマクロ Rational Team Concertのダッシュボードと計画

興味深い事実として指摘しておきますが、このカスタマーと最初に会話したときは、ブランチ・ベースのインテグレーションが議論した問題でした。しかし、直ぐに彼らは、Rational Team Concertのワークアイテムと計画策定の能力がプロダクトラインの計画策定と追跡にずっと良いソリューションであるだろうということを認識したのです。

訳者について

三ツ井欽一は、東京ソフトウェア開発研究所に所属するラショナル・システムズ開発担当マネージャーです。ラショナル・ソリューションの普及とお客様へ提供する価値の向上に日々取り組んでいます。

参考文献

学ぶために

製品や技術を入手するために

  • Rational Team Concert はこちらからダウンロードできます。 Jazz.net (US)。ご希望であれば(要登録)、10人まで無料で試用いただけます。 また、ご自分のシステムにインストールせずともサンドボックス中で試用することも可能です。
  • 目的に応じてIBMソフトウェアの評価ができます。ダウンロード、オンライン評価、クラウド環境での利用が可能です。 Evaluate IBM software (US) 。SOAサンドボックスによりサービス指向アーキテクチャの学習も可能です。 SOA Sandbox (US)。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational, DevOps
ArticleID=947037
ArticleTitle=Rational Team Concertによるアジャイルな組込みプロダクトライン開発
publish-date=10042013