私たちの開発組織がスクラムを手放すときがきましたか？
私は伝統的にスクラムの原則を使用してきた開発組織の一員です。 3週間のスプリントがあり、その最後に、お客様がオンプレミスでインストールするソフトウェアアーティファクトを独自の裁量で作成します。ほとんどのお客様は、奇妙なスプリントをすべてスキップすることを選択しているため、6週間ごとにのみインストールします。
これで、私たちのソフトウェアを使用する、またはすでに使用しているいくつかのブランチを持つ、新しい大規模な顧客がいます。各ブランチには、わずかに異なる要件があり、生産には厳しいスケジュールがあります。
数か月後の状況：
- 開発チームがバックログタスクに費やす費用は50％未満
- 日常業務はアドホックサポートチケットの影響を大きく受けます（これは、欠陥、データベースのクリーンアップ、ユーザーのトレーニング、または単純な原因分析に関係する可能性があります）。
- 毎週、すでに提供されているリリースのサービスパックを作成します。したがって、欠陥はマスターにコミットされますが、1つ以上の古いブランチにチェリーピックされます。
- 上記のサポートチケットとサービスパックに必要な時間は、今後2年間で増加し、その後再び減少すると期待されます。
- 私たちの顧客はしない傾向があります迅速なフィードバックを提供します。フィードバックループに数か月の遅延がある場合があります
-登録ブランチを編集-
Origin/masterで開発しています。ただし、現在リリース5.0.12を開発中であり、顧客が5.0.10で緊急に必要としているバグ修正または機能があるとします。この場合、5.0.10.1と5.0.11.1へのパッチを選択します。顧客固有のブランチはなく、誰もが同じソフトウェアを入手できます。
-編集の終わり-
私はスクラムがこの種の仕事にもはやふさわしくないと確信しています。私はDevOpsに精通していませんが、私の理解では、DevOpsは迅速かつ頻繁な展開に基づいて構築されています。私の理解が正しければ、それも当てはまりません。
これに対処するためのベストプラクティスはありますか？我々がすべき：
- サポートと開発を分割し、スクラムを開発用に保持しますか？ （専任のサポートチームが予定されています）
- かんばんに切り替えますか（ただし、アドホックサポートと開発を混在させます）？
いいえ。スクラムは、発生している問題と正確に対抗するように設計されています。
バグができるだけ早く報告されたら、バグを修正する反応的なアプローチに切り替えることができますが、これには、予測可能な完了日と、多くの場合ソフトウェアの安定性が犠牲になります。
プッシュバックして、すべてのリクエストがバックログに入れられ、優先されることを確認してください。テストに費やす時間を増やし、リリースするものが正確に要求されたものであり、バグがないことを確認します。バグのない週4回のリリースよりも、欠陥のない月1回のリリースを行う方が得策です。
ただし、3週間はスプリントには長すぎるとも言えます。 1週間のスプリントに移動します。
さくらんぼ狩りをやめろ！バグ修正をブランチにマージします。それから離れてではなく、単一のコードベースに向かって移動するようにしてください。
より多くの人々を雇います。どの方法を選択しても、1日は数時間しかありません。もっと仕事があるなら、もっと人が必要です。
Re：スプリントの長さ
どのスプリントシステムでも、少なくとも3つのスプリント、つまり顧客がスプリント1の結果を確認できるまでの所要時間は、スプリント2の間にバックログに発生する変更を示唆しており、スプリント3で完了する可能性があります。
この特定のケースでは、お客様は必ずしもすべてのスプリントをインストールするわけではなく、すぐには戻らないため、6週間後にインストールを検討し、9週目から11週目に15週目までの実装について問題を報告し、次に修正プログラムをインストールします。 21週目です。ほぼ6か月周期です。
1週間のスプリントがある場合、顧客は第6週にインストールし、第9〜11週にリクエストを取得して、第12週の次の6週間のサイクルに修正をインストールできます。
私の経験では、1週間のスプリントより短くすることは現実的ではありません。ちょうどビジネスのリズムと労働週の面で。 「来週までに完了」は許容されます。「2週間以内に完了します。他のATMに取り組んでいるため」は理解できる遅延です。 'SCRUM'は受け入れられないため、4週間で完了します。
特に新しい大口の顧客を引き受けたことにより、問題が何であるかを正確に指で正確に把握したかどうかはわかりません。スプリントの目標/期限を逃し始めていますか？品質が低下していますか？スループット/速度の低下が見られますか？バックログタスク（ロードマップに関連していると思います）にあまり取り組んでいないため、競合する見込み顧客を失っていますか？新しい顧客が原因で、作業構成がよりメンテナンス/バグ修正タイプの作業に変更されたという事実以外に何が変更されましたか？そして、問題を修正するためのリードタイムが近い将来に増加するのではないかと心配していますか？
フィードバックを提供してくれる顧客がたくさんいるのは良いことです。そして、少なくとも一時的には、製品ロードマップで作業できないことが悪いことではありません。おそらく、今こそ、家を整え、DevOpsについて学び、実装し、テストの自動化を導入し、チームメンバーの一部を殺害するときです。
ここでは、かんばんがそうするのを助けることができます。スクラムをあきらめる必要はありませんが、問題の改善と解決を支援するために、その上にカンバン（多くの人が呼ぶスクラムバン）を使用してください。かんばんはいくつかの方法で役立ちます-
- これは、おそらく現在行われているよりも詳細に、かんばんボードでのプロセス（および作業）を視覚化し、開発および展開プロセスのどのステップがボトルネックであるかを強調するのに役立ちます。
- 現在のパフォーマンスに関するデータの提供を開始し、リードタイムやスループットなどの重要なメトリックのベンチマークと改善目標の設定に役立ちます。かんばんメトリクスの詳細 こちら 。
- 作業が多すぎるためにリードタイムの増加が心配な場合は、ワークフローの各段階で実装できるWIP（作業中）の制限を実装して、チームメンバーがすでに持っている作業を完了するように勧めます。次の作業項目を開始する前に、彼らの皿。 WIPを制限すると、スループットが向上し、サイクルタイムが短縮されます。
- また、カンバンでは、カンバンボードで異なるスイムレーンを使用して、さまざまなタイプの作業（顧客の作業、バックログまたはロードマップ作業、技術的負債など）を視覚化して管理することができます。このようにして、チームと利害関係者の両方が、これらのさまざまなカテゴリ全体でどれだけの作業が行われているかの全体像を把握できます。カンバンの「サービスクラス」の作業の「優先、標準、固定日、無形」に分類することで、チームが行うと予想される各作業項目に関連する遅延のコストが何かを理解し、おそらく遅延のコストが少ないか、まったくない。
現在の状況は複雑なので、列レベルと特定のスイムレーンの両方でWIP制限を実装できます。
- もちろん、これを実行する前に、開発チームと利害関係者とのディスカッション（おそらく複数のディスカッション）が必要です。問題の内容と場所、および問題を解決するために必要なことを理解する必要があります。これらは、バックバンタスクと顧客のフィードバックを処理する明示的なポリシー（カンバンメソッドが推奨する何か）を考案するのに役立つはずです。おそらく、スプリントを2週間ごとに変更し、顧客は3つのスプリントごとにのみリリースして、容量を作成します。各タイプの作業への割り当て、全体的なバックログを定期的に確認し、次に取り上げる上位5項目または10項目に優先順位を付けるなど。
かんばんが、現在の開発者管理手法の分析と改善に役立つことは間違いありません。必ずしもスクラムをあきらめる必要はありません。 Scrumbanについてさらに詳しく知りたい場合は、 ここ を検索してください。
HTH-すべて最高！
あなたの質問には、これがプロセスの問題以上のものであると私に思わせるいくつかの事柄があります。作業項目管理については、すでにいくつかの素晴らしい答えがあります。
リード/サイクルタイムを測定することがサポート効率を分析する最良の方法であることに同意しますが、お客様がチケットを開いてからお客様の環境でクローズされるまでの時間を必ず測定してください。バニティ開発の測定基準は何の意味もありません。彼らが行うことは、開発者に顧客の費用をよく見せるだけです。
スプリントは作業を解決してピボットできるようにするための最良の方法であることに同意します。私は1週間のスプリント提案で完全に販売されていません。これは、最後に展開するために必要な労力に依存します（タコのようなものによる展開の自動化を検討したい場合があります）。
しかし、他の誰も持っていない私が提起したかった大きなポイントは、複数のブランチについてのあなたのコメントです。
あなたが説明することから、コードベースの複数のブランチがあり、それらの修正は2つの間でマージされる必要があります。ここで間違った方向に進んでいる場合、ソフトウェアの新しいフレーバーが必要な場合はどうなりますか？新しいクライアントを引き受けるとどうなりますか？あなたのソース管理はますます成長し、ますます管理しにくくなります。
トランクベースの開発に移行する必要があります（または少なくとも短期間の機能ブランチ）。機能のトグル/ロール/構成を使用して、クライアント/プロジェクトごとにソフトウェアをカスタマイズできます。
これを行うと：
- バグ修正/機能実装のオーバーヘッドを削減
- テストを単一のブランチに統合できるようにします（テストをより効率的にします）
- すべてのビルドが回帰テストされる適切なCIパイプラインを構築できます
- 個々のブランチの癖なしで適切な展開プロセスを開発することができます
コードのプッシュアウトが容易になるほど、機能の開発が容易になります。しかし、修正を展開する方が簡単です。つまり、チームが現在直面しているサポート作業が容易になります。何が起こっているのかわからないので、ログをさらに展開してください。今日解決する必要のあるバグを見つけました。DLLパッチを適用せず、新しいバージョンをデプロイしてください。
最後のポイントです。あなたはサポート作業に費やす時間について心配しているはずです、そうすべきです、それはたくさんのことであり、すべての中断はあなたたちの時間を要します。 スプリントに取り込む作業の基準を定義します、そうであれば、同等の作業項目をプッシュします。私の提案は、「P1基準」を24時間のコールアウト基準と同じにすることです。結局のところ、アナリストが午前2時にベッドから出ることがそれほど重要ではない場合、バックログで最も重要な作業を犠牲にすることはおそらく十分ではありません。
測定時には、計画して完了した作業のSPを記録します。不足しているスペースは、サポート作業の中断を表しています。あなたの懸念は、「計画された作業のどれだけを提供したか」である必要があります。解決するためにすべてをドロップしなかったサポート問題は、計画することができますが、バックログ項目に対してそうします。
[〜＃〜] tldr [〜＃〜]
- お客様が問題を提起してからクローズするまでにかかる時間を測定する
- トランクベースの開発モデルに移行する
- 展開の自動化を検討する
- ビジネスとP1基準を一致させます。それがスプリントを妨げるものです