政府プロジェクトのアジャイルアプローチへの挑戦

前回のアジャイルの議論ここでは何であるかを指定良い答えを持っていた重要なソフトウェア開発におけるアジャイルの方法論を実装の成功に。ポイントのほとんどは典型的な組織および管理の課題でしたが、1つのポイントは私を心配し、クライアントはプロセス全体に関与しなければならないということです。

クライアントは現実的に制御できないものの1つです。おそらく、ビジネスモデルは政府の請負業務に向いています。たとえば、厳しく厳しい契約が会社に次の義務を負わせている場合などです。

• 要求どおりにX機能を提供する

• 機能のリクエストは壁を越えて投げられますが、私たちはそれを聞きたくありません。

• 顧客の頭の中には機能の優先順位という概念はありません。それらはすべて重要であるか、私たちがそれらを要求しなかったでしょう。

• このプロジェクトは、オーバーランや締め切りに関係なく、Y以上の費用がかかりません。

• すべての作業を完全に実施するための、絶対的、厳格、最終的、交渉不能の期限。

私たちは以前にそのようなクライアントと仕事をしたことはありませんでしたが、プロジェクトのお金は過ぎ去るにはあまりにも良いです。この作業が必要です。

私はここに来て、HARDでプロセスを変更してアジャイル開発に移行しました。ここで、このプロジェクトが新しいプロセスに適合する場所を調整する方法がわかりません。私はこれまでに開発チームとプロセスをこの道に導くと信じていたオープンマインドなハンドオフ管理の贅沢を持っていませんでしたが、私たちはここにいるので、このプロジェクトが本当にアジャイルな方法。経営陣はこの道をリードしてくれると私を信じており、私たちが今いるこの状況はウォーターフォールを明確に要求しているので、彼らを失望させたと感じています。今バックトラックすると、彼らの信頼を失うかもしれないと思う。

ここにあるような他の答えは、この種のクライアントではアジャイルが不可能だと言っていますが、同意しますか？似たような状況にあり、それを機能させた人はいますか？アジャイルを成功させるためにどのような戦略を実装しましたか？

最初に気付くのは、アジャイルであることとアジャイルであることには違いがあるということです。アジャイルの技術と特性をゆっくりと展開する-機能横断型チーム、適応計画、進化的/増分的配信、タイムボックス化された反復、そしてリーンからのコンセプトの導入は、エクストリームプログラミング、スクラム、またはクリスタルの導入とは大きく異なります。

顧客の関与を明示的に述べます。はい、アジャイル手法の多くは顧客の関与を求めていますが、アジャイルである必要はありません。すべての政府/防衛関連プログラムでは、顧客との接点であるプログラムまたはプロジェクトマネージャーが常にいました。この人が「顧客の声」になります。電話会議、電子メール、または電話をかけて明確化するため、速度は低下する可能性がありますが、チームの顧客代表である1人の人物（または副PMもいる場合はグループ）を持つことができます。確かに、まったく同じではありません。しかし、柔軟性を持ち、変化に対応することについてアジャイルではありませんか？

また、いくつかの重要な概念についても説明します。事前定義された要件、「壁を越えて」機能要求を行う、「すべてが重要」であるため優先順位が付けられない、固定コストおよび/または固定スケジュールのプロジェクト。これらはそれぞれ異なる方法で対処できます。

すべての要件を前もって持っていると思う場合、そうではない可能性があります。要件は変わります。「完成して承認済み」の仕様を持っているからといって、それが石に固まっているわけではありません。どんな要件文書を持っているとしても、契約書で指定された方法で快適に感じる方法をキャプチャし、要件、設計、アーキテクチャを提供します。さらに、これらが生きているドキュメントであるかどうかを確認します（今日仕事で見たデザインドキュメントはリビジョンGとラベル付けされています。つまり、8回目の更新です）。特定のイテレーションでTBDとしてどれだけ離れることができるか、そして今どの程度固める必要があるかを尋ねます。

ドキュメントを機敏に操作してください。「チームが望んでいること」と「顧客が望んでいること」の間で努力を繰り返さないでください。たとえば、顧客が従来のソフトウェア要件仕様を望み、チームがユーザーストーリーを使用したい場合、時間を費やさないように、従来のSRSに適応し、ユーザーストーリーの代わりにアクションアイテムとローリングアクションアイテムリストを使用してください「システムは...」と「理由」の両方を策定する。ただし、プロジェクト間の違いに適応するためには、チームの規律が必要です。反射の問題をキャプチャします。

