スクラム環境で速度の大幅な増加は現実的ですか？

私のマネージャーは最近、生産性の目標と尺度として速度を使用することを本当に推し進めています。現在、平均速度50ストーリーポイントで作業しています。私のマネージャーは、ストーリーポイントを40％増やして70ストーリーポイントにすることを望んでいます（チームメンバーの増加はありません）。この増加が達成されない場合、彼はその理由を説明する完全な内訳を提供することを望んでいます。

チームのパフォーマンスを速度で測定し、それをターゲットとして使用するという考え全体は間違っているように思えますが、その理由を説明するのは難しいと感じています。助けがありますか？なぜ生産性を測定し、インセンティブを与えるのにこれが適切な方法ではないのですか？

さて、速度を40％上げるのは非常に簡単です-すべての推定値に40％以上のポイントを追加し、同じ量の作業を行うだけです。

これがそうであることを考えると、ターゲットとして速度を使用することが間違っている理由は明らかであるはずです。

glibの答えはあまりありませんが、すべてのことを正しく実行している間は、できるだけ速く進んでいると推定値がすでに推測しているということです。生産性を実際に40％向上させる唯一の方法は、残業するか、すべてを正しく行わないことです。これらはどちらも短期的には速度を上げますが、長期的には速度を下げます。そして、この場合の長期はそれほど長くはなく、1か月は外です。最適な長期戦略は、持続可能なペースを超えないことです。

ピープルウェアは、プログラマーの生産性を向上させようとする問題について雄弁に語り、よく引用される名作です。しかし、一般的に、あなたの道を進んでいるマネージャーの心を変えることは簡単ではありません。あなたのプロジェクトはトラブルに巻き込まれている可能性があります-これは確かに危険です。

コメントが指摘しているように、要求は明らかに間違っている。しかし、彼は生産性を絶えず改善したいのは本当に間違っていません。原則として、それはマネージャーが努力する（そして評価される）ものです。

とは言っても、マネージャーは常にパフォーマンスの向上を目指しており、スクラムとアジャイルは適応性がすべてです。速度は現在の持続可能なペースの尺度ですが、栄冠にとどまるべきではありません。スクラムには、プロセスで機能するものと機能しないものを評価および変更する場所があります。それを利用してプロセスを調整すると、生産性（および場合によっては速度）が上がるはずです。

それで、チームとしてより生産的になる方法を（回顧で）探していますか？スプリントには、不均衡な努力を定期的に消費するものがありますか？対処できますか？おそらく40％の増加はありませんが、5〜10％がスタートです。スプリントごとに、ボトルネックを探して対処する必要があります。最終的に、あなたは彼があなたのために設定した目標に近づくかもしれません。

TL; DR

Velocityは、スケジュールの見積もりや計画値の生成に非常に役立ち、プロセスのボトルネックやチームの能力の変化を評価するための意味のある検出コントロールにもなります。ただし、これは生産性の有効な尺度ではありません。

Velocityが管理ターゲットと混同される場合

「速度」は、過去の期間におけるチームの平均能力を表す範囲です。これは、過去のパフォーマンスの統計分析であり、将来のワークロード容量またはサイクル時間の確率的推定を予測するために使用できます。これは、計画目的のタイムラインまたは目標を設定する管理目標である「スケジューリング目標」とはまったく対照的です。

経験豊富なアジャイルプロジェクトマネージャーは、速度を適切に使用することは、チームが管理定義のスケジューリング目標を達成するための持続可能な能力を持っているかどうかを判断することであることを知っています。時には答えはイエスであり、誰もが幸せです。答えはノーである場合があり、その時点で鉄の三角形は範囲、コスト、時間、および品質に関するビジネス上の決定を強制します。

政治的選択肢を評価する

平均速度は50ストーリーポイントです... 40ストーリーポイントに40％増加するように依頼されました（チームメンバーは増加しません）。

推定の実践が適切であり、速度がかなり安定していると仮定すると、マネージャーは、推定スケールを調整したり、過去のパフォーマンスに基づかない管理目標を設定したりすることに喜びを感じません。正しく指摘すると、これは基本的に容量の問題です。

容量の制限は、チームの人数に関連している場合もあれば、組織プロセスの制限である場合もあります。もちろん、人を追加してもプロジェクトの実際のキャパシティが常に追加されるわけではありません。このよくある誤解の詳細については、ブルックスの法則を参照してください。

あなたが直面する問題は政治的です。投稿の口調からすると、マネージャーはチームの基本的な能力に実際の変更を加えることなく生産性の向上を望んでいるようです。したがって、解決策も政治的であり、本質的に教育的です。

