スクラム-スプリント中に忙しいチームメンバーは何ですか

そのため、スクラムスプリントは、特定の機能セットを実装する必要がある固定期間です。そして、スクラムチームは、これらの機能を提供することに全力を注いでいる人々で構成されており、その大部分は通常、開発者とテスターです。

これらのルールを確立した後、スプリント全体でこれらすべての人々を忙しく保つ方法を疑問に思うかもしれません。スプリントの開始時にはまだテストするものはありません。また、スプリントの終了時には、通常、開発/修正するものがまったくないか、ほとんど残っていません。

これを処理する2つのアプローチを見てきましたが、どちらも問題を適切に解決していないようです。

1）チームメンバーに、タスクがなくなったときの対処方法を決定させます。

短所：

• 彼らがすることを徹底的に計画していない場合（すなわち、主要なリファクタリング、新しいテストフレームワークへの切り替え）、彼らの仕事は役に立たないか、途中で立ち往生するかもしれません
• 一方、そのような作業の計画には多くの時間がかかる可能性があり、クライアントは即座に価値をもたらさないものにチームが時間を浪費するのを見ることに失望するかもしれません
• 通常、このようなタスクは完全に見積もることができないため、未熟な労働者がスクラムボードや他の場所に反映されることなく、YouTubeの猫を見ることに時間を費やすことは非常に簡単です。

2）スプリント内に開発専用のスペースを確保し、スプリントの終了後にテストを開始します（開発者が次のスプリントから機能の作業を開始するとき）

短所：

• 現在のスプリント用の機能を開発している間、開発者は前のスプリントからバグを修正することに気を取られ、現在のスプリント中に行われると推定された量の作業を実行できない可能性があります
• 2つのスクラムボードが必要です。1つは現在のスプリント機能用で、もう1つは以前のスプリントバグ用です。

だから私の質問は、スプリント中に開発者とテスターの間で作業を適切に分散して、誰も作業で過負荷になったり、いつでもタスクなしで終わることがないようにする方法ですか？上記のアプローチを改善する方法はありますか？または、より良いアプローチがありますか？

スプリントの開始時にはまだテストするものはありません

本当に？検証する必要はありませんか？顧客と話し合う必要はありませんか？評価するワイヤフレームはありませんか？検討するテスト計画はありませんか？

スプリントの最後には、通常、開発/修正するものがまったくないか、ほとんど残っていません

私はプロジェクトでその場所に行ったことはありません。これ以上の作業はありませんか？常に何かがあります。すべてのテストは完全に自動化されていますか？CIはどのように見えますか？データベースアクセスレイヤーをより簡単にリファクタリングできますか？そして、私は空のバグリストとバックログで何かに取り組んだことがありません。開発者は、ウォーターフォールテストフェーズで何をしていましたか？

「スクラム」とは何か、また「スクラム」ではないものについて非常に信心深い人もいます。私はそれについてあまり気にすることができませんでした。しかし、ここには2つの問題があると思います。

1. 顧客や開発者と協力して、適切なものを構築し、適切に構築することを確認するのではなく、開発者が「完成」したコードをテストする「従来の」QA部門。Lisa Crispinによるアジャイルテスト作業領域を見てください。最高のテスターがソフトウェア開発ライフサイクルのあらゆる段階に関与し、最高の開発者が独自のテストを作成します。

2. 1 つのスプリント内で短時間で完了するのに十分に簡単なタスクに分割される優先順位付けされたサイズのバックログを持たずに、1週間/ 2週間のスプリントのSCRUMスケジュールに近づきすぎないようにします。もしこれがあれば、もっと多くの作業が必要になります。このスプリントで最後に取り組んでいる機能は、このスプリントのリリースには含まれませんが、次の機能にいつでもアクセスできます。

さておき。小規模で結束力のあるチームがある場合、役割はそれほど重要ではありません。プロダクションコードを書くことを許可されていないラベルテスターを持つ人や、テストより上だと考える開発者にラベルを付ける人の代わりに、誰もがチームの成功に必要なものを実行する必要があります。彼らは必要です、これはクロス機能チームと呼ばれます。

@Cort Ammonがコメントで指摘した1つの追加ポイント。アジャイルマニフェストは、契約交渉に関する顧客のコラボレーションについて語っています。あなたはそれを言う：

すぐに価値をもたらさないものにチームが時間を浪費するのを見ると、クライアントは失望するかもしれません

説明するのは難しいかもしれませんし、顧客が時々非常に難しいこともあると理解していますが、これは私にとって大きな危険です。彼らはあなたのソースコード/クライアントとの関係/ビジネス/あなたが彼らのために開発しているものは何でもあなたを信頼しています。彼らが彼らの最善の利益のために専門的に行動することをあなたに信頼できないなら、あなたは問題を抱えているか、彼らのどちらかです。

