同じスプリントのdevとqa
私はこれを尋ねる最初のものではありませんが、私はまた、何が必要であるかを教えてくれるような他のそのような投稿から具体的なことを何も得ていなかったので、ここで質問をします。他のリソースを参照してください。
私の組織はアジャイル方法論を常に光沢のあるものとして実装しようとしていますが、適切に実装していないことはわかっています。現在、スプリントアイテムは開発完了であると言って完成しています。作業のQA部分は、アイテムをスプリントで完了として正常にマークするために必要ではありません。これは、スプリント成果物の主な動機が達成されていないことを意味します。
これは、真のアジャイル配信をサポートする構造の理想的な世界に到達する方法を知ることとは異なります。
だから私が探しているのは、アジャイルな方法で提供できる構造を実装するために必要なすべてです。本のリファレンスやオンラインの投稿、あるいはあなたが役に立ったことがわかっているものは、原則についての理論的な言及だけでなくそれを実装する方法の実用的なガイドである限り役に立ちます。
自動化の実装などの基本は、現在取り組んでいることです。ただし、開発者が開発を完了したか、QAが成果物のテストを完了したかについては、少なくともしばらくはカバーされていません。どちらもスプリントの終わりまでに完了することができ、どちらも残っていないが、QAの作業を待つ間、スプリントの終わり近くで開発者がアイドル状態になっていないか、QAがスプリントの終了後にQA作業を開始する彼らの作業。
どちらもスプリントの終わりまでに完了することができ、どちらも残っていないが、QAの作業を待つ間、スプリントの終わり近くで開発者がアイドル状態になっていないか、QAがスプリントの終了後にQA作業を開始する彼らの作業。
スクラムは個人ではなくチームのために最適化されるため、スプリントの最後に誰かがアイドル状態になれない理由は本当にありません。
そうは言っても、プロジェクトの最後のスプリントでない限り、これが可能になるシナリオを想像するのは難しいと思います。開発作業が完了すると、開発者は製品をテストするためにテスターと協力し続ける必要があります。スクラムの下でのソフトウェア開発はチームスポーツです。自分のソフトウェアのテストを支援したくない開発者、またはチームメイトの開発者がいる場合、それらはスクラムチームに属していません。
開発者が開発作業が完了したと思った後にできること：
- 自動テストの作成に役立ちます。たとえば、キーワードベースのテストツールを使用している場合、下位レベルのキーワードを記述できます。
- テストデータの生成でテスターを支援し、
- コードのテスト容易性に関する問題を修正します。たとえば、Webアプリを構築する場合、テスターが言及した直後に欠落しているID属性を追加します。
- バックログのグルーミングについてプロダクトオーナーと協力し、
- コードの小さなセクションを最適化し、
- 他の開発者がコードでフィニッシュラインを越えるのを助ける
- 必要なドキュメントを書くのに役立ちます
同様に、コーディングが完了する前にQAが何もしないシナリオは想像できません。以下は、スプリントの最初の数日間にテスターが実行できる多くのことの一部です。
- 受け入れ基準を完全に理解するために製品所有者と協力し、開発者がそれをどのように計画するかについて開発者と協力し、
- 高レベルのテストシナリオの生成
- テストデータの収集
- コードをテストしやすくする方法について開発者に提案する（Webアプリケーションに基づく簡単な例：対話する必要のあるすべてのWeb要素に一意のIDを追加するようにしてください）。
- 製品の所有者および開発者と協力して、高レベルのテストシナリオを改善します。
- 自動テストの作業を開始します。適切なテストフレームワークがあれば、ソフトウェアの準備が整う前に自動テストを作成するのは非常に簡単です。開発者と開発者がWebページやアプリ内の要素、それらの識別方法などについて共同で作業している場合は、
- テストの準備ができたらテストする準備ができるように、作成中のコードを確認します。
- バックログのグルーミングと次のスプリントの承認基準の作成について製品所有者と協力する。
...しかし、開発者が開発を完了したか、QAが成果物のテストを完了したかについては、少なくともしばらくはカバーできません...
スプリントの鍵は、チームが協力していることです常時。したがって、スプリントの開始時に、テスターは開発者と協力して、最初の作業で何をしているかを理解し、テスト方法をよりよく理解します。これらの作業は数日ではなく数時間で行う必要があるため、テストはほとんどすぐに開始されます。
テスト中、テスターはフィードバックを提供し、開発者は見つかった問題を修正します。したがって、開発者はテストが終了するまで終了していません。テストが問題を発見しない限り、テストが終了しない限り、「少なくともdevが完了したときの少し時間 "はありません。その場合、テストは目的を果たしません。
スプリントの最初に何もしないテスターと最後に何もしない開発者の問題は、スプリントの各タスクがミニウォーターフォールとして扱われる場合にのみ発生します。だからそれをしないでください。代わりに、各タスクを開発者とテスターの間の共同作業として扱います。
すでに述べたものとは異なるアプローチを提案させてください。 QAが別のチームまたは部門のままである場合、次の方法で作業することを検討できます。
現在、スプリントアイテムは「開発完了」であると言って完成しています
それは問題ないので、スプリントを完了するたびに、QAに配信できる新しいリリースがあります。このリリースのバージョン番号が5.0だとします。その後、QAは、前の春の新機能に重点を置いて5.0のテストを開始します。一方、開発者は次のスプリントの開発を開始します。6.0を目指しているとしましょう。
QAが重大な欠陥を検出するたびに、「5.x」ブランチと現在の開発ブランチで修正されます。これにより、一連の不具合を修正した後、QAの中間リリース5.1、5.2などが発生する可能性があります。そのようなバグ修正のために時間を確保するようにスプリントを計画する必要があります（ただし、QA担当者が欠陥を見つけられない場合でも、現在のスプリントの開発者はそのような時間が必要です）。 1つではなく2つのブランチでバグを修正する場合、通常、devブランチで修正するよりも少しだけ時間がかかります。これは、欠陥の根本的な原因が見つかったら、ほとんどの場合、バグを修正するだけなので、 devブランチ。修正を5.xブランチにマージし（バージョン管理システムを使用）、5.x行に新しいリリースを自動的に作成します。
QAが5.xラインのテストを終了したら、最終リリースを本番環境にデプロイできます。 QAで見つかったすべての欠陥をすぐに修正する必要があるわけではないことに注意してください。特定の問題の影響が小さい場合は、バックログに入れることが完全に可能です。
ご覧のとおり、このモデルでは、開発者が座ってQAが完了するのを待つ必要はありません。新しい6.0リリースの準備が整う前にQAが5.xラインのテストを完了した場合、彼らは残りの時間をテストの自動化に投資し、テスト計画を改善するための新しいテストについて検討するか、ドキュメントを作成するか、ツール。これにより、約1スプリントの遅延のある「プロダクションレディ」リリースの価格で、スプリントで機敏な方法で作業できます。
これは多くの人にとって、しばしば考え方の変化です。簡単な答えは、チームが同じスプリントで何かを開発およびテストする責任があるということです。それがあまりにも多くの作業である場合、より少ない機能をコミットする必要があります。
グリッドとしての作業を想像してください。各行はチームが実装したい機能を表し、各列はさまざまな従来の段階を表します。開発、テスト、解決、完了など...
通常のウォーターフォールアプリケーションでは、チームはすべての機能の開発を行ってから、テスト、解決済み...に移行します。このアプローチは、多くの場合、やり直しが多くなり、コミュニケーションが不十分になることがわかっているためです。
スクラムチームには、作業の一部を計画から完了まで実行するためのすべてのスキルセットが含まれている必要があります（完了、完了-本当に正当な理由があると主張できる場合を除き、ライブの顧客との生産で）。
したがって、1つの列全体を完成させる代わりに、チームは一度に少数の行を完成させることを目指しています。これらの各スプリントのいくつかを終了し、次のセットを開始する前にライブにプッシュします。これが良いアイデアである理由はたくさんありますが、この回答の範囲から外します。
これで、少数の機能を準備完了から完了に移行したいと考えました。同じスプリントでチームの開発とテストの両方を支援する方法を確認できます（これにもデプロイを含めたいと思います）。
まず、作業を表示します。これらの機能をプロダクションに導入するために必要なすべての作業を人々が見ることができれば、それを完了する可能性がはるかに高くなります。
次に、タスクを完了するのはチーム全体の責任です。テストは1人の責任ではなく、チーム全体の仕事です。一部の人はテストの専門知識を持っているかもしれませんが、他のチームメンバーを支援できます。テストできるのは彼らだけではありません。
考え方や文化を変えるのは難しいですが、私の主な提案は次のとおりです。
- 少数の小さなタスクを取り、各スプリントを実行するためにそれらを提供します
- 開発者が何もすることがないことに気付いた場合、より多くの作業を引き込ませないようにするには、テスト/展開プロセスを支援する必要があります。
- テスターを早期に関与させ、改善/計画セッションを使用して、実行する必要があるテストを特定します。このようなテストを計画することで、非テスターがテストに参加することがはるかに簡単になります。開発者にテストを自動化するように促してください！
[〜＃〜] tldr [〜＃〜]
各スプリントを本番環境に配信するようチームに奨励します。これにより、自然にバランスが取れ、より少ない作業で作業を進めることができます。
チームメンバーをさまざまなスキルを持つエンジニアと考えてください。開発者がテストできず、テスターが進行中の開発についてアドバイスできない理由はありません。準備完了の定義の一部として実行するテストを計画すると、テスターが他のチームメンバーが実行するテストをより簡単に設計できます。
完了の定義には、何かをライブに含めることを強くお勧めします。ストーリーは、本番に入るまでクローズされません。これにより、テスト/展開待ちの作業が非常に目立つようになり、頻繁なリリースが促進されます。