ATDD を実装するためのクイック ガイド
Key Takeaways
- ATDD は、コラボレーション不足、顧客ニーズに対する共通の見解の欠如など、アジャイル チームの抱える共通の問題の克服に役立ちます
- TDD を効果的に実装するにはトレーニング、実験、可視化などの作業が必要です。
- ATDD の実装は、いくつかのアジャイルチームに測定可能な利益をもたらした
- ATDD により、チームや組織は SDLC 全体を通して自動化を活用できる
- ATDD の実装にはチームの協力が必要
この記事は、チームやプロジェクトに ATDD を実装することに興味を持つすべての人に手引を示すものです。 企業のソフトウェア開発チームでの私の実体験に基づき、このアジャイル手法に従うことの利点を概説します。
コラボレーションは、アジャイル手法の中核的価値の 1 つです。 かつて、大規模なプロジェクトで作業していたとき、開発者、テスター、およびビジネス志向の人々の間のコラボレーションの欠如、要件が明確でないこと、頻繁に要件の範囲を広げること、完了したテストに関して可視性がないこと、プロジェクトのライフサイクルの後半で欠陥が確認されることなどに気づきました。 しかし、私にとって最も重要なことは、自動化フレームワークについて誰も知らないことでした。そのため、すべての自動化テストは、機能が開発され、テストの準備が整ってから書かれていました。 このような観察から、私は、人々がこの種の問題にどのように取り組んでいるのかを調べ始めました。 その結果、これらの問題の多くを軽減するために使用されるアプローチの1つとして、受入テスト駆動開発（ATDD）を発見したのです。 ATDDは、行動テスト駆動開発（BDD）、ストーリーテスト駆動開発（SDD）、Specification By Example（SBE）と同義に使われることが多いようです。 他のアジャイルアプローチと異なるATDDの主な特徴は、開発者、テスター、ビジネスパーソン、プロダクトオーナー、その他の利害関係者が1つのユニットとして協力し、何を実装すべきかを明確に理解することに重点を置いている点である。
私自身の経験に基づいて、チームが自身のプロジェクトで ATDD を実装する方法について、私のアイデアを共有します。
コンテキスト
私は、スタートアップの考え方を持つ大企業で働いていたので、あらゆる革新的なアイデアやフィードバックがチームから奨励されました。 あるアイデアが製品をより良くするか、あるいは会社の包括的な目標に役立つかどうかを確認するために、素早くプロトタイプを作りました。 私は、スクラムマスター、テクニカルリード、ビジネスアナリスト、デザイナー、デベロッパー、テスターからなる25名のチームで、リードテスターを務めました。 革新的な文化の結果、機能要件が頻繁に変更され、個人がサイロ化した環境で働き、チームの士気が極端に低下するなど、チーム内でしばしばカオスが発生していました。 これは私にとっては気になることでしたので、これらの痛みのポイントを解決するための支援を志願し、ATDDにたどり着きました。
The ATDD implementation cycle
Created by Raj Subramanian
ステップ 1 – Training and Experimentation
タスクに対するアプローチの方法は、特に個人が現在の組織の内外の異なるアジャイル チームで働いている経験を考慮すると多く存在するものです。 チームと組織の目標について共有された共通の理解をもたらすためには、適切なトレーニングを提供することが重要である。 特にATDDに関しては、目標、目的、期待、そして、このアプローチを使うことで得られる結果についての情報が含まれていなければならない。 トレーニングの後、さまざまなことを試し、繰り返しフィードバックを受けるために、小規模な実装から始めることが重要です
たとえば、ATDDを調査した後、私はさまざまな利害関係者に、なぜこのアプローチを探る必要があり、それによってどんな利益が得られるかを説明しました。 たとえば、チームの協力関係の強化、要件の明確化、ソフトウェア開発ライフサイクル (SDLC) における欠陥の早期特定、SDLC における可視性の向上と自動化の早期使用、および明確な受け入れ基準の策定におけるチーム全体の関与などです。 いくつかの長い議論の後、私たちは 25 人の元のチームを 2 つの小さなチームに分割することを決定しました。 チームAは12人で、ATDDを実装します。 チーム A は 12 人で構成され、ATDD を実装します。チーム B は残りの 13 人で構成され、すでに行っていることを継続します。
私は、ATDD について学び、どの概念がプロジェクトの文脈で意味をなすか、そして、このプロセスを通してどのように自動化を活用できるかを判断することによって、チーム A の 2 日間のトレーニング ワークショップを計画しました。 私は、トレーニングに理論的および実践的な演習の混合を含めました。
Source
Step 2 – Increasing Visibility
プロジェクトが複数のスプリントを通して生きると、従う必要のあるさまざまなプロセスを見失いがちである。 そこで重要なのは、目標、目的、および期待をチーム全体に見えるようにすることです。
ATDD を使い始めたとき、私は、従う必要のある毎日のプロセスをホワイトボードにそれぞれ書き出し、それをチームが毎日スタンドアップ会議を行う場所に置くことから始めました。 そして、各ユーザーストーリーの上に、そのストーリーが完成したとみなされるために必要な項目をチェックリストとして追加していきました。 こうすることで、どのようなATDDプロセスに従わなければならないのかが、曖昧にならないようにしました。 キックオフミーティングでは、開発者、テスター、ビジネスパーソンがチームとして要件について話し合い、自動化できる要件を特定し、ストーリーの受け入れ基準をGWT形式で概説しました。 もう一つのチェック項目は、QA-Devハンドオフで、開発者がテスターに、簡単なデモやディスカッションを通じて、要件がどのように完了し、ストーリーの一部としてどのようなユニットテストが書かれたかを示すものでした。 このハンドオフを通じて、テスターはユニットテストでカバーされていない部分を知り、実装された機能に対する理解を深めることで、より良いテストカバレッジを実現することができるようになりました。 チェックリストの項目は、時には自明なものもありますが、明確に記載されていることは良いことです。 もうひとつは、デモを見てビジネス担当者が最終的に承認し、その機能が事前に設定された要件と期待に従って構築されていることを確認するものでした。 これは、スクラム・マスター、プロジェクト・マネージャー、あるいはチームがプロセスに従うことを保証する人など、個々のチーム・メンバーのことです。 彼と私は、立ち上げ、計画、回顧、およびその他のチーム会議など、すべての会議で ATDD プロセスに従うことを定期的に全員に思い出させました。
ステップ 3- 反復学習とフィードバック
一定のフィードバック ループを持つことは、ATDD など、あらゆるアジャイル手法の実装で重要です。 チーム全体と毎週または隔週で振り返り会議を行うことは、プロセスのどの部分が実際にチームのためになっているか、そして、どの部分が修正される必要があるかを知るための重要な方法です。 すでにご存知のように、チームのためにならないことは、時間と労力の浪費につながります。 Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time」の著者である Brian Tracy 氏は、「時間の最も悪い使い方の 1 つは、まったく行う必要のないことを非常にうまく行うことである」と述べています (3507)
現在の情報テクノロジー時代において、組織は効果のないアプローチで時間やエネルギーを無駄にする余裕はなく、リーンで有効なプロセスを実施する必要があります。 これは、リーン スタートアップの検証された学習 (構築、測定、学習サイクル) の原則と結びついています。 これは、チームからの反応に基づいて、どのような変更が必要かを判断するための良い方法でした。 このミーティングは、2週間のスプリントの終わりに行われるレトロスペクティブミーティングとは別に行われました。 この方法によって、チームからの継続的なフィードバックがもたらされ、即座に効果的な変更を行うことができました。 フィードバックは、毎週のプロセスチェックインだけでなく、毎日のスタンドアップミーティングも貴重な情報源であることがわかりました。 個々のチーム メンバーのアップデートとディスカッションにより、プロセスに関連する赤旗が発見され、それがチームの他のメンバーに影響を与える前に、直ちに対処することができました」
概要
ATDD実装サイクルに従う結果、チームAの士気、コラボレーション、要件にかなりの違いが見られるようになりました。 各自が最初から最後までストーリーを所有した。 彼/彼女は、ストーリーが開発とテスト作業を開始するために必要なすべての情報を持っていることを確認した。 また、そのストーリーに関連するすべてのフォローアップが行われるようにした。 そして、スプリントの最後には、すべてのステークホルダーにストーリーを示す役割を担った。 3507>
Collaboration
キックオフミーティングは、ユーザーストーリーの共通理解を深めるために、ビジネスパーソン、開発者、およびテスターを一堂に集めました。 QA-Dev Handoff は、ビルドを QA サーバーにプッシュする前に行われ、開発者とテスターの両方が、ストーリーの一部として完了するテストを知るのに役立ち、実装された機能に対するより良い理解をもたらしました。 テスターだけでなく、チーム全体がオーナーシップを持つようになり、自動化の可視性が高まった。 また、企画会議では、チーム全体でストーリーを議論することで、より多くのアイデア、質問、議論が生まれました。 チーム内でピアツーピアのコーチングセッションを行い、お互いに学び合うことにしました。テスターはペアで探索的テストを行うようになり、技術に関する様々なトピックについて話し合うために、異なるチームメンバーによってランチラーニングセッションが開催されるようになりました。 3507>
Requirements
私たちの以前のプロセスにおける主な問題の 1 つは、要件の頻繁な変更とスコープクリープでした。 ATDD アプローチでは、開発者がストーリーに取り組み始めると、要件が固定されることが不可欠でした。 どんな変更も、他の予定されているストーリーと並行して優先順位をつけ、次のスプリントに追加されなければなりません。 これは、開発者とテスターの両方の仕事量を減らし、利害関係者が完成した機能に対して非現実的な期待を抱くのを防ぐものでした。 その結果、定期的な実験とフィードバックの後、元のチーム全体がこのアプローチを使用するようになりました。
Conclusion
私は ATDD のアプローチを推奨し、開発とテストは SDLC においてできるだけ早く開始すべきであるという「左遷パラダイム」に合致しています。 SDLC の初期に自動テストを書き始めたので、自動化への可視性が高まり、その結果、チーム内の協力体制が強化されました。
ソース
ATDD は「1 サイズ フィット オール」ソリューションではないことを覚えておいてください。 私のプロジェクトのコンテキストで最も理にかなっていたのはアジャイル アプローチでしたが、チーム内のプロセスを改善する方法は他にもいろいろあります。 私がこのアプローチを採用したのは、より良い受け入れテストに焦点を当てたからですが、それ以上に重要なのは、コラボレーションに重点を置いたからです。
著者について
Raj Subrameyer氏は、技術キャリア戦略家として、人々が夢の仕事に就き、成功したリーダーになることを支援することに焦点を当てています。 そのため、このような「掟破り」のような、「掟に縛られない」「掟に縛られない」「掟に縛られない」生き方が求められています。 ハイテク業界での経験を生かし、私たちがいかにしてテクノロジーを受け入れ、完全なデジタル市民になれるかについて研究し、講演や執筆活動を行っている。 彼は、さまざまなカンファレンスで人気のスピーカーであり、CEOWORLD Magazine、Authority Magazine、Career Addict、Thrive Global、Addicted2Success、The Good Men Projectなど、数多くのポッドキャストや出版物で紹介されています。 また、新刊「Skyrocket Your Career」の著者でもあります。 専門分野は、キャリアアップ、リーダーシップ、モチベーション、生産性、起業家精神など。 余暇には旅行とクラフトビールを楽しんでいる。 彼のウェブサイト
では、どのように人々にサービスを提供しているか、より多くの情報を得ることができます。