スクラムショップの場合は、適切なフレームワークチャネルを通じてこの問題に対処するようにスクラムマスターに依頼してください。バックログのグルーミングとスプリントの回顧は、多くの場合、この特定の問題に対する理想的な検査と適応の機会です。

スクラムショップでない場合は、組織内で懸念に対処する適切な方法を決定する必要があります。あなたが上司と良い関係にあるなら、あなたは彼にアジャイルの推定と計画のコピーを貸し出して、昼食で話し合うためにあなたの二人に会うかもしれません。

他のすべてが失敗した場合は、履歴書をブラッシュアップし、プロジェクトが崩壊するまで専門家の最善を尽くして死の行進に備えてください。ITプロジェクトの68％が失敗します。管理目標が組織の能力にしっかりと根ざしていない限り、おそらくあなたもその1人になります。

マネージャーがスクラムチームでどの役割を果たしているのか理解できませんか？彼はコーチですか？彼は製品の所有者ですか？

彼がコーチなどのようにチーム内にいる場合（開発タスクで働いている場合）、自分の生産性を過小評価している理由を尋ねることができます。繰り返しごとに30ストーリーポイント以上を個人的に想定できると考えている場合は、見せてみましょう。

もっとありそうなのは、彼がチームの外にいるのか、プロダクトオーナーなのか？もしそうなら、彼はそのような愚かな要求をすることを理解すべきであり、彼は敏just性をやめた。

基本的なルールは、製品所有者が目標を設定し、チームが反復で実行できることを設定することです。そうしないと、古典的でよく知られている鉄の輪、つまりリソー​​ス、速度、機能につながります。2つ選んでください！一度に3つを選択することはできません（品質は調整変数ではないため、低品質でコーナーをカットしようとすると事態はさらに悪化します）。

彼が現在の目標を変更したくない場合、チームにさらに多くの人を採用することで生産性を40％向上させることができますか？一部のチームメンバー向けの事前トレーニングに投資しているのでしょうか？また、チームは継続的な改善を通じて時間の経過とともに速度を上げる可能性がありますが、確かに任意の決定によってではありません。

チームの速度を変更しようとすることは、部屋のサイズを変更しようとするようなものです。それはできますが、基本的に部屋を変える必要があります。

スクラムマスターや、それを説明できるスクラムの基本的な理解を持っている人がいますか？

この場合、マネージャーはチームから正直で忠実な見積もりを得た後、間違った方向を変えました。マネージャーは、利害関係者に目を向け、要求された時間内に要件を完了できないことを伝えます。マネージャー/アナリストは、どの機能を含める必要があり、他の機能は待機できる（2、3週間だけの場合でも）優先順位を付けます。利害関係者が不合理である場合、関与するには上位のマネージャーが必要になる可能性がありますが、これは一般的に困難であり、他のすべての議論が必要になる場合があります。

私はあなたの靴にあった場合、私はプロジェクトが理由として、詳細なケースを思い付くでしょうIS限り、推定されたとして取るつもり。また、低返品アイテムを特定するようにしてください。あまり価値がなく、かなりのプログラミング作業を必要とするアイテムを見つけ、それらをスプリントから削除することを主張します。また、「Y」の日付に「X」を配信し、それが実行可能であることを確認する反復アプローチを考え出し、その後、残りのアイテムを取得するフォローアップの繰り返しを考え出します。

基本的に、誰かが利害関係者に、期限までに何を受け取ることができるか、そして要件の大部分が含まれていることを伝える必要があります。そして、次のリリースまでに、残りのアイテムが含まれることになります。顧客が不合理である場合、上級管理職が関与する必要があり、マネージャーはこれを実現できるはずです。

ただし、顧客が約束を超えており、これまで誰も話していない場合、それは困難な戦いになります。残念ながら、これは珍しい状況ではありません。

2つの問題に直面しているように思えます。

気になる速度の測定に関する部分は、おそらく測定がコストであることです。本当に改善したいのは価値です。残念ながら、ソフトウェアの価値を測定することは、困難で主観的なことで有名です。それでも、不完全で主観的な測定基準でさえも有用です。本当の問題は、チームがより多くのコードを書く必要があるということではなく、ストーリーがより価値がある必要があるということかもしれません。

もう1つの問題は、アカウントに基づいて、マネージャーが生産性が40％向上すると予想したことです。あなたの質問には、このリクエストの文脈が記載されていませんでした。あなたのチームが改善を望んでいるなら、それは良心的かもしれません。または、あなたのマネージャーがあなたのチームのパフォーマンスが低いと信じていることをそれほど微妙に示すこともできます。

編集：あなたのコメントに基づいて、状況は悪いようです。あなたの会社はあなたとあなたのチーム（おそらくあなたのマネージャーも）を解雇するための土台を築いているようです。別の仕事を探すことをお勧めします。

