スクラム-スプリント中に忙しいチームメンバーは何ですか
したがって、スクラムスプリントは、特定の機能セットを実装する必要がある固定期間です。そして、スクラムチームは、これらの機能を提供することに専念しているすべての人々で構成され、その大半は通常、開発者とテスターです。
これらのルールを確立したら、全スプリント中にこれらの人々全員を忙しくしておく方法を疑問に思うかもしれません。スプリントの初めにはまだテストするものはなく、スプリントの終わりには通常、開発/修正するものはほとんどないか、ほとんどありません。
私はこれを処理する2つの方法を見てきましたが、どちらも問題を適切に解決していないようです。
1）チームメンバーに、タスクがなくなったときに何をするかを決めさせます。
短所：
- 彼らの行動が完全に計画されていない場合（つまり、大規模なリファクタリング、新しいテストフレームワークへの切り替え）、彼らの仕事は役に立たないか、途中で行き詰まっているかもしれません。
- 一方、そのような作業の計画にはかなりの時間がかかる可能性があり、クライアントは、チームがすぐに価値をもたらさない何かに時間を浪費していることに失望するかもしれません。
- 通常、そのようなタスクは完全に見積もることができないため、無意識の労働者がスクラムボードや他の場所に反映されずにYouTube猫を見て時間を費やすのは非常に簡単です
2）スプリントに開発専用のスペースを確保し、スプリントが終了した後（開発者が次のスプリントから機能の作業を開始するとき）にテストを開始します。
短所：
- 現在のスプリントの機能を開発している間、開発者は以前のスプリントのバグを修正することに気を取られ、現在のスプリント中に行われると推定された量の作業を実行できなくなる可能性があります。
- 2つのスクラムボードが必要です。1つは現在のスプリント機能用、もう1つは以前のスプリントバグ用です
だから私の質問は、スプリント中に開発者とテスターの間で作業を適切に分散して、誰もが作業で過負荷になったり、タスクがなくなったりしないようにする方法ですか？上記のアプローチを改善する方法はありますか？または、より良いアプローチはありますか？
スプリントの最初はまだテストするものはありません
本当に？検証する必要はありませんか？顧客との話し合いはありませんか？評価するワイヤーフレームはありませんか？検討するテスト計画はありませんか？
スプリントの最後には、通常、開発/修正するものが何もないか、ほとんどありません
私はプロジェクトでその場所に行ったことがありません。もうやる必要はありませんか？常に何かがあります。すべてのテストは完全に自動化されていますか？ CIはどのように見えますか？データベースアクセスレイヤーを単純化するためにリファクタリングできますか？そして、私は空のバグリストとバックログで何かに取り組んだことがありません。ウォーターフォールのテスト段階で開発者は何をしていたのですか？
「スクラム」とは何か、そうでないものについて非常に信心深くなる人もいることは知っています。私はそれについてあまり気にすることができませんでした。しかし、ここには2つの問題があると思います。
顧客や開発者と協力して、正しいものを構築していることを確認するのではなく、開発者がコードを「完成」したらコードをテストする「従来の」QA部門。 Lisa Crispinによる アジャイルテストの四分円 を見てください。最高のテスターはソフトウェア開発ライフサイクルのすべての段階に関与し、最高の開発者は独自のテストを作成します。
1週間/ 2週間のスプリントのSCRUMタイムテーブルに近すぎず、短時間で完了するのに十分簡単なタスクに分割された優先度とサイズのバックログを持たない within単一のスプリント。あなたがこれを持っていれば、それに取り組むために常により多くの仕事があるでしょう。たぶん、このスプリントで作業する最後の機能は、このスプリントのリリースには含まれていませんが、いつでも次のリリースに進むことができます。
さておき。あなたが小さなまとまりのあるチームを持っているなら、役割はそれほど重要ではありません。プロダクションコードの作成を許可されていないラベルテスターを持っている人や、テストを上回っていると考える開発者にラベルを付けられている人を置く代わりに、チームが成功するために必要なあらゆることを全員が行う必要があります。彼らは必要です。これは部門横断的なチームと呼ばれます。
@Cort Ammonがコメントで挙げたもう1つのポイント。アジャイルマニフェストは、契約交渉よりも顧客のコラボレーションについて話します。あなたはそれを言う：
クライアントがすぐに価値をもたらさない何かにチームが時間を浪費していることに失望するかもしれません
説明するのは難しいかもしれませんし、顧客が時々非常に難しいこともあると理解していますが、これは私にとって大きな赤旗になるでしょう。彼らは彼らのソースコード/クライアント関係/ビジネス/あなたが彼らのために開発しているものは何でもあなたを信頼しています。彼らがプロの最善の利益のために専門的に行動することを信頼できない場合は、問題があるか、問題があります。
私は 投稿 を書いて、ソフトウェア開発者が専門家とは見なされていないことについて話しています。クライアントの要件を途中で変更したクライアントに直面した専門の医師、弁護士、土木技師は、品質を低下させ、それについてうめき声を上げるだけではありません。彼らはそれが問題であると彼らのクライアントに話します。クライアントがプッシュした場合、専門家は責任を負うため、危険なほどに劣った基準で盲目的にそれを行うことはありません。専門的な入学試験は受けていないため、責任を負いません。だからといって、もっと良くしようとするべきではありません。
要約すると、スプリントの最初と最後で人々がより効率的になるようにすることについてあまり心配する必要はありませんが、チーム内のより広い問題の兆候と見なします。 eXtreme Programming（XP） について聞いたことがありますか。ここで適用するXP=の原則は、コミュニケーションと尊敬です。
- チームが尊敬するのは、彼らが最善だと思うことを実行することです。猫の動画をたくさん見ると、開発者が貧弱になるか、扱いが悪くなると私は主張します。
- コミュニケーション。開発者がお互いに、テスターに、管理に、顧客に話しかけている場合、おそらく誰もが次に何が起きているかについて良い気持ちを持っているはずです。
最初のポイントは、スクラムはすべての個人を最適化することではなく、チームを最適化することです。チームが生産的かつ効率的である場合、タスクの開始時または終了時に誰かがアイドル状態であっても、問題にはなりません。
しかし、私が参加したすべてのチームには、常に多くの作業があります。特定の懸念事項をいくつか取り上げます。
スプリントの最初はまだテストするものはありません。
これは文字通りの意味では真実かもしれませんが、テスターの唯一の仕事は「テストする」ことだと考えることを意味します。テストを始める前にできることはたくさんあります。 1つは、製品の所有者や開発者と会って要件を完全に理解することです。テスト計画の作成、テストデータの収集などで忙しい場合があります。優れたフレームワークの贅沢があれば、事前に自動テストの作成を開始できます。
スプリントの最後には、通常、開発/修正するものが何もないか、ほとんどありません
まだ修正すべき点が不足している開発チームを見たことがありません。しかし、それは彼らがスプリントの終わりにやるべきことではありません。スプリントの終わりに向かって、彼らはテスターが製品をテストするのを助けるべきです。彼らは自動テストの作成を支援し、テスターが作成したテストやフィクスチャ/キーワード/その他をコードレビューできます。ドキュメントチームと協力して、作業の完了などを支援できます。
これを処理するための2つのアプローチを見てきました... 1）チームメンバーに、タスクがなくなったときに何をするかを決定させます。
あなたの考えの欠点は、個人がタスクを使い果たすことです。タスクは全体としてチームに属します。現在のスプリントにストーリーやタスクが残っている限り、他の作業をしてはいけませんチーム用。
スプリントに開発専用のスペースを確保し、
このアプローチは、スクラムまたはアジャイルの従来の定義には含まれていません。アジャイルの要点は、チーム全体が共通の目標に向けて取り組むことに関与していることです。つまり、ストーリーを完成させるために必要なall作業は、スプリントで表す必要があります-設計、開発、テスト、ドキュメンテーションなど。
最後に、これが唯一の他の実行可能な解決策ではありません。あなたは本当の解決策を無視します。つまり、すべてのチームメンバーは、スプリントでストーリーを完成させるために必要に応じて売り込む必要があります。
目標はteam目標ですが、各個人が個別の目標を持っているかのように書いています（「自分のタスクを終了する」）。誰かが何もする必要がない場合、彼らは現在取り組んでいることを確認し、支援を申し出ることができます。または、次のタスクやストーリーを担当して、作業を開始することもできます。
私が働いたすべてのアジャイルショップでは、テスターは chickens と見なされるため、開発者のようにスプリントでタイムボックス化されません。ソフトウェアを入手する前に、テスターは計画を作成し、ソフトウェアを受け取るための環境が適切に設定されていることを確認する必要があります。この一部として、彼らはそれらのような設計ドキュメントを目撃する必要があります。
次に、スプリントを埋める必要があります。もちろん見積もりはブラックアートであるため、見積もりが適切であれば、スプリントの最後に時間がないはずです。正確に満たされることはほとんどありません 。
開発者がスプリントの最後に時間がある場合でも、この時間を追跡して、付加価値があることを確認する必要があります（新しいフレームワークの学習、分析、さらにテストなど）。
バグ修正は、スプリントに入れるのに完全に許容できるアクティビティです。それは機能に貢献し、価値を追加します。これは、次のスプリントから盗まれた時間とは見なされません-より適切に機能を終了します。