改良アクティビティをカレンダーに「ロック」する必要がありますか？ -スクラムチームのメンバー全員が参加する必要がありますか？
2週間のスプリントがあり、POはグルーミングアクティビティを編成します。グルーミングアクティビティは、必要に応じて、開発時間の10％を超えないようにする必要があります。
質問は次のとおりです。-調整アクティビティをカレンダーに「ロック」する必要がありますか？ -スクラムチームのメンバー全員が参加する必要がありますか？
私の懸念：-すべてのチームメンバーが参加している場合、すべての機能がすべての参加者に対応しているわけではない状況が発生する可能性があります。しかし、一部のメンバーだけに電話をかけると、グルーミング後のコミュニケーションで何かが失われるのでしょうか？
改良アクティビティをカレンダーに「ロック」する必要がありますか？
これはhaveにはなりませんが、10％がいつヒットするかがわかっていると、スプリントの計画が非常に簡単になります。グルーミングミーティングによってスプリントがランダムかつ自発的に中断されるのは嫌です。私が知っているほとんどのチームは、その時点を設定することを好むので、準備することができます。身だしなみは、人々が盲目的につまずくべき会議ではありません。適切に見積もるには、誰もが問題のストーリーを読んで、不明な点を見つけたり、自分で解決できる質問をクリアしたりする必要があります。ですから、人に話を読んだり、会議の外でしか答えられないような質問をしたりすることに時間を無駄にしないでください。
スクラムチームのメンバー全員がそれに参加する必要がありますか？
必須？いいえ。誰かが病気や休暇中の場合でも、会議を開催できます。人生は続く。しかし、あなたはすべてのメンバーが出席することを求めていますべきです。彼らはより生産的に働くことができなかったでしょう。答えはyes彼ら全員が参加しすべきであり、他には何もしません。コミュニケーションと透明性は、スクラムのキー機能です。製品の一部を変更する開発者もいれば、その変更について何も知らない開発者は不健康で逆効果です。非常に、veryまれなケースを除いて、バックエンドのみの変更やフロントエンドのみの変更などはありません。ユーザーに表示されないバックエンドの変更はユーザーに価値をもたらしません。そのため、一部のテクニカルストーリーを除いて、それはストーリーではなく、完全ではありません。バックエンドなしで（つまり、データの読み取りや書き込みなしで）フロントエンドを変更することは、完全に簡単なことのようです。別の企業ブランドへの切り替えやスプラッシュスクリーンの統合などの例外があるかもしれませんが、まれです。
したがって、everybodyは、製品のevery変更について知っている必要があります。そうでなければ、あなたはスクラムチームではなく、同じ部屋で同じ上司のために働いている開発者の集まりです。
スクラムやその他のアジャイル手法で一般的に達成しようとしていることは、目標に向かって予測可能な進歩です。
これを台無しにすることができる主なものの1つは、他のチームまたは人々に依存するタスクです。
例えば。 「それは3時間しかかからない簡単な仕事です」。 3日後、「他のタスクが完了していないためブロックされています」
または。 「なぜこの最優先課題は行われないのか！」 「優先度の高いものはスキップしました。ボブがそれらを実行するのに最適な人物であり、他に好きなものを追加したからです」
これが、あらゆるタスクに取り組むことができる部門横断的なチームメンバーと、製品に必要な技術スタック全体をカバーできる部門横断的なチームを持つことを称賛する理由です。
したがって、私は強くアドバイスnotタスクをFEとBEに分割し、すべてのチームメンバーがすべての会議に参加するようにします。
計画会議が長くなりすぎている場合は、タスクとスプリントを小さくしてください。これにより、より少ない計画でより少ないバイトをとることができます。
あなたがする必要があるどのくらい計画を立てようとしないでください。いくつかのことを行って、thenがどれだけ完了したかを確認します。確かにあなたはいくつかの行き止まりを下る可能性があります。しかし、あなたはあなたの目標に向かって徐々に、測定可能な進歩を遂げるでしょう。
最終的には、チームによって異なります。 スクラムガイド は、絞り込みの方法を指定しません。ただし、 Nexus や LeSS などのスケーリングされたスクラムフレームワークでは、リファインメントはアクティビティからイベントに昇格し、その周りにもう少し構造とガイダンスがあります。ただし、これは、1つの製品バックログを調整する複数のチームがある場合に予想されます。
私が一緒に仕事をしたチームは、カレンダーでチーム全体の調整会議をしたいと思っていましたが、調整に関する他の作業は、個別に、小グループで、またはこの定期的にスケジュールされた調整セッションの外で臨時の完全なチームセッションで行われます。定期的にスケジュールされたセッションは主に見積もりに焦点を当てていますが、それ以外の作業は、作業が明確にキャプチャされ、理にかなっており、適切にスライスされ、チーム全体が見たり見積もりを行う準備が整っていることを確認することです。
製品バックログアイテムがスプリント計画の前に十分に調整および推定され、この状態の製品バックログアイテムが十分にある限り、製品所有者はアイテムの注文に関するトレードオフの決定を行うことができますが、洗練はチームに任されています。
しかし、なぜ10％で絞り込みをタイムボックス化しているのか疑問に思います。スクラムガイドは、このような制限を設けず、固定された固定ウィンドウではなく、推定値として10％を使用します。チームで作業する場合、長期間にわたって10％より大幅に短い時間、または長期間（通常2〜4のスプリント）に対して10％を大幅に超える時間は、遡及的に質問する可能性があります。 。しかし、このしっかりとしたタイムボックスはスクラムの一部ではありません-私は適切な改良が行われていることを確認したいと思います。 Sprint Planningとその後のSprintの実行が容易になるのであれば、10％以上費やしたいと思います。
私はスクラムの専門家ではありませんが、これは最終的には私見です
- チーム上、そのサイズ、およびメンバーがチームに特化している程度（またはチームが完全に部門を超えている場合）
- バックログ自体、それがチームの一部のみに関係のあるセクションに細分できる場合、またはそれが不可能な場合（つまり、製品によって異なります）。
たとえば、グルーミングセッションがフロントエンド機能のみをカバーすることが事前に明確であり、チームがフロントエンド開発者とバックエンド開発者に分かれている場合（質問が課すように）、バックエンドも招待することはおそらくあまり意味がありません。会議への開発者。ただし、私の経験では、純粋な「フロントエンド機能」はそれほど頻繁ではなく、フロントエンドを変更するだけでユーザーストーリーを実装できるかどうか、またはフロントエンドとバックエンドの変更が必要かどうかが事前に明確でない場合があります。
したがって、チーム全体を招待することは理にかなっていますが、場合によっては回避できます-POはチームチームに最適なものをチェックする必要がありますtheir製品および個々のセッションのトピック。
グルーミングアクティビティを「カレンダーで修正」する必要があるかどうかは、チーム、通常の勤務時間、および日時が事前に通知されていない場合に実際に参加するのがどれほど難しいかに依存します。しかし、それはソフトウェアエンジニアリングの問題ではなく、一般的な職場の問題です。
最近、私は毎週1時間の調整時間から始めて、そこから成長するプロジェクトを始めています。その時間の間に、成し遂げられたことが成し遂げられます。新しいものを植えることなく、庭を少し維持するような感じです。追加の会議ですぐに手に負えなくなると、グループ全体が共同でプロセスを理解し、成長させることができます。
優先課題が存在する場合、アイデアは他の会議であり、個々のプロジェクトに関連するプロセスがそれらをキャプチャします。