クライアントはアジャイル開発方法論をどのようにサポートできますか？
私の会社は、特にソフトウェアプロバイダーおよびオペレーターとして、ヨーロッパの公共インフラストラクチャの分野で働いています。現在、私たちの開発作業はすべて、この質問に関連する2つの主要サプライヤーに仕分けされています。私たちの会社の背景は（準）公共部門にあるので、いくつかの開発方法はここに到達するのに少し時間がかかります。
サプライヤの1つは最近、より大きなIT企業との合併を経験し、その結果、アジャイル開発手法をより深く採用するようになりました。これまでのところ、システムの詳細な仕様書と一括払いで作業してきましたが、アジャイル開発方法についての（限られた）理解から、これはこのモデルでは現実的ではありません。さらに、私たちはプロジェクトが予算を超えて実行するという経験をしたので、事前の綿密な計画は、将来と同じくらいの関連性を持って、水晶玉のように少し思えます。
もちろん、これについてサプライヤーと話し合いましたが、プロジェクトの進行中の総支出をどのように監視するか、プロジェクトの進行に合わせてどのノブを回せばよいかなど、非常にきちんとした適切な情報を提供してくれましたコスト。彼らはまた、大きくて扱いにくい仕様シートを開発する代わりに、可能な場合はユーザーストーリーとして要件を定式化する必要があると述べました[「Xとして、Zを達成するためにYを実行できるようにしたい」。
他のサプライヤーは本日、事前に作業量を見積もることに問題があると述べ、上記と同様のモデルについて議論し、熱心でしたが、公共部門での経歴があるため、アジャイル開発方法の経験は比較的ありません。上手。彼らは、アジャイルモデルは「最初は最終製品がどのようになるかを言うことはできない」という意味だと述べました。そして、「特定の製品や機能がどれくらいの費用がかかるかを合理的な確実性をもって言うことはできません。」これは通常、クライアントの取引相手です。
しかし、私の理解では、最終製品がどのように見えるかを言えないのは、プロジェクトの進行中にクライアント（この場合は）がループに保持され、プロジェクトに入力をもたらすことができるという事実が原因です。 、それを彼らが望むように、または彼らがどのようにそれを「意味する」かを形作るため。正直なところ、私が指定したように各システムがどのように見えるべきかわからないので、他のクライアントの多くがそうしているのではないかと思います。費用については、上記で説明したように、事前の見積もりはできないものの、例えば、機能の削減、部品の簡素化など。
質問：プロジェクトの計画に関して、アジャイル開発と従来のウォーターフォールモデルの違いについての上記の理解は正しいですか？
顧客として、サプライヤーによるアジャイル開発を最も効果的にサポートするにはどうすればよいですか？どんな推奨読書も参考になります。
毎月支払うことのできる最大工数、最低限の機能/機能など、私たちが要求または主張する必要があるものはありますか？
追伸これがスタックを間違って質問する場合は、自由に動かしてください。
編集：わかりやすくするために、最初の会社はカンバンモデルを採用することを提案しました。おそらくスクラムアプローチからいくつかの側面を借りています。
あなたの理解は一般的に正しいです。
純粋なアジャイルについて話し合うときに聞く大きな不満の1つは「クライアントは何が行われるのか、いつ行われるのか、そしてどれだけの費用がかかるのかを正確に知る必要がある」ということです。あなたがその不確実性を受け入れ、自分自身でリスクを取ることをいとわないという事実は、すでにあなたを素晴らしいクライアントにしています。ただし、注意が必要です。アジャイルは間違いを犯しやすいです。そして、良いアジャイルプロセスがあなたに約束されたすべてをあなたに与えることは事実ですが、それが間違って行われると、それはあなたをろばに刺します。
最初に対処する必要があるのは、法的契約です。高フィードバックと継続的支払いを可能にする契約はまれです。そして、多くの法的契約の専門家は彼らとの経験がありません。私はあなたの法務部門に連絡し、あなたとあなたの供給者との間でどのような契約を作りたいかについて深く話し合うことを強くお勧めします。あなたの法的専門家はおそらく、何が、いつ、どれくらいの費用がかかるかを定義する「伝統的な」契約を作成する傾向が強いでしょう。このアプローチに抵抗するために、あらゆる努力を払う必要があります。
他の回答者の1人がデモについて言及しています。はい。機能しているソフトウェアのデモを1週間または2週間ごとに見たいと考えています。ただし、デモを「偽造」するのは簡単なので、注意してください。本番環境で実行されている機能のうち、約束されたもの以外のものは受け入れないでください。これは、それが開発、テスト、提供され、サポートされていることを意味します。この機能は、好みの環境で自分で使用できるはずです。実稼働環境とは異なるデモを行うか、自分以外の人がデモを行うと、実際に実稼働対応の機能に変えるために必要な追加の作業を簡単に隠すことができます。
また、蓄積された技術的負債が開発の速度を低下させ、変更を行うためのコストが高くなる場合は、「フラシッドスクラム」シナリオにも注意する必要があります。コードとアーキテクチャを開発のペースを速く保つのに十分な高品質に保つには、多くの規律と動機が必要です。開発が始まり、機能が迅速に作成されると、誤ったスピード感に陥りやすくなります。しかし、時間の経過とともに機能が追加されるにつれて、開発は遅くなります。そのため、数日前にかかっていた機能が、今では数週間かかります。これが起こらないようにするために、クライアントとしてあなたが何ができるかわかりません。あなたはあなたのサプライヤーの能力を信頼しているかもしれません。しかし、適切なアジャイル開発を一度も行わなかった場合、おそらく品質を長期的に維持するためのスキルと経験が不足しています。たぶん、独立したサードパーティの請負業者に開発品質をチェックしてもらい、頻繁に報告してもらうことはありますか？開発プロセスと環境が俊敏性をサポートしており、プロセスの無駄が最小限であることを彼らに実証してもらいたいと思うかもしれません。
クライアントとして、開発チームと協力して大きな価値を追加できます。
できるだけ直接彼らと話してください。彼らにあなたのビジネスがどのように機能するか、そして彼らが構築しているソフトウェアがなぜそれを前進させるのに役立つのか説明してください。ビジネスのある部門のソフトウェアの特定の部分を扱うときは、その部門の専門家を連れて行ってください。
共有言語/語彙を作成し、開発者がコードと内部コミュニケーションでこの言語をできるだけ使用するように主張します。開発チームとのコミュニケーションがはるかに容易になり、ビジネスに関する知識をテストできます。結局のところ、コードで終わるのは、開発者があなたのビジネスについて持っている理解です。
チームと一緒に、機能のバックログを作成します。製品所有者としてのあなたの仕事は、このバックログを注文することです。そのため、ビジネスにとって最も重要なものが最初に作成されます。
チームに、頻繁に、毎日、毎週、隔週で、適切な頻度でリリースするよう依頼します。 haveは本番環境ではありませんが、本番環境にできるだけ近づけます。実際のユーザーにこれらのリリースをテストしてもらいます。これらの実際のユーザーからフィードバックを収集します。必要に応じて機能を調整します。
これらのガイドラインに従えば、有用なソフトウェア製品を作成できる可能性は、事前の詳細な仕様よりもはるかに高くなります。それはあなたが最初に心に描いていたものと正確には違うかもしれません、それはおそらくより良いでしょう！
アジャイルは継続的なフィードバックについてです。あなたは作業が進行中であることを見て、おそらくそれを非常に早い段階でそして頻繁に使用し始めます。開発者と月に1回またはそれ以下のミーティングを行うのではなく、少なくとも週に1回ミーティングを行います。ただし、これらは退屈なミーティングではなく、あなたとエンドユーザーが試してみる「デモ」のようなものです。彼らが開発している新しいソフトウェア機能。これが、アジャイルチームが正しい方向に進んでいるかどうかを確認する方法と、そうでない場合に修正する方法です。
もう1つの重要な側面は、優先順位（リスクとニーズの両方）を明確に把握することです。最初に取り組むべきことは、最も不確かなことか、絶対に最も必要とすることのどちらかです。そうすれば、これらの問題を早期に解決できます（時間とお金を最小限に投資して）。これらの不確実性の1つが契約違反であることが判明した場合、プロジェクトをキャンセルしたり、大幅に失うことなく再計画したりできます。ソフトウェアが、ユーザーがそれなしでは生活したくないという重要なニーズを満たしている場合は、残りの機能が開発されるのを待たずに、本稼働に移行できます。このように、アジャイルはより経済的であり、他のアプローチよりもリスク管理が優れています。
Henrik Knibergによるトレンチからのリーンを読むことをお勧めします。あなたのようなヨーロッパの公共部門プロジェクトのケーススタディです。
アジャイルソフトウェア開発の基本的な価値の1つは、「契約交渉よりも顧客とのコラボレーション」です。あなたはおそらく契約を単に処分するつもりはありませんが、サプライヤと直接協力して、両者が関係から何を期待しているかを理解し、誰もが必要なものを手に入れることができます。
そこには特異なアジャイル方法論はありません。同じフレームワークを使用している組織でさえ、その方法に違いが生じる可能性があります。関係を定義するためのオープンなコミュニケーションとコラボレーションのラインは、おそらくあなたが得ようとしている最良の答えです。サプライヤは、理解を深めることができるように、サプライヤが使用している方法論を説明しているリソースを紹介できる場合があります。
アジャイルはソフトウェアプロジェクトを悩ませるすべての問題の万能薬ではなく、計画の欠如や設計経験や専門知識の欠如の言い訳にもならないことを覚えておくことは重要です。それはまた、必ずしも滝よりも効率的ではありません。鉄の超高層ビルを建設することは、犬小屋、家庭、そして小さな商業オフィス、そして超高層ビルを介して行われる場合、より効率的でないという同じ理由でです。
とりわけ、アジャイルはウォーターフォールモデルの2つの欠点を解決しようとします。1つは、情報システムの理想的な動作を特定することが難しい場合があることです。ソフトウェアは時間とともに変化する可能性があるように設計されています。これらのリスクは、開発の規模と期間に比例します。
アジャイルによって生じるリスクは、大量の手直しが行われる可能性があること、または基本的な設計がすぐに整合性を失う可能性があることです。クライアントまたは開発者は、早期に適切な設計を行うことが有益であった場合に、早期にハードワークを怠ることがあります。また、ソフトウェアプロジェクトの部分的な実装には通常、ある程度の有用性がありますが、あまり有用ではない場合や、最初から利用できる代替案よりも有用性が高い場合があります。
特注のソフトウェアサプライヤーにとって、アジャイルと呼ばれるものの利点は、特に機能を提供せざるを得ないこと、および金融リスクがクライアントに戻されることです。商業的には、ソフトウェア開発者のギャングマスターの雇用モデルに似ており、クライアントはそのようなギャングを管理するために必要なスキルと経験を持っていることに注意する必要があります。
これはattorneys：の質問になるかもしれませんが、これらのサプライヤーとの契約交渉は現在どのように行われていますか？どのシステムを構築するか、それを実現するためにいくら支払う必要があるかを決定する権利が必要です。現在、このようなシステムを導入しています。 「アジャイルmumble mumble ...」を装って、このサプライヤーがゲームのルールを変更しようとしているように聞こえます。
すべての現代的なアジャイルプラクティスと一緒にプレイして、サプライヤーと親密になることができます。また、宣伝されているメリットのいくつかを享受することもできます。最初から2つのことを必ず確認してください。
- 自分で説明する必要なく、いつでもプロジェクトを停止してサプライヤーと別れる権利を確保してください。あなたは費やされた時間とそれ以上のために支払います。
プロジェクトが成功しないことは明らかな時点で気付くかもしれないので、これは重要です。または、もはや関連性がありません。または、より良いオプションがポップアップします。これはあなたのサプライヤーをつま先に保ち、彼らはあなたを幸せに保つように動機付けられます。
- あなたがノーリターンのポイントを超えて移動しないことを確認してください。
バックアップ計画を立てます。これは、古い方法で少し長く作業を続け、別の方法を試す可能性があります。これは常に可能であるとは限りませんが、これがない場合、最初の問題は問題点になるため、重要です。あなたは乾杯し、あなたのサプライヤーはあなたに朝食を用意します。
ソフトウェアプロバイダーと協力したいクライアントとしての非常に良い質問と非常に良い態度！ +1
アジャイルは考え方です、いくつかの価値と一連の原則からなる考え方-そして、チームや企業が意思決定を導くために使用できるものです。たとえば、クライアントとの鉄壁の契約の構築に焦点を当てるべきでしょうか、それとも、より包括的でコラボレーションを促進するような単純なものを導入すべきでしょうか？
スクラムとカンバンは「管理フレームワーク」作業の計画、完了、展開方法を構造化するのに役立ちます。これらは、ユーザーからの迅速なフィードバックにより展開サイクルを短縮し、チームをより柔軟に調整できるようにします。クライアントのニーズに。
アジャイルやスクラムなどのフレームワークを初めて適用する企業は、本（またはコンサルタント）が言うことを理解せずに、なぜそれを行っているのか理解することができない場合があります。プロジェクト管理アプローチから、次の点に留意してください。
- [〜＃〜] what [〜＃〜]に焦点を当てて、機能（アプリケーション、フローなど）を理解して[〜＃〜]なぜ[〜＃〜]必要なもの（それから得られるビジネス価値）であり、技術スペシャリストが[〜＃〜] how [〜＃〜]でビルドします。
- あなたが要求している仕事から得ようとするビジネス価値は、多くのコンテキストを[〜＃〜] how [〜＃〜]に追加する必要があります構築される-チームがそれを理解するのを助けます。たとえば、銀行のログイン画面の作成は、子供向けのWebサイトの作成とは異なります。
- 「プロジェクトチーム」との関係を構築して、彼らが仕事の進捗状況を公開できるようにしてください。スクラムとカンバンはすべて柔軟性に関するものです。反復中のフィードバックは、実際に展開する前に付加価値のある変更を行うのに役立つ場合があります。スコープのクリープを意味するのではなく、「ポップアップが実際に機能しないので、表示されたので、削除してフォームに収まるように時間をかけないでください」のようなものです。
成果物の支払いについて。私たちが支払う方法は国によって異なるため、合法的に必要なもののコンテキスト内で、反復ごとに支払うことができます。私たちの業界では、スプリント後に成果物の支払いを行います-たとえば、チームがスプリント（2週間）で完了すると確信している作業を行うと、作業するチームのメンバーに対して1時間ごとに課金されますあなたの要求。合意された成果物がスプリントの最後に展開の準備ができている場合は、料金を支払います。チーム自身の過失により約束された結果を提供できない場合、会社はそのスプリントのチームの費用を負担します。コンテキスト内では、これは、部分的な成果物に対して部分的な支払いが発生することを意味することもあります。