このデモではあるWebアプリケーションの開発プロジェクトにおいて、開発統括部長、ビジネス・アナリスト、製品オーナー、プロジェクト・マネージャー、開発者、テスターのそれぞれがひとつのチームとなり、イノベーションのスピードを加速し、ビジネス上非常に重要なデッドラインを守るため、各自の役割を効率的に担っていく模様をご紹介しています。 短時間でこの理想的な開発スタイルを支えるJazzプラットフォームの価値と魅力を理解していただけます。
オートデモはこちら(日本語のサイトになります)。
Jazzプラットフォームで実現するソフトウェア開発プロジェクトの姿
以下の翻訳内容をご参照ください。
イントロダクション
ジャズ・レボリューションはジャズに関連したさまざまな情報を提供する総合オンラインサイトです。何千にも及ぶデジタル化されたオリジナルの演奏情報がカタログ化されています。 ジャズ・レボリューションは世界中のジャズファンを対象としたプレミアム・サイトです。
最近、同様のサービスを提供する競合サイトが現れ、競争が激しくなってきました。それらに対抗し、新しいイノベーティブなサービスを迅速に提供し、ユーザー数を増やすことが大きな課題です。イノベーションのスピードを高めるため、開発チームはアジャイル・プラクティスを適用し、コラボレーティブなソフトウェア開発のために Rational のソリューションを適用しました。
この開発プロセスとプラットフォームを適用することで、ユーザーの求めるサービスを短時間で提供し競合サイトに対抗することが可能になりました。
開発統括部長 キャリー・ドイル
開発統括部長としてキャリー・ドイルは、ソフトウェア・デリバリーを通じて継続的にイノベーションを実現する必要があります。キャリーはまずエグゼクティブ・ダッシュボードを参照し、すべてのプロジェクトの状況を確認します。スケジュールやコスト、品質、ユーザーの信用度、リスクなどです。以前は手作業でこれらのデータを抽出していました。Rational を活用することでチームの進捗やパフォーマンスをリアルタイムに把握することが可能になりました。それもチームの作業を邪魔することなしで。
キャリーは現在ジャム・セッションについて特に気にしています。それは新しいサービスで、ミュージシャンたち一箇所に集まることなく、オンラインでレコーディングのスケジュールを組むことを可能にします。最近ジャム・セッションの計画レビューを行いました。
そのミーティングで国際ジャズ協会社長のジョン・コークランと会いました。彼の影響力の高いベータ・テスターです。ジョンは新しいサービスに大きな期待を寄せています。
彼は次に開催されるコンベンションで基調講演にキャリー・ドイルを招き、新しいサービスであるジャム・セッションのデモを依頼しました。その際に、機能要求として上げている機能状況確認も依頼してきました。それはジャム・セッションを行う前にミュージシャンが自分の演奏内容を確認すると言うものです。
ジャム・セッションのデモ依頼をうける前に、キャリーは現在のプロジェクト・ステータスを確認します。キャリーはジャム・セッション・プロジェクトを選択しドリルダウンして詳細な情報を確認します。リリース・プランの内容をレビューし、バーンダウン・チャートで進捗を確認し、ユーザーの信用度がイテレーションごとに増えていること確認しました。コストとスケジュールはターゲットを達成していることを確認し、リスクも全体にわたって減少していること確認しました。こういった透明性により、キャリーは実際のプロジェクト・データに基づいた意思決定を行ったのです。
キャリーは開発チームにジョン・コークランからの機能拡張要求の優先度を高めるよう指示を出します。ダッシュボードからジョンの機能拡張要求に関するステータスを確認します。その要求はすでに提出済みでしたが、まだプロダクト・バックログに入ったままでした。
キャリーは追加のコメントを加え、最近のジョンとの会話に基づき、この新機能の実装を次回コンベンションでのデモに間に合わすように指示を出しました。このようにダッシュボードはプロジェクトの状況はさまざまな情報ソースからデータを収集してリアルタイムなステータスを表示します。
キャリーはこれらからジャム・セッションのデモはコンベンションに間に合うことを確信しました。タイムシートで進捗をトラッキングし評価し、主要なプロジェクトをこなしていくことで、市場に対してジャズ・レボリューションの価値を高めることができます。
プロダクト・オーナー フィル・ジョンソン
ビジネス・オーナーであり、プロダクト・アナリストでもあるフィル・ジョンソンはよいアイデアを実装可能な要求に落とし込みます。フィルはダッシュボードからキャリーの要求リストを参照し最近の変更を確認します。ジャムについての新たな要求を確認し、次のイテレーションに盛り込むようプランします。彼専用にカスタマイズされたワークスペースより、ジョンの機能拡張要求を、ビジネス・プロセス・モデルやユースケース、スケッチ/ストーリーボードに展開します。
必要に応じ前のバージョンを参照することもできます。フィルは最新のストーリーボードをレビュー用に引き出し確認します。その中から最新のコメントを参照します。いくつかのマイナーな要求がすでに承認され、リリースに向けて実装済みであることを確認します。
要求に関してこのように複数の面から評価できるビューを提供することで、フィルは関係者の同意をより迅速に得ることができ、作業のやり直しを削減し、チームがよりお客様の価値にフォーカスした開発を行うこと支援できます。
フィルはプロダクト・バックログにアクセスし、ジャム・セッション・プロジェクトで上がっている要求の優先順位を変更します。次のリリースにこの要求への対応が含まれるようにするためです。 カーメンに次のリリースに含めるようメールを送ります。
フィルはダッシュボードからどの要求が実装され、テストされているか確認することができます。
Rationalダッシュボードにより効率的にステークホルダーのコンセンサスを得ることが可能になります。複数のイテレーションを通じて各要求のステータスをトラッキングできます。
つまりこれらの機能を通じてチーム全体がユーザーの最も関心の高い要求に対して優先的に開発を行うことを可能にします。
チーム・リーダー カーメン・スワォラー
チーム・リーダーとしてカーメン・スワォラーは時間とコスト、リソースを調整し予定通り、予算どおりのプロジェクトを完了させなければなりません。
チーム・メンバーと協力し一連の反復とマイルストーンを計画し実行していきます。 カーメンはちょうど完了した反復パフォーマンスをレビューし、チームが安定して開発を行い、反復を終えることにスコープを着実にこなしていることに満足します。カーメンはジョンの要求を次のマイルストーン・リリースに含めるようにというフィルのコメントを確認します。プロジェクト・バックログを開き、フィルがすでにジョンの機能拡張要求がリストの上の方に優先度を上げているのを確認します。次の反復を計画する前に、カーメンは前の反復からベロシティーの傾向をレビューします。
チームは1反復あたり20ストーリー・ポイントをこなしていること、反復ごとに安定してきていることがわかります。つまり予見性が高まっており、Rational ソリューションを適用して以来、ジャズ・レボリューションのユーザー満足度があがっていることと一致します。
カーメンはチーム・ミーティングで次の反復計画を行います。優先度の高いワークアイテムをプロダクト・バックログから取り出し反復計画に入れます。カーメンのチーム・ベロシティー評価に基づき、20ストーリー・ポイントに達したところでとめます。そしてすべてのワークアイテムがチーム・メンバーそれぞれに割り当てられます。
カーメンはタスクボードでどのタスクが完了し、どのワークが遅れているか、プロジェクトの進捗を確認します。ビルド、ストリーム、ワークアイテム、イベント・フィード、成果物のそれぞれのリアルタイム・ビューとヒストリカル・トレンドから、カーメンは自信をもってプロジェクトの舵を取ることができます。
開発者 レイ・ミッシェル
開発者として、レイ・ミッシェルのミッションはエレガントなソフトウェア・ソリューションをできるだけ効率的に創り出すことです。レイはカーメンのチーム・ミーティングに参加し次の反復をプランします。
レイは割り当てられていないワークアイテム・リストからやりたいワークを選びます。各ワークアイテムを複数タスクに分解し、それぞれのワークロードの悲観値、楽観値、最頻値を見積もります。レイやチーム・メンバーは今までオーディオの録音に関連した仕事をしたことがありませんでした。そこで悲観値にかなり多くのバッファーを入れた見積もりとしました。
そのためチームは反復の完了日に間に合わないというリスクが発生しました。このリスクを削減するため、オーディオ・セッション録音する再利用可能なアセットを検索します。高い評価の録音アセットを探し当てますが、MP3フォーマットしかサポートしていません。そのほかのフォーマットが必要かどうか判断するため、オリジナルの要求を確認します。すぐに最初のリリースではMP3フォーマットで十分であることを確認できました。チーム文書に簡単にアクセスすることで、今まで何時間、何日もかかっていた疑問が、いまや数分で解決できます。
レイは悲観値の見積もりを変更し、スケジュールについてのリスクを削減しました。レイは自分の作業がチーム全体を危険な状態にすることがなくなったという自信をもち、プロジェクトに臨みます。チームが目標を達成するために、リスクを理解し対応することは重要です。レイが自分自身でリスクを回避する見積もりを行ったことは、プロジェクト全体の見積もりに対する予見性を高めます。
レイは最初のタスクを開始します。その機能拡張に対するコードを書き上げ、個人ビルドを実行し、彼の変更がチーム・ビルドを壊すことがないことを検証します。いくつかの単体テストを行い、彼の作業結果をチーム・エリアに提出します。レイはビルドが安定していることを確認したあと、実作業時間を記録し、タスクをクローズし、テスト待ちであるという状態に変更します。
このようにRationalソリューションによって、簡単にタスクに関係する情報をアクセスしたり保管できます。また簡単にチームのプラクティスや承認されたプロセスに従うように導きます。リリース日に近づくに従い、確実なリリースを確保するためさらに各種チェックを追加します。こういったフェーズに応じたガバナンスによって、チームは実現すべきイノベーションとプロジェクトの予見性とのバランスをとることができます。
テスト・リーダー サラ・カルダー
ジャズ・レボリューションのテスト・リーダーとしてサラ・カルダーは、オンライン・サービスが使い勝手や機能性、パフォーマンス、セキュリティーの観点から問題がないことを確認します。
今までサラはチームから隔離されている感じがしていました。今回は Rational ソリューションによってハイ・パフォーマンスなチームの一員として統合されていると感じています。
サラはダッシュボードからいくつかのワークアイテムが追加のテストを必要としていることを気づきました。新たなチーム・ビルドが提出されたこと、機能拡張要求がテスト待ちになっていること、要求テスト完了率が100%に達していないことです。テストを必要としているあらたな要求をドリルダウンします。その機能拡張を検証する新しくテストケースを作成します。
そしてスケジュール、担当者などテストケースの詳細を定義します。新機能を検証するテスト・スクリプトを記述します。それからテスト用のPCを予約し、正しくビルドが行えるようセットアップし、自動的にテスト・スクリプトが実行できるよう記録します。
サラは自分のワークスペース内で、テストを計画し、実行するのに必要なすべてにアクセスできます。要求の詳細や、計画アイテム、ビルド、手作業で行うテスト、テストケースの作成など、実際にソフトウェアをテストするための環境のセットアップすべてです。テスト・スクリプトをテストPC上に構成した異なるブラウザーで実行しようとしたところ、テストが失敗しました。サラはそのビルドに対して障害を記録します。
その障害は自動的にチーム・リーダーのカーメンにダッシュボードとeメールにて回覧されます。
このリアルタイムな通知機能によって、チーム・リーダーは迅速にこの障害の解決を最適な担当者に割り当てることができます。カーメンはレイにこの障害を割り当てました。彼はすぐに問題を認識し、解決し、次のチーム・ビルドに修正を提出しました。
提出された修正は自動的にサラのテスト項目に追加され、テストが実行されました。今回はテストは成功したため、サラはその結果を記録し、その機能要求はリリース可能であるというステータスに変更しました。
このように障害の検出から解決までのソフトウェア・ライフサイクル自動化によって、チームはより付加価値の高いアクティビティーに集中し、非効率でつまらない手作業から開放されます。
サラとフィルはそれぞれのダッシュボードから、全体の品質とジャム・セッションの要求に対する達成率をレビューします。コンベンションまで1ヶ月を残し、チームはすぐれた計画と実行により、期待された結果を達成できました。
まとめ
キャリーのチームがジャズ・ライブ・キーノートで行ったジャム・セッションのデモは大成功でした。このおかげもあって会社はこの四半期で20%のユーザー数増加を達成しました。
キャリーはこの成功は Rational ソリューションによるところが大きいと感じています。チームが根本的に変革し、コラボレーティブに透明性の高いソフトウェア開発が実現できたのです。特にキャリーは重要な改善のポイントはチームの能力にあったと思っています。
- 地理的、機能的、組織的に分かれているものを横断したコラボレーション
- チーム・プロセスとワークフローの自動化
- プロジェクトを成功に導くために欠かせないチーム・ステータスとメトリクスなどのレポート
IBM Rational がどのようにあなたのビジネスに貢献するか、単一の機能から、エンド・トゥ・エンドのソリューションまで、また柔軟なクラウド・ソリューションのオプションも加わり、各種詳細はこちらのリソースをご参照ください。
Application lifecycle management (ALM) (US)
IBM, IBMロゴ, ibm.com, Rationalは、世界の多くの国で登録されたInternational Business Machines Corp.の商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、http://www.ibm.com/legal/copytrade.shtml(US)をご覧ください。