開発に着手したら、5回または6回の反復を実行し、顧客を施設に招待して実装のサブセットを確認します。このプロセスをすすぎ、繰り返します。いくつかの方法で求められる継続的な関与ではありませんが、可視性が高いという利点があります。顧客から「いいえ」と言われたら、少なくとも試してみました。彼らがイエスと言うなら、あなたは彼らが敏beingであることを悟ることができます。私が行っていた1つのプロジェクトで、顧客は数か月（通常3〜5か月）ごとにサイトを訪問しました。彼らは私たちがQAテストを通過するのを見て、エンジニアと懸念を話し合い、プログラム/プロジェクトオフィスとビジネスをします。全員が同じページにアクセスできる機会でした。

テストとメンテナンスは、他のアジャイルプロジェクトと同じように行われます。適切な方法でテスト手順を作成し、欠陥を文書化し、契約上の義務ごとにメトリックを追跡し、テスト結果を文書化します。TDDをフォローしたい場合は、ぜひ行ってください。継続的インテグレーションも良いアイデアです。プロジェクトステータスのミーティング中に、プロジェクトマネージャーはこの情報を使用して、「N個の要件を実装し、M個のテストを行い、X個のテストに合格」と言い、お金のある人のプロジェクトの健全性とステータスを更新します。

お金について言えば、固定コストや固定スケジュールの問題があります。

固定されたスケジュールを扱うことはかなり簡単です。要件を考えると、完了できる反復の数がわかります。各イテレーションのワークロードは、実装、テスト、および統合する機能の観点からはかなり固まっています。難しいかもしれませんが、機能を分割して事前に反復に割り当てることは不可能ではありません。これは、顧客を招待するという私のポイントに戻ります。1年で、2週間の反復を使用している場合は、四半期ごとに顧客を招待し（四半期ごとに顧客を招待し）、前の作業の結果を示します。要件の優先順位付け、将来の計画、およびスケジューリングの進め方を彼らに見せてください。

固定予算の取り扱いも同様です。どれだけの時間があるか、プロジェクトにどれだけのリソースがあるか、どれくらいの費用がかかるか、したがって反復ごとに誰もが作業できる時間を知っています。誰もがこれを注意深く追跡することを保証するだけの問題です。あなたの会社が残業のコストを食うことができるなら、それを手に入れてください。それ以外の場合は、全員が適切な時間を働いていることを確認し、優れた時間管理スキルとタイムボクシングを使用して、全員の生産性を維持します。生産性の高い時間は、コストを抑えるために必要なものです。会議やオーバーヘッドのコストなしで、より付加価値の高いドキュメントとソフトウェアを提供します。

最終的には、必ずしもアジャイルであるということではなく、アジャイルを良いものにし、アジャイルにするものを適用することです。要件の変更に対応したり、顧客が望まない場合でも頻繁にソフトウェアを配信したり、付加価値のあるドキュメントのみを作成したりすることができます（契約上作成する義務があるものは何でも）。

はい、そのようなプロジェクトにはアジャイルは適切ではありません。要件がすでに行われ、固定されているように聞こえるからです。ウォーターフォールは、顧客の規律がきちんと整っていて、書面で彼らが望むものを正確に伝えることができればうまく機能します。彼らは間違っているかもしれませんが、少なくともあなたはそれを書面で持っており、あなたがそれを届けるとあなたは報酬を受け取ります。（もちろん、これは顧客満足度を意味するものではありません。彼らが実際に必要としないものを提供する可能性があります。）

アジャイルは、あなたが持っていない問題を解決するために作成されました：要件の不確実性によるリスク。

顧客が変更リクエストを要求することはありますが、次の2つのパスのいずれかに従う必要があります。

1. お金がとても良かったので、プロジェクトのさまざまな段階でX個の新機能を吸収し、シャツを失うことなく出てきます。
2. 最初に顧客に厳しい価格を交渉することにより、新しい機能要求ごとに、価格が変更注文を生成し、それに付随する購入注文（または元の発注書）を実装します。変更命令は、機能またはスケジュールへの影響を詳しく説明します。期限を変更できないと言う場合、プロジェクトを進めると、後で変更するのに費用がかかるため、変更命令は指数関数的に高くなります。

関係＃1では関係がより友好的に感じられますが、事実、価格で絞れない購買部門を見つけることは非常にまれなので、ほとんどの場合、状況＃2にいます。つまり、関係は対立的ですが、ビジネスで生き残るためには、地位を保ちながら関係をうまく管理する必要があります。これはプロジェクトマネージャーの仕事の大部分です。

状況＃1にいるように思えますが、これは良いことです。私は、すべての後、彼らは支出していないため、政府との契約は、彼らはお金を気にしない唯一の場所です想像彼らのお金を、彼らは費やしているあなたのお金を。

...政府との契約作業。例えば、厳しく厳しい契約が会社に以下を義務付けている場合

最初。厳しいです。しかし、柔軟性はありません。それは、単に細部への注意と、変更命令の長く長いストリングを必要とします。

