１．ソース管理システムを使っている？
CVS 等のこと。これがないと複数のプログラマの作業を調整することができないし、
バージョンを戻したりとか、複数のバージョンを管理したりとかいったことが
できない。
２．１ステップでビルドできる？
１ステップで、スクラッチからビルドして、ダウンロードサイトだろうと
CD-ROM のインストールだろうとリリースできるものができるということ。
#ifdef や各国語バージョンもすべて作成できなければならない。
３．デイリービルドしてる？
デイリービルドすることによって、ビルドできないソースを放置することが
なくなる。いい方法は、昼休みにデイリービルドし、うまくいけば昼休み後に
みんなが最新のソースをチェックアウトし作業を続ける。失敗したら、
チェックアウトせずに以前のソースで各々作業を続ける。もちろん、ビルドが
うまくいくように修正作業もおこなう。
４．バグデータベースはある？
・バグを再現する手順
・期待される（正しい）ふるまい
・観察される（バグの）ふるまい
・誰に割り当てられているか
・修正済みか否か
この５つは最低でも管理しなければならない。Bugzilla を使うとよい。
５．新しいコードを書く前にバグを直してる？
バグを直すのが遅ければ遅いほど、時間もコストもかかるので、できるだけ速く
修正するということだ。また、バグがなければ、直ちにリリースすることだって
できるのだ。
６．アップデートされてるスケジュールがある？
デモや広告など、ビジネス上の計画を立てるためスケジュールは必要だ。
また、スケジュールを立てることによって、実装すべき機能を明確にしなればならず、
それにより、あまり重要でない機能を先に実装してしまうなどということを
避けられる。
７．仕様書はある？
アジャイルな開発手法だと仕様書がないというか、実装しながら
設計していくというやり方のようだが。。。
いずれにしても、いきなりコードを書き始めるというやり方はまずいのだ。
最初から実装レベルの細かい仕様書を作る必要はないし、作れないだろうが
おおまかなレベルの仕様書は書く必要がある。
８．プログラマは静かな環境で働いてる？
ゾーン（集中状態）に入るには時間がかかる。よって、静かな環境で
働く必要がある。理想的には個室ということだが、なかなか難しいかな。
９．手に入る最高のツールを使ってる？
プログラマがストレスを感じないようにするということだ。
よりよいツールを使えば、生産性も上がる。
１０．テスタはいる？
TDD を実践してるときは、少なくとも単体テストはプログラマがやるだろう。
統合テストやユーザビリティテストでは、より時給の安いテスタを使え、って
ことだな。
１１．採用前にコードを書かせてる？
当然のことだが、なかなかやってるところは少ないかな。
履歴書と世間話で決めてるところが大半かな。
１２．ユーザビリティテストをしてる？
GUI プログラムではこれが重要。ユーザビリティによってユーザに
受け入れられるかどうかが決まってくる。
いわゆる『廊下でのユーザビリティテスト』で十分。５人に使ってもらえれば
９５％の問題点は分かる。
No comments:
Post a Comment