翻訳者から。 Habréには、TDDに関する記事が数多くあります。 しかし残念ながら、彼らは企業レベルでTDDを包括的に実装する方法についての詳細な情報を持っていません。 この記事でこれに対する答えが得られるように思えました。このような目標を自分で設定すれば、この記事は役に立つかもしれません。組織内でテスト駆動開発（TDD）を実装しようとするチームに出くわしました。 問題をよりよく理解するために、チームメンバー間で調査を実施しましたが、トレーニングを行った後でも、多くの作業が残っていることがわかりました。 この戦略は、だれでも組織にTDDを実装できるように設計されていますが、アイデアの中には中規模および大企業にのみ適用されるものもあります。
チームメンバー（全員がトレーニングを受けた）に関する私の調査により、次の問題が明らかになりました。
- TDDをあまり経験していない場合、人々はTDDを単独で使用するのが困難です。
- 実際のシステムとは異なり、簡略化された例がTDDトレーニングで使用されます。
- 定期的にソフトウェアをリリースする必要がある管理者からの通常の圧力なしで、実験と試行に時間がかかります。
- Visual BasicやJavaScriptなど、実世界で使用されている言語がありますが、これらは例として使用されることはありません。
- 典型的なプロジェクトはレガシーコードでいっぱいですが、このコードを改善する方法は説明されていません。
- そして、いつものように勉強する時間はありません-製品を生産する必要があります。
主な問題
これらの症状に基づいて、主な問題は何ですか？
テスト駆動開発は習得が困難です。 学習段階（根付いた習慣になる期間）は、通常2〜4か月続き、その間生産性が低下します。 最終的に、
利点は明白であり、TDDは単独で使用されますが、問題はこの時間を表示する方法です。 多くの開発者は数日でgiveめます。
私が見たほとんどの実装戦略は、教室での活動（またはeラーニング）と1対1のメンタリングに焦点を合わせています。 よくやった、彼らは確かに彼らの目標を達成しますが、私はもっと多くが必要だと思います。
教室での指導には2つの重要な問題があります。例は単純すぎて、実際の問題に関係していないため、実際にこれを試す機会はほとんどありません。
インタラクティブな学習が優先されるため、トピックを深く掘り下げることができますが、実際にすべてを試す機会はまだ十分ではありません。 さらに、これらのコースは通常、他の学生との交流なしで開催されます。 クラスメートや同僚から質問を聞いた後、自分で理解できるようになることがよくあります。
1対1のメンタリングは、同じチームの複数のメンバーと同時に作業することを除いて、スケールしません。 これは、少数の専門家と数百人または数千人の人しか助けを必要としない大企業の環境では特に困難です。
本は素晴らしい選択肢ですが、エンジニアリングの実践に関する本を読むことを好む開発者はほとんどいません。また、この方法でTDDを学ぶ人でさえ大きな問題を抱えています。 オンラインコースのように、学習の問題は自分の肩にかかっています。
そして最後に、レガシーコードはすでに困難なタスクを何百倍も難しくしています。 開発者は、「これらの密接に関連するオブジェクトをどのようにテストできますか？ このコードは複雑ですが、このアルゴリズムを確認するにはどうすればよいですか？ „
一つのアプローチ
何が機能しますか？ これまでのアプローチには、深さの欠如とコミュニケーションという2つの重要な問題があります。 完全な戦略には、アプローチの組み合わせが含まれます。
- 教室での学習-開発者はTDDの概要が必要であり、教室での授業は依然としてほとんどの人にとって最良の選択肢です。
- オンライントレーニング-これは主要なアイデアを統合するのに役立ちます。ところで、トレーニングの過程でオプションのステップがある場合、これはそれです。
- 忍耐-あなたが計画したよりも時間がかかります。
- メトリクス-コードカバレッジツール（例： Emma 、 Cobetura 、 NCoverなど）を使用して、測定が良いか悪いかを示す1つの方法にすぎないことをチームメンバーに説明します。明らかに、これはテストの品質を測定するものではありません。結果は一粒の塩で取得する必要があります。
- インスパイアプライド-開発者は、クリーンでシンプルなコードとテストがどのように見えるかを知る必要があり、努力する価値があると感じる必要があります。 Bob MartinはClean Codeという本を書いたばかりで、それについてよく話しています。
- 管理-開発者は、TDDへの移行には時間がかかり、チームの速度が低下することを理解しているという経営陣からの明確な声明が必要です。 技術的負債の速度と蓄積と比較して、品質が重視されることを明確にする必要があります。 ほとんどの開発者は、「有用な」コードの生成、生成、生成を迫られています。マネージャーは、このステートメントを複数回繰り返す必要があります。 この声明が出される組織のレベルが高いほど、より多くの人々が耳を傾けます。
- ペアプログラミング-行き詰まっていて、次にどこに行くべきかわからない場合は、パートナーが助けてくれることがよくあります。他の初心者と一緒に仕事をするのも良いスタートです。
- コミュニティ-経験を共有するために組織（または都市）にコミュニティを作成しますTDDの使用方法を学習している他の人々とコミュニケーションをとり、お互いの成功と間違いから学び、TDDに必要な文化の成長を支援します。 新しいアイデアを共有する機会。
- Coding Dojo-小さな問題を一緒に解決する練習をする場所で、グループ内の問題を研究することを重視した安全なコラボレーション環境であり、必ずしもそれを解決するわけではありません。
- 読書セミナー-本から章を議論するために、8人以下のグループが定期的に集まります。
- コーチの定期的な訪問-チームが道に迷い、TDDの練習をやめると、正しい道に戻るのに役立ちます。 このような場合、1人または2人の単純なペアでチーム全体に再び感染する可能性があります。
この計画の中心となるのは、継続的なコミュニケーションを作成し、TDDを中心としたコラボレーションを拡大することです。 これらの戦略のうち、ペアプログラミング、
コーディング道場 、リーディングセミナーの3つがこの分野に集中しています。
コーディング道場
コーディングDojo（Randory形式を使用）は、小さなグループ（15人以下）がTDD（
Danilo Satoから適応）を使用して問題を解決するイベントです。
- 作業はプロジェクターと同じコンピューターで実行されます
- エンコードはペアで行われます
- カップルのメンバーの1人が5〜10分ごとに切り替わります（すべてが7分間正常に機能していました）。
- 開発者は、視聴者が「キーボードで」何が起こっているのかを理解できるように、彼らが何をしているかを説明する必要があります。
- 視聴者は、テストに問題なく合格した場合にのみデザインにコメントする必要があります。
- 聴衆が混乱している場合、作業は停止し、開発者は何が起こっているのかを説明する必要があります。
経験から、最初は非常に小さなタスクを選択することをお勧めします。
読書セミナー
セミナーを読むために利用できる多くの本があります。
通常、チームはセッションごとに1〜2章を処理します。 ペースは、人々が仕事以外で読むのに十分遅い。 さらに、彼はこの章のいくつかのポイントの詳細な議論に十分な時間を提供します。
共同学習の利点
セミナーにはピザ（またはその他の食べ物）が必要です。仕事と似たようなことをするために個人的な時間を過ごすように人々に求めるため、インセンティブが必要です。 2つのワークショップは交互に行うことができるので、人々は1つのことにこだわっていると感じることはありません。 そして、グループが会議から会議まで一定であることを期待すべきではありません。
グループのメンバーはお互いにコミュニケーションを取り、利益を得るため、ワークショップとコミュニティは自習よりもはるかに役立ちます。 その結果、私たちは決して到達しなかったものについて学びます。
TDDを習慣にする
一般的に、これらはキーです。 それらは、成功する実装戦略の作成に役立つと思います。
- 忍耐、練習、深さ
- 管理サポート
- 多国間アプローチ
- 開発者は開発者を支援します