私はスクラムのいくつかの側面(2週間のタイムボクシング)を取り上げたチームと作業を始めたばかりです(現在、チームはすべての見積もりまたはスプリントのポイント数に同意していませんが、これを変更します製品の所有者は、ある程度の開発経験を持つ技術リソース(科学者)でもあります。
製品所有者のタスク(主に研究が関係する)をチームのタスク(いくつかは研究といくつかの開発である)と混合するのが適切ですか。
私はスクラムのいくつかの側面(2週間のタイムボクシング)を取り上げたチームと作業を始めたばかりです(現在、チームはすべての見積もりまたはスプリントのポイント数に同意していませんが、これを変更します製品の所有者は、ある程度の開発経験を持つ技術リソース(科学者)でもあります。
製品所有者のタスク(主に研究が関係する)をチームのタスク(いくつかは研究といくつかの開発である)と混合するのが適切ですか。
回答:
スクラムの専門家は、プロダクトオーナーとスクラムマスターは2人の異なる人物である必要があると述べています。ただし、開発チームから除外するようなルールはありません。スクラムガイドの注記:
開発チームの規模
最適な開発チームのサイズは、機敏さを保つのに十分なほど小さく、重要な作業を完了するのに十分なほど大きくなります。開発チームのメンバーが3人未満の場合、相互作用が減少し、生産性の向上が小さくなります。小規模な開発チームは、スプリント中にスキルの制約に遭遇し、開発チームが潜在的に解放可能な増分を提供できなくなる可能性があります。メンバーが9人を超えると、調整が必要になります。大規模な開発チームは、経験的なプロセスを管理するには複雑すぎます。プロダクトオーナーとスクラムマスターの役割は、スプリントバックログの作業も実行していない限り、この数には含まれません 。
最終行の当然の結果として、プロダクトオーナーがスプリントバックログの作業を実行している場合、そのオーナーは開発チームのメンバーとしてカウントされます。
そうは言っても、あなたの仕事を上手く行うためにどんなことでもしなさい。
プロダクトオーナーは、製品の価値と投資収益率を最大化する責任があります。シンプルに見えるかもしれませんが、通常はフルタイムで非常に厳しい役割です。おそらくスクラムで最も難しい役割です。市場機会の分析や製品の利害関係者やユーザーとの協議から正しい決定を下すこと、製品ロードマップとバックログを常に洗練された状態に保ち、計画に参加することまで、多くの高レベルの戦略的作業と低レベルのタスクが含まれます。アクティビティを確認し、チームが質問に答えられるようにするなど。
POがそれ以外の他のタスクを担当している場合、ほとんどの場合、それらはマージナルとしてのみ表示されます。ですから、私の答えは「はい」です。本当に必要な場合、およびスプリントのソフトウェア増分の生成に直接貢献する場合は、POのタスクを作成しますが、平均的なスクラムプロジェクトで頻繁に発生することはないと思います。
スクラムは何よりもまずコミュニケーション、そして適切でタイムリーな仕事をすることです。チームの生産性を最大化できるのであれば、その目標を達成するために何でも大丈夫です。
しかし、うまくやるのは難しい。私は現在その立場にあり、まだ開発の時間を残している間、製品の所有者として適切な時間を費やすことが難しいと感じています。ただし、この時点で、この特定のチームには配置が適切に機能します。パフォーマンスが低下したときに二重の義務を果たすという決定を再検討しますが、それまではこの方法で作業を続けます。
だから、それを試してみてください。プロセスを継続的に改善できるように、振り返りを行います。以前にいくつかの方法論に固執することで、チームの生産性が妨げられないようにしてください。