<< 前 ホーム 次 >>

bakaid: 201004151

@gdgdilerのほうにも書いたけど、不具合の津波の話。

リリース近くにテスト期間を設けるっていうのはよく
あるし、それが悪いっていうわけじゃなくって。

ただ、テストっていうのは不具合を見つけるためにやる
もの (by @m_seki) であるから、基本的には、どれくらい
不具合が出るか予測できない。で、実際にテストしたら
ドッと不具合報告が来るなんていうのがよくある。この
『ドッと来る不具合報告』を『不具合の津波』と呼ぶ
ことにしたわけね。

で、当然、不具合の津波っていうのはいろいろと具合が
悪い。リリース間近だから時間的な余裕がない。余裕が
ないとヤッツケの修正をしてしまいがちになる。さらに
余裕がないから、修正の確認も十分にできない。だから、
いつまで経っても不具合が収束しないっていう悪循環に
なりやすい。

それと、いつもいってるように、突発的な不具合って
いうのは、将来に対する負担になる。リリースが近いと
いっても、その裏では次のバージョンの開発が進んで
たりするわけで、でもリリース間近なほうに不具合が
出たらそっちを優先して対応しなきゃいけないわけで、
次のバージョンの開発が遅れちゃう。それで次のバージョン
のスケジュールもキツキツになってと、これまた悪循環に
なりやすい。

で、不具合の津波をなくすっていうか、波の高さを
ならす、平準化しないといけないわけで。

だから、結局、テストは頻繁にやるしかないっていう
結論になる。TDDみたく自動化テストでもいいだろうし、
ドッグフードを食べるのもいいだろうし、忍者式テスト
(by @m_seki) みたいなのでもいいだろうし。とにかく、
テストを日常的な活動の一部にする必要があると。

cf. 忍者式テスト:http://www.jasst.jp/archives/jasst04/pdf/A7ah.pdf

--

だから、こうやって考えてみると、古典的な開発手法って
いうのは、各工程 (と呼ばれるもの:いわゆる計画とか
分析とか設計とか実装とか試験とか) をそれぞれ一回
(あるいは数回) しかやらないところが一番ダメな
ところなんだなぁと。

それぞれの工程は独立したものじゃなくって、相互に
フィードとフィードバックし合うっていうか、それが
自然な姿であって、ムリヤリブツ切りにするほうが
不自然なんだなぁと。

本家Permlink

<< 前 ホーム 次 >>


Copyright © 1905 tko at jitu.org

バカが征く on Rails