失敗したスプリントと締め切りに対処する

多くのスクラムの本や記事では、スプリントの失敗（チームがスプリントバックログの一部の機能を完了できなかった場合）はそれほど悪いことではなく、時々発生します。そして、次のスプリントで何かを改善します。そして、チームは彼らがコミットした仕事を完了しないことで罰せられるべきではありません。

これは開発者の観点からは素晴らしいように見えますが、深刻なクライアント向けに何かを開発しているソフトウェア会社「Scrum-Addicts LLC」（「Money-Bags Corporation」）があるとします。

1. Scrum-Addictsマネージャーは、Money-Bags用のソフトウェアを作成することを提案しています
2. 彼らは機能のリストに同意し、Money-Bagsは出荷日を提供するように頼みます
3. スクラム中毒マネージャーはスクラムチームに相談し、チームはすべての機能を完了するには3週間のスプリントが必要だと言っています
4. Scrum-Addictsマネージャーは、安全のために1週間を追加し、1か月でソフトウェアを出荷することを約束し、Money-Bagsと契約を結びます
5. 4回のスプリント（出荷期限）後、スクラムチームは機能の80％しか提供できません（新しいシステムでの経験不足、本番環境の以前の機能の重大なバグを修正する必要性など）。
6. スクラムが示唆しているように、この時点で、製品は潜在的に出荷可能ですが、Money-Bagsは契約で述べられているように機能の100％を必要とします。だから彼らは契約を破って何も支払わない。
7. スクラム中毒者は、マネーバッグからお金をもらえず、投資家は結果に失望し、それ以上会社を助けたがらないため、破産寸前です。

明らかに、スクラム中毒者の立場になりたいソフトウェア会社はありません。アジャイルとスクラムについて私が理解できないのは、チームが上記の状況を回避するために計画と期限に対処することを提案する方法です。要約すると、2つの質問があります。

誰が悪いのか？

1. 適切な計画を立てることが彼らの仕事だからです
2. チーム。彼らができる以上の仕事をすることにコミットしたから
3. 他の誰か

何を終わらせるべきなのですか？

1. マネージャは、期限を元のチームの推定値の2倍（または3倍）遅らせる必要があります。
2. チームメンバーは、何をしてもコミットしたすべての作業を行うように奨励する必要があります（失敗したスプリントに対してペナルティーを発行することにより）
3. 会社の締め切りポリシーに適合しないため、チームはスクラムを削除する必要があります
4. 私たちは皆、ソフトウェア開発をやめて修道院に参加すべきです
5. ???

あなたの例には、いくつかの基本的な管理上の問題があります。

• Scrum-Addictsマネージャーが「ハードデッドライン」契約に署名し、「新しいシステムが関与している」状況で33％の安全マージンしか追加しない場合、それはかなり無謀です。

• 1か月後に機能の少なくともx％を提供できるかどうかを利用して、期限内に機能の80％しか得られない場合に顧客が少なくとも部分的にお金を支払う契約を交渉することができます。全か無かの契約は、ソフトウェアベンダーにも顧客にも利益をもたらさないものです。つまり、ベンダーにお金が0だけでなく、顧客にも機能が0になります。また、「ウォーターフォール」のようなオールオアナッシングの開発方法論では、このようなコントラクトを書くことしかできません。アジャイルなアプローチは、さらなる可能性をもたらします。

• 最初の1回または2回のスプリントの結果を見れば、チームが締め切りに間に合わないことがマネージャーに明らかになるはずです。そのため、彼は以前のアクションを実行し、残りのタスクと機能の優先順位を再設定するか、より早く顧客と再交渉する必要がありました。たとえば、マネージャーは残りの機能の一部の範囲を縮小しようとしたため、チームは契約で言及されたすべての機能を提供できましたが、それぞれの機能の範囲は縮小されていました。

タスクが思ったよりも長くかかることが判明した場合、開発方法論はそれからあなたを救いません。しかし、スクラムのようなアジャイルなアプローチは、その状況で何が起こるかを管理するより多くの機会を経営者に与えます。もし彼らがそれらの機会を利用しなければ、それは明らかに彼らのせいであり、チームのせいではなく、「スクラム」のせいではなく、「アジリティを受け入れない」ための顧客のせいでもない。

「アジャイルソフトウェア開発のためのマニフェスト」の価値声明の1つは次のとおりです。

契約交渉を介した顧客コラボレーション