彼をクビにする。つまり、彼の頭を振り返って、彼は彼のチームのすべての信頼を失ったことを説明し、彼はビジネスにとって価値がないと説明します。このレベルの能力のないマネージャーは、以下のチームよりもはるかに簡単に交換できることを説明します。

そのようなマネージャーに我慢する正当な理由はありませんが、それは開発者が辞任することを自動的に意味するべきではありません。必ずしもビジネスに問題があるわけではなく、この1人の個人にだけ問題があります。その問題を修正してください。

そして、経営陣からのシャッシングを防止するために、これが許される間違いではないことを明確にしてください。これは、責任あるマネージャーが自分が管理しているチームを理解していないことを示しています。それは固定には向いておらず、現在の労働市場にも必要ではありません。マネージャーはスポーツコーチのように非常に交換可能です。オーナーはチームを解雇しません。

さて、これは裏目に出る可能性のある戦略のように見えるかもしれません。しかし、考慮してください：とにかく上層部が上司と関係なく、とにかくあなたはすでに負けポジションにいるでしょう。したがって、あなたがまだその負けポジションにいない状況だけを考慮すれば、結果はおそらくはるかにポジティブになるでしょう。本当のリスクは、上級管理職がマネージャーを含むチーム全体を解雇することです。そのリスクを推定できるのはあなただけです。どうやらあなたの出力が望まれている、そうでなければ彼らはそれのそれ以上を求めないだろうが、どの価格で？

私の経験では、チーム、問題領域、テクノロジースタックのいずれにも変化がないため、チームの実際の速度を上げることは非常に困難でした。

私が増加を達成できたのは、次の問題でした。

• 技術的負債の整理 すべてが正しい（必ずしも最新ではない！）バージョンを実行していること、コードが適切にファクタリングされていること、システムに冗長性がないこと（重複コード、未使用コードなど）を確認する

• 改善プラクティス; 可能な限りペアリング（はい、速度が上がることがわかりました）、積極的にリファクタリングする時間を取り（同じ！）、スコープとフォーカスについて冷酷です

• 仕事に最適なツールを見つけて購入します（例：ReSharper for .NETはその価値があり、Ruby開発にはAirbrakeとSplunkなど）。

私はここで、あなたのマネージャーが速度のas意的な増加を要求しているのは赤い旗だと言う他の人々に同意します。優先度の高い別の仕事を探しています。

あなたのマネージャーは、チームに余分な時間を働かせるように頼んでいます。ボトルネックを取り除き、効率を上げると速度が多少向上しますが、その増加（40％）を得る唯一の方法は、長時間労働することです。その期間にはより多くの作業単位を詰め込む必要があるからです。

シナリオを見てみましょう。

2週間の対話の場合、10日間としましょう。ユートピアは1日8時間であり、ストーリーポイントは作業日に抽象化されます。したがって、上から見ると、ベロシティは8になります。しかし、人々はおそらく、メール、会議、トイレ休憩などで1日6時間の余裕を持っているでしょう。したがって、ベースラインは6です。1日10時間で残業するようにしたいとしましょう。したがって、開発者ごとに10の速度ポイントになります。

あなたの速度は常に変動します。おそらく、その反復中に多くのバグに対処しなければならなかったために低かったかもしれません。おそらく要件が欠けていたかもしれません。仕事が過大評価されていたり、チームが余分な時間を費やしたために高かったのかもしれません。

しかし、安定した50歳の場合、実際に70歳に達するには余分な時間が必要になります。

速度の問題は、それが従属変数であり、開発プロセスの測定された出力であるということです。速度を40％上げることを要求することは、より速く走るように車に向かって叫んで、より早く仕事に取り掛かろうとするようなものです。より多くの燃料と空気をエンジンに供給するか、より高速な車を取得することにより、速度を上げ、さらに交通量の少ないルートを見つけます。

開発者時間あたりの機能ポイントなどで適切に測定しても、長時間労働しても速度は上がりません。1日あたりのポイントを測定し、測定中の「日」を再定義する場合にのみ機能します。これは、速度の錯覚のみを提供します。

速度を上げるには、devプロセスの独立変数を改善する必要があります。より高速なコンピューターとコンパイラー、より効率的なビルドシステム、より優れた設計プロセス、より有能な開発者、より優れたワークスペース、超大型のモチベーション。40％改善するには、非常に大きな変更が必要です。

マネージャーがチームを共通の作業室の周りにある閉鎖的なオフィスに配置することを検討するか、チームのまったく新しい開発ハードウェアを購入するか、それとも40％を獲得できる場合はチームを指導するために本当に上級の開発者を2人雇うことを検討してください。開発プロセスへの入力を改善するためのリソースがない場合、それは改善への誠実な関心をほとんど排除します。これにより、マネージャーをリバースエンジニアリングして、何が本当に彼をやる気にさせているのかを把握することができます。

