スクラムの2つの異なるプロジェクト間で開発者の時間を調整する方法は？
私は、新しく作成されたチームのスクラムマスターになりました。これは、ソフトウェアの作成と、他のデプロイされたアプリケーションの保守を担当します。つまり、基本的に各チームメンバーには開発と運用のタスクがあります。
私は彼らが過去2週間でどのように機能するかを観察しており、チームがこれらのタスクの調整に問題を抱えていることに気付きました。開発者がコーディングに集中しているとき、プロダクションで発生した問題を修正するために中断され、前のタスクに再び集中することは困難です。
運用作業に開発者時間の％を割り当てようとしましたが、どうやらこれは問題を解決していません。以前にこのような状況に遭遇したスクラムマスターからの連絡に興味があります。それをどのように管理し、どのような提案をしましたか。
この問題はスクラムと同じくらい古いものです。解決策はありますが、気に入らないでしょう。
- バックログに新しいタスクを置きます。
- 開発者を邪魔しないでください。
- 次のスプリントを待ちます。
開発者を複数のスクラムに入れ、2つの個別のバックログを用意するか、スプリントに時間の一部のみを割り当てて、スクラムが達成しようとしていること、つまり、完了したタスクの一貫したフローに対してすべての作業を行います。
これらのタイプのことを試してみると、基本的に「カオス」または「JFDI」開発方法論に戻り、付随するすべての問題が発生します。
- 開発者はいつでも外出先で10のタスクを持っています。誰が作業しているか、いつ完了するかは誰にもわかりません。
- プロジェクトを完了するまでの時間は不明です。これは、他のプロジェクトが同時に発生していることに依存しているためです。
- プロジェクトの優先順位について一貫した見解はありません。他のマネージャは、開発者をペットプロジェクトに誘導します。
もちろん、このアドバイスに対する通常の返答は「しかし、私にはそれができません。ビジネスには、これらのプロダクションのバグをできるだけ早く修正する必要があります！」です。
しかし、それは本当ではありません。
この程度までビジネスに影響を及ぼしている実際のバグが本当に多くある場合は、専門家になってテストを改善する必要があります。すべてを修正するまで、バグと自動テストに取り組みます。 QAチームを雇って、すべての新しいリリースを徹底的にテストします。
次のいずれかである可能性が高いです。
バグは、運用上の問題、ディスク領域の不足、DRなし、バックアップなし、フェイルオーバーなしなどです。OPSチームに参加してください。
バグは、ユーザーがシステムがどのように機能するかを理解していないことです。「これが発生しました！バグですか？」ヘルプデスクを取得してユーザーをトレーニングし、ドキュメントを作成します。
ロールバックの恐怖。あなたは新機能をリリースし、それが何かを壊しました、修正を急いでしようとしないでください。以前のバージョンにロールバックし、バグをバックログに入れます。
ここでは、枠を超えて考えようとしています。
製品の所有者があなたのやり方で物事を見ることができない可能性があるため。それでも、待ちきれない重大なエラー、開発者の支援が必要なクライアントとのミーティングなど、1人の開発者をスプリントからしばらくの間取り除く必要がある場合があります。
これを予想して、あなたの利益のためにそれを使ってみませんか？
現実的になるには、5人以上のチームが必要です。
しかし、なぜすべてのスプリントから1人の開発者を連れ出さないでください（開発者間でローテーションし、それぞれが順番を取得します）。
ほとんどの場合、修正のために完全な開発者を使用するのに十分なエラーがないので、実行できる他の問題またはタスクがあります。
- テストを実行してパフォーマンスのボトルネックまたはスケーラビリティの問題を特定する
- ビルドシステムの維持
- クライアントとのミーティング
- 新しいフレームワーク/ライブラリの研究
- 使用したい言語機能の探索
- セキュリティ問題について読む
- データベースのメンテナンス
- サーバのメンテナンス
チームの速度が上がったり、ストレスが減ったり、経営陣との対立が減ったり、知識を向上させるための時間を実際に得ることができます。
私が使用した本当に重要な生産上の問題に対する開発者の努力を管理するための効果的なソリューションは、「バットマンアプローチ」です。
新しい機能を開発する際のプロダクションサポートの負担の高額な側面はコンテキストの切り替えであるため、制限することを目的とする必要があります。
チームの賛同を得て、チームメンバーのリストを作成し、それを循環させます。これにより、毎日、立ち会いで新しい人物が「バットマン」と宣言され、その日の重要な制作問題に対応します。チームの残りのメンバーは、コンテキストスイッチを必要とせずに開発に集中でき、誰もがサポートの痛みを公平に分かち合うことができます。 5人のチームの場合、開発者が中断される可能性のある週1日と、中断されずに予測可能な開発時間が4日間です。
これには、チーム間で知識/経験が共有されるという利点があるため、特定の問題を修正し、単一障害点およびサポート問題の公平な分割を担当する担当者が1人ではありません。