Scrum-Addicts LLCが顧客とのコラボレーションを確立する代わりに契約を交渉したという事実から、私は彼らの俊敏性に疑問を抱かせます。

一つはっきりしていることは、敏Ag性は誰もが受け入れる必要があるということです。敏ility性は開発者だけのものではありません。マネージャーと顧客もアジャイル宣言の価値を受け入れる必要があります。顧客が敏g性を受け入れず、厳格な契約と最小限のコラボレーションが必要な場合は、敏a性を使用しないか、より良い顧客を見つけます。

締め切り駆動型の開発で契約バブルに閉じ込められているのは顧客の責任です。

誰が悪いのか？

マネージャー、法務部、会計士-選んでください...

この例は多少不自然であることがわかっていますが、会社が100％満足していなかった場合に1ドルも払わずに立ち去ることができるという事実は、滝と機敏な思考が混ざり合うように、即座に警鐘を鳴らすべきでした。

顧客はケーキを食べて食べたい-日付Zまでに製品Xが$ Yで手に入る限り、滝、ミニ滝、機敏な、ラ・ラ・ランドを喜んで受け入れます。

アジャイル開発では、開発チームと顧客が方法論の観点から同じページにいることが絶対に必要です。文化の違いを考えるだけで、ウォッシュで出てくるのは希望的観測です。

ITプロジェクトは未知のものを扱います。これらのいくつか未知数でもある、未知の未知数。どういう意味ですか？

たとえば、鉄道模型のおもちゃの橋を見てみましょう。既知のすべてのパラメーターがあります。

• あなたは谷がどれほど大きいか知っています

• 山の素材、高さ、安定性などを知っています。

• どれだけの材料が必要か知っている

• 以前の「プロジェクト」から、似たようなものを構築するのにどれくらい時間がかかったかがわかります。

余分な時間とお金を投資する計算に影響する多くの変数が関係しています。しかし、来週末に終了するかどうかは考えずに言うことができます。

さらに例を見てみましょう。

• 自分の鉄道模型の橋を建設するのではなく、見知らぬ人のために橋を建設するとしましょう。あなたの仕事は、2つの山の間に鉄道橋を建設することです

• モデルランドスケープの前に情報がほとんどないとしましょう

• 風景についての情報は、つまり、2つの山があり、あまり大きくないようです

• 山の一貫性は岩とゼリーの間にあります

• 総費用は最大10ドルです

• 職場は完全に暗く、明かりはありません。8試合分の箱しかない

• 締め切りは3時間です

それはITプロジェクトに類似しています。橋の建設の経験があり、既知の地形を歩くのは簡単です。それを難し​​くするのは闇です。あなたがほとんど予測できない多くの事柄があります：山の測定は暗闇の中でしばらくの間突っついた後にのみ知られています。山の一貫性も同様です。それから、あなたがどれくらいの時間を要し、どれくらいの費用がかかるかを見積もることができます。ここで、未知のものとは、具体的な地形などのように、プロジェクトの開始時にはわからないものです。しかし、最も経験が多く、保守的な見積もりでも、予見できないものがあります。これらは、少し混乱した未知の未知のものです。

すべてのIT企業がそれを知っている必要があります。プロジェクトのリスクに対処する必要があります。

1）（金融）リスクを最小限に抑える方法はいくつかあります。取引には、作業増分ごとに顧客が支払う金額を含めることができます。そのため、増分1が配信された後、部分料金を支払う必要があります。Scrum-Addicts LLCが提供する限り、最小限の財務リスクがあります。より詳細なスプリントの目標を計画するほど、すべてのスプリントのリスクは低くなります。つまり、Money-Bags Corporationが契約の80％を受け取った場合、少なくとも契約値の80％を支払う必要があります。スプリントに失敗した後に支払いを拒否した場合、リスクは100％の支払い拒否ほど高くありません。

2）Scrum-Addicts LLCには開発者に問題があります

スクラムアディクトマネージャーはスクラムチームに相談し、チームはスクラムアディクトマネージャーが安全のために1週間を追加し、1か月でソフトウェアを出荷することを約束し、契約に署名するすべての機能を完了するには3週間のスプリントが必要だと言いますマネーバッグ付き

