・ワークフローのどの部分をソース管理ツールに任せるか 社員が上流設計フェーズに参加できる能力としては、ALMを目的としているTFSでPLMを一緒に行うわけではないことを理解し、PLMの成果物やイテレーションを理解して、参加者としてPLMのタスクのステータスを推進していく必要がありました。PLMがTFS + MS Projectで管理されていようが、Git + Redmineで管理されていようが、PLMで定義された成果物に対するタスクのステータスを推進させていけば良いということになります。PLMのタスク化や成果物の定義などは、その組織や会社における製品戦略とのかかわりが強く、製品戦略における汎用的な手法（マーケティングなど）は、ALMのプロセス推進とは全く別物だからです。 一方、構築フェーズや運用フェーズでは、社員はALMの成果物とイテレーション、成果物に対するタスクのステータスを定義し、管理者として社外協力者やアライアンス、ベンダーなどをコントロールしていく必要があります。 必要な作業はロールの洗い出しと責務の定義、イテレーションの計画とイテレーション内のワークフローを構成するロールを策定することです。それらはTFSの運用設計であり、TFSにそのような機能があるわけではないからです。 前述（「プロセスを社内のワークフローに落とし込む」）のとおり、ロールには「プログラマー（コーダーを想定）」と「SE（コーダーとペアプログラミングを組む相手を想定）」および「ビルド管理者（開発責任者を想定）」を設定しました。このロールがワークフロー内でステートを推進していきます。イテレーションはワークフローのステートが完了まで行くことと換言できます。ステートが完了まで行くことで振り返りができ、次のイテレーションにフィードバックできるからです。CMMIの場合、確立されたプロセスに則った実践が、メンバーの習熟度を向上させるのに対して、Agileではイテレーションを繰り返すことでプロセスを完成させていく（または時代に合わせて変化させていく）というアプローチが採られることに注意が必要です。それが、Agile Unified ProcessではUnified Processを組織に合った形に合致させていくことを目的としているため、必ず次のイテレーションにフィードバックさせる必要があるということです。 このイテレーション内で、TFSの機能をどのように使い、運用としてどのようにプロセスを推進させていくかをブランチ機能や作業項目、ワークアイテム等のTFSの機能を使って解説していきます。 まず、Main、Dev、Releaseのブランチを作成します。この手順はVersion Control […]
・プロセスを社内のワークフローに落とし込む ユニファイド・プロセスをベースに策定した試験的なプロセスを社内のワークフローに落とし込む作業には、要求～基本設計までの上流設計フェーズ、詳細設計～試験までの構築フェーズと運用フェーズに分割して提案しました。社内のワークフローをAgileに適用する際、イテレーションが同じロールで繰り返されることが習熟度につながっていき、プロセスの確立につながると考えたからです。また、このロールにキャリアを連動させることは、社員教育にもつながるという提案をしました。提案先の企業の社内ワークフローのロールとして、社員による上流設計フェーズと協力会社による構築フェーズおよび運用フェーズが定着していたためです。 つまりここでいう社員教育とは、システム調達（プロキュアメント）のキャリアラダー・プランを策定することです。社員によるTFSの管理委託ができるようになることではなく、ALMを社内に定着させ、システムの品質を管理し、ベンダーを選定する能力とコントロールする能力を開発することです。上流設計フェーズでは自らが設計に参加できる能力を持ち合わせ、構築および運用フェーズでは管理する能力を持ち合わせる必要があったため、フェーズによってTFSを使う目的が異なることを訴求することは重要でした。多くの企業において、社員のキャリア開発プランは社内のさまざまなワークフローと深く結びついてます。その企業のキャリア開発に則ったプロセスでなければALMは社内に定着しません。 上流設計に参加できる能力は、ALMの視点でのみ考えれば、Agile Unified Processにおけるイテレーションとその成果物の構成を理解することでタスクのステートを推移させていくことが可能です。上流設計フェーズのイテレーションとその成果物の構成を定義する作業については、製品戦略などと深くかかわるためPLM側の責務とし、ALMの提案書では、構築、運用フェーズにおけるイテレーションとその成果物の構成を定義する作業を提案しました。 TFSには7種類（以降に「」で括ってあります）のチケット（TFSでの呼称は「ワークアイテム」）があります。これらの種類は組織やプロジェクトに応じてすべて使っても良いし、いくつかの種類にまとめてもかまいません。提案した方法は、いくつかの「タスク」と「バグ」、「テスト」で構成された「機能」があり、その「機能」のいくつかと複数の「テスト」で構成された「ユーザーストーリー」があり、そのいくつかの「ユーザーストーリー」と複数の「テスト」および複数の「懸案事項」があるイテレーションを構成するように提案しました。TFSの7種類のワークアイテムにはすべて「状況」（ステート）があるため、このステートを管理することができます。イテレーションを通して、ワークアイテムの種類を統合していくなり、それぞれのステートを変更していくなりといった規律の確立こそが構築、運用フェーズにおけるプロセスの管理であることを訴求しました。 前述のコミットのワークフロー内でのステートの変化を以下のように提案しました。 ワークフロー内のステートの変化
業務用かどうかに関わらず、ソフトウェアの開発ではユニファイド・プロセスが重要であると考えます。ユニファイド・プロセスはAgileやScrum、Extream Programming等と相反するものではなく、ユニファイド・プロセスがカスタマイズされたものであると考えられるからです。元来、ユニファイド・プロセスはプロジェクトや組織によってカスタマイズされることを期待しており、適切なカスタマイズは、ユニファイド・プロセスの導入効果を最も発揮する重要な手法です。 業務用ソフトウェアの場合、このプロセスの単位は大小さまざまであると考えます。大きなひとつの構築プロセスと小さな改修プロセスや機能追加プロセス、技術検証プロセスなどが同時に推進していくことの方が多く、構築がひと段落してから第2フェーズの機能追加、バグ改修といった”裕福な”プロジェクトはそう多くはありません。多くの場合、運用しながら並行して機能追加や既知の潜在バグ改修といったプロジェクト推進が求められます。 このような形態のプロジェクト推進に対応しやすいと思われるのがAgile Unified Processです。Rational Unified Processを簡素化したAgile Unified Processは、規律をベースとするプロセス推進法であり、 Test-Driven Development (TDD)やAgile Modelingなどを含み、それらの作業を簡略化するツールの使用が推奨されています。Agile Unified Processは、大小さまざまな各プロセスの規律がイテレーション後に充足、改修されながら確立されていくため、最初に試験的なプロセスが必要となります。 […]