私は、ソフトウェア開発者が専門家と見なされていないことについて話す投稿を書きました。専門の医師、弁護士、土木技師は、クライアントの要件を途中で変更したクライアントに直面し、品質を低下させ、それについてうめき声を上げるだけではありません。彼らはそれが問題になることをクライアントに伝えます。クライアントがプッシュした場合、専門家は責任を負うために盲目的に危険なほど劣った標準にしないでしょう。私たちはプロの入学試験を受けないので、責任はありません。だからと言って、私たちがより良くなろうとするべきではないという意味ではありません。

要約すると、スプリントの最初と最後で人々をより効率的にしようとすることについてあまり心配するのではなく、むしろチーム内のより広い問題の症状としてそれを見るでしょう。eXtreme Programming（XP）について聞いたことがありますか。ここで適用するXPの原則は、コミュニケーションと敬意です。

• チームが最高だと思うことを行うことを尊重します。猫のビデオをたくさん見ているのなら、開発者が貧弱であるか、猫の扱いが悪いと主張します。
• コミュニケーション。開発者が互いに、テスターと、管理者と、顧客と話をしているなら、おそらく誰もが次に何が起きているのかをよく感じるはずであり、そうでなければ彼らはただ尋ねることができます。

最初のポイントは、スクラムはすべての個人ではなく、チームの最適化に関することです。チームの生産性と効率が高い場合、タスクの開始時または終了時に誰かがアイドル状態であるかどうかは重要ではありません。

しかし、私がこれまでやってきたすべてのチームには、常に多くの仕事があります。いくつかの具体的な懸念に対処しましょう。

スプリントの開始時にはまだテストするものはありませんが、

それは文字通りの意味では真実かもしれませんが、テスターに​​とって唯一の仕事は「テストする」ことだと考えることを意味します。テストを開始する前にできることがたくさんあります。1つは、要件を完全に理解するために、製品所有者や開発者と会うことです。彼らは、テスト計画の作成、テストデータの収集などに忙しい場合があります。優れたフレームワークの豪華さがあれば、事前に自動テストの作成を開始できます。

スプリントの最後には、通常、開発/修正するものがまったくないか、ほとんど残っていません

修正すべきものが不足している開発チームはまだ見ていません。しかし、それは彼らがスプリントの最後にすべきことではありません。スプリントの終わりに向かって、彼らはテスターが製品をテストするのを助けるべきです。自動テストの作成を支援したり、テスターが作成したテストやフィクスチャ/キーワード/などをコードレビューしたりできます。ドキュメントチームと協力して、作業の完了などを支援できます。

これを処理するための2つのアプローチを見てきました...

あなたの思考の欠陥は、個人がタスクを使い果たすことです。タスクはチーム全体に属します。現在のスプリントでチームにストーリーやタスクが残っている限り、他の仕事をしてはいけません。

開発のためだけにスプリントにスペースを作ります。

このアプローチは、従来のスクラムまたはアジャイルの定義には含まれていません。アジャイルのポイントは、チーム全体が共通の目標に向かって取り組むことに関与しているということです。つまり、ストーリーを完成させるために必要なすべての作業は、設計、開発、テスト、ドキュメントなどのスプリントで表現する必要があります。

最後に、これが他の実行可能な解決策ではありません。真の解決策を無視します。つまり、スプリントでストーリーを完成させるために、必要に応じてすべてのチームメンバーが参加する必要があります。

目標はチームの目標ですが、各個人が個別の目標を持っているかのように書いています（「タスクを終了する」）。誰かが何もする必要がない場合、彼らは現在取り組んでいるものを見て助けを申し出ることができます。または、次のタスクまたはストーリーを取り上げて作業を開始できます。

私が働いたすべてのアジャイルショップでは、テスターは鶏と見なされているため、開発者のようにスプリントでタイムボックス化されていません。ソフトウェアを手に入れる前に、テスターは計画を書き、ソフトウェアを受け取るための環境が適切に設定されていることを確認する必要があります。これの一環として、彼らはどんなデザイン文書でも目を光らせているべきです。

次に、スプ​​リントをいっぱいにする必要があります。もちろん見積りは黒い芸術であるが見積りが良いならスプリントの終わりに余暇があるべきではないので、それはめったにいっぱいになりません。

開発者がスプリントの終わりに空き時間を持っている場合は、この時間を追跡して価値を高めていることを確認する必要があります（新しいフレームワークの学習、分析、さらなるテストなど）。

バグ修正は、スプリントに入れるのに完全に受け入れられるアクティビティです。機能に貢献するため、付加価値があります。これは、次のスプリントから盗まれた時間と見なされるべきではありません-より適切に機能を仕上げます。

理想的な世界では、チームは部門を超えて機能します。誰もがそれぞれの専門分野を持っていますが、誰もが別の専門分野として働くことができます。テスターが最も単純なタスクをコーディングできない場合、職域を超えたチームはありません。

SCRUMの方法は、チームが機能を横断できるようにすることです。とにかくテスターに​​はテスト自動化のスキルが必要です。これは、それほど複雑でないものをコーディングするための短いステップです。