これは、a）開発者がスクラムを経験していないか、b）スクラムを間違っていることを示唆しています。チームがスクラムを使用する時間が長いほど、見積もりは良くなります。チームが見積もりを行い、マネージャーが「安全」として「バッファー」を追加した場合、マネージャーはチームよりもよく知っているようで、これは悪い兆候です。経験豊富なチームがいる場合、「managerbuffer」は必要ありません。チームはそれをすでに見積もりに含めています。アイデアは、チームがより多くのスプリントを一緒に使用すればするほど、チームがその長所と短所を認識し、現実的な見積もりを行うためのいくつかのメトリックを持っているということです。もちろん、すでに述べたように、未知の未知数があります見積もりが難しくなる傾向があります。または少なくとも不正確。しかし、長期的には、推定値はどんどん良くなるはずです。

誰が悪いのか？

1）管理

前述のように、リスク管理には明らかに失敗があります。会社が破産の危機にIfしている場合、会社はそれに値する。あなたがそのような会社で働いているなら：去ってください！

2）チーム

経営陣がまったく馬鹿げているとしても、チームはそのようなプロジェクトに対して意見を述べたはずです。優れたマネージャーはリスクを知っている必要があります。しかし、優れた開発者はリスクを指摘する必要があります。そして何よりも、何かが失敗した場合、チームは早期に報告する必要があります。

何を終わらせるべきなのですか？

今：お金の袋を法廷に持ち込む

将来のために：そのような契約をしないでください

スクラムは、管理の失敗のせいではありません。スクラムは、失敗した多くのITプロジェクトの経験に基づいて開発されました。失敗を防ぐことはできず、チームや経営陣の無能さを治すこともできません。基本的な考え方は次のとおりです。

• コミュニケーションの方法を構築する（誰が何についていつ誰と話すか）

• 開発者が障害を早期に報告することを奨励する

• タスクとサブタスクの問題を分割する

• 時間と能力を構築するために

• タスクをタイムスロットに分散する

• 予測不可能なものをもう少し予測可能にします（計画ポーカー）

または全体：リスクを最小限に抑えるため。

スクラムはハンマーのようなツールです。優れたツールであるかどうかは、使用方法に関する知識に依存します。しかし、時々ドライバーがより適しています。それはあなた次第です。

まず、「誰のせいですか？」尋ねるのは間違った質問です。非難を割り当てるのは楽しくてすべてであり、おそらく非難された人以外の全員が安心します（「おい、それは私のせいじゃない、上司はそう言った！」という意味で）が、それはあなたの時間の生産的な使用ではない、実際には逆効果となり、従業員の士気を低下させる可能性があります。

それを見るより良い方法は「遅延の原因は何ですか？」です。それは技術の経験の欠如でしたか？テスト/ QAで検出されなかった重大なバグ？テストの欠如/ QA？推定が楽観的すぎる？チームのそれほど楽観的ではない推定を考慮に入れていませんか？誰かがバスにぶつかった？原因が何であれ、次の質問は「これが二度と起こらないようにするにはどうすればいいのですか？」です。いくつかの（願わくはまれな）ケースでは、その答えは「まあまあ解消する」かもしれませんが、「責任者を罰する必要がある」から始めると、大部分のケースを見ることはほとんどありません適切なソリューションではない場合。

プロジェクト内では、すでに沈没しています。締め切りが来て、なくなったことが明らかになったらすぐにあなたに顧客に警告しました（そうしました、そうですか？そうでない場合、それは問題の一部です）、そして今はそれが綴られているにもかかわらず処理されなければなりません契約書に記載されています（実際には契約書に記載されていますよね？）。一般的に言えば、不足しているものをどのように提供するかを顧客と交渉する必要があります。多くの人々は、契約を変更できないものと考えていますが、a）契約を破棄し、購入したものを所有していない、b）契約違反のために会社を訴え、法廷で多額のお金を使っている、 c）トラブルを最小限に抑えて製品を入手する方法の交渉。ほとんどの企業はcを選択します。

将来に向けて、価格/期限を顧客に見積もる前に、納期の遅れやコスト超過に伴うリスクを分析する必要があります（そのような原因として考えられるものは何ですか？計画する必要があります）、その情報を使用して、何を約束するかを決定するのに役立ちます。100％またはゼロの場合、リスクが高いため、価格が高く期限が長いことは明らかです。

この答え全体でアジャイルについては話していないことに気付くでしょう。なぜなら、この時点では本当に重要ではないからです（顧客のスクラムへの関与を少し忘れますが、それは非常に重要です）。この問題は、アジャイル、ウォーターフォール、または使用する開発プロセスで発生します。はい、アジャイルは、リスクがより早く実際の問題になったかどうかを確認できるようにし、プロセス自体に顧客を巻き込むことで、リスクをより適切に管理するのに役立つはずです。