政府機関は実際、ゆっくりと非効率的な方法で機敏です。常に正式で詳細な変更要求を作成（および交渉）する必要があります。

要求どおりにX機能を提供する

変更命令によって変更されるまで。

機能のリクエストは壁を越えて投げられますが、私たちはそれを聞きたくありません。

コミュニケーションのチャネルは変更命令です。予算とスケジュールの影響。

顧客の頭の中には機能の優先順位という概念はありません。それらはすべて重要であるか、私たちがそれらを要求しなかったでしょう。

これは回避するのが難しいです。「要件分析」に多額のお金を費やしている非政府系企業でさえ、優先度とトレードオフの情報に邪魔されない、大きくて平らな、蒸し暑い要件の山が不完全であることを知らせたくありません。彼らはすべてを得るために良いお金を払ったの要件を満たす。どうしたらもっと情報が欲しいですか？

これは難しい問題です。

このプロジェクトは、オーバーランや締め切りに関係なく、Y以上の費用がかかりません。

変更要求を除きます。Yと締切を変更します。

すべての作業を完全に実施するための、絶対的、厳格、最終的、交渉不能の期限。

「交渉不可」は一般的に真実ではありません。交渉可能です。交渉するのは辛いだけです。

政府機関との交渉の重要な部分は、コストとスケジュールの変更のために「弁護士レベルの証拠」が必要であるという事実です。優れたパワーポイントスライドを使用したいくつかの注意深い技術プレゼンテーションは、「証拠」ではありません。主張するには多くの文書が必要です。

政府関係者は、これを可能な限り安価で効果的なものにするために、力を尽くしてすべてを実行したという申し分のない証拠を提供する必要があります。彼らは、すべての決定が公共の報道機関で再現され、後から見直されることを知っています。

ソフトウェア開発の複雑さ、および政府の仕事の事後、「月曜日の朝のクォーターバック」の側面は、彼らが作る消極的な証拠を圧倒せずに契約を変更することは。

適切にアジャイルなアプローチを困難にします。

「プロセスとツールに対する個人と相互作用」は難しいです。あなたは個人と仕事をしていませんが、仕事をしている政府の代表者はプロセスによって制約されています。

このようなプロジェクトでは、彼らはあなたの手をスコープ、リソース、および時間に結び付けました。管理しなければならないのは品質だけです。そう...

他の方法で得られるアジャイルなアプローチの利点を最大限に活用することはできませんが、品質リスクを軽減し、問題をクライアントに早く通知することができます。

だからできる限り機敏に：

1. 要件を確認し、技術的なリスクを考慮して優先順位を付けます。バックログとして優先順位付けされた要件を設定します。
2. スプリントのバックログを処理します。スプリントの機能を設計、テスト、コーディングします。クライアントとの対話が欠落しているため、要件ドキュメントはこのアクティビティのクライアントを表す必要があります。
3. 各スプリントレビューにクライアントを招待します。彼らはノーと言うことができますが、彼らはイエスと言うかもしれません。そして、あなたは後でよりも早くフィードバックを得るでしょう。

締め切りに対して実行を開始すると、何が行われたかを示すことができます。おそらく、その時点で、クライアントは、すべてを取得するつもりはないことを知って、何をしたいのかを伝えるのに十分な優先順位を付けます。また、最もリスクの高い処理を行う必要があります。つまり、締め切り時刻のタスクは、余分な時間を費やすのが一番簡単です。

このタイプのクライアントは普通ではないと思います。あなたは以前に同様のプロジェクトを要求したグループを扱っているので、彼らは彼らが望むものを正確に知っています。それらの仕様が変更されることは決して言及しません。

要求どおりにX機能を提供する

提案どおりにX機能をあいまいに提供し、すぐに変更する準備ができていれば幸運です。

機能のリクエストは壁を越えて投げられますが、私たちはそれを聞きたくありません。

彼らが何を望んでいるかわかっているなら、それを構築してください。

顧客の頭の中には機能の優先順位という概念はありません。それらはすべて重要であるか、私たちがそれらを要求しなかったでしょう。

これで負けることはできません。必要に応じてビルドしてください。

このプロジェクトは、オーバーランや締め切りに関係なく、Y以上の費用がかかりません。すべての作業を完全に実施するための、絶対的、厳格、最終的、交渉不能の期限。

あなたが政府のためのプロジェクトを一度も構築したことがないなら、それは難しいものです。履歴がある場合は、配信できるかどうかを判断できる場合があります。これは、彼らがうまく支払っていない（10ドルのハンマーで50ドルを払っていることで悪名高い）、または不合理な期待があるという意味ではありません。これらの仕様では、チームの誰かが顧客として行動し、仕様と比較して作業を承認する必要があります。欠陥を見つけて要件を変更するように頼んだとしても、おそらくそうではないでしょう。

