スクラムの使用中に会社の手順をどのように実装しますか？
私のマネージャーは、分析と設計の新しいISO手順を実装するタスクを提供します（後でそれはソフトウェア開発サイクル全体になります）。なぜなら、チームには要求されるソフトウェアを開発する方法論がないためです。 「開発者は彼らがやりたいことをする」。
私のマネージャーはSCRUMを実装したいと思っています（一般的なアイデアを持っているだけです）が、SCRUMでは手順が反復的であるため、チームはどのプロセスを使用するかを決定します（要件の収集方法、設計x UI、どのようにプログラムする必要があるか）、私はそれが物事をどのようにすべきかという技術的な手順を持つことと矛盾していると感じています。
質問
SCRUMで発見する一般的な要件はありますか？インタビューのように、クライアントとの調査、そしてそれらの要件のスタックは、バックログのための複数のスプリント会議でチームと共有されるか、チームと利害関係者との継続的な発見です（スプリント会議のユーザーストーリー）
私は設計手順を作成する必要があります。これは、UI設計（モックアップ、プロトタイプなど）へのアプローチ方法を説明するものです。
特定の方法論なしで各アプリケーションの開発プロセス全体を再作成する責任は取り除かれますが、アナリストはこの手順に従い、プロジェクトが何をプロジェクトと共有して実装を開始するかを見た後、実装を開始します。
質問がメインの質問に固有のものではないことは知っていますが、それらの回答は答えを見つけるのに役立ちます。
私は認証を取得するつもりはありません。社内のすべての手順は標準のISO27001で行われていますが、試行錯誤を繰り返しながらドラフトプロセスを進めています。
経営陣が望んでいるのは、開発サイクルがどのようになるかについての確立された手順です。これは、作業と同じように流れが進化するため、アジャイル/スクラム手法と統合するのが少し難しいと感じました（おそらくそれについてもっと調査する必要があります）。人をプロセスに置きます。
スクラムはソフトウェアの開発方法を教えず、コミュニケーションの瞬間と関係者間で情報を転送する方法を指示するだけです。スクラムはソフトウェア開発方法論ではありません。計画セッション、スタンドアップ、デモを行い、壁のバーンダウンを維持し、役割（SM、PO、チーム、クライアント）。 ISOを実行したい、または実行する必要がある場合、それはストーリーを見積もるときに考慮しなければならないタスクの一部にすぎません。
ソフトウェアがXYZに準拠する必要がある場合、それは完了の定義の一部にすぎません。競合があってはなりません。スクラム自体には、製品要件を無効にする権限がありません。それがそのように感じるならば、それは何人かの人々がそれを彼らのやり方にするための言い訳としてスクラムを使用しているという理由だけです。これは珍しいことではありません。
SCRUMで発見する一般的な要件はありますか？インタビューのように、クライアントとの調査、そしてそれらの要件のスタックは、バックログのための複数のスプリント会議でチームと共有されるか、チームと利害関係者との継続的な発見です（スプリント会議のユーザーストーリー）
スクラムは特定の方法については黙っています。
プロダクトオーナーの役割は、プロダクトバックログのアイテムが開発チームに役立つ方法で明確に表現され、プロダクトバックログアイテムの順序が管理され、すべての利害関係者が何について明確であるかを確認する責任があります。チームは現在取り組んでおり、次に取り組む予定です。
スクラムフレームワークの何も、これらのことを行う方法をプロダクトオーナーに伝えません。プロダクトオーナーである唯一のものは1人です。アナリストや製品マネージャーのチームが存在する場合もありますが、チームの利害関係者と製品ビジョンを代表する1人の人物がいます（代替を特定することもお勧めします）。
製品バックログが良好な状態にあることを確認することの一部は、要件を発見してキャプチャすることです。しかし、これは、利害関係者と製品所有者の両方にとって快適な方法で行うことができます。
私は設計手順を作成する必要があります。これは、UI設計（モックアップ、プロトタイプなど）へのアプローチ方法を説明するものです。特定の方法論なしで各アプリケーションの開発プロセス全体を再作成する責任は取り除かれますが、アナリストはこの手順に従い、プロジェクトが何をプロジェクトと共有して実装を開始するかを見た後、実装を開始します。
ここで役立つかもしれないものは、「Readyの定義」の概念です。スクラムフレームワークは、「完了の定義」を定義します。完了の定義は、すべてのチームが作業が完全に完了していることを確認するのに役立ちます。ただし、一部のチームは、「準備完了の定義」の概念も開発しています。これは、開発チームがバックログ項目を開始する前に行う必要がある作業です。
チームが独自の仕事のアプローチを選択する限り、それはスクラムの原則です-チームは仕事のやり方を検査し、適応することができます。ただし、外部からの指導があれば、チームの働き方に制限を設けてもかまいません。 ISO要件に対応するプロセスを文書化した場合でも、「プロセス調整」を実行することもできます。各ISO要件の意図を完全に理解し、組織の標準を文書化する必要があります。
余談ですが、私は Disciplined Agile を見ることをお勧めします。 Disciplined Agileに実装されているプロセスライフサイクルモデルの1つは、スクラムに大きく基づいています。他のモデルは、他のアジャイルで無駄のない方法論に基づいています。ただし、スクラムとは異なり、ガバナンス（ISO標準、CMMI、規制要件）やこれらの環境でアジャイルメソッドを実装する方法などの懸念に対処します。
- SCRUMで発見する一般的な要件はありますか？
はっきりとは違います。 Henrik Kneibergの言葉を引用すると、「プロジェクトの始まりは、あなたが最も知らないときです。それでは、なぜすべてを計画するのですか？」
スクラムの全体的なアイデアは、ユーザーのニーズと「正しい」デザインが出現するということです。要件収集プロセスは進行中です。そうは言っても、製品のキックオフまたはリリース計画セッションが1、2日続き、チーム全体がユーザーと話し合ったり、どこから始めればよいかについて話し合ったりすることは珍しくありません。経験上、少し前もって時間を費やす価値はありますが、特定したものがすべて間違っている可能性があり、破棄する必要があると仮定すると、正確にどれだけ短くするかという基準を設定する必要があります。
- 私は設計手順を作成する必要があります。これは、UI設計（モックアップ、プロトタイプなど）へのアプローチ方法を説明するものです。
素晴らしい質問です！ワーキングアグリーメントはスクラムと完全に互換性があります。最良の開発プラクティスはチームから来る必要がありますが、そのチームは通常、他のチームや会社全体と協力する必要があります。バランスを見つける必要があります。明らかに、チームがAccess '97でアプリ全体を構築したいのであれば、それはおそらく難しいことです。それがチームが望んでいることであるかどうかは関係ありません。一方で、それらを軽く保つようにしてください。たとえば、会社全体がラピッドプロトタイピングに特定のプログラムを使用している場合は、それを会社の標準として含めますが、衝突しないより良いオプションまたは別の選択肢があることをチームに知らせます（おそらく、節約できるオープンソースバージョン）同じファイル形式で）。
スクラムには、ここで役立つ2つの重要なツールがあります。準備完了の定義と完了の定義です。それらの非常に短い説明は、チームがそれらをスプリントに入れる前にアイテムが準備完了の定義を満たさなければならず、チームがそれらが終了したと言うことができる前に完了の定義を満たさなければならないということです。複数のチームがある多くの場所では、すべてのチームに共通のDoRとDoDがあり、個々のチームがそれらに追加できます。
アナリスト
だから、これは主なことではありませんが、あなたはそれを言及し、それはあなたをつまずかせるかもしれないものです：対処する必要のある「何」またはニーズ、または解決する必要のある問題は、製品によって識別および改善されます自分の考えをチェックするためにチームや利害関係者と話し合うオーナー。次に、チームはそのニーズをどのように解決するかを決定します。実装を作成します。データソース、UIフロー、グラフィック要素が完了した状態でバックログアイテムがチームに届く場合、実装の一部はスクラムチームとスプリントの外部で行われています。
多くの場合、これを見ると、アナリストやデザイナーはすべてのことを前もって行っており、結果は常に同じです。アナリストやデザイナーは埋もれてしまいます。 6人のコーダーは、アナリストが複雑な問題を解決するよりもはるかに高速にコードを記述します。この場合、それらの問題を解決し、その相互作用を設計することはすべて実装の一部です。そのデザイナーまたはアナリストはチームの一部であり、ループインする必要があります-その作業はスプリントの一部である必要があります。それはあなたの質問から少し外れていることを私は知っていますが、私は何かを言いたかったので、非常に多くのチームがその罠に陥るのを見てきました。
SCRUMは実際にはアジャイル開発原則のセット以上のものであることを指摘する価値があると思います。私の理解から、実際にはかなり明確に定義された開発プロセス（スプリント、毎日のスクラム、スプリントの計画など）があります。だからあなたのこの声明
sCRUMではステップが反復的であるため、チームは使用するプロセスを決定するので、物事がどのように行われるべきかという技術的な手順を持つことと競合していると感じています。
sCRUMには、ソフトウェアを開発する方法に関する技術的な手順が中核にあるため、私はイライラします。
あなたの質問について
SCRUMで発見する一般的な要件はありますか？
製品所有者の役割は、機能要求を作成する責任があります。機能要求は、スプリント計画会議中に（ユーザーストーリーで）さらに指定されます。
残念ながら、私はISO 27001についてあまり知らないので、それをSCRUMと組み合わせようとすることが理にかなっているのかどうかはわかりません。ただし、もう一度言いますが、SCRUMがアジャイルであるからといって、プロセスを定義しないわけではありません。それどころか、SCRUMはプロセスを明確に定義し、それに準拠することについて非常に厳格です（プロセスに対する独自の調整を定義したり、既存のプロセスに組み込んだりする際の自由度がはるかに高いかんばんなど、他のアジャイルメソッドと比較して）。
ここ スクラムとそのプロセスの詳細を読むことができます。