まず、これはあらゆる開発方法論の問題です。少なくとも反復開発システムでは、期限の終わりに顧客に見せることができます。これは、製品を完成させるための延長を得るのに十分かもしれません（顧客がそれ以上支払わなくても！）。

ただし、期限が期限である場合があります。ゲームを書いていると想像してください。クリスマス休暇に間に合うように絶対にリリースする必要があります。その間違いを犯したことで多くの会社が倒産しました！

特定の日付までに特定の量の機能を完了する必要があるアジャイルメソッドの場合、スクラムはおそらく使用するのに最適な方法ではありません（スクラムはdevを遅くし、プロセスを変更するのに十分なアジリティを許可しないことが常にわかっているため必要です。

方法論に関係なく、必要なのは、進行状況を可視化するために必要な機能のバックログを設定することです。スプリントごとの進捗は十分ではなく、最終的な目標を達成しているかどうかはわかりません。そのため、かんばんスタイルの方法論の方が優れています。左側のすべての機能を設定し、システムを介してそれらを機能させて、完了までの進捗を示します。

これにより、スクラムでは処理できない方法でまだ実行する必要があることに人々の心が集中し、開発チーム以外の人々が残っているものと目標を達成する可能性があるかどうかを確認できます（したがって、顧客の期待を早期に管理できます） 、またはこれらの残業ボーナスを必要になる前に手配します）。

スクラムは、陶芸家が永遠に何かを継続的に定義し、洗練するシステムです。この種の開発にはまったく適していません。他の人はこのスタイルを管理しながら、繰り返し開発コンセプトを維持することができます。かんばんはそのようなもので、クリスタルは別のものです。しかし、理解するために不可欠なのは、スクラムを宗教的にフォローしている場合、アジャイルではないということです。真のアジャイルシステムは、これらの特定の問題に対処するためにモーフィングできる必要があります。そのため、そもそもアジャイルと呼ばれ、実行する必要のあることを実行することについてです。それをあなたの働き方に織り込んでください。

開発パラダイムは、契約パラダイムと同期していません。理想的には、契約書の書き方は変わるでしょうが、実際に起こる可能性は低いでしょう。ただし、スクラムをドロップしたとしても、サプライズがあり、締め切りに間に合わないことがあります（すべての設計を前もって行っており、すべてが間違っていたため、かなり遅れる可能性が高いです！）。

契約書の書き方を変更してもしなくても、作業内容を出荷できます。その後、完了していない機能を完成させるために、開発時間のサイクルを消費して契約を履行します。

約束した日に約束したすべてを届けられなかったことはいいことですか？いいえ。ただし、時間通りに機能するものを提供できれば、顧客はずっと幸せになります。その後、遅れて走り、何も提供していない場合よりも残りの部分を迅速に提供できます。

多くのスクラムの本や記事では、スプリントの失敗（チームがスプリントバックログの一部の機能を完了できなかった場合）はそれほど悪いことではなく、時々発生します。そして、次のスプリントで何かを改善します。そして、チームは彼らがコミットした仕事を完了しないことで罰せられるべきではありません。

この種の行動を「罰する」方法は、終了しなかった人が次のスプリントで行うことができる仕事の量を制限することです。クールなものに取り組むチャンスは消えつつあります。良い仕事をすることに対する報酬は、より多くの仕事です。

これは開発者の観点からは素晴らしいように見えますが、深刻なクライアント向けに何かを開発しているソフトウェア会社「Scrum-Addicts LLC」（「Money-Bags Corporation」）があるとします。

Scrum-Addictsマネージャーは、Money-Bags用のソフトウェアを作成することを提案します。機能のリストに同意し、Money-BagsはScrum-Addictsマネージャーがスクラムチームに相談して出荷日を提供するよう要求します。 -スクラム中毒マネージャーがすべての機能を完了するための長いスプリントは、安全のために1週間を追加し、1か月でソフトウェアを出荷することを約束し、4スプリント後のMoney-Bagsとの契約に署名します（出荷期限）スクラムチームは80％しか配信できません機能の（新しいシステムの経験不足、本番環境の以前の機能の重大なバグを修正する必要性などのため）スクラムが示唆するように、この時点で、製品は潜在的に出荷可能ですが、Money-Bagsには100％が必要です契約で述べられているように、機能の。だから彼らは契約を破って何も支払わない。

