2006年02月24日
これが現実なのかもなぁ
@ITの「テストファーストでユーザーも開発者も幸せに」の記事
ちなみにこのアーキテクト塾でさり気無く（ってか堂々と）クロさんが出てますね〜最近は常時結合、TDDと言えばクロさんみたいなイメージになってきました（＾＾）
中盤からは著名人らによるパネルディスカッション記事になってるんですが、ちょっと意外だったのはひらなべさんのところでもテストファーストの実施率は全案件の1割程度、完全ピュアなテストファーストを実行したのは今まで1件だけ・・これが現場の実情なのかもなぁ。
そもそも導入による効果を明示化しないことにはなかなか理解は得られないということか
Posted by GAMMARAY at 2006年02月24日 12:17
| TrackBack
げげ、見つかっちゃいました。
まさか記録されているとも思ってなくて
色々ベラベラしゃべっちゃったので...恥ずかしいんですよね。この記事(-_-
#まだ読んでません
うーん、難しい話ですね。
私自身の（大規模開発の）現場の実感としては、テストファーストよりも先にまずやるべきことがたくさんあるだろう、と思ってます。
テスト計画の策定、テストケースの設計方法の学習、システムテストの項目や実施方法の検討、などなど。
その辺を抜きにして、まずいきなりテストファーストという、コーディング部分にフォーカスした施策だけをやたらと採り上げても、なかなか受け入れられにくくても仕方ないんじゃないかと思います。
いやだって、例えば UnitTest だけでマルチスレッドバグを潰せるかといえば No なわけで、全体的なテストの枠組みの中にテストファーストや xUnit/VSTS をどう組み入れていくか、という発想が重要なのだと思うのですが。
……とマジレスしてみるテスト^^。
私自身、お客さんに VSTS を薦める場合には、まずテスト全体の見直しも含めてお話ししてたりします。
> くろさん
いやいや、こうやって発信してくのは大事っすよ。
これからも伝道師としてどんどん発信していってください！
> nakamaさん
おっしゃるとおりだと思います。
私が今度社内で実施する勉強会も「現実的なアジャイル」をテーマにやろうと思ってますが、アジャイルだろうがなんだろうが、導入すれば全てがうまく解決される魔法の杖では決してない、まずは現状をしっかり認識、分析することこそが大事なんだってところを強調しようと思っています。
いつもROMしてます。
興味本位でコメントさせてください。
プロジェクトにとってのテストファーストの意義は、「仕様の確定責任を完全に設計者に渡す。プログラマは、これを積極的に放棄する」ってことなんだと思ってます。
（違ったら以下の議論は崩壊しますが＾＾；）
で、その結果、そのプログラマは将来、どういうふうに設計できるようになっていくんだろう、ってのを考えちゃいます。
若干、年寄りなもんで、何年かの単位で社員を成長させていかなきゃならん、って時に、（単に自分が経験していないからなのかもしれないけど）新しい開発方法論と、どう組み合わせてメンバーを成長させればいいか、ってのが悩みのタネなんです。
（先細る方法論もたくさんとおりすぎていくし。。）
参照している記事をみてて、実際にテストファーストを導入するかを判断するときに、議論の本質とは違うけど、こんなことも年寄りは考えていたりもします。
って感想文みたいですが、いちお、マジレス＾＾。
私見ですが、新人さんには最初はウォーターフォールでやってもらうのが一番良いかと思っています。
というのもまず一通りやってみて、そこで振り返ってからでないと、RUPにせよアジャイルにせよ、それらプロセスが提示している本来の意図って絶対に分からないと思うんです。
失敗してこそ気づくことや学ぶことがあると。
まぁだからといって最初は積極的に失敗しろとは言えませんが、往々にしてなにかしら失敗する部分ってあるでしょうしねぇ（＾＾；