Ryuzee.com

Joel on Softwareによるソフトウェア開発チームの評価について、あちこちでエントリがあったので便乗。
このテスト、12項目あるが、12点は完璧、11点は許せる範囲、10点以下だったらその組織は深刻な問題かかえている、とかいってしまう厳しいテストだ。
はてなは12点満点。
アプレッソは10点

ちなみに自分の所は、１，２，４，５，６，７、９、１２で、８点。ちょっと甘目かも知れないけど、いま目指している所で、順次適用中なので、そのように採点してみた。
ただ、大事な事は、「成し遂げたい目標のために、今何をやるべきか、この先何をやるべきかを決めたら、腹くくってやり続ける」ってことだ。色々な本に色々な事が書いてある。同じことが書いてある場合もあれば矛盾する場合もある。でも一度決めたら自分が納得して良し悪しが分かるまで徹底的にやるしかない。中途半端にあちこち齧っては方向転換を繰り返すような組織ではいかん。

1. ソース管理システムを使っているか？
2. １オペレーションでビルドを行えるか？
3. 毎日ビルドを行うか？
4. 障害票データベースを持っているか？
5. 新しいコードを書くまえにバグを修正するか？
6. 更新可能なスケジュール表を持っているか？
7. 仕様書を持っているか？
8. プログラマは静かな労働環境にあるか？
9. 買える範囲で一番良い開発ツールを使っているか？
10. テスト担当者はいるか？
11. プログラマを採用するときにコードを書かせるか？
12. 「廊下での使い勝手テスト」を行っているか？

1. ソース管理システムを使っているか？

使っている。Subversion。少なくとも最近全案件で必須にしていて、ソースだけじゃなく、ドキュメントやテストコードも対象範囲にしているから、まぁ問題ないだろう。しかし一方で静的サイト構築案件をやっているチームだとこれが出来ていない。自分の管轄ぢゃないけど、いつもデグレしたとか、大騒ぎしている。

2. １オペレーションでビルドを行えるか？

DBに初期データ登録して、設定変更して、どうのこーのして、みたいなことは順次止めている。昔の協力会社が作った糞なソースなんて、IF文で、快活環境だったらこっちに繋げて本番環境だったらあっちに繋げるみたいな記述があって、本番用にはコンパイルしなおす、とかいう驚愕の実装があったな。最近は、デプロイ⇒即稼動前提にしているし、初期データの投入もインストーラ化しちゃうから問題ないだろう。

3. 毎日ビルドを行うか？

そもそも俺らはスクリプト系ばっかだ。ビルドって概念は無い。まぁ毎日自動回帰テストするかどうかって聞かれればしていない。CruiseControlとかPHPUnderControlとか使うと良いのは分かっているが、まだ出来ていない。

4. 障害票データベースを持っているか？

Tracで全部管理。新規要望も不具合もTracに突っ込んで、チケットドリブンで開発。沢山のメールに追われてどの不具合が直し終わった/終わってない、とかの苦労をすることはなくなっている。個数が見えると減らしたくなるのが人情だ。

5. 新しいコードを書くまえにバグを修正するか？

そりゃそうだよ。テストコードが全部書けているわけではないところが痛いところだが。

6. 更新可能なスケジュール表を持っているか？

普通にある。まぁたまに納期だけ先に決まったスケジュールがあるが、そういう場合は実装機能を減らす。それも許されなかった案件があるが、品質はとてつもない。もうそんな経験はしたくないな。

7. 仕様書を持っているか？

普通に概要設計、詳細設計、テスト仕様書・・・と揃っているものもあれば、テストコードだけが揃っているものもある。但し仕様書は所詮中間生成物なので、個人的には大量なものは要らないと考えている。設計の思想と、本当に重要な箇所だけに絞れば良い。あとはテストコードが仕様を明らかにしてくれる。

8. プログラマは静かな労働環境にあるか？

こりゃダメ。とにかく電話が鳴りすぎ。思考を中断されると、生産性は格段に低下する。家でソース書くと会社の数倍のパフォーマンスは出るな。

9. 買える範囲で一番良い開発ツールを使っているか？

これは口をすっぱくして言っている。人的コストが一番高いのだから、生産性をあげるためには、必要な道具は揃えるべきだ。僕のところだと、全員パソコン２台以上、メモリも増設、デュアルディスプレイもOKで、20インチ以上の環境。良いものが出たらどんどん買い換えている。
開発ツールは、Eclipseとか、Subversionとか、デファクトスタンダードに揃えている。

10. テスト担当者はいるか？

この間やった案件ではいたんだけどね。ひたすらSeleniumでテストを記録しては、デイリーで実行したり、モンキーテストしたり。ただ全部の案件でやるのは無理だなぁ。テストはテストのための能力が必要だとは思う。

11. プログラマを採用するときにコードを書かせるか？

これやりたい。けどやっていいのかなぁ？一応ブログの有無は聞いている。アドレスは聞いていないけど。でもやっぱり会社のためにも本人のためにも、お互いが理解しあった上で採用した方が良いとは思う。人事と親分に相談してみるか。

12. 「廊下での使い勝手テスト」を行っているか？

まぁやっているように思う。俺なんかは特に、作ったものは直ぐ見せたい人だし。

参考文献

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
著者／訳者：Venkat Subramaniam Andy Hunt
出版社：オーム社( 2007-12-22 )
定価：￥ 2,520
単行本（ソフトカバー）
ISBN-10 : 4274066940
ISBN-13 : 9784274066948

このエントリは参考になりましたか？

よろしければ5段階評価で該当する☆をクリックしてください。

“ジョエル・テストによる現状分析”へ2件のコメントがあります。

• masayang 2008/08/29

  Agile2008(や、過去のAgile Conference)では、テスト担当者を置く、という事に否定的なんですよね。

  自分は、「テスト記述は開発者の責任」と思ってます。

• Ryuzee 2008/08/30

  ＞masayangさん

  単体テストやモックオブジェクトによるテストは開発者が記述するのは全面同意なんですが、普通のSIで言うところの結合テストや総合テスト、さらにはユーザビリティテストとか、そういうのはどうするのが普通なんでしょうか？

コメントする

Name (required)

Mail (will not be published) (required)

Website

XHTML: 以下のタグが利用可能です: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback