TDDを試せる環境を用意する。これがなきゃ始まらない。
保存したら即実行、前提データの準備、UIの実行、時間をコントロールするライブラリー、モックライブラリー、Given, When, Thenのフレームワークなど道具を揃え、 すぐに書けるように準備する。
簡単なお題でRed Green Refactorを試して、体で体感する。
経験者による実演でTDD進め方を観て学ぶ
テストを書くことのリマインダー。
リズムを忘れないように。Red、Green、Refactorのステータスを確認しながら。ペアでやるとなおよし。
「先にテストを書く」の制約を緩めて、ちょっとづつテストする。書いたテストを参考に先にテストを書くを試す。
武道家の型の練習のように、体や頭が俊敏に反応するまで、練習を繰り返す。
学習パターン
TDDを学ぶイベントや研修に参加する。社内でTDDBCを自前で開催する。
リーダブルコードを学ぶ。設計原則を学ぶ。オープンソースを読そみ、参考となるテストの書き方を学ぶ。イデオムやパターンを学ぶ
１人では学べない複数人で学習する
工程ごとの見積りが、テスト実施しにくい場合。
時間外の自発的残業でテストの道具を揃える。書いてみる。ほどほどに。
上司の説得許可コスト抑えて開始する。
炎上プロジェクトでも、限定された時間枠内で試して、現場での知見を得る。出来る範囲で。
「割り込み」対策。個人で割り込みの優先順位の対話をできるようにする。チームで取り組んでいるなら別アプローチを。
ループを妨げる環境要因を徹底的に取り除く。テスト実行するまでの時間は？ディスプレイは？マシンは？フォントは？エディタは？机は？椅子は？ホワイトボードは？すぐに相談した人の場所は？テストケースを書く情報源のアクセス手段は？オンライン上の対話方法は？etc...
テストなし既存コードにテストを差し込んでからTDDを開始。最初の差し込み対象を選ぶ。
テストなし既存コードにテストを差し込んでからTDDを開始する場合に、優先順位付けする
相談できる同志 (Fearless Change)、協力を求める (Fearless Change)
１人では解決するには時間がかかるので、経験者アドバイスをもらう。
ついつい、現状に戻りがちなのを防ぐ
ペアでTDDの進め方を学び合う。異なるロールの目線でテストを書く
師弟関係でTDDの技能を伝承する。
１人TDDに熱中に注意。よい期待する振る舞い、ネーミング、設計、は１人では発見できない。
鏡の剣士。手動テストなどの現状を可視化し、次の現状把握、判断し、アクションを取る。
ビジネスサイドにも効果が実感できるとこから始める。頻繁にデモをするには、安心して既存の振る舞いを残しつつ新しい振る舞いを追加しつづけられる仕組み=TDD（Acceptance Testing, Unit Testing）が必要。
ビジネスサイドにも効果が実感できるとこから始める。
ビジネス側を巻き込まずに始められる。
TDDの新しい取り組みを実施するための時間を確保する。無駄なフィーチャ、無駄な会議など発見し対処する。
自動テスト実施までを「プログラミング完了」と、開発の規律を浸透させる。
テスト込みで実行可能な作業量を推測し、コミットする。
割り込み作業を整備する。
スプリント毎にゴミコードを吐き続ける防止策を練る。テストの道具を整える。テストを差し込む。
割り込みが入っても、誰かは集中して開発を続ける。
例えば、プログラマがテストコードを書く。テスターが複数のプロジェクトを渡り歩き、プログラマにテストの道具やTDDを指導できるようになる。
PO・顧客が忙しい場合。開発チーム側から代理を立てる。PO目線でテストパターンを開発者と一緒に書き出していく。ペアで開発する。責務を移動せよ。顧客代理の組み合わせ。
着手できるとこらから。ちょっとづつ始めよ。
リリース前とスケジュールプレッシャーがキツイなら別の機会を。
実際にソフトウェアが使われる現場に乗り込み、良質なテストパターン（本当に必要とされる、ソフトウェアの期待する振る舞いは何だろうか？）を発見する。
「割り込み」と捉えず、過去に発見できなったテストパターンを今まさに発見したと、歓迎する。優先順位が高いなら、テスト書くところから対処
バグ報告件数や手動テスト時間を測定し、次のアクションの判断材料にする。鏡の剣士
プロダクトをまたいで、良いテストの書き方のサンプルを参照できるようにする
複数人でテストの良い書き方について議論し、判断基準を揃えていく。
テストのコードレビュー