なぜ測定するのですか？
プロジェクトがあります。 愛する、愛する、あなたが成長し、繁栄したい人へ。
しかし、この繁栄の基準がない場合、その繁栄をどのように評価しますか？
「次のFのセンサー」を使用しない場合、問題が解決不能になる前にどのように迅速に対応できますか？
問題の原因がわからない場合、改善すべき点をどのように理解しますか？
要するに、プロジェクトを効果的に管理するためにメトリックが必要です。問題を診断し、ローカライズし、修正して、問題を解決するために選択した方法が本当に役立つかどうかを確認します。
さまざまなタイプのメトリックを共有します。それぞれがテストされており、かなりのメリットがあります。 それらを紹介するたびに、どのチームも非常に怠andで不快です。追加の情報を保存し、そこで何かを測定し、官僚を育てなければなりません。 しかし、メトリックから初めて恩恵を受けると、怠inessは規律と特定のメトリックの重要性に対する深い理解に置き換わります。
そして、彼らが来なければ、メトリックは安全に捨てられます;）
ストーリー1：誰が彼をここに入れたの??
ある偉大な会社では、経営陣が「低品質の製品」について不満を言っていましたが、その欠点はテストにありました。 私の仕事は、この迷惑な誤解の原因を分析し、何らかの形でそれらを解決することでした。
タスク＃1が明らかになりました： ミスしたエラーの％を推定します：テスターが何かを見逃しているのは本当ですか？ これを行うために、バグトラッカーの「クライアントから報告された」フィールドに入力し、この方法で古いバグをマークしてカウントしました。 割合は5％をわずかに上回っていましたが、どれも重要ではありませんでした。
それはたくさんですか、それとも少しですか？ 私の経験では、これはかなり良い割合です。 では、テスターが多くの点で見逃しているのはなぜですか？
もう1つのフィールド「リリースバージョンで再現」を導入しました。 テストベンチから新しいエラーを登録するたびに、テスターは最新のユーザーバージョンにあるかどうかを確認しました。ユーザーは特定のエラーを報告しなかったのでしょうか。 最初の月の結果- バグトラッカーに登録されたエラーの約40 ％がリリースバージョンで再現されます。
本当に多くのことを見逃していることがわかりますが、ユーザーは特定のエラーを報告しませんが、「あなたのソフトウェアはダメです！」という意見が明らかに形成されています。 したがって、メトリックセンサーを形成しました。何が問題なのか：
- リリースバージョンエラーの欠落率
- ユーザーがエラーを報告した割合
私たちは目標を設定します（それ以外の場合、なぜ何かを測定する必要があるのでしょうか？）！ リリースバージョンにヒットするエラーの10％を超えないようにします。 しかし、これを確実にする方法は？ リソースを過度に拡張しますか？ タイムラインを増やしますか？
この質問に答えるには、さらに掘り下げて、この質問に答える新しい指標を探す必要があります。
この場合、見逃したすべてのエラーについて、「スキップの理由」というフィールドをもう1つ追加しました。 そして、以前にこのバグが発生しなかった理由を示します。
- 不明な要件（必要であることを知らなかったか、理解しなかった）
- テストを考慮に入れなかった（SOをテストすることを考えなかった）
- テストされていません（テストはチェックされましたが、機能が壊れたため、このエリアは再度チェックされませんでした）
このアルゴリズムを使用して、私はすでに多くの企業で脱落の原因を研究しており、結果は常に異なります。 私の場合、テスト担当者はテストを考慮していなかったため、エラーの60％以上が見逃されていました。つまり、テストする必要があるとさえ考えていなかったためです。 もちろん、あらゆる面で取り組む必要がありますが、パレート法に依存して60％から始めました。
「この謎を解決する方法」をブレインストーミングすることで、さまざまなソリューションが得られました。テストグループの不足している欠陥についての毎週の議論、アナリストや開発者とのテストの調整、ユーザーとの環境や条件を研究するための直接コミュニケーションなど これらの新しい手順をゆっくりと導入することで、わずか2か月で、見逃したエラーの割合を20％に減らしました。 チームを拡大するのではなく、タイムラインを増やすのではありません。
まだ10％には達していませんが、7月には14％でした。すでに目標に近づいており、実装者の保証から判断すると、顧客は品質の変化にすでに気付いています。 悪くないでしょ？
ストーリー2：fireはどこから来たのですか？
このストーリーは、私自身のプロジェクトの1つに関するものです。 私たちはひどく必要で有用なサービスを開発していますが、開発スケジュールは私の心を温めませんでした。 当然、私のプロジェクトのすべてがテストで非常に優れていますが、なぜ開発はほとんど織り込まれていないのですか？
当然、私は主観的な感情を「ゆっくり」測定することから始めました。 これを理解する方法は？ 比較対象 1か月あたりのKLOC 反復する機能？ 計画に関する平均内訳は？ 当然、最初の2つのメトリクスでは何も役に立たないため、機能の内訳の内訳を調べ始めました（反復には固定された機能セットがないため、深刻な遅れはありません-2週間で何とかテストしてから投稿します）。 しかし、機能！
彼らによれば、私たちは条件を平均1.5-2回混乱させることが判明しました！ Redmineからこの情報を取得するのに何がかかるかはお話ししませんが、ここではそのとおりです。 そして、「5」「なぜ」という原則を使用して、さらに掘り下げていきたいと思います。 なぜそう 計画が下手ですか？ 結果が速すぎますか？ または資格が低いですか？ 時間がかかりますか？
私は分析し始めました：平均して、1つの小さな機能が15から40のバグを占めており、それらを修正するためには機能自体を開発するよりも時間がかかります。 なんで？ それはたくさんですか、それとも少しですか？ 開発者は、すでに開発された機能を変更するために多くの要求があると不満を言っています-これは本当ですか、または主観的な誤った評価ですか？
さらに掘ります。 私は、追加のフィールドから膨らんだ貧しい不幸なバグトラッカーフィールドに入ります：「エラーの理由」。 履歴＃1のように、つまり外観ではありません。 このフィールドは、開発者がコミットの際に、何をどのように修正したかを確実に知っているときに入力されます。 そして、答えのオプションは次のとおりです。
- コード（ここで入手して台無しにした）
- 要件の誤解（「ああ、何が必要か正確に理解できませんでした！」）
- 要件の変更（製品所有者は結果を見て、「本当に、それは違う必要があり、私が最初に要求した方法ではない」と言った）
コードに約30％のエラーがありました。 要件の変更-5％未満（開発者は驚きましたが、認めた-これは理由を示しているためです！）。 そして、エラーのほぼ70％は要件の理解不足が原因でした。 私たちの場合、バグ修正の開発に時間がかかると、機能の開発によって半分の時間が費やされます。
どうする
製品の所有者の要件を見つけ、数行で説明するすべてを詳細に文書化し、製品の所有者で終わり、秘書に転送し、24時間体制で新しい機能を文書化するテクニカルライターを雇うことから始まり、問題の多くの解決策を見つけました。 これらのオプションはどれも好きではありませんでした。同じオフィスに座っている4人の開発者のチームには官僚的すぎます。 したがって、次のことを行いました。
- 製品の所有者は、いつものように、新しい機能について簡単に説明します
- 開発者は、実装方法、実装方法、この機能で何をすべきかについて慎重に考えます
- その後、開発者とROは一緒に座り、開発者は開発中
の機能の明るい未来についての考えを詳細に伝えます - いかなる状況でも、開発者は上記のアクションアルゴリズムを経ることなく、ROとビジョンを調整することなく、新しい機能の作業を開始しません。
- テスターはこのプロセスに最も頻繁に参加し、テストする困難な瞬間を事前に促します
現在、週に3〜7人程度の1時間ごとの「話し手」がおり、2〜3人が出ています。 開始されたバグの数が減少し、そのうち50％以上がコードエラーになりました。したがって、次のタスクはコードレビューを導入することです。 現在、新しい「主な問題」があります。
しかし、アナライザーメトリックからは、センサーメトリックに戻り、春以降、機能の期限を50％以上見逃していなかったことに気付きました。その前は、平均内訳値は50％から100％であり、さらにそれ以上でした。
そして、これはほんの始まりです！ ;-)
歴史＃3：開発者を減速させているのは誰ですか？
別の話は、最近のサードパーティ企業での経験に関するものです。 真のアジャイル、毎週の繰り返し...そして毎週の締め切り！
同社の経営陣が述べた理由：「開発者は多くのバグを許容している」。
私はこれがどのように起こるか分析し始めました。 私はこのプロセスに参加し、今井の著書「ゲンバカイゼン」で非常にクールに説明されていたので、横から見ました。 そして、これは私が見たものです。新しいイテレーションの準備金曜日、木曜日にリリースします。 火曜日から水曜日に、テスト用のアセンブリがあります。 水曜日から木曜日に欠陥が始まります。 金曜日に、開発者は新しいイテレーションの準備をする代わりに、毎週バグを緊急に修正します。
私はタスクトラッカーで、ボードの機能が複製される場所を尋ね、機能のステータスを書き留めました：機能は開発のために受け入れられ、機能はテストされ、機能はテストのために送られ、改訂のために送られ、機能はテストされ、リリースのために受け入れられました。
また、「機能がテストのために提供された」と「機能がテストされ、修正のために送信された」までの平均時間はどのくらいだと思いますか？ 1.5日間！
そして時々-ブロッキング障害のみ。
この会社の開発者は、ブレーキテスターについて不満を述べましたが、テスターと管理者は開発者に反対しました。「あなた自身がテストする必要があり、生の製品を与えないでください。」 しかし、シーザーのシーザー！
そのため、1.5日は許容できないほど長いメトリックがあります。少なくとも3倍削減したいと考えています。これにより、リリースが1日早くなります。 どうやってやるの？ 繰り返しになりますが、ブレインストーミング、アイデアの束、プロセスの参加者の90％は、「開発者は自分でテストする必要がある」と主張しています。
しかし、最終的に、私たちはそれを別の方法で試すことにしました：開発者によると、機能が準備ができたらすぐに、テスターは彼と一緒に1台のコンピューターに座って、ペンでノートブックを持ち、チェック、コメント、ノートブック内の気づいたジャムを書き始めます。追跡。 このモードのバグ開発者の半分以上がその場で修正します！ 結局のところ、この機能は書かれているだけで、まだ頭に残っています！
期間を1.5日間から0.5日間に短期間で短縮しましたが、実際には別のより深刻な変更を達成しました。ステータス「改訂版送信」に移行した機能の割合は、ほぼ80からほぼ20に減少しました。 それは4回です！ つまり、機能の80％が「テスト」ステータスに移行した後すぐに受け入れられました。このステータスに移行する少し前に、テストがその場で実行されたため、エラーの登録時間と修正のコストが大幅に削減されました。
ちなみに、ストーリー3は、目標をすぐに達成した唯一のものです。 繰り返しの中断はまだありますが、今は例外です。ほぼ毎週木曜日、開発チームは時間通りに家を出て、金曜日に次の繰り返しの準備が始まります。
ビンゴ！
結論
私は本当に乾いた処方を描き、哲学し、理論化したくありませんでした。 私は新鮮な（2012！）経験から具体的な話をしました。 予算を変更せずに期限を短縮し、品質を改善したストーリー。
メトリックを有効に使用する準備がまだできていませんか？
それから私たちはあなたに行きます！ :)