スクラムの2つの異なるプロジェクト間で開発者の時間を調整する方法は？

私は新しく設立されたチームのスクラムマスターになりました。このチームは、ソフトウェアの作成と、デプロイされた他のアプリケーションの保守を担当しています。したがって、基本的に各チームメンバーには開発および運用タスクがあります。

過去数週間、彼らがどのように機能するかを観察してきましたが、これらのタスクの調整にチームが問題を抱えていることに気付きました。開発者がコーディングに集中していると、本番で発生した問題を修正するために中断され、以前のタスクに再び集中することは困難です。

開発作業時間の％を運用作業に割り当てようとしましたが、明らかにこれは問題を解決していないようです。以前にこの状況に遭遇したスクラムマスターからの連絡に興味があります。どのようにそれを管理し、どのような推奨事項がありますか？

この問題は、スクラムと同じくらい古いものです。解決策はありますが、気に入らないでしょう。

• バックログに新しいタスクを追加します。
• 開発者を中断しないでください。
• 次のスプリントを待ちます。

開発者を複数のスクラムに配置する、2つの別々のバックログを作成する、またはスプリントに時間の一部のみを割り当てることは、スクラムが達成しようとしているもの、つまり完了したタスクの一貫したフローに対してすべての作業を割り当てます。

これらのタイプのことを試してみると、基本的に「カオス」または「JFDI」開発手法に戻り、それに付随するすべての問題が発生します

• 開発者はいつでも外出先で10個のタスクを実行できます。彼らが何に取り組んでいるのか、いつ終了するのかは誰にもわかりません。
• 他のプロジェクトが同時に何を行っているかに依存するため、プロジェクトを完了する時間は不明です。
• プロジェクトの優先順位に関する一貫した見解はありません。他のマネージャーは、開発者をペットプロジェクトに転換します。

もちろん、このアドバイスに対する通常の対応は「しかし、私にはできません！ビジネスでは、これらの生産バグをできるだけ早く修正する必要があります！」です。

しかし、それは本当ではありません。

この程度までビジネスに影響している実際のバグが本当にたくさんある場合は、専門家になってテストを改善する必要があります。バグと自動テストをすべて修正するまで作業してください。QAチームを雇い、すべての新しいリリースの徹底的なテストを行います。

可能性が高いのは、次のいずれかです。

• バグとは、運用上の問題、ディスク領域の不足、DRなし、バックアップなし、フェイルオーバーなしなどです。OPSチームを結成します。

• バグとは、ユーザーがシステムがどのように機能するかを理解していないことです。ヘルプデスクを取得してユーザーをトレーニングし、ドキュメントを作成します。

• ロールバックの恐怖。あなたは新しい機能を立ち上げましたが、それは何かを壊しました、修正を急いで行こうとしないでください。前のバージョンにロールバックして、バグをバックログに記録します。

ここで箱の外側を考えようとしています。

製品所有者にあなたのやり方で物事を見せることは不可能かもしれないので。ただ待つことができない重大なエラー、開発者の支援が必要なクライアントとの出会いなど、しばらくの間スプリントから1人の開発者を連れ出す必要がある場合があります。

これを予想して、それをあなたの利益のために使ってみませんか？

おそらく現実的になるには、5人以上のチームが必要になります。

しかし、スプリントごとに1人の開発者を連れ出さないでください（開発者間を回転し、それぞれが順番を回します）。

修正のために完全な開発者を使用するのに十分なエラーがない可能性が最も高いため、他に実行できる問題またはタスクがあります。

• テストを実行してパフォーマンスのボトルネックまたはスケーラビリティの問題を特定する
• ビルドシステムのメンテナンス
• クライアントとのミーティング
• 新しいフレームワーク/ライブラリの研究
• 使用したい言語機能を調べる
• セキュリティの問題について調べる
• データベースのメンテナンス
• サーバのメンテナンス

チームの速度が上がり、ストレスが下がり、経営陣との対立が下がる可能性があり、実際に知識を改善する時間を得ることができます。

私が使用した、真に不可欠な生産上の問題に対する開発者の努力を管理するための効果的なソリューションは、「バットマンアプローチ」です。

新しい機能を開発する際のプロダクションサポートの責任が高いのはコンテキストスイッチングであるため、それを制限することを目指してください。

チームの賛同を得て、チームメンバーのリストを作成し、それを繰り返して、毎日新しい人がスタンドアップミーティングで「バットマン」と宣言され、その日の重要な生産問題に対応します。チームの残りの部分は、コンテキストを切り替えることなく開発に集中でき、誰でもサポートの苦痛をかなり共有できます。チームが5人の場合、開発者が中断される可能性があるのは週に1日であり、4日間の中断のない予測可能な開発時間です。

これには、チーム間で知識/経験が共有されるという利点があるため、特定の問題を修正し、単一障害点になり、サポートの問題を公平に分割する責任はありません。