形の美しさ、近さ、速さ、正確さ。
Kさんはこういってました。
yvsu pron. yas
ユーザの立場からすると、仕様書どおりに動いていることが品質が高いということではない。多少のバグがあっても、実際に使うエンドユーザが機能に魅力があると感じて、ビジネスとして成功することが、品質の高さにつながる。
バグだらけでどうしようもないプログラムならともかく、ある程度以上の障害発生率を確保できてしまえば、バグの実際の数と顧客満足度はあんまり関係しなくなってきますよね。
だいたいお客さんが「バグ少なくなったなぁ」って感じてくれるのは50%以上改善とかそのくらいからで、そんな改善を何年もずっと続けることができれば、今ごろこの世からバグなんて消えてるｗｗ
だからあくまで顧客満足度が大事な指標で、障害発生率はその中のパラメータの一つって感じてた。
僕もバグを減らしましょうってことより、バグが出てから改修版をリリースするまでの時間を如何に短縮するかの方に力を注いでいた。
これはリーダが指揮して、やり方そのものを変えないと短くならない。バグ減らすのなんてサブリーダが勝手にやってくれるから、なんもいわない（^^
この数字を上げてその次の戦略がプログラミングファーストだったんだけど・・その前に辞めちゃったけどね（^^
ほかのリーダで、バグの数よりお客さんがバグで仕事がストップする時間をMTBF使って見ていて、実績上げてる人がいた。その人が書いた論文は面白かったなぁ。
プログラミングファーストでは、ペアで開発するんだけど、ペアプロではなく、一人がプログラミングをしているときに、もう一人はテストシナリオを書く。そして、お互いにレビューしあう。これでより、品質を高められると思います。
yvsu pron. yas
プログラム開発とテストの距離が離れているとあんまり面白くなくって、より粒度の細かいところでペアにした方がいいんじゃないかって思ってたので、こういう考え方の人がいてくれてうれしい。でも「思います」って書いてあるってことは、実績はないのかなぁ?
僕も実際の開発でそこまでやったことないので気になってます。
以前、日記でシステムテストを別の協力会社が担当している場合の話を書いたけど、その頃、時系列的には少し前の話。
バグ一件のやりとりも会社対会社の話になっちゃて、あんまり効率よくなかったし、正直関係というか空気もよくなかった。
窓口決めてちゃんとやりとりしろとかいうのが当時の方針でテスト担当サブリーダだった僕がやってたんだけど、正直困ってね。
まず効率悪くて時間がかかるのが問題。
例えばバグ票受け取ったけど再現しません。テストやった人にさらに詳細な手順を聞いてみる。と、テストやった人にとってはバグ票書いたのは昔の話なので細かい手順はもう忘れちゃってます・・・と
自分がリーダになったときに、これは変えた。やっぱりバグ修正が滞ってきたので、テスト担当会社の人と一計を企てた。
システムテストを1週間、完全に停止して、その間、システムテスト環境でデバッグやります。テスト担当者もその間試験現場に来てデバッグやっている人に横からアドバイスしてください。と
システムテスト環境の充実したりソースでやりたいってこともあったけど、それよりプログラム担当とテスト担当がサシでコミュニケートするきっかけを作りたかった。
これは思いもかけずうまく行って、一週間でほぼすべて問題解決した。一週間っていったのはあくまで先方の都合でその期間に全部直るって、正直思っていなかった。担当者にちゃんとした実力を出させる機会を設けなかった僕のミスだった。
それから先は、基本的に担当者レベルでやりとりすることにした。リーダの仕事はバグ票受け取って、処理する担当者を決めることだけ。
普通、これくらいの開発だと、だれが担当するか決める為の障害切りわけ作業なんてのが入るけど、僕のチームではそんな役職置かずに僕の判断で決めるって合意は取れていた。
他のプロジェクトとスピード感は全然違う。実際担当者の負荷は増えているので作業時間は抑えるよう僕はブレーキ踏んでいるんだけど、それでもほかのプロジェクトより圧倒的に早い。
このやり方だと、途中に自社内のテスト担当が絡まないので逆にテスト手順の修正着手が遅くなっちゃうんだけど、どのみち修正方法の詳細わからないとテストの検討もできないので、むしろそれでいいでしょう、となった。
僕がやったのはここまで。だからその先が気になる。
