開発チームをよりアジャイルに移行するよう取り組んでいます。ストーリーポイントの見積もりと、個人のスキルとの関係について質問があります。
シナリオは、私たちのチームメンバーが部門横断的なスキルを持っていないというものです。完全にフロントエンドに焦点を当てる人もいれば、バックエンドだけに焦点を当てる人もいます。
チーム構成に応じて計画に失敗した問題。平均速度がスプリントあたり200ポイントだとすると、その数を超えてはなりません。ただし、タスクはスプリントごとに異なり、バックエンドタスクまたはフロントエンドタスクが少なすぎる場合があります。
私の質問は、バックエンドとフロントエンドのタスクを別々に分けて計画する必要があるのか、それとももっと良い方法があるのでしょうか。
スクラムで計画するとき、最初に気づくのはnotみんなが忙しいように作業を計画することを試みることですが、チームが試行する特定の機能を計画することを試みるべきです。スプリントの最後に配信します。
スクラムでは、計画への入力は製品バックログであり、ビジネスに最大の価値を提供する順序で目的の機能を含める必要があります。計画中は、スプリントを満たすのに十分な作業ができるまで、製品バックログの先頭からアイテムを取得します。
製品のバックログの上部に、主にフロントエンドの作業を伴う多くの機能が含まれている場合、200ストーリーポイントマークに達する前に、スプリントが「いっぱい」になる可能性があります。ここで完全とは、フロントエンド開発者が完全にロードされていることを意味します。
スクラムフレームワーク内では、この状況に対処するためのいくつかの可能性があります。
スクラムの目標は、個人として最大の能力/生産性で作業することではなく、チームがビジネスに最も利益をもたらすことを生み出すことです。
チームがスプリント計画中にストーリーを描くとき、彼らは利用可能なスキルを考慮に入れるべきです。つまり、バックエンドの容量が十分にある場合は、バックエンドを多用するストーリーを描画し、フロントエンドを多用するストーリーをボードに残すか、またはその逆の可能性があります。
他に何もなければ、一部のプログラマーは必要なリファクタリングの時間を見つけるかもしれません。
不均衡が長期間続く場合は、チームを再トレーニングまたは変更します。
バックエンド開発がゼロまたは非常に少ない(またはその逆)場合は、実用的な目的のために、休暇中または別のプロジェクトで作業した場合と同じように扱います。特定のスプリントでは、ストーリーポイントの合計が調整されます。
管理の観点からは、これをペアプログラミングで人々をクロストレーニングする機会として扱うことができます。クロストレーニングがこのプロジェクトの目標の1つである場合は、両方の開発者の時間/ポイントをカウントします。クロストレーニングを含むプロジェクトを計画するより正確な方法があります。
はい、タスクを作業領域の専門知識で分割する必要があります。これにより、正確なリソースとプロジェクト/スプリントの計画が可能になります。ストーリーポイントの推定後、2週間のインタラクションの次の数か月の間に100のフロントエンドポイントと50のバックエンドポイントがあるとします。
これが事実である場合、非常に高いレベルでは、同じように終了する必要があります。
ストーリーポイントの推定が最初のステップです。 2つ目は、リソース割り当て、ワークストリーム+依存関係の計画です。
プロジェクトはそれぞれ異なり、スキルセットが異なる人々が揃っています。データベースに戻るまでずっとUIフロントエンドを実行できる「フルスタック」開発者はほとんどいません。 .Netのような一般的なテクノロジー内でも、ASP.NET MVC、WCFサービス、Entity Frameworkなどの専門分野があります。そのため、バックログからスプリントを計画するときは、開発者のスキルセットを考慮に入れると、効率的に利用できます。全面的なリソース。