TDDを開始するのはいつ？

みなさんはTDDをどのようなタイミングで開始していますか？

私はアーキテクチャが決まり、
テストフレームワークの環境構築が出来てから

だと思っています。

そんなの当たり前　と思う方もいると思いますが、
この「テストフレームワークの環境構築」には、
アーキテクチャの雛形ソースや
テストの為の実際のサンプルコードや例などが
いくつか出来ている状態までを含んでいます。

 ここまで出来ていないと
恐らくTDDは難しいと思っています。
ここまでの環境が無いと
何から手を付けてい良いかが分からないですよね。

つまり、
環境が無い状態では、ＴＤＤは難しい
という事だと思っています。

昨今の顧客要求＆論理量では
いきなりテストを作る　といってもなかなか難しいですよね。

なので、いかに早い段階でアーキテクチャを決定し、
開発で使用するテストフレームワークを構築するか

が最大のポイントであり、プロジェクト成功の鍵である。

と思っています。


ですが、このアーキテクチャ決定と
テストフレームワーク構築が
難しいのでしょう。

難しいというより、やるべき事なので、
簡単とか難しいとか考えた事は無いですが、
やはり、これも昨今の要求の複雑化の影響だと思いますが、

この2つが難しい現状である事は間違い無いと感じています。

みなさんは、どのタイミングでＴＤＤを開始していますか？！

XPはやっぱりすごい！

今更ですが、
eXtreme Programmingは改めてすごい！！

「運転で大切なのは，車を正しい方向に進めることじゃないのよ
　大切 なのは、常に注意を払って
　細かく左右に方向修正していくことなの」

これ、とっても、良い表現ですよね。
最初に読んだ時、かなり衝撃的だった。

社内でXPの推進を始めて、既に10年以上となりますが、
改めて、関連書籍を読み返しても、当時の衝撃が復活してきます

XP自体は、開発手法ですが、
プロジェクト管理も同じだと思う。

日本では、「かもしれない運転」を教えられるが、
まさに、
「大切 なのは、常に注意を払って
　細かく左右に方向修正していくこと」
に尽きる。

プロジェクト管理は「かもしれない運転」を促すだけ。
そして、左右確認などを、キチンと実施している事をチェックする

車は来ないだろう
分かっているだろう
などはなく

車が来るかもしれない
分かっていないかもしれない（勘違いしているかもしれない）
というアプローチを絶えず実施する必要がある

これを実施する事で、
開発チーム内、顧客　の両面で認識違いによる無駄な後戻りがなくなり、
顧客満足度に貢献出来る。

更には、
「かもしれない運転」（確認する事)でコミュニケーションが円滑になり、
開発チーム内、顧客共にメタファが生まれる

メタファが生まれると、後は、確認の手間も軽減され話が早くなる。

あとは、課題の気づきや
スモールリリースなどでお互いに信頼関係が生まれ（顧客含めて）、
信頼がリスペクトへと成長すると、
顧客含めたeXtremeなチームが誕生する

素晴らしいぃ～！！！！

eXtreme ProgrammingはやっぱりeXtremeだね！

なぜリボンか？！

つい先日、「なぜ、リボンなの？」
という質問がありました。

理由は、
いろいろ考えて、いちばんピッタリきたのがリボンだった
という事なのですが、

拘っていたのは、

1)ぐるぐる回るイメージ
2)スパイラルとかプロトタイプとは違うイメージにしたい
3)中心は単体テストとリファクタリングでぐるぐる回る
　小さな改善を繰り返すイメージを強調出来る絵にしたい
4)コーディングという工程は削除する
5)外側（リリース）から、また中心に戻る絵にしたい
6)コンセプト共有という上流工程を強調したい
7)ぐるぐる回るけど、基本的に一つ前には戻れる絵にしたい
8)必要なところ（工程）には、戻れる絵にしたい
9)V字は、なんだかんだ言ってかっこいいので、
　V字よりカッコイイ、アートで美しいイメージの絵にしたい！
10)マコネルの「アートなXX」という表現が好き


と、なんだかけっこう多いですね....

これらに拘り、いろんな絵を書きました。
ぐるぐるした絵をいっぱい書きました。

そして、いちばんピッタリきたのがリボンだった
という事です。

組込みとTDD

振り返ってみると、私も長い間？　独自ではありますが、
単体テスト（xUnit）に取り組んでいます。
そのほとんどが組込みですが、なかなか浸透していないですよね。

ですが、最近は、組込み業界にも
テスト駆動や単体テスト処理実装の流れが押し寄せているように感じます。

この流れから、リーンやアジャイルの単なるやり方ではなく、
コンセプトがフォーカスされる事を強く望んでいます。
というより、微力でも、私にも何か出来る事が無いかと模索しています。

単体テスト処理実装＆全単体テストの自動実行
とイテレーション型開発、
更にはMVP（Minimum Viable Product）は切っても切り離せないですからね。

私は、単体テスト処理の実装とリファクタリングを繰り返す
リボンモデルを社内で浸透させるべく活動していますが、
組込みは派生開発も多く、
途中から単体テスト処理を実装する事の
大変さというか、
空しさというか、
やり切れない切なさを実感しています。

そこに更に、リファクタリングなんて無理！
という現場の心の悲鳴を強く感じています。

しかしながら、一方で、
単体テスト処理の実装とリファクタリングを繰り返す事で、
高品質を維持する事が実現出来ている例もある　という事で、

何をやるか　というより、リボンモデルの基本の考え方
（単体テストとリファクタリングの繰り返し）
が、社内で広く浸透する為に、なにをすべきか

と、試行錯誤しています。