スクラム-スプリント外で作業する開発者

スクラムチーム

• 3 x開発者
• 2 xテスター
• 1 x自動化テストアナリスト

開発者がテストせず、テスターが開発しないという点で、私たちは多機能チームではありません。これが問題の根本原因だと思います。

現在、2週間のスプリントを行っています。

スプリントの開始時には誰もが忙しく、開発者は開発作業を開始し、テスターはテストの準備（テストケースの作成など）を行っています。

テスターが準備を完了すると、開発作業が完了するのを待っているか、開発作業が完了して開発者がフィードバック/バグを待っています。

開発者はここでitい足を踏み入れ、現在のスプリントの範囲外にあるバックログのアイテムの作業を開始します。これにより、現在のスプリントで常に次のスプリントを開発するという奇妙な影響が生まれています。私にはこれは正しくないと思う。

経営者の観点からは、彼らは開発者が机に座って何もしないよりはむしろ仕事をすることを望んでいますが、同時に、スクラムチームの目標と焦点は現在のスプリントのみにあるべきだと感じています。私たちのチームが多機能であることを願っていますが、残念ながらそれは達成できません。テスターに​​は開発作業を行うのに必要なスキルがなく、開発者の大多数はテストが彼らの下にあるという意見を持っています。

これはスクラムの問題と見なされますか？これに対する解決策はありますか？スクラムは多機能チームでのみ機能しますか？

可能であれば、これに関する他の人々の経験を知りたいです:)

これは、パイプライン処理によって引き起こされるかなり一般的な問題です。チームは多機能ですが、もちろんパフォーマンスを低下させる内部サイロがあります。

まず、重要だと思ういくつかの点に注意したいと思います。

1. 開発者が事前に反復作業を行っている場合、開発者は計画会議を先取りしています。プロダクトマネージャーとチームは、次の反復で最も価値のあるものを適切に議論する必要があります。開発者は優先すべきことは何もないので、優先順位付けを効果的に行うべきではありません。

2. 反復をどのように分割して配置しても、チームにサイロで作業するスペシャリストがいる限り、常に全員を常に占有し、単一の計画会議で単一のチームを持つことはできません。純粋なウォーターフォールのアプローチを使用しても、「壁を越えて物を投げる」必要があり、フィードバックを待つ必要があります。

3. また、多くの場合、単一のストーリーに開発フェーズ、テストフェーズ、バグ修正フェーズ、それに続く...が必要になるという問題があります。 、コンテキスト切り替えが必要なため。

明らかに、この状況には非常に大きなコストがかかります。チームは協力していません。QAチームが関与するたびにこれに遭遇したので、さまざまなソリューションを試す少しの時間がありました。

私にとって非常にうまくいったのは、次の2つのツールです。

1. チーム全体が作業を行う責任があるという原則を強調します。開発者が「もう問題ではない」と言っている方法であるため、「開発者が行った」ストーリーを拒否します。これは建設的でも特許的にも偽りです。チームが受け入れたストーリーを配信しない場合、配信されなかったのはチーム全体です。

2. 開発者とQAの両方の時間を占有するには、それらをペアにします。これは、選択できる専門知識とドメイン知識を共有するための断然最良の方法です。開発者は、テスターがタスクを自動化するのを支援できます。テスターは、コードが脆弱であるため、コードをテストすることが重要な場所を開発者に示すことができます。コラボレーションと作業の両方が、そうでない場合よりも速くなります。

これらの2つの手法を使用すると、チームのサイロ化が少なくなり、パフォーマンスが向上します。テスターと開発者がジョブを交換することはほとんど不可能ですが、彼らはお互いを責めるのではなく、チームとして働いて内部で問題を解決することができます。

SCRUMとスプリントに関連する作業方法に問題はありません。評価時に、開発者の作業が計画よりも短い時間（およびどれだけ短い時間）で終了したかが記録されます。これにより、チームは次のスプリントでより多くのストーリーポイントを獲得できます。結局のところ、スプリントのポイントは計画を改善することです。明らかに改善の余地があります。

私たちは常に現在のスプリントで次のスプリントを開発しています

うわあ！これは技術的にはスクラムでは不可能です。次のスプリントにどのバックログアイテムが含まれるか、つまり、スプリントプランニングセッションの次のスプリントの開始時に設定されることはわかりません。

組織がスクラムを妨害するために発明した新しい創造的な方法について学ぶことは、依然として興味深い。

