公的機関から、スクラム、かんばんなどの用語と概念を説明するアジャイル開発の101に関する非公式ワークショップを行うように依頼されました。私は約5年間アジャイル環境で働いてきましたが、私はスクラム伝道者とは思いません。

ワークショップの後、彼らはそのアイデアを気に入りました。しかし、彼らは外部のソフトウェア会社に彼らのためにソフトウェアを開発するよう依頼する必要があるので、彼らにはアプローチがおそらく適用されないだろうと説明した（彼らは少数の開発者しかいない）。この活動は、結果、価格、および期間を説明する公開入札プロセスで行う必要があります。これは、この組織（公的研究機関）の予算を申請するための法的要件です。

これらの制約は、アジャイル開発の基本原則とは幾分矛盾しています。

スクラムはそのような環境では互換性がありませんか？

この組織に何をお勧めしますか？

スクラムはおそらくこの組織には適していません。

スクラムガイドから、「スクラムは複雑な製品を開発、提供、維持するためのフレームワークです。」また、製品に取り組んでいる開発チームの3〜9人のメンバー、製品所有者、およびスクラムマスター（開発チームにいるかどうかは問わない）の合計4〜11人のチーム向けに設計されています。

内部開発に関しては、少数の開発者しかいないことに言及しています。スクラムチームを編成するのに十分な規模のチームがない場合、スクラムのすべてを使用することは意味がありません。ただし、一部のスクラムプラクティスは組織にとって有用な場合があります。

契約開発の場合、外部関係者の1人がスクラムを使用することは可能です。この場合、研究機関がスクラムの実践を知り、役割とその仕組みを理解することが役立ちます。外部開発組織がどのようにスクラムのプラクティスやその他のプラクティスを使用しているかの詳細を理解する必要がありますが、それがどのように機能するかを理解するのに役立ちます。たとえば、Sprint Reviewsに参加する必要性を理解するか、製品バックログを注文する際に組織（おそらく製品所有者）と協力します。

米国政府内のデジタルサービス機関である18Fは、政府が法律と整合性のある方法でアジャイル手法を使用できるように契約を作成する方法について多くの作業を行っており、作業方法の詳細な要件ではなく一般的な結果を指定しています行われます。リソースには次のものが含まれます。

• アジャイル契約形式による政府の成果の改善
• アジャイルブランケット購入契約
• モジュラーコントラクト（大規模なプロジェクトをアジャイル開発で小さなモジュラープロジェクトに分割する）
• あなたのプロジェクトは「agilefall」を使用していますか？

アジャイル作業方法の利点は、パート15のように事前に詳細なソリューションを指定するのではなく、契約の授与後、つまり授与後の実行中に問題の解決策を見つけることに焦点を当てることです。多くの場合、高レベルの契約配達エリアを説明する製品バックログアイテムとして、詳細なソリューションを必要とする問題を特定します。

この問題を理解するため、管理予算局および連邦調達局は、SOWの使用を停止し、サービスを取得するためにPerformance Work Statement（PWS）の使用に移行するよう機関に指示しました。PWSは、「どのように（方法）が行われるかではなく、何を（結果）が行われるかについての一般的な条件で要件を示す必要があります」 「方法」で作業が行われます。ミッションオーナーとして、あなたは「何を」達成する必要があるかについての専門家ですが、この2つを統合するとミッションが危険にさらされ、契約が価値を提供するのが難しくなります。

基本的に、このアプローチは、詳細な仕様のページを事前にリストするのではなく、サービスプロバイダーを雇用してソリューションを設計することに似ています。施設は建築家を雇って「ビルは4階建てで、屋根のピッチは37ºでなければなりません。3階には、モーションによって制御される4つの蛍光灯器具を含む237平方フィートのキッチンが必要です。 -天井の敏感なライトスイッチ。」むしろ、設計者がクライアントと相談して設計サービスを提供する契約を結び、その分野の専門家であるベンダーに頼って、成果物を作成します。

詳細は適用される機関と調達ポリシーおよび法律によって異なりますが、大規模な政府ITプロジェクトのすべての失敗の中で、ソフトウェア開発のための公開入札をより現代的なアジャイル方法論に移行しようと取り組んでいるグループがあることを示しています十分な政治的意思と信頼できる開発パートナーを与えられた。そのようなプロジェクトの構想と管理の方法に大きな変化があります（プロセス全体でユーザーにフィードバックを提供するための多くの継続的な時間を含む）。

典型的に聞こえます。入札が書かれて、オファーが入って、競争相手の1人が契約を与えられました...公的組織の代表者に関しては、プロジェクトは完了です。

これがこれらのプロジェクトの多くが失敗する理由です。彼らが予算を超えた後。

彼らが欠落している（または少なくとも彼らの懸念のいずれかを感じていない）点は、彼らが会議やデモに参加すべきである利害関係者であるということです。

そのため、アジャイルやスクラムとの競合は一切ありません。それは人々が自分の役割を引き受けていないことです。これを引き起こすのは政府の働き方です。

「私たちはこのシステムを持ちたいと思っており、それに何らかの努力を払って、それをどこまで引き継ぐことができるかを見るつもりです」とは違います。

