反復を早期に終了する
アジャイル手法を使用している人について、これについていくつか意見を求めたい...
現在のプロジェクトでは、計画されたユーザーストーリーの開発が反復の終了前に終了していること、およびテスト作業とビジネスの受け入れが実際に私たちを最後に向かって長く引きずっていることを発見しています。これは、問題の開発者には空き時間があり、現在のイテレーションカードが「完了する」前に、基本的にイテレーション+1バックログに出て、そこでカードの作業を開始することを意味します。イテレーションマネージャーとして、これをやめたいと思います。「まあ、開発者がやったので、次に何を開発するのか」ではなく、グループがすべてのカードを完成させる責任を負う、よりチーム指向のアプローチが必要です。
私が直面している問題は、これをチームに納得させることです。一方で、開発者が自分で書いたコードをテストしたくない理由を理解しています（もちろん、自分で書いた単体テストはありますが、実行する手動テストはバイアスの影響を受ける可能性があります）。チームは、開始する前に多くの作業が行われるため、次の反復を容易にするものとして先に進むことを考えています。これは、計画/実際のシステム全体を台無しにしていると思いますが、なぜこれが重要なのかをチームに納得させるのは困難です。
みんなと女の子はどんなアドバイスをすることができますか？開発者が先に到達するのをどのように阻止しますか？彼らは代わりに何をすべきですか？物事がまだ行われている場合、これは物事のスキームにおいてどのくらいの問題ですか？
これは通常、「失敗」によって引き起こされます。これは、スプリントで計画されたすべてを提供しておらず、経営陣からは否定的なものと見なされています。チームがどれだけの量を提供できるかを正確に知るには、時折失敗する必要があることを忘れないでください。また、各スプリントで約束された機能を提供するかどうかだけでなく、提供できるコードの量によってパフォーマンスが部分的に判断されることをチームに思い出させる必要がある場合もあります。
そうでない場合、なぜチームは早く仕事を終えるのですか？例えば：
- 彼らは、スクラムの一般的な問題である見積もりを超過していますか？もしそうなら、チームをもう少し強くプッシュする証拠として「早期に終了した」スプリントを使用してください。
- 彼らはチームの外部から支援を受けていますか？もしそうなら、これらをワーカーとして追加します。
- 既存の製品のサポートなど、考えられる中断に時間が割り当てられましたか？もしそうなら、次のスプリントの見積もりを減らします。
また、自動テスト、製品のインストール/展開が最新であること、ドキュメントが完全であることなど、開発作業に加えてサポートタスクが実行されていることを確認します。これらの完了基準を上げることを検討してください。または、テストデータを作成したり、テストケースを自動化したりして、開発者にQAを支援してもらいます。
スプリントチームは、開発者がタスクを早期に終了するかどうかではなく、スプリントチームの有効性によって判断されることを忘れないでください。
彼らが先に到達するのを止めてよろしいですか？開発者が（iteration + 1）を見るのを防ぐと、次のイテレーションでは、開発タスクを完了するのにはるかに長い時間がかかります。つまり、QAでテストする時間が大幅に短縮されます。
私たちのチームでは、繰り返し発生するテーマは実際には反対であり、開発者は過剰にコミットする傾向があるため、タスクを完了しないか、最後の方で正しく実行します。これには、QAが反復の最初の2/3で十分な作業を行わず、最後に作業が多すぎるという影響があります。
私たちが投げかけたアイデアの1つは、チームがすでに行っていることを実際に実行しようとすることです。開発者が作業を減らして早く終了するようにして、開発者が（iteration + 1）を見始めることができるようにします。このようにして、いくつかのストーリーがより早く行われるため、a）QAは最初は退屈せず、最後は圧倒されません。また、計画では、人々がすでに前の作業を確認する機会があったので、より良いタスクの見積もりがあります。
開発者であることとテスターであることは、非常に異なる個性と非常に異なるスキルセットを必要とします。ほとんどの開発者が定期的にQAに飛び込むことをためらうことがわかります。彼らは単に仕事をあまり楽しんでいないだけでなく、実際に彼らの仕事を楽しんでいるQA担当者をもう一人雇うのではなく、テストを「強制」された開発者から同じ品質を得ることができません。
ただ私の意見（そして私は開発者です）
徹底していないために早く終了する開発者を見たことがあります。私の本では、開発者はテスターと同じようにテストの責任を負っています。したがって、テスターが報告する必要のある多くのことを見つけた場合、管理時間とその後の再テスト時間の両方が追加されます。
開発者は、実行する単体テストの非常に印象的なコレクションを構築できますが、それでもコードに重大な障害が発生する可能性があります。おそらく原因は、彼らが必要な機能をあまりにも狭く考慮していることです。おそらく、より多くの代替フローを呼び出す必要があるユースケースに戻る可能性があります。あるいは、コード品質が低いことと、ユニットテストが少なすぎるか単純すぎることを示している可能性があります。
一部の開発環境では、開発者が自分のデスクで利用できるものでテストするには難しすぎるため、シミュレーターでテストされたり、合格したりする機能が多数ある場合があります。公平を期すために、開発者テストと受け入れテストの範囲は、テスターがどれだけ作業しなければならないかという大きな要因です。
もう1つの考慮事項は、開発者とテスターの比率、およびテストの自動化に使用できるツールと比較したテスト構成の複雑さです。開発が10分で単体テストを実行するが、複雑なユーザーインタラクションやハードウェアや外部デバイスとのテストがテストの一部ではない場合、テスターが長い極であるのはおそらく正常です。テスターは開発者よりも自分の作業を文書化するために多くのことを行う可能性があり、これが真実である場合、一方が近道を取っているのか、他方が不要な作業を行っているのかについて何らかの評価があるかもしれません。
開発者は、客観性を損なうような方法でテスターに影響を与えてはなりません。ただし、開発者が単体テストとテスターで変更されたコードに関するドキュメントを共有することは非常に合理的だと思います。一部のグループでは、開発者が一連の作業を行い、スケジュールがほぼ使い果たされたときにビルドをテスターに渡します。他のグループでは、テスターはデイリービルドを取得するため、新しいビットが利用可能になったときにテストを進めることができます。一部のグループでは、テスターは、最適なタイミングで独自のビルドを生成することもできます。
一部のチームは、コード/意思決定カバレッジテストを行うための高度なトレーニングを受けたスタッフを配置できるように、Software Development Engineer inTestというタイトルの人を追加しています。これは、一部のアジャイルガイドラインに反する可能性がありますが、実行すべきであると私たちが言う開発者テストの実践も同様です。
スプリント中にさらに多くのストーリーをプッシュし続ける限り、この動作を回避するのは難しいでしょう。代わりに、新しいストーリーを除いて、残りのスプリントを自分がしていることと一緒に過ごすようにします。ビルドの自動化、先週からのクールな新しいツールの学習、テスト、数週間のバーベキューなど、できることは無数にあると思います。それに応じて、新しいスプリントを計画することができます新しい反復でより多くのストーリー（それが目標である場合）。
テストと受け入れをスピードアップできる場合は、そうしてください。できない場合、これは制限要因です。
テスト中に何が起こっているのですか、そしてなぜそれがそれほど長くかかるのですか？
これはリソースの問題である可能性があります（5人の開発者、1人のテスター-機能しません）
あるいは、テストが過度に徹底していて、問題がまったく見つからない場合もあります。その場合は、テストを減らして自動化を増やしますか？
それとも、品質が悪く、やり直しや修正がたくさん必要なため、テストに時間がかかるのでしょうか。その場合、開発者は速度を落とし、より良い品質を構築する必要があります（そして、最終的には開発中にQAを使用することを検討します）。
賢い人（私はそれを調べるのが面倒です）は、開発者の仕事はQAを廃業させることだと言いました。