さて、他の回答が上司の要求を真剣に受け止めていることに少し驚いています。生産性の40％の向上を要求する人は、ソフトウェア開発に関する最初のことを知りません。

このトピックに関するPhil Factorを読むのは今でも楽しみです。

IT管​​理には2つの基本的なルートがあります。苦労して得た技術的ノウハウと成功したプロジェクトから得た信頼性に基づいて、血、汗、涙を通して取引を学び、徐々にはしごを上っていくことができます。または、鋭いスーツを着てネクタイを締め、専門用語を学び、トップに向かってスムーズに話すことができます。

両方のルートは同等に効果的です。後者の品種に対処することは、確かに失望と不信の瞬間を引き起こす可能性があります...絶望さえ...そしてそれらのいくつかはこれらの物語で文書化されています。

しかし、権力者の地位に技術的な不備があると、悲しみやみになりやすくなり、同じブラシですべての管理者を苦しめます。フィルはそれに反対します。ほとんどのマネージャーは一生懸命働き、会社に貢献します。いくつかの簡単なガイドラインに従うだけで、貧しいマネージャーでさえ必要な水準まで訓練することができます。すべての人に利益をもたらす方法で上司の機能を支援することは、チームの責任の一部です。

最終的に、あなたがそれらを訓練することができないか、昇進させるか、それらを避けることができないなら、あなたは職場の豊かなコメディへの彼らの意図しない貢献のためにそれらを愛することを学ぶことができるかもしれません。

「悲しみとembみ」にならないようにアドバイスするのが最善です。技術的な問題で技術的に無能な上司と戦わないでください。彼はそれを個人的な攻撃として見るだけです。

あなたのマネージャーは、速度の使用を誤解しています。これはメトリックではなく、ターゲットでもありません。その目的は、スプリントごとのチームワークロードの調整です。
考えてみると、速度は最良の推測から明らかになり、各スプリント後に再測定します。通常、時間が経過すると、多少安定するはずです。しかし、それは、それがあなたのチームが実際に行っていることの副産物であるという事実を変えません：あなたの顧客のために価値を創造します。

ターゲットやメトリックとして使用するのが間違っている理由は、それがバニティメトリックになるためです。それは紙の上では良さそうに見えますが、製品が顧客のニーズを完全に満たしているかどうかを反映することはまったくありません。それが最も重要なことです（私は願っています）。

私の経験に関して、ポイントに直行します。

まず、見積もりを膨らませることができますが、それだけではありません。

2番目（前提：膨張せず、単にチームの速度に集中する）、

チーム内のスキルを見つけてください。彼らは彼らが最高のものに取り組んでいますか？アプリケーションの構築や複雑なことに関して難しい決定を下すために、システム設計者が必要ですか？チームはどのように努力を費やしていますか？彼らは問題の解決策の研究、リファクタリング、ビジネス上の意思決定などに時間を費やしていますか？

彼らは快適で、集中し、評価されていますか？彼らのために次に何が起こっていますか？

これは「限界に追い込まれている」のではなく、チーム全体が「限界に向かっているのか？」という質問のようなものです。「どうすれば限界を押し広げられるのでしょうか？」...

私は一流の高性能チーム（最初の構築および/または移行）を持っています...チームの動機は成功の鍵です...そして、アプリケーションのベースがどのようになるかを計画することが不可欠です。私またはチームメイトがシステムアーキテクトの役割を取得し、「もの」をどこにどのように配置するかを決定することがあります。

時々、チームメイトの効率が低下していることがわかったとき、私は彼らを破って、彼らが飲み物のビールや彼らが好む何かのために出るように誘います。これにより、競合が解決され、翌日に再び集中します。

販売...

速度を上げることができない理由を説明するのが難しい場合は、ROIを使用します。

スクラムは、クライアントにとって最も重要なことに焦点を当てます。理論的には最も収益性の高いタスク。

あなたの問題が開発努力の販売に関するものである場合、開発努力のROIを販売する代わりに、ストーリーポイントを直接「価格」に変換すると思います。チームが高いROIで機能していることを証明できる場合、誰が質問しますか？また、チームが「コンフォートサイズ」を見つけた場合、すべてのチームに制限があります。すべてのタスクを完了できなかった場合、月ごとに少しずつ増やしてみてください（おそらく）制限です。

タスクの履歴、収益（利用可能な場合）、使用したスト​​ーリーポイントを表示し、生産性がチームの努力ではないことを示します。やった