速度の大幅な増加はスクラム環境で現実的ですか？
私のマネージャーは最近、ベロシティをターゲットおよび生産性の指標として使用することを本当に推進しています。現在、50ストーリーポイントの平均速度で作業しています。私のマネージャーは、40％増加して70ストーリーポイントにすることを望んでいます（チームメンバーの増加なし）。私たちがこの増加を達成しない場合、彼は私たちに理由を説明する完全な内訳を提供することを望んでいます。
チームのパフォーマンスを速度で測定し、それをターゲットとして使用するという全体的な考えは私には間違っているようですが、その理由を説明するのは難しいと思います。何か助け？なぜこれが生産性を測定してインセンティブを与える正しい方法ではないのですか？
まあ、速度を40％増やすのは完全に簡単です。すべての推定値に40％のポイントを追加して、同じ量の作業を行うだけです。
これがそうであることを考えると、速度をターゲットとして使用することが間違っている理由は明らかであるはずです。
不快な答えは少なくなりますが、すべてのことを正しく行いながら、できるだけ速く進んでいることを前提に推定しています。生産性を40％向上させる唯一の方法は、残業するか、すべてを正しく行わないことです。これらはどちらも短期的にはスピードアップしますが、長期的にはスローダウンします。そして、この場合の長期はそれほど長くはなく、外側では1か月です。最適な長期戦略は、持続可能なペースよりも速く進まないことです。
Peopleware プログラマーをより高い生産性に追い込もうとすることの問題について雄弁に語り、しばしば引用される古典です。しかし、一般的に、あなたの道を進んでいるマネージャーの心を変えるのは簡単ではありません。プロジェクトに問題が発生している可能性があります。これは確かに危険信号です。
コメントが指摘しているように、要求はそれが置かれた方法とは明らかに間違っています。しかし、彼は絶えず生産性を向上させたいと思うことは本当に間違っていません。原則として、それはマネージャーが努力する（そして評価される）ものです。
とはいえ、マネージャーは常にパフォーマンスの向上を目指しており、スクラムとアジャイルはすべて順応性のあるものです。速度はあなたの現在の持続可能なペースの尺度ですが、あなたはあなたの栄光に腰掛けるべきではありません。スクラムには、プロセスで機能しないものを評価および変更するための場所があります。それを利用してプロセスを調整すれば、生産性（そしておそらく速度）が上がるはずです。
それで、チームとしてより生産的になる方法を（振り返って）探していますか？あなたのスプリントに、不釣り合いな量の努力を定期的に費やす何かがありますか？対処できますか？おそらく40％の増加にはなりませんが、5-10％から始めればいいのではないですか？スプリントごとにボトルネックを探して対処する必要があります。最終的には、彼が設定した目標に近づく可能性があります。
TL; DR
速度は、スケジュールの見積もりや計画値の生成に非常に役立ちます。また、 プロセスボトルネックの評価 またはチームキャパシティの変更に対する意味のある検出制御にもなります。ただし、これは生産性の有効な尺度ではありません。
Velocityが管理ターゲットと混同されている場合
「速度」は、過去のある期間におけるチームの平均容量を表す範囲です。これは過去のパフォーマンスの統計分析であり、将来のワークロードキャパシティまたはサイクルタイムの確率論的推定を予測するために使用できます。これは、計画の目的でタイムラインまたは目標を設定する管理目標である「スケジューリングターゲット」とはまったく対照的です。
経験豊富なアジャイルプロジェクトマネージャーは、ベロシティの適切な使用は、チームが管理者定義のスケジュールターゲットを満たす持続可能な能力を持っているかどうかを判断することであることを知っています。時には答えはイエスであり、誰もが幸せです。答えがノーの場合もあります。その場合、 鉄の三角形 は、スコープ、コスト、時間、および品質に関するビジネス上の決定を強制します。
政治的オプションを評価する
平均速度は50ストーリーポイントです... 40％増加して70ストーリーポイントにするように依頼されました（チームメンバーは増加しません）。
見積もりの実行が適切であり、速度がかなり安定していると仮定すると、マネージャーは、見積もりスケールを調整したり、履歴パフォーマンスに基づいていない管理目標を設定したりしても、喜びを感じられません。あなたが正しく指摘しているように、これは基本的にcapacity問題です。
キャパシティーの制限は、チームの人数に関連している場合もあれば、組織のプロセスの制限である場合もあります。もちろん、人を追加しても、必ずしも実際のプロジェクト容量が追加されるわけではありません。この一般的な誤解の詳細については、 ブルックスの法則 を参照してください。
あなたの顔の問題は政治的なものです。あなたの投稿の調子から、マネージャーはチームの基本的なキャパシティに実際の変更を加えることなく生産性の向上を見たがっているようです。したがって、解決策はまた政治的であり、本質的に教育的です。
スクラムショップの場合は、適切なフレームワークチャネルを通じてこの問題に対処するようにスクラムマスターに依頼してください。バックログのグルーミングとスプリントの振り返りは、この特定の問題の多くの場合、検査と適応の理想的な機会です。
スクラムショップでない場合は、懸念事項に対処するための適切な方法を組織内で決定する必要があります。あなたが上司と仲良くしている場合は、2人で昼食をとりながら話し合うために、彼に アジャイル見積もりと計画 のコピーを貸与することもできます。
他のすべてが失敗した場合は、履歴書をブラッシュアップし、プロジェクトが爆破するまでプロとして最善を尽くすことによって、 死の行進 の準備をします。 ITプロジェクトの68％が失敗 ;管理目標が組織の能力にしっかりと根拠がない限り、あなたの目標はおそらくその1つでしょう。
上司がスクラムチームでどのような役割を果たしているのか理解できません。彼はコーチですか？彼は製品の所有者ですか？
彼がコーチなどのようにチーム内にいる場合（彼は開発タスクで働いています）、彼が自分の生産性を過小評価している理由を彼に尋ねるかもしれません。イテレーションごとに30ストーリーポイントを個人的に想定できると彼が信じている場合は、それを見せましょう。
より可能性が高い：彼はチームの外にいる、おそらく製品の所有者か？もしそうなら、彼はそのような愚かな要求をすることを理解するべきです、彼は敏捷性をやめました。
基本的なルールは、チームがイテレーションで実行できることをチームが設定しながら、製品の所有者がゴールを設定することです。そうしないと、古典的でよく知られている鉄の循環、つまりリソース、速度、機能につながります。 2つ選んでください。一度に3つを選択することはできません（覚えておいてください：品質は調整変数ではありません。低品質でコーナーを切り取ろうとすると、事態はさらに悪化します）。
彼が現在の目標を変更したくない場合、チームにもっと多くの人を採用することで生産性を40％向上させることができるでしょうか？チームメンバーの事前トレーニングに投資しているのではないでしょうか。チームはまた、継続的な改善を通じて時間の経過とともに速度を上げることができますが、確かに恣意的な決定によってではありません。
チームの速度を変更しようとすることは、部屋のサイズを変更しようとすることに似ています。それは可能ですが、基本的には部屋を変える必要があります。
スクラムマスターや、スクラムの基本を理解している人に説明してくれる人はいませんか？
この場合、マネージャーはチームから正直で忠実な見積もりを得た後、間違った方向を向いています。マネージャは利害関係者に頼って、要求された時間内に要件を完了できないことを彼らに知らせることになっています。次に、マネージャー/アナリストは、どの機能を含める必要があるか、他の機能（数週間であっても）を待機できる他の機能を優先する必要があります。利害関係者が不合理である場合、関与するためには上級管理職が必要になる可能性があり、これは一般に困難であり、他の一連の議論全体が必要になる可能性があります。
私があなたの立場にあった場合、プロジェクト[〜＃〜] is [〜＃〜]が見積もられた時間を要する理由について、詳細なケースを考え出します。また、返品の少ない商品を特定するようにしてください。あまり価値がなく、プログラミングにかなりの労力を必要とするアイテムを見つけ、それらをスプリントから削除するように主張します。また、「Y」の日付に「X」を配信する反復アプローチを考え出し、それが実行可能であることを確認してから、残りのアイテムを取得するフォローアップの反復を考え出します。
基本的に、誰かは、締切までに何を受け取ることができるかを関係者に伝え、要件の大部分が含まれていることを伝える必要があります。次のリリースまでに、残りのアイテムが追加される予定です。顧客がそれほど不合理で、上層部の関与が必要な場合、マネージャーはこれを実現できるはずです。
しかし、顧客が約束を超えていて、今まで誰も話していない場合、それは困難な戦いになります。残念ながらこれは珍しい状況ではありません。
彼をクビにする。つまり、彼の頭を越えて、彼がチームへの信頼をすべて失ったことを説明し、彼はビジネスにとって価値がないことを説明します。このレベルの能力のないマネージャーは、以下のチームよりもはるかに簡単に置き換えることができることを説明します。
そのようなマネージャーに我慢する正当な理由はありませんが、それは必ずしも開発者が辞任すべきだという意味ではありません。この1人の個人だけで、ビジネスに必ずしも何か問題があるわけではありません。その問題を修正します。
そして、上級管理職からの脱却を先取りするために、これが許される間違いではないことを明確にしてください。これは、責任のあるマネージャーが管理しているチームをno理解していることを示しています。それは修正に向いておらず、現在の労働市場に必要があるわけでもありません。マネージャーは、スポーツコーチと同じように、抜群に入れ替えることができます。オーナーはチームを解雇しません。
さて、これは裏目に出る戦略のように見えるかもしれません。しかし、考慮してください：上層の管理者が上司と関係なくても、とにかくあなたはすでに敗北状態にあるでしょう。したがって、まだその負けた立場になっていない状況のみを検討すると、結果ははるかにポジティブになります。本当のリスクは、上級管理職がマネージャーを含むチーム全体を解雇することです。そのリスクを推定できるのはあなただけです。どうやらあなたの出力が望まれている、そうでなければ彼らはそれ以上のことを求めないでしょうが、どの価格で？
2つの問題に直面しているようです。
気になる速度の測定に関する部分は、測定がコストであることです。あなたが本当に改善したいのはvalueです。残念ながら、ソフトウェアの価値を測定することは悪名高いほど困難で主観的です。それでも、不完全で主観的な測定基準でさえ役立つ場合があります。実際の問題は、チームがより多くのコードを作成する必要があることではなく、ストーリーがより価値のあるものである必要があることです。
もう1つの問題は、あなたのアカウントに基づいて、マネージャーが生産性を40％向上させることを期待していたことです。このリクエストのコンテキストについては、質問には記載されていません。あなたのチームが改善したいという希望があれば、それはいい人かもしれません。または、マネージャーがあなたのチームのパフォーマンスが低いと信じていることはそれほど微妙な兆候ではないかもしれません。
編集：あなたのコメントに基づいて、状況は悪いようです。あなたの会社はあなたとあなたのチーム（おそらくあなたのマネージャーも）を解雇するための基礎を築いているようです。別の仕事を探すことをお勧めします。
私の経験では、チーム、問題ドメイン、テクノロジースタックのいずれも変更されない限り、チームのactual速度を上げることは非常に困難でした。
私が増加を達成することができたところで、それは問題でした：
技術的負債を片付ける;すべてが適切な（必ずしも最新ではない！）バージョンを実行していること、コードが適切に因数分解されていること、およびシステムに重複がないこと（重複したコード、未使用のコードなど）を確実にする
プラクティスの改善;可能な場合はペアリング（はい、速度が上がることがわかりました）、積極的にリファクタリングする時間を取って（同上！）、スコープとフォーカスに冷淡です
仕事に最適なツールを見つけたり購入したりします（たとえば、ReSharper for .NETは、ゴールド、Airbrake、SplunkでRuby開発など）に相当する価値があります）。
私は、あなたのマネージャーが速度の任意の増加を要求することは危険信号であると言うここの他の人々に同意します。優先順位の高い別の仕事を探しています。
あなたのマネージャーはあなたのチームに余分な時間を働かせるように求めています（または伝えています）。ボトルネックを取り除き、効率を上げると速度が多少向上する可能性がありますが、その増加（40％）を得る唯一の方法は、その時間内により多くの単位の作業を行う必要があるため、長時間勤務することです。
シナリオを見てみましょう。
2週間の対話の場合、10日としましょう。ユートピアは1日8時間であり、ストーリーポイントは就業日に抽象化されます。したがって、上から見ると、あなたのベロシティは8になります。しかし、再言すると、人々はおそらく電子メール、会議、トイレ休憩などで1日6時間以内に到達しているでしょう。したがって、ベースラインは6です。たとえば、残業で1日10時間勤務したいとします。つまり、開発者1人あたりの速度ポイントは10になります。
あなたの速度は常に変動します。おそらく、その反復中に多くのバグに対処しなければならなかったため、それは低かったかもしれません。多分、要件が欠落しているかもしれません。おそらく誰かが数日間病気になったかもしれません。作業が過大評価されたか、チームが余分な時間を費やしたため、多分それは高かったでしょう。
ただし、安定した50である場合、実際に70に到達するには、追加の時間が必要になります。
速度の問題は、それが従属変数であり、開発プロセスの測定出力であることです。速度を40％上げることを要求することは、より速く走るように車に向かって叫ぶことで、より早く仕事に取り掛かろうとするようなものです。エンジンにより多くの燃料と空気を供給するか、より速い車を手に入れ、さらに交通量の少ないルートを見つけることにより、速度が向上します。
開発者の1時間あたりの機能ポイントなど、適切に測定すれば、より多くの時間を費やしても速度は向上しません。 1日あたりのポイントを測定し、測定中の「日」を再定義する場合にのみ機能します。これは速度の錯覚のみを提供します。
速度を上げるには、開発プロセスの独立変数を改善する必要があります。より高速なコンピューターとコンパイラー、より効率的なビルドシステム、より優れた設計プロセス、より有能な開発者、より優れたワークスペース、スーパーデューパーモチベーション。 40％の改善には、非常に大きな変更が必要です。
共通の作業室の周りの囲まれたオフィスにチームを配置すること、チームにまったく新しい開発ハードウェアを購入すること、または40％を獲得できる場合はチームのメンターとして本当の上級開発者を雇うことをマネージャーが検討するかどうかを尋ねます。開発プロセスへの入力を改善するために利用できるリソースがない場合、それは改善への誠実な関心をほとんど除外します。これにより、マネージャーをリバースエンジニアリングして、彼を本当に動機付けているものを突き止めることができます。
さて、私は他の回答が上司の要求を真剣に受け止めていることに少し驚いています。生産性の40％増加を要求する人は、ソフトウェア開発についての最初のことを知りません。
私は今でもこのトピックについて Phil Factor を読んで楽しんでいます。
IT管理には2つの基本的な方法があります。苦労して得た技術的ノウハウと成功したプロジェクトから得た信頼性に基づいて、血、汗、涙を通して貿易を学び、徐々にはしごを上っていくことができます。または、鋭いスーツとネクタイを着用し、専門用語を学び、上に向かってスムーズに話すことができます。
どちらのルートも同じように効果的です。後者の品種を扱うことは確かにいくつかの瞬間に失望と信じられないほどの瞬間を引き起こす可能性があります...絶望さえ...そしてそれらのいくつかはこれらの物語で文書化されています。
ただし、権力の地位に技術的な能力不足が発生した場合、悲しくなり、苛立たしくなり、すべてのマネージャーに同じブラシでタールを塗るのは簡単です。フィルはそれに対して助言します。ほとんどのマネージャーは一生懸命働いて会社によく貢献しています。いくつかの簡単なガイドラインに従えば、貧しいマネージャーでも必要な標準にトレーニングできます。すべての人に利益をもたらす方法でマネージャーが機能するのを支援することは、チームの責任の一部です。
最終的に、それらを訓練したり、昇進させたり、または回避したりできない場合は、職場の豊かなコメディへの意図しない貢献のためだけにそれらを愛することを学ぶことができます。
「悲しくて怒り狂わない」というアドバイスは、あなたが得ることができる最高のものです。技術的な問題について、技術的に無能な上司と戦わないでください。彼はそれを個人的な攻撃と見なすだろう。
あなたのマネージャーはベロシティの使い方を誤解しています。これはメトリックではなく、ターゲットでもありません。その目的は、スプリントごとのチームワークロードの調整です。
あなたがそれについて考えるならば、あなたの速度は最良の推測から現れ、それは各スプリント後に再測定します。通常、時間が経過するにつれて、ある程度安定するはずです。しかし、それは、チームが実際に行っていることの副産物であるという事実、つまり顧客のための価値の創造を変えるものではありません。
それをターゲットやメトリックとして使用するのが間違っている理由は、それがバニティメトリックになるためです。紙の上では見栄えがしますが、製品が顧客のニーズを満たしているかどうかを反映するものではありません。そしてそれが最も重要なことです（私は願っています）。