スクラムは公開入札に対応していませんか？
公的機関から、スクラムやかんばんなどの用語や概念を説明する101のアジャイル開発に関する非公式ワークショップを行うように依頼されました。私は約5年間アジャイル環境で働いてきましたが、私は私をスクラムエバンジェリストとは思っていません。
ワークショップの後、彼らはアイデアを気に入った。ただし、外部のソフトウェア会社にソフトウェアの開発を委託する必要があるため、このアプローチはおそらく適用されないだろうと説明しました（開発者はごく少数です）。このアクティビティは、結果、価格、時間枠を説明する公開入札プロセスで実行する必要があります。これは、この組織（公的研究所）の予算を申請するための法的要件です。
これらの制約は、アジャイル開発の基本原則にいくらか矛盾しているように見えますか？
スクラムはそのような環境で互換性がないのですか？
この組織に何を勧めますか？
スクラムはおそらくこの組織には適していません。
スクラムガイドの「スクラムは、複雑な製品を開発、提供、維持するためのフレームワークです。」また、製品に取り組んでいる開発チームの3〜9人のメンバー、プロダクトオーナー、およびスクラムマスター（開発チームに参加しているかどうかに関係なく）の合計4〜11人のチーム向けに設計されています。
内部開発に関しては、開発者は数人しかいないとおっしゃっていますね。スクラムチームを編成するのに十分な規模のチームがない場合、すべてのスクラムを使用することは意味がありません。ただし、一部のスクラムプラクティスは組織にとって役立つ場合があります。
受託開発の場合、外部関係者の一人がスクラムを利用することが可能です。この場合、研究機関がスクラムの実践について知り、役割とその仕組みを理解することは役に立ちます。外部開発組織がスクラムのプラクティスやその他のプラクティスをどのように使用するかについての詳細を理解する必要があるかもしれませんが、それがどのように機能するかを理解するのに役立ちます。たとえば、スプリントレビューに参加する必要性を理解したり、製品バックログの注文に関して組織（おそらく製品所有者）と協力したりします。
米国政府内のデジタルサービス機関である18Fは、政府がどのように契約を作成して、法律に準拠した方法でアジャイル手法を使用できるようにするかについて多くの作業を行い、詳細な要件ではなく一般的な結果を指定して、行われることです。それらのリソースの一部は次のとおりです。
- アジャイル契約形式による政府の成果の向上
- アジャイルブランケット購入契約
- Modular Contracting （アジャイル開発で大きなプロジェクトを小さなモジュラープロジェクトに分割）
- プロジェクトは「アジャイルフォール」を使用していますか？
アジャイルな作業方法の利点は、パート15のように詳細なソリューションを前もって指定するのではなく、契約が与えられた後、つまりアワード後の実行中に、問題の解決策を見つけることに重点を置くことです。詳細なソリューションを必要とする問題を特定します。多くの場合、高レベルの契約配信領域を説明する製品バックログアイテムです。
この問題を理解して、行政管理予算局と連邦調達政策局は、SOWの使用を停止し、サービスの取得にPerformance Work Statement（PWS）の使用にシフトするように指示しました。 PWSは、「（方法）をどのように実行するかではなく、何を実行するかという一般的な条件で要件を述べる必要があります」優れた契約担当官は、専門家のサービスを購入することは、あなたが最も知識がないことを意味することを代理店に助言します「どのように」仕事で行われます。ミッションオーナーとして、あなたは「何を」のエキスパートであり、達成する必要がありますが、2つを融合すると、ミッションが危険にさらされ、契約が価値を提供することが難しくなります。
基本的に、このアプローチは、詳細な仕様のページを事前にリストするのではなく、サービスプロバイダーを雇ってソリューションを設計するようなものです。施設は、「設計は4階建てで、屋根のピッチは37度でなければなりません。3階には、モーションで制御される4つの蛍光灯照明器具を含む237平方フィートのキッチンが必要です。落とし天井の高感度ライトスイッチ。」むしろ、彼らは建築家がクライアントと協議して設計サービスを提供し、結果の成果物を作成するためにその分野の専門家であるベンダーに依存するという契約を結んでいるでしょう。
詳細は、適用される機関および調達のポリシーと法律に依存しますが、大規模な政府ITプロジェクトのすべての失敗の中で、ソフトウェア開発の公開入札をより近代的なアジャイル手法に移行するために活動しているグループがあることを示しています。十分な政治的意志と信頼できる開発パートナーがいる。このようなプロジェクトの構想と管理の方法には大きな変化があり（プロセス全体を通じてユーザーからのフィードバックを提供する多くの継続的な時間を含みます）、組織が追求することに関心がある場合とない場合があります。
いいえ、SCRUMは公開入札と互換性がありません。公開入札で購入するものを明示する必要があります。
「購入者は、5人の開発者と認定されたSCRUMマスターを含む経験豊富なSCRUMチームから、2週間の開発スプリントを10個購入する予定です（購入者はステークホルダーの役割を果たします。スプリントは2018年3月から2018年7月まで実行されます）」はかなり妥当です入札開始。もちろん、必要なチームのスキルをリストし、彼らが取り組むプロジェクトについてのアイデアを与える必要がありますが、チームを雇うために入札することは完全に許容されます。
もちろん、ここでは「固定スコープ」をあきらめています。結局のところ、それはSCRUMにとって典型的なことです。入札でもう少し多くの表現を使用して（ただし、ここでは法的領域に入る）、小規模なスコープ拡張、つまり少数の追加のスプリントを許可できます。ただし、最初の10回のスプリントの後に追加の10回のスプリントを希望する場合は、おそらく再入札する必要があります。
それは典型的に聞こえます。入札が作成されると、オファーが提出され、候補者の1人に契約が付与されます...公的機関の代表者に関する限り、プロジェクトは完了です。
これが、これらのプロジェクトの多くが失敗する理由です。彼らが予算をはるかに超えた後。
彼らが欠けている点（または少なくとも彼らの懸念の何も感じていない）は、彼らが会議やデモに出席すべきステークホルダーであるということです。
したがって、アジャイルやスクラムとはまったく競合しません。それは彼らの役割を拾っていない人々です。これを引き起こすのは政府の働き方です。
それは、「このシステムが欲しいと思っており、それにある程度の努力を払い、どこまでそれを実行できるかを見てみたい」とは異なります。
いいえ。それは、「私たちの民主主義は、その時までにこのシステムを持つことを決定した」のようなものです。これは、一方では100％の成功ともう一方では100％の失敗の間に余地を残しません。最初から運命づけられた。
また、ばかげたレートを求めることは市場への誘いでもあります。高すぎるためにプロジェクトを行わないことは選択肢ではなく、入札が書かれる前にそれを行うという決定はすでに行われています。
十分に公平であるとしても、利害関係者が彼らの役割を取り上げても、彼らは完全に無力になるでしょう。同じ理由で、これらのデモのどれにも信頼できる棒はありません。
それは難しい。
あなたは明らかに自由な予算で仕事を入札することはできません。したがって、何を行う必要があるか、そしてこれを行うにはどれだけの労力が必要かを検討する必要があります。
現在、多くのソフトウェアプロジェクトが失敗する理由は、事前の修正、時間、労力、スコープが非常にエラーが発生しやすいという事実によるものです。たとえば、入札で指定された仕様には、ほとんどの場合あいまいさが伴います。
したがって、アジャイルだけでなく、ソフトウェア開発に対する公開入札の概念にも根本的な問題があります。あなたが指定した時間に、誰かが外に出てあなたが望むものを正確に作成する可能性は低いです。
ある程度の柔軟性を考慮すれば、これを改善できます。
公共の入札に仕事を出すプロセスは柔軟ではないようです。ただし、契約が成立すると、リグルルームがある場合があります。たとえば、アジャイルな作業を許可することはできますが、これがスコープに影響を与える可能性があることを受け入れる必要があります（そして法的認可を取得する必要があります）。
これで、何が起こっているかを早期に確認し、製品に組み込まれる前に変更を加えることができるので、これはより良い製品になると信じています。厳密なフィードバックループと反復的な開発により、actual要件（入札に出されたものとされない場合がある）に適合する製品を作成できます。
状況によりますが、おそらくそうです。
IT関連のプロジェクトで政府と協力したことがある人なら誰でも、実際には入札に記載されている「ハードリミット」がすべて満たされることはないことを知っていることを、私は喜んでお金を賭けます。物事は予算を超え、遅れたり、スコープが変更されたりする傾向があります。通常はそれらの倍数です。政府がこれが真実であることを認めて、ガイドラインのように扱いたいと思っているなら、スクラムは本当にうまくいくでしょう。
個人的な経験（私自身と専門家のネットワークの両方）から、政府プロジェクトの大部分で要件が頻繁に変化することを知っています。責任ある委員会は、プロジェクトの最後に最終的に関与するときにも、多くのフィードバックを持つ傾向があります。これらはスクラムが適している問題です。
ただし、これには政府とその機関の考え方の根本的な変更が必要です。ほとんどの国ではveryですが、この変更が行われる可能性はほとんどありません。それまでは、公開入札はスクラムでの作業と互換性がありません。 （その点については、私の個人的な意見では、公開入札は引き続きany持続可能なソフトウェア開発手法と互換性がありませんが、それはまた別の問題です...）
この組織に何を勧めますか？
この時点では何もありません。
ここで欠けているのは、彼らの現在のプロセスが彼らに引き起こしている問題の物語です。スクラムは盲目的に推奨するものではありません。ポイントがあります。ワンサイズではありません。
現在のプロセスによってどのような問題が発生したかを尋ねます。聴く。実際の問題に対処する方法のみを推奨します。彼らは現在のプロセスに偏っています。火口は、開発プロセスを指示するように見えるかもしれませんが、そうではありません。彼らは配信プロセスを指示します。しかし、それはおそらくこのチームが以前に作成する必要がなかった特徴です。
アジャイルは、プロジェクトの存続期間中に要件が3％以上変化したときに最適に機能します。そうでなければ滝はまだ非常に効果的です。現在でも多くの場所で使用されています。そしてもちろん、成功した開発者の多くは、どちらの方法でもプロセスを形式化していません。非難は、難しい問題が技術的なものであり、人々についてではない場合に有効です。
ですから、彼らの現在のプロセスとそれが抱えている問題について話し合ってください。これらの方法がどのように役立つかを説明します。しかし、壊れていない場合は修正しないでください。