私はスクラムを初めて使用し、スプリントの背後にあるチームの概念を理解していますが、ソフトウェア開発に精通していないプロダクト オーナーからの干渉を最小限に抑えるチームの保護者が必要だと思います。あなたの成功は何ですか? また、どのようなホラーストーリーを体験しましたか?
アップデート：
ビジネス プロセスを実装するためのコーディングと、クライアントに適したアーキテクチャの作成との間のバランスを探しています。プロダクト オーナーがビジネス ユニットの出身である場合、データ モデルなどに費やすべき時間についてのガイダンスが必要です。
意味：
「制御不能な」プロダクト所有者とは、通常、時間枠を積極的に設定する一方で、その見積もりを作成する実際の技術的能力を持たないビジネス ユニットの誰かを意味します。通常、この担当者は次のように言います。「来週の運営委員会との次の会議の前に、これらの画面が必要です。そのため、まずそれらの成果物に優先順位を付けます。運営と話し合った後で、データベースに取り組みます。」
みんな素晴らしい答え。良い情報をありがとう。
責任はスクラムで非常に明確に定義されています。プロダクト オーナーはバックログ項目を定義して優先順位を付け、開発者はスプリントでどれだけのことができるかをコミットします。
したがって、プロダクト オーナーには見積もりを設定する権限がまったくありません。もちろん、彼は特定の時点まで何かが必要だと言うことができます-それは単に起こります. しかし、それが可能かどうかを判断するのは開発者です。それができない場合は、スコープを変更する方法や、PO のニーズを可能な限り満たすためにできることを一緒に考えなければなりません。
さて、これがスムーズに機能しない状況で SM が正確にどのように行動すべきかは、特定の状況に大きく依存します。ただし、彼がチームを PO から保護するよりも、PO とチームの間の良好な関係とコミュニケーション文化を促進することを望んでいます。
「制御不能」の問題ではないと思います。
「来週の運営委員会との次の会議の前にこれらの画面が必要なので、まずそれらの作業成果物に優先順位を付けます。我々は、運営委員会と話し合った後にデータベースに取り組みます。」
このステートメント自体には、本質的に問題はありません。アプリが適切に抽象化されている場合、DB はとにかく分離されています。最初の UI の主な問題は、より心理的なものです。非開発者は、画面を見ればほとんどの作業が完了したと思い込み、物事が「遅くなる」と大騒ぎします。ただし、実際の問題は次のとおりです。
あなたが製品所有者としてフラグを立てた人は製品を所有していないため、十分な責任を負っていません。
製品は全体であり、単に「機能要件」(用語を借りる) ではありません。SM は腰を落ち着けて、達成する必要がある舞台裏の作業の範囲を理解することを PO が押し付けようとしないことを断固として主張する必要があります。PO がスコープ全体を見始めると、実際には、より広範な利害関係者コミュニティに対するあなたの代表者になることができます。
最終的には、SM が強制プロセスを担当します。彼らはそのように振る舞うべきです。
プロダクト オーナーは、あいまいな、またはさまざまな顧客の要求からあなたを保護する人物であると考えられています。
製品所有者は見積もりを出してはなりません。
「データモデルなどに費やすべき時間についてのガイダンスが必要です。」
右。優先順位付けとはまさにこのことです。仕事を定義し、優先順位を付けます。優先順位に従って作業します。
何が制御不能になる可能性がありますか？
何かが完了する前に作業を再定義しますか?
作業が完了する前に優先順位を再定義しますか?
解決策は同じです。作業を細かく分割して、変更を加える前に何かを完了させます。
短い (2 週間) スプリントの場合、制御不能になることはありません。もう少し実用的な 4 週間のスプリントを選択すると、問題が発生する可能性が低くなります。
イテレーション（スクラムのスプリント）スコープは、イテレーション中に変更しないでください。そのため、一度に1つの反復のみが計画されます。S. Lottが指摘したように、反復が短いほど、プロダクトオーナーは新しいことをより早く計画できるようになります。
スクラムマスターの役割は、チームをそのようなプレッシャーから隔離することであり、新しい要求は次の反復を待たなければならないことをプロダクトオーナーに伝えるものとします。
現在、プロダクトオーナーの役割は、チームが生み出す作業の価値を最大化することです。したがって、現在の反復の終了を待つことができなかった新しい最優先のアイテムがある場合でも、同様の見積もりでアイテムを置き換えることができます。そしてそれは開始されていません。これは例外であり、規則ではありません。
明確に定義されたエンゲージメント ルールに固執することで、あなた (SM) はむしろチームを率いることに時間を費やすことができます。
S.ロットに同意します。短いスプリントの方が優れています。短いユーザー ストーリーが役立ちます。ユーザー ストーリーを最大 2 ～ 4 日に制限しようとしています。
すべてのユーザー ストーリーが明確に定義されていること、および所有者がそれらに同意していることを確認してください。
スプリントが開始されたら、新しいタスクを現在のスプリントに追加することはできませんが、次のスプリントで優先度を高くすることができると主張してください。スプリントが短いほど、これははるかに簡単になります。
また、人為的な期限の強制を取り除くために、可能な限り次のスプリントの開始まで、現在のスプリントからアイテムを提供しないでください。
アジャイル開発で最も難しいのは規律です。規律あるチームとスクラム マスターがあれば、ユーザーはそれに慣れ、物事はよりスムーズに進みます。プロジェクト管理用のソフトウェアを使用しているかどうかはわかりませんが、Rally を見てください。彼らは、過去1年ほどの間にいくつかの大きな改善を行いました.
私は 2 つの異なるショップでアジャイルを使用しましたが、どちらの場合もうまく機能しています。制御不能な何かがシステムを台無しにする可能性があるとは思いません。スプリントの前に、実行するすべてのタスクを計画し、それらにかかる時間を推測します (常に切り上げます)。次に、スプリント中に実行できる作業量を概算できます。
ほとんどのショップでは、4 週間のスプリントと 1 日 6.5 時間の作業時間を使用しています。スプリントが設定されている場合、新しいタスクを導入することはなく、スプリントに忍び寄る計画外の作業のみが、追加する機能のバグを修正します。もちろん、それは推測時間に含まれると想定されます。
より具体的な答えが必要な場合は、「制御不能」なプロダクト オーナーの意味を定義する必要があります。
言いたいことが2つあります。
おそらく、ある種の R&D マネージャー (必ずしもスクラム マスターである必要はありません) がいて、プロダクト オーナーではありません)。
この男は、開発者を「保護」することができ、そうすべきです (私はそう思います)。そのような人がいたとき、私たちは状況にありました、そしてそれはかなりうまくいきました. たとえば、彼はバックログで機能しないものを取得するのを手伝ってくれました。
今、私たちはこの男を持っていません。私たちのマネージャーはスクラムマスターです。そして、彼は私たちを守るのにもかなり良い仕事をしています. とはいえ... ここでの問題は、ジェネリック スクラム マスターには公的な権限がないことです。そのため、彼は「あなたは彼らにそんなに圧力をかけるつもりはない」とは言えませんが、チームが助けを必要としていると判断した場合は、もちろん話すことができますし、話す必要があります。
チーム自体とプロダクト オーナーも時間とともに進化し、お互いをより気遣うようになります。プロダクト オーナーは、チームがそれ以上のことをコミットしない場合や、「今は非機能的な作業に時間が必要だ」と言う場合を理解しています。
しかし、繰り返しますが、もちろん、開発者の世話を主な責任とする別のR&Dマネージャーがいればいいのですが...そうすれば、よりバランスが取れると思います..
また、サポート タスクのために開発者を借りるサポート部門もあります。場合によっては、この顧客またはその顧客に対して何が行われるか、または行われないかについて合意するのが難しい場合があります (サポートがすべてを望んでいるため)。この場合、R&D マネージャーも非常に良いアイデアです..
理想的には、開発者がマネージャーやシールドを必要としないように、完全にリーンになるアイデアが好きです...しかし、それが機能するかどうか、またどのように機能するかはわかりません... :)