shin1が最近読んだ記事

私達はスクラムを利用したアジャイル手法を提案し、顧客の密な協力、オープン・コミュニケーションそして少しずつ開発していくことに集中しました。

顧客の密な協力

いくつかのイテレーションの後、これらの機能について’可能な限りの’見積もりを作成することでこの問題を解決しました。その頃には、自分達の開発速度について確信の持てる精度の情報を蓄えていました。従って、作成したバーンダウン・チャートを使うことでプロジェクトの状況の追や、進捗状況の共有がとてもよく出来ました。このことで学んだのはどんな見積もりでもないよりはマシということです。例えほとんど情報が入手できないとしてもです。

そうかな「どんな見積もりでもないよりはマシ」と言えたのは、その前にある「いくつかのイテレーションの後」だからではないかな。

どのようにして複数の拠点からなる1つのチームで共同作業をしたのでしょうか？まず、私達はSkypeを徹底的に使いました。ウェブカム、ヘッドセット、優れたマイクそして大きな画面を確保しました。こうして私達は全体会議と同様に1対1の会議も行うことができました。全て手元にあったものとフリー・ソフトだけで実現できました。停電の場合でもSkypeのセッションが継続できることを保証するためにインド側のネットワークにUPSを設置した以外、特別な投資は一切不要でした。

顧客だけではなく、チーム内での対話も重要。ちなみに、「スケール・アップ」と見出しにあるが、ここは「スケールアウト」か「スケールアウトしつつスケールアップ」みたいな書き方の方が適切なんじゃないかなぁ？

私達は単体テストと受け入れテストという2つのレベルでテストを自動化しました。前者に対してはJUnitを使い、カバレッジの測定にはCloverを使ってサーバ・サイドのコードに対して80%のカバレッジを目標にしました。受け入れテストはFitNesseを使って自動化しました。実装された全てのユーザ・ストーリーに対して受け入れテストがFitNesseで記述されました。詳細なテスト・スイーツがあることで、デグレは通常スプリントの最中に発見して潰すことができました。このアプローチのもう一つの優れた点はテスターがスプリント開始当初から有効に機能するということです。ユーザ・ストーリーの実装の前にテスト・ケースを作るのです。

テストファースト。まぁそれは置いといて、海外ではFitnessが結構メジャーなんだよなー。嫁さんが3年か4年ほど前に調べていたようだが、あんまり情報が無くて断念した記憶があったんだけども。

そこでユーザ・インタフェースの機能については大きく手動によるテストに依存することになりました。システムが大きくなるに連れ、リグレッション・テストにどんどん時間がかかるようになりました。さらに悪いことに、外部のテスターはシステムのこの部分にだけデグレを発見したのです。テストが自動化されていればこれは防げたかもしれません。このことで学んだことは、時にテストの自動化は難しいこともありますが、プロジェクトが進めば必ずや元は取れるだろうということでした。

いつも、最後にこの結論になるが、皆ちっとも学ばないんだよな。自動化にこだわりすぎるのも問題だけど、UI自動化だって手段はあるんだし、こうなる前に仕組みを持っておくべきだろう。