スクラム中毒者は、マネーバッグからお金をもらえず、投資家は結果に失望し、それ以上会社を助けたがらないため、破産寸前です。

月曜日に木曜日に雨が降り、金曜日まで雨が降らないと100ドル賭けたら、あなたは私のお金を取る権利があります。ギャンブルのチャンスではなく、天気予報が必要な場合は、火曜日に最新の予報を提供できる契約が必要です。

明らかに、スクラム中毒者の立場になりたいソフトウェア会社はありません。アジャイルとスクラムについて私が理解できないのは、チームが上記の状況を回避するために計画と期限に対処することを提案する方法です。

MBがボールを持って帰りたい理由を考えてみてください。MBは最初の1か月で作業を行うことを要求しませんでした。SAは1か月で100％の重要な機能を約束しましたが、提供しませんでした。SAはMBではなく期限を設定しました。SAは任意に1週間を期限に追加しました。では、なぜこれが締め切りなのでしょうか？

時折、仕事をするソフトウェア会社と競争するとき、月を誇示して約束する誘惑に負けます。専門家は月が必要かどうかを慎重に確立します。MoneyBagsのより重要なニーズはどれですか？1か月のうちに100％の機能または機能する製品ですか？彼らは本当に重要なことさえ知っていますか？厳しい締め切りを設定する予定のイベントはありますか？

私がスクラム中毒者でこの契約を交渉していた場合、Money-Bagsのビジネスニーズについてさらに詳しく知り、Money-Bagsが満足できる柔軟性を付与する契約を構築したいと思います。アジャイルプロセスがどのように機能するかを教えて、彼らが私たちに何を期待するかを知ってもらいたい。

この方法では、1か月以内にすべてが突然完全に機能することを期待するのではなく、1〜2週間で最初の成果物を評価することを期待します。

要約すると、2つの質問があります。

誰が悪いのか？マネージャー。適切な計画を立てることが彼らの仕事だからです
。チームは、
他の誰かよりも多くの仕事をすることにコミットしているからです。

私たちが1か月先に進む前に、誰もがこの悲劇を止めることができたでしょう。

Money-Bags Corpを、ウォーターフォールプロセスをアジャイルであると明らかに不正に表したチームを雇ったことで非難することができました。契約自体は、これがアジャイルではないことを明らかにしています。1か月以内に計画を立てても、機敏になりません。

アジャイルであると主張する場合、1か月のスプリントを1つだけ使用してアジャイルです。これは、滝と同じことなので、お勧めしません。

何を終わらせるべきなのですか？

アジャイルはどうですか？スプリントごとに何かを提供しますか？締め切り前にフィードバックを受け取りますか？一週間のスプリント？締め切りが危険にさらされていると疑う瞬間に、隠れたり祈ったりするのではなく、厳しい契約を再交渉するのはどうですか？少なくとも、運命のプロジェクトで時間を無駄にするのをやめ、より合理的な顧客を見つけることができます。

マネージャは、期限を元のチームの推定値の2倍（または3倍）遅らせる必要があります。

期限乗数は、時計を15分早く設定するのと同じくらい便利なので、遅れることはありません。自分が今何をしているのかを理解する前に、あなたは自分をだますことができます。

初期の見積もりは間違っています。どれだけ間違っているかをキャプチャしてみてください。5週間、与える、または数週間は、完了日が実際にどれだけ不確実であるかを表現できる簡単な表現です。正確に推測しようとするのではなく、推測がいかにワイルドであるかを推測します。実際の作業を行い、実際のデータを取得します。その後、より狭い範囲で見積もりを開始できます。1〜2週間で十分です。

チームメンバーは、何をしてもコミットしたすべての作業を行うように奨励する必要があります（失敗したスプリントに対してペナルティーを発行することにより）

チームメンバーを奨励する必要があります。失敗、コミット、またはその他。罰やボーナス（ニンジンとスティック）の研究などの人為的な結果を構築するのではなく、プログラミングなどの創造的な仕事をしている人は、自律性、習得、目的の3つを提供すると最もよく反応することを示しています。

ダニエルピンクはこれについてTEDの講演をしています。話はアジャイルではなく動機についてですが、これらのポイントをアジャイルにマップする方法は簡単にわかりました。

自主性-私は自分の人生を指揮したい-バックログから仕事を選びましょう。
マスタリー-重要なことをもっと良くしたい-顧客からのフィードバック。
目的-私は自分よりも大きな何かの一部になりたい-共同チーム。

