チームの規模が10を超えても、一緒にリリース計画を立てることはできますか？

次のリリースで何を行うかを決定し、各ユーザーストーリー（および特定のストーリーのサブタスク）のタイミングを見積もるとき、グループでこれを行うのですか、それともマネージャーだけですか？

チームサイズが10の場合、これは実用的ですか？

それはどのくらいかかりますか？

優先順位付けは、コードの利害関係者であり、ビジネスの利害関係者が機能要件の場合と同様に非機能要件の責任者である上級開発者を含む、さまざまな利害関係者からの入力を使用して、単一の製品所有者が行う必要があります。

見積もりは絶対に仕事をする人によって行われるべきであり、配達を迫られるマネージャーによって決して行われるべきではありません。しかし、半ダース以上の人がこれについて議論するのに何時間も費やすという本能は正しいです。理想的な世界では、1つのチームに4人以上7人以下になるようにチームを分割する必要があります。5人が理想的です。

何らかの理由でこれが絶対に不可能であり、不可能であることを受け入れる前にその理由に5つの理由を適用する必要がある場合は、4〜5人のチームがチームによって選択され、彼らに代わって見積もりを行う必要があります。

私の意見では、10人のチームとしてリリース計画を行うべきではありません。ほとんどの場合、最終的に巨大な会議になり、どのような議論でも6〜8人が完全に切り離されて退屈していると感じるでしょう。それに加えて、3〜4時間の疲れが部屋に閉じ込められます。そして、10人が話す場合、あまりにも多くの会話があることを考慮してください。彼らが話さない場合、あなたは貴重なインプットを得られないかもしれません。

私たちはジョセフの会社とよく似たことをしました。以前のリリースには8人のエンジニアがいて、リリース計画には2週間かかっていました。そして、それは絶対に残忍でした。毎日数時間後、私たち全員が話し合いをできるだけ短くして、会議が早く終わるようにしようと思います。

このリリースでは、チームのサイズが2倍以上になりました。そのため、製品のある領域を永続的に所有する小さなチームに分かれました。小さなチームのそれぞれにリードがありました。次に、リードのみを使用して高レベルのリリース計画を実行しました。これにより、部屋に4人の開発者しかいなかったため、より迅速かつ効率的になります。この間、どのチームがどのような話をするのか、製品がどのように分割されるのかを特定しました。また、これにより、製品全体の全体像がリードされます。

その後、各リードは自分のチームに戻り、そのチームのみが担当したリリースの部分を調べました。この間、いくつかの詳細を記入し、ストーリーポイント値を割り当てました。

最後に、すべてがまとめられ、チーム全体が何が起こっているかをチームの全員が理解できるように、1つの最終ウォークスルー（ディスカッションよりもプレゼンテーションのほうが多く）を行いました。

この方法で完全に成功したリリースはありませんでしたが、リリース計画は全体的に以前よりスムーズに行われ、それをはるかに活用したと思います。重要なのは、どのミーティングでも3〜4人を超える開発者がいなかったことと、全員の声がまだ聞こえていたことです。

できれば、10人の開発者を3つのグループに分けることをお勧めします。全体的なリリースを3つのほとんど重複しない領域に分割できない場合、2つのグループでも1つの大きなチームよりも優れています。

私は実際にはリーダーとして複数のプロジェクト（および複数のチーム）の一部ですが、10以上のプロジェクトがいくつかあります。私が取り組んでいるほとんどすべてのプロジェクトで、リリース計画はリードとビジネスアナリストが行っています。ただし、私たちの状況では、BAはマネージャーではないため、マネージャーはリリース計画には実際には参加しません。

ただし、見積もりは実装チームによって行われ、両方の部分は別々ですが、非常に関連しています。

見積もりは、タスクが完了するまでにかかる時間ですが、リリース計画は、それらのタスクが処理されるようにスケジュールされたときです。

計画はビジネスの懸念事項に従って行われるべきであり、見積もりは技術的な懸念事項に従って行われるべきです。したがって、見積もりと計画の分割。

このタスクは、マネージャーによってより効率的に実行されます。小さなチームでは、役割が混同される傾向があります。誰もがすべてに関与しています。しかし、チームが成長するにつれて、これは管理不能になり、役割を明確に定義する必要があります。

私がすべてに関与したいという欲求を得るのと同じくらい、それは単に生産的ではありません。