Scrum: An Evidence-Based Management Approach
How to Problem Solve with a Professional Scrum Master In today's rapidly changing and complex business environment, the need for an evidence-based, flexible strategy is paramount. At Agile-ity, we offer…
How to Problem Solve with a Professional Scrum Master In today's rapidly changing and complex business environment, the need for an evidence-based, flexible strategy is paramount. At Agile-ity, we offer…
In the last “Ask a Professional Scrum Trainer” episode I got a question that was not answered during the session. BTW: Here you find all Peter Gfader's podcasts. So here…
Answering the question, “when will it be done?” in the VUCA (volatile, uncertain, complex, ambiguous) environments that agile was designed for has always been problematic. Afterall, the future is unknown.…
A central feature of the Scrum framework is the concept of a cross-functional team. But what exactly is cross-functionality, and how is it beneficial? Let's explore this topic in…
TL; DR: How Elon Musk Would Run YOUR Business with Joe Justice Joe Justice worked for Bill Gates, Jeff Bezos, and Elon Musk. In this Hands-on Agile meetup, Joe shared…
In the past years, Johannes Schartau, Christiaan Verwijs, and I wrote many articles on Zombie Scrum. Heck, we even wrote a complete Zombie Scrum Survival Guide! I’d like to believe that…
„Wir brauchen ein Produkt, das die Kunden lieben, welches aber auch für unser Geschäft funktioniert.“ Dies schreibt Marty Cagan in seinem Buch „Inspiriert“. Eine Idee für ein Produkt zu haben,…
Are you looking to embark on an Agile transformation journey for your organisation? Look no further than tryScrum's white paper on the Stages of Agile Transformation. In this paper,…
Effective Stakeholder Engagement is key to the product's success and one of the essential skills all product people should have. This article is final part of the Effective Stakeholder Engagement…
私がアジャイルテストについて学んだことの多くは、Janet GregoryとLisa Crispinの著書「実践アジャイルテスト」から得たものです。この本や他の多くの本から学んだテクニックや考え方を、何年も前から自分のチームで実践してきました。この本が日本語に翻訳されたことで、多くの人がJanet GregoryとLisa Crispinの知恵に簡単にアクセスできるようになったことをとても嬉しく思います。今回は、この本から一つの考え方を紹介します: 「アジャイルテストの4象限」です。「アジャイルテストの4象限」とは何か、そして有効性を高めて、顧客が満足できる優れたプロダクトを開発できるようにスクラムチームがどのようにして生かせるかを説明します。 ソフトウェア品質には多くの側面があり、それぞれに異なるテストアプローチが必要です。何をもって「テストが終わった」と言えるのか?各テスト種類の目的は何か?このモデルはソフトウエアプロダクト開発チームがこのような質問に答えられるようになるためのツールです。各象限を説明します: 第1象限(左下)は、技術に焦点を当てて、チームを支援する・導くテスト活動になります。単体テスト、コンポネントテストやシンプルな結合テストが含まれます。場合によって、テスト駆動開発(TDD)によって作成される時もあります。第1象限のテストは基本的に自動化する必要があります。第1象限のテストは「プログラマーテスト」と呼ばれることがあります。Kent Beckによると、「プログラマーがコードの内部品質を測定する」(Extreme Programming Explained)ためのものです。 第2象限(左上)は、ビジネスに焦点を当てて、またチームを導くことを目的としています。機能テスト、ストーリーテスト、プロトタイプなどが含まれます。これらのテストは、第1象限からのテストと部分的に重複することもありますが、プロダクトやシステム全体の動作により重点を置いています。場合によって、受け入れテスト駆動開発(ATDD)によって作成されます。 私の経験では、この象限は最もよく理解されている象限かもしれません。多くのチームがこの象限に多くの時間を費やし、これらのテストを自動化し、早期に、頻繁に実行することの重要性を理解しています。 第3象限(右上)は、プロダクトを批評することにビジネスに焦点が当てられています。これらのテストは主に手動で実行されます。用意されたテストシナリオに従うか、探索的アプローチで実行されます。第3象限に属するテストは、チームのメンバー以外の方がかかわることがあります。 第3象限を活用して、スクラムチームがプロダクトやユーザーが求めているものに関する仮説を検証します。優れた開発チームは例えば6ヶ月に1回のUATフェーズに満足しません。リスクを最小化するために、このようなテストを早期に、そして頻繁に行います。スクラムチームがスプリントごとに完成したインクリメントを作成する大きい理由の1つは、このような検証を行うためです。 第4象限(右下)は、技術に焦点を当てて、プロダクトの非機能的な側面を批評するものです。プロダクトの反応のスピード・パフォーマンスはどれくらいあるか?高負荷の時サーバーなどは落ちないか?を検証します。コンプライアンス、セキュリティ、安全性、その他の「○○性」テストも含まれています。第4象限に位置するテストは、通常、様々なツールのサポートを得て実行されます。これらのテストも、残念ながら実行される頻度が低すぎたり、遅すぎたりすることが多いのです。開発するプロダクトによっては、非機能要件がプロダクトのコアな競合上の優位性になることがあります。第4象限のテストを自動化し、CI/CDパイプラインの一部として実行しないチームは、大きなリスクを負っています。 第1象限と第2象限は、プロダクトが仕様や要件に適合しているかどうかの検証に焦点を当てます。第3象限と第4象限は、プロダクトが目的に合っているかどうかの検証に焦点を当てます。 順番は特にありません。考える順番、重要性など、1・2・3・4にはその意味が含まれていません。 このモデルはある意味で世の中に既にあったプラクティスを整理しているだけだと思われるかもしれませんが、私はこのモデルに価値があると思うところは、主に2点です シンプルである一方、網羅的であること。テスターやチームがさまざまなテストの種類について考えて、何かを無視する・目落とすことがないようにするのに役に立っています。 なぜテストをするのでしょうか?その答えは明白に見えるかもしれませんが、実はかなり複雑です。「ビジネス面」と「技術面」、そして「チームを支援するためのテスト」と「プロダクトを批評するためのテスト」と言う二次元で構成されていることで、各テストに明確な目的を持たせています。テストを考える際に、目的を明確にすることで集中もできるし、無駄のリスクも制限されると思いますす。 要するにアジャイルテストの4象限は、強力なコミュニケーションツールになります。 また、スクラムのフレームワークの中で、以下のような様々な方法で適用することができます: 最初に「完成の定義」を決める際に。また、スプリントレトロスペクティブなどで「完成の定義」を検査・適応させる際に。 ユーザーがインクリメントに満足しなかった時、バグが発生した時、様々な問題の原因を特定し、二度同じことが再発しないように対策を考える際に。 チームが新しいプロダクトバックログアイテムの開発に着手し、どのようにしてテストを進めていくかを話し合う際に。 アジャイル開発を支援するテストの進め方に関してもっと詳しく知りたいという方には、以下をお勧めします: 「実践アジャイルテスト」を読む。 Janet GregoryとLisa…
Scrum is founded on empirical process control, and inspection is one of the three pillars. Each of the Scrum accountabilities participates in one or more inspections. If you feel that…
Teams are more effective when they learn how to effectively combine their skills to complete a shared task. This is the essence of cross-functionality. Cross-functional teams are defined as consisting…
In Kürze: Retrospektiven Moderation Die magische Technik, um eine langweilige Retrospektive in eine hervorragende Retrospektive zu verwandeln, liegt in der regelmäßigen Rotation der Moderatorenrolle unter allen Teammitgliedern. Erfahren Sie mehr…
In the fast-paced world of software development, agile methodologies have revolutionized the way teams work. Among the various frameworks, Scrum has emerged as a popular choice for its focus…
El desarrollo ágil y centrado en el cliente de productos y servicios se basa en aprender lo antes posible, y de manera empírica, las necesidades del cliente y cómo entregar soluciones que funcionen. 👉 Lee este artículo y el…