失敗したスプリントと期限への対処
多くのスクラムの書籍や記事では、失敗したスプリント（チームがスプリントバックログの一部の機能を完了できなかった場合）はそれほど問題ではなく、ときどき発生し、チームがミスから学んだ場合に実際に役立つ可能性があると述べています次のスプリントで何かを改善します。そして、チームはコミットした仕事を完了しなかったことで罰せられるべきではありません。
これは開発者の観点からすばらしく見えますが、ソフトウェア会社「Scrum-Addicts LLC」が深刻なクライアント向けに何かを開発しているとしましょう（ " Money-Bags Corporation "）：
- スクラムアディクトのマネージャーは、マネーバッグ用のソフトウェアを作ることを提案しています
- 彼らは機能のリストに同意し、Money-Bagsは出荷日を提供するように求めます
- スクラムアディクトマネージャは、スクラムチームに相談し、チームはすべての機能を完了するために3週間のスプリントが必要になると述べています。
- Scrum-Addictsマネージャーは、安全のために1週間を追加し、1か月でソフトウェアを出荷することを約束し、Money-Bagsと契約します
- 4つのスプリント（出荷期限）の後、スクラムチームは機能の80％しか提供できません（新しいシステムの経験不足、本番環境の以前の機能の重大なバグを修正する必要があるなど）。
- スクラムが示唆するように、この時点では、製品は出荷可能である可能性がありますが、契約に記載されているように、Money-Bagsには100％の機能が必要です。だから彼らは契約を破って何も支払いません。
- スクラムアディクトはマネーバッグからお金を得られなかったために破産の瀬戸際にあり、投資家は結果に失望し、会社をこれ以上支援しようとはしません。
明らかに、どのソフトウェア会社もスクラム・アディクトの立場になりたくありません。アジャイルとスクラムについて私が理解できないのは、チームが上記の状況を回避するために計画と期限に対処する必要があることを彼らがどのように提案するかです。要約すると、2つの質問があります。
誰に責任があるのですか？
- 適切な計画を立てることが彼らの仕事なので、マネージャー
- チームは、彼らができる以上の仕事をすることを約束したので
- 他の誰か
何をすべきか？
- マネージャーは、元のチームの見積もりよりも2倍（または3倍）遅れて期限を移動する必要があります。
- チームメンバーは、（スプリントが失敗した場合にペナルティを発行することにより）コミットしたすべての作業を行うように奨励されるべきです。
- 会社の期限ポリシーに適合しないため、チームはスクラムを削除する必要があります
- 私たちはみんなソフトウェア開発をやめ、修道院に加わるべきです
- ???
あなたの例には、いくつかの基本的な管理上の問題があります。
スクラムアディクトマネージャが「ハードデッドライン」契約に署名したが、「新しいシステムが関与する」状況で33％の安全マージンしか追加しない場合、それはかなり無謀です。
1か月後に少なくともx％の機能を提供できることは、顧客が締め切り時に機能の80％のみを受け取ったときに少なくとも部分的にお金を支払う契約を交渉するために使用できた可能性があります。オール・オア・ナッシングの契約は、ソフトウェアベンダーも顧客も利益をもたらさないものです。つまり、ベンダーのお金が0になるだけでなく、顧客の機能も0になります。そして、「ウォーターフォール」のようなオール・オア・ナッシングの開発方法論では、そのような契約を書くことしかできません。アジャイルなアプローチは、さらなる可能性を提供します。
最初の1つまたは2つのスプリントの結果を見ると、チームが期限に間に合わないことがマネージャーに明らかにされているはずです。したがって、彼は以前のアクションを実行し、残りのタスクと機能の優先順位を再設定するか、顧客との交渉を早める必要があります。たとえば、マネージャは残りの機能の一部のスコープを縮小しようとした可能性があるため、チームは契約で言及されているすべての機能を提供できますが、それぞれのスコープは縮小されます。
タスクが思ったよりも長くかかることが判明した場合、開発方法論はそれからあなたを救うことはできません。しかし、スクラムのような俊敏なアプローチは、経営者にその状況で何が起こるかを制御するより多くの機会を与えます。彼らがこれらの機会を利用しない場合、それは明らかにチームのせいではなく、「スクラム」のせいではなく、「俊敏性を受け入れない」という顧客のせいではありません。
「 アジャイルソフトウェア開発のマニフェスト 」の価値観の1つは次のとおりです。
契約交渉を介した顧客のコラボレーション
Scrum-Addicts LLCが顧客とのコラボレーションを確立する代わりに契約を交渉したという事実は、彼らの敏捷性に疑問を投げかけます。
明確なことが1つあります。敏捷性はすべての人に受け入れられる必要があります。俊敏性は開発者だけのものではありません。マネージャーと顧客も、アジャイルマニフェストの価値を受け入れる必要があります。顧客が俊敏性を受け入れず、厳格な契約と最小限のコラボレーションを必要とする場合は、俊敏性を使用しないか、より良い顧客を見つけてください。
期限主導の開発では、契約バブルに閉じ込められてしまうのは顧客の責任です。
誰のせいですか？
マネージャー、法務部、会計士-あなたの選択をしてください...
この例は多少人為的なものであることは知っていますが、会社が100％満足しなければダイムを支払わずに立ち去ることができるという事実は、滝と俊敏な思考を混ぜ合わせるべきであるように、すぐに警報ベルを鳴らすはずです。
顧客はケーキを手に入れて食べたいと思っています-日付Zまでに$ Yの製品Xを入手している限り、滝、ミニ滝、アジャイル、ララランドを喜んで受け入れます。
アジャイル開発絶対に必要開発チームと顧客は方法論の観点から同じページにいる必要があります。文化の違いを洗い出すだけで出てくると思うのは希望的な考えです。
ITプロジェクトはunknowns;を扱います。これらの一部unknownsは偶数unknown unknownsです。どういう意味ですか？
たとえば、鉄道模型のおもちゃの橋を見てみましょう。あなたが知っているすべてのパラメータがあります：
あなたは谷がどれほど大きいか知っています
あなたは山の素材、その高さ、安定性などを知っています。
必要な材料の量を知っている
以前の「プロジェクト」から、同じようなものを構築するのにどれくらいの時間がかかったかがわかります
余暇とお金の投資の計算に影響を与える多くの変数が関係しています。しかし、それが来週末に終了するかどうか、考えずに言うことができます。
例をさらに一歩進めます。
自分の鉄道模型用の橋を建てるのではなく、完全に見知らぬ人のために橋を架けるとしましょう。あなたの仕事は、2つの山の間に鉄道橋を作ることです。
モデルランドスケープの事前情報がほとんどないとします
風景に関する情報は、山が2つあり、あまり大きくはないようです。
山の一貫性は岩とゼリーの間です
総費用は最大10ドルです。
職場は完全に暗く、明かりの可能性はありません。8試合の箱しかありません
締め切りは3時間です
これは、ITプロジェクトに類似しています。橋を架けた経験があり、既知の地形を歩くのは簡単です。それが難しくするのは暗闇です。あなたがほとんど予測できないことはたくさんあります：山の測定値は、暗闇の中でしばらく突っ込んだ後で初めて知られます。山の一貫性も同様です。それから、あなたはそれがあなたにかかる時間とどれくらいの費用がかかるかについて見積もりを作ることができます。ここでunknownsは、具体的な地形など、プロジェクトの最初はわからないものですが、予測できないものがあります。最も経験があり、最も保守的な見積もりであっても。これらは未知の未知数であり、少々混乱が生じます。
すべてのIT企業はそれを知っている必要があります。彼らはプロジェクトのリスクに対処しなければなりません。
1）（金融）リスクを最小限に抑える方法はいくつかあります。取引には、顧客がすべての現段階で支払う金額を含めることができます。したがって、増分1が配信された後、部分料金を支払う必要があります。 Scrum-Addicts LLCが提供する限り、財務リスクは最小限です。より細かいスプリント目標が計画されるほど、すべてのスプリントの総リスクは低くなります。つまり、Money-Bags Corporationが契約の80％を受け取った場合、少なくとも契約額の80％を支払わなければなりません。スプリントに失敗した後に支払いを拒否した場合、リスクは100％の支払いを拒否するほど高くはありません。
2）Scrum-Addicts LLCは開発者に問題があります
スクラムアディクトマネージャーはスクラムチームに相談し、チームはすべての機能を完了するのに3週間のスプリントが必要であると述べています。マネーバッグ付き
これは、a）開発者がスクラムの経験がないか、b）開発者がスクラムを間違って実行していることを示唆しています。チームがスクラムで作業する時間が長いほど、見積もりは良くなります。チームが見積もりを行い、マネージャーが「安全性」として「バッファー」を追加した場合、マネージャーはチームよりもよく知っているようです。これは- 悪い記号。経験豊富なチームがいる場合は、「マネージャーバッファー」は必要ありません。チームはすでに見積もりにそれを含めています。アイデアは、チームが一緒に働いたスプリントが多いほど、チームはその長所と短所を理解し、現実的な推定を行うためのいくつかの指標を持っているということです。もちろん、すでに述べたように、推定を困難にする傾向がある未知の未知数があります。または少なくとも不正確です。しかし、長い目で見れば、見積もりはどんどん良くなるはずです。
誰に責任があるのですか？
1）管理
上記のとおり、リスク管理には明らかに失敗があります。会社が破産の危機に瀕している場合、会社はそれに値する。あなたがそのような会社で働いているなら：辞めてください！
2）チーム
経営陣がまったくばかげているとしても、チームはそのようなプロジェクトに反対すべきでした。優れたマネージャーはリスクを知っている必要があります。しかし、優れた開発者はリスクを指摘する必要があります。そして何よりも、何かが失敗した場合、チームは早期に報告する必要があります。
何をすべきか？
今：Money-Bagsを法廷に連れて行く
将来のために：そのような契約をしないでください
スクラムは管理の失敗のせいではありません。スクラムは、失敗した多くのITプロジェクトの経験に基づいて開発されました。失敗を防ぐことはできず、チームや経営陣の無能さを解消することもできません。基本的な考え方は次のとおりです。
コミュニケーションの方法を構築する（誰が何についていつ誰と話すか）
開発者が障害を早期に報告することを奨励する
タスクとサブタスクの問題を分割する
時間と容量を構成する（誰がいつ何をするか）
タイムスロットにタスクを分散する
予測不可能を少し予測可能にする（ポーカーを計画する）
または全体：リスクを最小限に抑えるため。
スクラムはハンマーと同じようにツールです。それが良いツールであるかどうかは、それをどのように使うかについてのあなたの知識に依存します。ただし、ドライバーの方が適している場合もあります。それはあなた次第です。
まず、「誰のせいですか？」質問するのは間違っています。非難を割り当てることは楽しく、すべてであり、非難された人を除くすべての人を安心させます（「ちょっと、それは私のせいではない、上司が言ったように」という意味です）、しかしそれはあなたの時間の生産的な使用ではありません、そして実際には逆効果となり、従業員の士気を低下させる可能性があります。
それを見るためのより良い方法は、「遅延の原因は何か」です。テクノロジーの経験不足でしたか？テスト/ QAで検出されなかった重大なバグ？テスト/ QAの欠如？見積もりが楽観的すぎますか？チームのそれほど楽観的な見積もりを考慮に入れていませんか？誰かがバスに襲われましたか？原因が何であれ、次の質問は「これが再発しないようにするにはどうすればよいですか？」です。一部の（できればまれに）ケースでは、その答えは「まともなものを取り除く」かもしれませんが、「責任のある人を罰する必要がある」から始めると、ケースの大部分が表示されない可能性があります。適切なソリューションではない場合。
プロジェクト内では、すでに沈んでいます。締め切りが来てなくなった場合、それがスリップすることが明らかであるとすぐに顧客に警告しました（そうしたので、そうですか？そうでない場合は、それが問題の一部です）。契約書に記載されています（実際には契約書に記載されていますよね？）。一般的に言えば、不足しているものをどのように提供するかを顧客と交渉する必要があります。多くの人々は、契約を変更できないものとして考えたいと思っていますが、a）契約を破棄し、購入したものを持っていない、b）契約違反で会社を訴え、法廷で多額の費用を費やしている、 c）トラブルを最小限に抑えて製品を入手する方法を交渉する場合、ほとんどの企業はcを選択します。
将来的には、顧客に価格/締め切りを見積もる前に、締め切りの遅れやコスト超過に伴うリスクを分析する必要があります（そのようなことの考えられる原因は何ですか。を計画する必要があります）、その情報を使用して、何を約束するかを決定するのに役立ちます。それが100％かまったくない場合であれば、リスクが高いため、明らかに高い価格と長い納期を見積もることになります。
この答え全体で私がアジャイルについて話していないことに気付くでしょう。これは、この時点では（それは非常に重要ですが、顧客がスクラムに関与することを少しの間忘れてしまうからです）、それは重要ではありません。アジャイル、ウォーターフォール、または使用するあらゆる開発プロセスでこの問題に直面します。はい、アジャイルはリスクをより適切に管理するのに役立つはずです。リスクがより早く実際の問題になったかどうかを確認し、プロセス自体に顧客を関与させることで、常に通知を受けることができますが、万能薬ではありません。
開発パラダイムは、契約パラダイムと同期していません。理想的には、コントラクトの記述方法が変更されることになりますが、実際にはそうなることはほとんどありません。ただし、スクラムを落としても、サプライズがあり、納期を逃してしまいます（そのすべての設計を前もって行って、それがすべて間違っていたために、後で遅れる可能性があります。）。
契約の書き方を変更してもしなくても、作業内容を出荷します。次に、完了しなかった機能を完了するために、開発時間のサイクルを食べて契約を履行します。
約束した日に約束をすべて果たせなかったのはいいことですか。いいえ。ただし、時間どおりに機能するものを提供し、残りの部分を迅速に提供できれば、単に遅れているだけで何も提供できない場合よりも、顧客の満足度が高くなります。
まず、これは開発方法論に関する問題です。少なくとも、反復的な開発システムでは、締め切りの終わりに顧客に何かを提示する必要があります。これは、製品を完成させるための拡張を取得するのに十分な場合があります（顧客がそれ以上支払わない場合でも！）。
締め切りが締め切りになる場合もありますが、ゲームを作成していて、クリスマス休暇に間に合うようにリリースする必要があると想像してください。その間違いを犯したことで多くの会社が倒産しました！
特定の日付までに特定の量の機能を完了する必要があるアジャイルメソッドの場合、スクラムはおそらく使用するのに最適な方法ではありません（スクラムは開発を遅くし、プロセスを変更するのに十分な俊敏性を実現できないため、必要。
方法に関係なく必要なのは、必要な機能のバックログを設定して進行状況を可視化することです。スプリントごとの進捗は十分ではなく、最終的な目標を達成しているかどうかはわかりません。したがって、かんばんスタイルの方法論の方が優れています。左側にすべての機能を設定し、システム全体でそれらを操作して、完了までの進捗状況を示します。
これにより、スクラムでは処理できない方法で実行する必要があることに人々の心が集中し、開発チーム以外の人々が残っているものと、目標を達成する可能性があるかどうかを確認できます（したがって、顧客の期待を早期に管理できます） 、またはそれらが必要になる前にそれらの残業ボーナスを手配します）。
スクラムは、永続的に何かを定義し、改良していくことを永遠に熟考するシステムです。この種の開発には適していません。他の人はこのスタイルを管理でき、それでも反復的な開発コンセプトを維持できます。かんばんはそのようなもの、クリスタルは別のものです。しかし、理解する必要があるのは、スクラムを宗教的にフォローしている場合は、アジャイルではないということです。真のアジャイルシステムは、これらの特定の問題に対処するためにモーフィングできるはずです。それが、そもそもアジャイルと呼ばれていた理由です。それは、実行する必要があることを実行することについてであり、固定期限がその一部である場合は、それをあなたの働き方に織り込んでください。
多くのスクラムの書籍や記事では、失敗したスプリント（チームがスプリントバックログの一部の機能を完了できなかった場合）はそれほど問題ではなく、ときどき発生し、チームがミスから学んだ場合に実際に役立つ可能性があると述べています次のスプリントで何かを改善します。そして、チームはコミットした仕事を完了しなかったことで罰せられるべきではありません。
この種の振る舞いを「罰する」方法は、終了しなかった人が次のスプリントで実行できる作業量を制限することです。かっこいいものに取り組むチャンスはなくなっています。良い仕事をすることに対する報酬はより多くの仕事です。
これは開発者の観点からは見栄えがいいですが、ソフトウェア会社「Scrum-Addicts LLC」が本格的なクライアント（「Money-Bags Corporation」）向けに何かを開発しているとします。
スクラムアディクトのマネージャーは、マネーバッグ用のソフトウェアを作成することを提案しています。彼らは機能のリストについて合意し、マネーバッグは出荷日を提供するように求め、スクラムアディクトのマネージャーはスクラムチームに相談し、チームは3週間かかると述べています-すべての機能を完了するための長いスプリントScrum-Addictsマネージャーは安全のために1週間を追加し、1か月でソフトウェアを出荷することを約束し、4つのスプリント（出荷期限）の後、スクラムチームは80％しか提供できない（新しいシステムの経験不足、本番環境の以前の機能の重大なバグを修正する必要があるなどの理由で）スクラムが示唆するように、この時点では、製品は出荷可能である可能性がありますが、マネーバッグには100％が必要です契約で述べられているように、機能の。だから彼らは契約を破って何も支払いません。
スクラムアディクトはマネーバッグからお金を得られなかったために破産の瀬戸際にあり、投資家は結果に失望し、会社をこれ以上支援しようとはしません。
月曜日に、木曜日に雨が降り、金曜日まで雨が降らないと100ドル賭けたら、あなたは私のお金を取るのが正しいでしょう。ギャンブルをする機会ではなく、天気予報が必要な場合は、火曜日に最新の天気予報をお知らせする契約が必要です。
明らかに、どのソフトウェア会社もスクラム・アディクトの立場になりたくありません。アジャイルとスクラムについて私が理解できないのは、チームが上記の状況を回避するために計画と期限に対処する必要があることを彼らがどのように提案するかです。
MBがボールを持ち帰りたい理由を考えてください。 MBは、最初の1か月で作業を行うことを要求しませんでした。 SA 1か月で重要な機能の100％を約束し、配信されませんでした。SA MBではなく期限を設定してください。SA =締め切りに任意に1週間を追加することもできます。なぜこれが締め切りなのですか？
時折、仕事のソフトウェア会社が競争するとき、月を誇示したり約束したりする誘惑に屈する。専門家は、月が必要かどうかさえ慎重に確認します。 MoneyBagsの最も重要なニーズはどれですか？ 1か月の間に100％の機能または機能している製品？彼らは本当に重要なことを知っていますか？厳しい締め切りを迎える今後のイベントはありますか？
スクラムアディクトがこの契約について交渉している場合、マネーバッグのビジネスニーズについてもっと知り、マネーバッグが満足できる限りの柔軟性を与えるように契約を構築したいと思います。アジャイルプロセスがどのように機能するかを教えて、彼らが私たちに何を期待すべきかを理解させます。
この方法では、すべてが1か月で突然完全に機能することを期待するのではなく、最初の成果物を1〜2週間で評価することを期待します。
要約すると、2つの質問があります。
誰が悪いのか？適切な計画を立てることが彼らの仕事なので、マネージャー
チームは、彼らができる以上の仕事をすることを約束したので
他の誰か
私たちが道を1か月下る前に、誰でもこのおかしな行為を止めることができたでしょう。
明らかにウォーターフォールプロセスをアジャイルであると不正に表現しているチームを雇ったことでMoney-Bags Corpを非難することができました。契約自体は、これがアジャイルでないことを明確にしています。 1か月で計画を立てても、俊敏性はありません。
それがアジャイルであると主張した場合、それは1か月のスプリントが1つしかないアジャイルです。ええ、やはり滝と同じなのでお勧めしません。
何を終わらせるべきなのですか？
アジャイルはどうですか？すべてのスプリントを配信しますか？締め切り前にフィードバックをお寄せください。 1週間のスプリント？締め切りを隠して祈るのではなく、危険にさらされている疑いがある瞬間に厳格な契約を再交渉するのはどうですか？少なくとも、運命のプロジェクトで時間を無駄にするのをやめて、より合理的な顧客を見つけることができます。
マネージャーは、元のチームの見積もりよりも2倍（または3倍）遅れて期限を移動する必要があります。
期限の乗数は、時計を15分早く設定するのと同じくらい便利なので、遅れることはありません。自分が何をしているかを理解する前に、自分をだますことができます。
初期の見積もりは間違っています。どのように間違っているかをキャプチャしてみてください。 5週間は、数週間を与えるか、取るかは、完了日が実際にどれほど不確かであるかを表すことができる単純な表現です。正確に推測しようとするのではなく、推測がどれだけ乱暴であるかを推測します。実際の作業を行い、実際のデータを取得します。その後、より狭い範囲で推定を開始できます。これを行うには、1〜2週間で十分です。
チームメンバーは、（スプリントが失敗した場合にペナルティを発行することにより）コミットしたすべての作業を行うように奨励されるべきです。
チームメンバーを奨励する必要があります。失敗、コミット、またはその他。罰やボーナス（にんじんと棒）のような人為的な帰結を構築するのではなく、研究は、プログラミングなどの創造的な仕事をする人々が、自律性、習得、目的の3つを提供する場合に最もよく反応することを示しました。
Daniel Pinkはこれについて TEDトーク を持っています。話はアジャイルではなく動機についてですが、私はこれらのポイントをアジャイルにマッピングする方法を簡単に見ました：
自律性-私は自分の人生を導きたい-バックログから仕事を選びましょう。
習得-私は重要なこと-より良い顧客フィードバックを得たいです。
目的-自分よりも大きなものの一部になりたい-共同チーム。
スクラムは会社の期限ポリシーに適合しないため、チームはスクラムを削除する必要があります。スクラムはウォーターフォールよりも正確に期限を迎えることができます。締切を考えれば、スクラムで対応できます。時間、機能、スキルに応じて、47の機能のうち1つだけで対応できる可能性がありますが、対応できます。
アジャイルプロジェクトは非常にスタイルを設定できるため、チームが家に帰るたびに、出荷の準備ができています。これは、出荷を顧客にテストしてフィードバックを提供するように要求していると考えない限り、ばかげているように見えます。発生が早ければ早いほど、調整を行うことができます。これはすべての可能な締め切りを迎えます。すべての機能とは限りません。しかし、それは重要な機能にあなたを導きます。
私たちはみんなソフトウェア開発をやめ、修道院に加わるべきです
ええ、私を実際の部屋から離れた部屋に閉じ込めるように、私はLESSコードを書くつもりです。
私はこの回答をサイズまで編集しました。興味があれば編集履歴を読んでください。
誰もが機敏でなければなりません。あなたがそれを決定するものは何でも、誰が何を、どのように、いつ、どこで、なぜすべての当事者によって行うかのように見えます。アジャイルな顧客、管理者、開発者。
発送日をあまり遠くに指定することはできません。見積もりを出します。
誰かがクライアントの期待を管理する必要がありました。いくつかのスプリントが遅れることについてあまり心配しない理由は、プロジェクト全体の遅れを防ぐように調整するためです。 1〜2回のスプリントの後に終了する予定がないという結論に達した場合は、「出荷日」に達した時点でクライアントに伝えます。
今、あなたは何をしたいですか？不要な機能を削除するか、日付を移動します。あなたが時間通りに配達できれば、あなたはそうするでしょう。悪い知らせをためらうことはありません。
一部のプロジェクトでは、より早く出荷できるかもしれません。
クライアントが望まない場合、アジャイルになることはできません。
ゴール
私は、次の2つの「測定基準」がビジネス上の決定の基礎となるはずだと考えています。
- 収益性の高い作業です（クライアントにとって）
- できる限り効率的に作業していますか
これらは非常に普遍的です。もちろん、非常に複雑になります。たとえば、利益を生む作業とは、製品が正しく機能していること、ユーザーが製品を使用できること、製品が正しく販売されていることなどです。これらの多くの場合Scrum-Addicts LLC "は責任を負いません。
問題
契約は、上で概説した目標に焦点を合わせていません。 「オールオアナッシング」という条項があります。すべてを成し遂げて支払いを受け取るか、何もせずに支払いを行わないでください。ただし、これは作成される価値とは直接関係ありません。次に続くもう1つの欠点：時間と費用をかけて、契約が守られていることを確認する必要があります。なぜ私たちはこのお金を使いたいのでしょうか？その間に要件が変更され、注文されたソフトウェアが価値を生み出していないことが判明した場合、契約が確実に履行されることをどのように支援しますか？より多くのお金が流出しています！もちろん、この動作には理由があります。
- 文化的に私たちはそのようなものを買うのに慣れています。私たちは自動車の場合と同じようにソフトウェアを購入することを期待しています。構成を選択し、価格と期限を指定し、これら2つが満たされない場合は非常に不満です。
- リスクと説明責任を軽減したい
- 私たちは安定性を求めています。それは計画を立てるのに役立ち、気分を良くします（そしてクライアントも重要な側面です！）
結局のところ、目標を可能な限り満たすことができる妥協案を選択する必要があります。
これはそれが機能する方法です
- 製品のの代わりにサービスと作業の契約を結んでいる
- 比較的短期間で終了する必要がある
- 最適な効率を確保するために緊密に連携する
- 「Scrum-Addits LLC」と「Money-Bags Corporation "-すべての情報をトンネリングする"単一の連絡先 "はここでは機能しません
よく私は基本的に「アジャイルである」とだけ言った。ここに理由があります：
- プロセスと契約は、ゴールにできるだけ多くのお金を費やすように最適化されています
- あなたは彼の仕事をするために請負業者を信頼する必要があり、彼が仕事をしていることを確認するために多くのお金を投資する必要はありません。
- 期待/契約が満たされない場合に請負業者を訴えることは、通常は役に立ちません。そうすることは、単にそれを落とすよりも費用がかかるからです。ここでの主な懸念のいくつかは、市場投入までの時間です。あなたはあなたが得るよりも法廷に行くことによってはるかに多くのお金/ビジネスを失うでしょう。
- 結局のところ、自分でいくつかのリスクを負う必要があります。