いいえ。それは「我々の民主主義が、それまでにこのシステムを持つことを決定した」ようなものです。これは、一方で100％の成功と他方で100％の失敗の間に余地を残しません。最初から運命。

それはばかげた料金を要求する市場への招待でもあります。費用が高すぎるためプロジェクトを行わないことは選択肢ではありません。それを行う決定は入札が書かれる前に既になされています。

関係者が自分の役割を引き受けたとしても、まったく無力です。同じ理由で、これらのデモを実行するための信頼できるスティックはありません。

いいえ、SCRUMは公開入札と互換性がありません。あなたは、公開入札で購入するものを明示的に述べる必要があります。

「購入者は、5人の開発者と認定SCRUMマスターを含む経験豊富なSCRUMチームから2週間の開発スプリントを10個購入しようとしています（購入者は利害関係者の役割を果たします）。スプリントは2018年3月から2018年7月まで実行されます」入札の開始。もちろん、必要なチームのスキルをリストし、彼らが取り組むプロジェクトについてのアイデアを与える必要がありますが、チームを雇うために入札をすることは完全に受け入れられます。

もちろん、ここでは「固定スコープ」をあきらめています。結局のところ、これはSCRUMに典型的なことです。入札でもう少し言い回しをします（ただし、ここでは法定領土に入っています）。小さなスコープ拡張、つまり少数の追加スプリントを許可できます。ただし、最初の10回のスプリントの後にさらに10回のスプリントを希望する場合は、おそらく再入札が必要になるでしょう。

それは難しい。

あなたは明らかに、無制限の予算で作品を入札することはできません。そのため、何をする必要があり、これを行うにはどれだけの労力が必要かを検討する必要があります。

現在、多くのソフトウェアプロジェクトが失敗する理由は、前もって修正、時間、労力、およびスコープが非常にエラーを起こしやすいという事実によるものです。たとえば、入札で指定された仕様には、ほとんど常に曖昧さがあります。

そのため、アジャイルだけでなく、ソフトウェア開発の公開入札の概念にも根本的な問題があります。指定した時間内に、誰かが外に出て、あなたが望むものを正確に作成する可能性は低いです。

ある程度の柔軟性を考慮すれば、これを改善できます。

仕事を公開入札に出すプロセスは柔軟ではないようです。ただし、契約が成立すると、苦労する余地があるかもしれません。たとえば、アジャイル作業を許可することもできますが、これがスコープに影響を与える可能性があることを受け入れなければなりません（そして法的許可を得る必要があります）。

今、私はあなたが早期に何が起こっているかを見て、それらが製品に焼き付けられる前に変更を加えるようになるので、これはより良い製品になると信じています。タイトなフィードバックループと反復的な開発により、実際の要件により適合した製品を作成できます（これは、入札に出されたものである場合とそうでない場合があります）。

それは異なりますが、おそらくはいです。

IT関連プロジェクトで政府と協力した経験のある人なら誰でも、入札に記載されている「厳しい制限」がすべて満たされないことを知っていることを賭けたいと思います。物事は予算を超え、遅れ、および/または範囲が変更される傾向があります。通常、それらの複数。政府がこれが真実であることを認めて、彼らを彼らがそうであるガイドラインのように扱うことをいとわないならば、スクラムは本当にうまく働くことができます。

個人的な経験から（私自身と私の専門的ネットワークの両方で）、政府のプロジェクトの大部分で要件が頻繁に変わることを知っています。また、責任ある委員会は、プロジェクトの最後に最終的に関与する際に多くのフィードバックを受け取る傾向があります。これらはスクラムが適している問題です。

ただし、これには政府と政府機関の側の考え方の根本的な変更が必要です。ほとんどの国では、この変化が起こることはほとんどありません。その時まで、公開入札はスクラムでの作業と互換性がありません。（さらに言えば、私の個人的意見では、公開入札ではとの互換性であり続けるであろう任意の ...持続的なソフトウェア開発の実践が、それは別の時間のために別の問題です）

この組織に何をお勧めしますか？

この時点では何もありません。

ここで欠けているのは、現在のプロセスがどのような問題を引き起こしているのかという話です。スクラムは盲目的に推奨するものではありません。それにはポイントがあります。ワンサイズですべてに合うわけではありません。

現在のプロセスがどのような問題を引き起こしたのかを尋ねます。聴く。実際の問題に対処する方法のみを推奨します。彼らは現在のプロセスに偏っていきます。Tinderは開発プロセスを指示するように見えるかもしれませんが、そうではありません。彼らは配達プロセスを指示します。しかし、それはこのチームがこれまでに経験したことのない違いです。

プロジェクトの存続期間中に要件が3％以上変化する場合、アジャイルが最適に機能します。そうでなければ、滝はまだ非常に効果的です。現在でも多くの場所で使用されています。そしてもちろん、多くの成功した開発者は、どちらの方法でもプロセスを形式化することはありません。非公式は、難しい問題が技術的なものであり、人々に関するものではない場合にうまく機能します。

そのため、現在のプロセスとそれが抱える問題について話します。これらの方法が何に役立つかを伝えてください。ただし、破損していない場合は修正しないでください。