悲しいことに、あなたが説明したのは、ソフトウェアプロジェクトにどのように取り組むべきかについての典型的な顧客の見解です。これは、顧客が不合理だと言っているわけではありません。結局のところ、これは他の何か（たとえば、家）の構築を実行する方法ではありませんか？とはいえ、私が実際に知っていること以上のものは提供していません。あなたが求めているのは...アジャイルプラクティスの適用はこの状況で実行可能ですか？

あなたが説明する状況に多くの点で似ているプロジェクトを終えたばかりの利点があります。

1. 修正された（石で、地獄か高水で）締め切り。
2. 機能要件ドキュメント（「聖書」）。当然のことながら不十分です。
3. 従来の役割：プロジェクトマネージャー、ビジネスアナリスト。
4. 弱いエンゲージメントビジネスユーザー（「製品スポンサーなし」と言えますか？）。

...そしてもちろん、先見の明のある開発チームは、上記にもかかわらず、アジャイルな方法で作業しようとしています：

1. 2週間の反復。
2. スタンドアップ;
3. 回顧;
4. ペアプログラミング;
5. TDD;
6. 継続的インテグレーション。

ただし、ビジネスにとってこれはリモートで意味のあるものですか？いいえ。締め切りの2か月前まで、慎重に観察された反復と計画会議までは、頭のない鶏の炎の狂乱に見捨てられました。

他の人が上で提供した答えは、多かれ少なかれ妥協です。私の意見では、アジャイル（「アジャイル」または「アジャイル」）は、妥協すると有害な方法で「行われ」ます。私の考えでは：

妥協やアジャイルはありません。

アジャイルの精神は、追いかけ、無駄を取り除き、残酷に自分自身に正直であることです。大規模なプロジェクトでのソフトウェアの見積もりがせいぜいギャンブルであることは、今では十分に文書化され、否定できない事実です。これの見込み客を教育することは、ソフトウェアの専門家としての私たちの義務ではありませんか？クライアントが私たちが専門家であることを受け入れたくない場合、立ち去るのは私たちの職業上の義務ではありませんか？

私が今いる場所で働き始めたとき、私はあなたがよく尋ねたのと同じ質問をしていることに気づきました。政府との契約で滝について言わなければならないことがあります。皮肉なことに、アジャイルは政府の顧客（現実的には滝のように働く）の流行語になっているため、基本的に柔軟性のない顧客とのアジャイルプロセスの実装はさらに難しくなっています。

「Scrummerfall」、「Agilefall」、または「A mess」と呼ばれるシステムがありますが、この（ガルガンチュアン）プロジェクトが長年にわたって前進しているため、多くの点で徐々にアジャイルプロセスを採用することができました。 。私たちが行った方法の1つは、基本的に、顧客とは対照的に、システムのユーザーとの通信経路を見つけることです。私たちの顧客は任命された役人が率いる息苦しい部門であり、彼らは仕事中にソフトウェアに触れることは決してなく、それを理解したくありません。私たちのユーザーは、重要なタスクを達成しようとする分野の正規の政府職員です。私たちにとって、コミュニケーションフィードバックループを確立する鍵は、私たちと同じように俊敏性を発揮できるようにすることが、UAT（ユーザー受け入れテスト）の必要性でした。

私たちのプロジェクトの初期段階で、広大な政府顧客のさまざまなオフィスから実際のユーザーの代表グループがここに集まることが決定され、彼らが一連のソフトウェアをテストするテストスクリプト。非常に非公式なこととして、要件チームは今回を実際のエンドユーザーからフィードバックを得るための非常に貴重な方法に変えました。一方、政府内のUATテストチームは、官僚機構を介して、変更命令を含む最終的な正式な要件プロセスにますます影響を与えるように取り組みました。最終的な結果として、私のようなBAはスクラムチームに組み込まれた代役プロダクトオーナーとして行動し、実際の顧客と非常に機敏に機能できる貴重な対面時間を得ることができます。

明らかに、多くの問題があり、まだアジャイルではありませんが、政府の請負セクターで実際にその方法論を実際に使用している主要なアジャイルプロジェクトの例として我慢できました。

要約すると、自分の組織内でアジャイルな伝道者としての経験を活用して、顧客に浸透します。彼らと一緒に学習プロセスを行い、彼らの側にいる主要な人々との信頼に基づいてパートナーシップを確立し、彼らが必然的に持っている正式な、骨化された要件プロセスに取り組みます。あなたが開発しているものを実際に使用しなければならない地上の人たちに感謝されるでしょう！

要件はきちんと書かれていると仮定しており、要件が意味するものだと思うと考えています。アジャイルプロセスの前後は、彼らが求めたものに加えて、彼らが意図したものを得ることを確実にするのに役立ちます。