スクラムは会社の締め切りポリシーに適合しないため、チームはスクラムを削除する必要があります。スクラムはウォーターフォールよりも正確に締め切りを迎えることができます。締め切りスクラムがあれば、それに応えることができます。時間、機能、スキルに応じて47の機能のうち1つだけで対応できますが、対応できます。

アジャイルプロジェクトは非常にスタイリングできるため、チームが家に帰るたびに出荷の準備が整います。これは、出荷をテストしてフィードバックを提供するよう顧客に求めるものと考えない限り、ばかげているように見えます。早ければ早いほど、調整を行うことができます。これは、考えられるすべての期限に達します。すべての機能ではありません。しかし、それは重要な機能にあなたを導く。

私たちは皆、ソフトウェア開発をやめて修道院に参加すべきです

そうです、実生活から離れた部屋に閉じ込められたようなことは、私にLESSコードを書かせます。

この回答をサイズに合わせて編集しました。興味があれば、編集履歴を読んでください。

誰もが機敏でなければなりません。あなたがそれを決めるものは何でも、すべての関係者が誰が、何を、どのように、いつ、どこで、なぜ行うか、のように見えます。アジャイルな顧客、管理者、開発者。

発送日を先に指定することはできません。見積もりをします。

誰かがクライアントの期待を管理する必要がありました。いくつかのスプリントが遅れることをあまり心配しないのは、プロジェクト全体が遅れないように調整するためです。1〜2回スプリントを終えて「出荷日」に間に合わないという結論に至った場合は、クライアントにそのことを伝えます。

今、何をしたいですか？不要な機能を削除するか、日付を移動します。時間通りに配達できれば、そうするでしょう。悪いニュースをもたらすことをheしないでください。

一部のプロジェクトでは、早く出荷できるかもしれません。

クライアントが望んでいない場合、機敏に動作することはできません。

ゴール

次の2つの「測定基準」は、ビジネス上の意思決定の基礎となるはずです。

• 収益性の高い仕事です（クライアントにとって）
• できる限り効率的に作業していますか

これらは非常に普遍的です。もちろん、それは非常に高速なのは、より複雑になり、例えば、仕事が有益であることが正しいことをやって、製品についてです、ユーザーが製品を使用することができるという、製品が正しくなどを販売している-これらの"のロットのスクラム、依存症LLC」は責任を負いません。

問題

契約は上記の目標に焦点を合わせていません。「all or nothing」句があります-すべてを完了して支払いを受けるか、何も実行せずに支払いを行いません。ただし、これは作成される値に直接関係しません。次の欠点もあります。今、時間とお金を費やして、契約が守られていることを確認する必要があります。いったいなぜこのお金を使いたいのでしょうか？その間に要件が変更され、注文されたソフトウェアが価値を生み出していないことがわかった場合、契約が確実に履行されることはどのように役立ちますか？排水溝に行くだけのお金があります！もちろん、この動作には理由があります。

• 文化的には、私たちはそのようなものの買い物に慣れています。車の場合と同じようにソフトウェアを購入することを期待しています。構成を選択し、価格と期限を与えられ、これらの2つが満たされない場合は非常に不幸になります。
• リスクと説明責任をオフロードしたい
• 私たちは安定性を望んでいます。それは計画に役立ち、気分が良くなります（そしてクライアントも重要な側面です！）

一日の終わりには、目標を可能な限り満足させる妥協案を選択する必要があります。

これはどのように機能するかです

• 製品の代わりにサービスと仕事の契約を結んでいる
  • 比較的短期間で終了する必要がある
• 最適な効率を確保するために緊密に連携する
• 「Scrum-Addits LLC」と「Money-Bags Corporation」の両方から必要なすべての関係者が関与します-すべての情報をトンネリングする「単一の連絡先」はここでは機能しません

まあ、私は基本的に「アジャイルになる」と言った。理由は次のとおりです。

• 目標にできるだけ多くのお金を使うようにプロセスと契約が最適化されている
• 請負業者が自分の仕事をすることを信頼する必要があり、彼が仕事をしていることを確認するために多くのお金を投資する必要はありません。
• あなたの期待/契約が満たされていない場合、請負業者を訴える能力は通常助けにはなりません。ここでの主な懸念のいくつかは、市場投入までの時間です。あなたはおそらくあなたが得るよりも多くのお金/ビジネスを法廷に行くことで失うでしょう。
  • 結局のところ、自分でリスクを負う必要があります。