スクラムは、個人ではなくチームのために最適化されます。スクラムのポイントは、チームが効率的になることです。開発者が現在のスプリント以外の作業を開始している場合、彼らはチームを傷つけています。また、春を埋めるのに十分な作業を計画しなかった場合、計画プロセスでいくらか失敗していることも示します。

開発者が開発タスクを使い果たしてしまった場合、チームの誰でもテスター、技術ライター、またはデザイナーを絶対に売り込んで支援する必要があります。彼らは必ずしも実際のテストを書く必要はありませんが（そうすべきです）、テストプロセスに参加できます。彼らはテスターがより効率的になるのを助けるスクリプトを書くことができます、または彼らは彼らの課題が何であるかをテスターと単に議論し、それらの課題を克服するのを助けますテストなどで使用できます）。

問題の核心は、開発者が常に現在のスプリントに取り組んでいない場合、チームとしてまだ働いていないことだと思います。スクラムマスターは注意を払い、個人の集合ではなく、ユニットとしてチームを機能させるように努力する必要があります。

これは管理上の問題であることもお勧めします。開発者に忙しくしておくようプレッシャーをかけている場合、彼らはスクラムを完全には受け入れていません。これは、スクラムマスターが支援できるもう1つのことです。スクラムがどのように機能するかを理解するために管理者と協力し、開発チームを破壊するのではなく、サポートしてサポートすることができます。

ここで重要な問題は次のとおりだと思います。

開発者の大部分は、テストは彼らの下にあるという意見を持っています

当社でこれを処理した方法は、開発者に、それを証明できない場合、実際に作業を終了したと言うことができるかどうかを尋ねることです。もちろん、それを証明する唯一の方法は、彼らが書いたコードが実際に機能することを実証することであり、これはテストを通して行われます。彼らがテストに参加することに同意すれば、テストはより迅速に行われ、追加の機能をコード化する時間も増えることに注意する必要があります（これもテストする必要があります）。

コードのテストは開発者レベルより下ではないことを指摘してください。これは開発プロセスの不可欠な部分です。コーディングだけと切り離すことはできません。誰でもコーディングできます。誰もがコーディングして、コーディングしたものが実際に機能することを証明できるわけではありません。

開発者を忙しくさせるもう1つの方法は、スプリントで開発した機能の自動テストのコーディングに取り組むことです。これらのテストは、定期的に実行される回帰テストに使用できます。

いずれにせよ、スプリントの開始時に計画されていなかった何かをすることは、大したことではありません。計画されていないことをするよりも、何もしない方が良いです。これらのケースで彼らが書く機能は、おそらく十分にテストされていないため、DoD（Definition of Done）の基準を満たしていない可能性が高いと考えられます。これは、バグを導入して製品の品質を低下させる確実な方法であり、それによりチームは回帰問題とコンテキスト切り替えの下降スパイラルに陥り、結果としてストレス、速度の低下、そしてそのためにチームを終了します。

理論的には、SCRUMチームのすべてのメンバーは同じ知識を持っている必要があります。これにより、各メンバーは他のすべてのメンバーからすべてのタスクを引き受けることができます。そうでない場合は、知識を広める必要があります。

しかし、実際には常に何らかの専門化があります。ソフトウェアは複雑な場合があり、チームメンバーのスキルは異なります。チームを開発者とテスターに​​分割することは、スペシャライゼーションの1つの（非常に一般的な）例です。

知識を広めるには、経営陣が受け入れようとするよりも時間がかかる場合があります。

私の経験では、いくつかのことができます。

• チームを小さくしすぎないでください。たとえば、4人の開発者と4人のテスターがいる場合、タスクを別の開発者またはテスターに​​移動する方が簡単です。この例のように3/2しか持っていません。
• 大きなタスクを分割してみてください。より小さなタスクがある場合は、より柔軟になります。
• 時間が残っている場合に実行できるオプションのタスクをいくつか定義します。

これらの提案は100％SCRUM理論ではないかもしれませんが、最初に開発作業を続けなければなりません。SCRUMは単なるツールボックスです。

チームの同期を解除する必要があるようです。そのように：

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

テストの自動化を理解している人は、数日早く始めなければなりません。

しかし、私はあなたのチームに問題を感じています。自分のコードをテストしない開発者に問題があります。テスト担当者がコードを確認せずにテストを準備する場合、おそらく開発されたプログラムの決定点を考慮しないブラックボックステストのみを実行しています。ソフトウェアの品質に満足していますか？