写真による診断：表とグラフを使用して製品の状態を把握します

大企業や新興企業内の製品の美しいアイデアは、ほとんどの場合、実装段階で多くの困難に直面します。 多くの場合、作業が進行し、バグが修正され、リリースが近づいていますが、製品の状態に関する一般的な理解はありません。 これは、ソフトウェアまたはサービスの作成者の独自の天才（特にスタートアップに関して）が彼らの目を捉え、製品の問題が適切に理解されていないために起こります。 その結果、最良の場合、チームはリリース日以内に収まらず、最悪の場合、実行不可能な製品が生まれます。ユーザーはそれを軽cornしてアルファを呼び出し、フィードバックフォームを通じてクリエイターにヘイトレイを送信します。



キャプテンエビデンスのヒント：これを防ぐためには、開発の各段階で製品の状態を理解できることが重要です。 この大きな記事では、最も視覚的な形式で表とグラフの形で彼の状態を評価するための方法論を提案しています。 ここでは、過去6年間の私の経験とParallels Novosibirskオフィスのチーム全体の経験をまとめています。 明確にするために、Parallels Plesk Panelを作成しています。これは、Webホスティングサービスを提供する世界のほぼ2つおきのサーバーで使用されるホスティングパネルです。 この手法を適用すると、次の結果が得られました。

1. （インシデント率に応じて）リリースされたリリースの品質を大幅に改善しました。
2. リリースがより予測可能になり、予測と予測の精度が大幅に向上しました。
3. 何かがうまくいかなかった理由と、将来それを回避する方法を理解しました。

カットの下やコメントで関心のある人に尋ねます。 ご質問にお答えします。



この記事は、オムスクでのQASib会議でのスピーチに基づいています。







大企業で働くという申し出に署名するか、スタートアップを作成することで、お金、成功、仕事からの評価を期待しています。 旅の初めには、すべてが美しく雲一つないように思われます。私たちはクールなソフトウェアや便利な機能を備えたサービスを考え出した天才であり、チームと多くの時間を費やしました。 成功への道は簡単で手間がかからないように見えます。



理解は、通常、リリースの準備中です。 問題が始まります：作業の一部を外部委託したサードパーティチーム、締め切りでダイナマイトし、チームの誰かが予期せず病気になった、実装中に考えられた機能がはるかに困難であることが判明し、選択された技術的ソリューションは最も成功していないようです。 さらに、あなたはバグの海にdrれており、将来のユーザーからの要件は常に変化しています。このリリースに突入する必要がある新しい超重要な機能が登場します。 このような背景に対して、人々の動機はゆっくりと溶けています。 これらの問題はあなたを飲み込み、リリースが行われるのを妨げる可能性があります。 その結果、「お金の袋」を見ることができません。 パニックからそれほど遠くはありません。



「誰が責任を負うべきか？」および「何をすべきか？」というよく知られている質問に対する答えは、必然的にあなたの手で収集されるデータを分析することによって得ることができます。 タスク、現在の進行状況、結果、見つかった問題、その他の有用な情報を何らかの方法で修正すると、製品のステータスを簡単に追跡できます。 納屋の本でプロジェクトの「ログブック」を維持する権利はありますが、APIまたは理解可能なデータベース構造を持つシステムにデータを保存することをお勧めします。 APIやデータベースを使用すると、情報に簡単にアクセスして解析できます。



Parallels Plesk Panelチームは、 TargetProcessシステムのタスクとバグを処理します。 このシステムには多数のレポートが組み込まれており、リリースに関する情報、その作業の現在の進行状況、完了したタスクと未完了のタスク、チームのロードとリソースのバランス、発見されたバグ、場所のダイナミクスなどに関する情報をすばやく受け取ることができます。 より詳細で多様な情報が必要な場合は、TargetProcessデータベースから直接取得します。



さて、今すぐ直接データとグラフに。



将来的に製品の状態を正しく評価できるようにするための最初のステップの1つは、一般的に計画したことをすべて実行できるかどうかを評価することです。

一方で、優れたチームと、顧客/製品所有者/プログラムマネージャーからの一連の機能があります。 これを比較する必要があります。



最初に、チームが消化できる工数（またはストーリーポイント、または「オウム」）を把握する必要があります。 たとえば、3か月のリリース期間が推定されます。 毎月4週間、毎週5日間、毎日8時間です（簡単にするため、休日は考慮しません）。 同時にチームは10人で構成され、3人は非常に生産的な人、5人は普通の従業員、2人はかなり長い間プロジェクトに取り組んできた新人です。 まとめると、チームは1回のリリースで約4000人時の総重量で作業量を消化することができます。



チームが何をしなければならないかを考えましょう：新機能のテスト-2200時間、バグのチェック-350時間、リリース終了時のリグレッションテスト-600時間、自動化-500時間、休日-160時間（チームの能力からそれらを差し引くことができます。必要に応じてここに置くことができます）、リスク-200時間（人の病気、「必須」マークが付いた予期せぬ新機能、他のチームによる遅延などが通常ここにあります）。 合計3800時間。 私たちは何とかして、適切な品質のリリースを保証しているようです。



かどうか？



しかし、チームの生産性がまだ行われている作業量よりも大幅に少ない場合はどうでしょうか？



いくつかのオプションがあります：

1. 黙って、すべてをそのままにしておき、それがどういうわけかそれ自体で決定されるか、人々の休暇、自動化、またはテストの一部を放棄すると考えられ、製品の品質の低下につながる可能性があります。 まあ、何？ OK！ 嫌いな製品に取り組んでいる場合や、破壊したいチームと一緒に作業している場合は正常です...このようなアプローチが業界で頻繁に使用されているのは残念です。
2. チームの生産性をプログラムおよびプロジェクトマネージャーに制限するというこの問題をもたらし、リリースの機能数の削減、またはリリース日を後日に変更することを実現する。 多かれ少なかれ聞こえます。 そして、あなたはこの状況に困難で興味深いテストとして関わり、3番目の方法に進むことができます。
3. 同じことを、より短時間で、より少ない労力で行う方法を考え出します。 理想的には、最後の2つのオプションを同時に使用する必要があります。

必要な作業量が、チームが消化できる作業量と相関していることを確認してください。 さて、またはあなたはこの問題を回避する方法について明確な計画を持っていました。



あなたの見積もりは、リリースバーンダウンチャートの基礎となります。



ロシア語に翻訳すると、バーンダウンは「地面に焼き付ける」ように聞こえます-これはこのグラフの意味とよく一致しており、完了した作業量と時間に対する残りの作業量を示します。



これでスライドが作成されます。





たとえば、3か月続くリリースのQAチームの作業スケジュールを考えます。



緑色の線は、各チームメンバーが資格とパフォーマンスに応じて毎日一定量の作業を実行する場合のリソースの理想的な使用率に対応しています。 青い線は、常に実行する必要がある作業量を示しています。



グラフは次のことを示しています。

• 最初の7日間はリリースタスクの計画と評価でした
• その後、約3週間、リリースの作業が行われました（青い線は緑と平行であるため、タスクは計画に従って実行され、最初の見積もりが成功したため）
• リリースの開始から1か月後、新しい機能の追加や人件費の再評価が原因である可能性が高い青色のラインアップが見られます
• 再び、計画どおりに進行しないタスクの作業を確認します（チームのいずれかの病気、他のチームの側での遅延、低品質の機能などが原因である可能性があります）。

これがリスクに固有である場合-優れている場合、そうでない場合-状況を修正するために何をすべきかを決定する必要があります。



そして、チャートの別の行である赤い点線は、最近と同じペースで作業を続けた場合にリリースが実際に終了する時期を示しています。 最近のタスクの実際の使用速度に基づいて、毎日再計算されます。



スケジュールは単純に見えますが、プロジェクトの現在の状況を理解するのに非常に役立ち、現在の状況に基づいて計画をタイムリーに調整できます。



便利なライフハック。 プロジェクトの一般的なスケジュールに加えて、開発用とQA用に別々のスケジュールを設定することは理にかなっています。 チームが大きく、サブコマンドに分割できる場合、各チームのスケジュールを維持することをお勧めします。 これは、プロジェクトのボトルネックを見つけるのに非常に役立ちます。 おそらく、プロジェクト全体をプルダウンし、飛び立たせないチームを見つけることさえできます。



多くの場合、質問があります：修正しますか？ 時間はありますか？ ここでの答えは、リリースで未解決のバグの数に関する情報によって与えられ、優先度ごとにグループ化されます。



バグごとに、優先度をp0からp4に設定します。ここで、

• P0-できるだけ早く修復する必要があります
• P1-反復/スプリントの終了前に修正する必要があります
• P2-リリースの終了前に修正する必要があります
• P3-時間があれば修理する
• P4-それ以外では、間違いなく生きることができます

例として、次のグラフを検討してください。





緑色の線は、開いているバグp0-p1の数を示しています。グラフから判断すると、すべてのバグp0-p1が修復されたとき、4週間と8週間が反復の終了であると想定できます。 これは、反復を閉じるための基準の1つです。



赤い線はそれぞれ、未解決のバグp0-p2の数を示し、青い線はリリース上の未解決のバグの総数を示します。



したがって、反復の開始時と途中でバグp0-p1のボリュームが非常に速くなり、反復の終了前にすべてを修正して修正を確認することができない場合、適切な決定を下す必要があります：バグの優先順位を変更するp1）、機能の一部を次の反復に転送し（バグ修正に自由時間を費やします）、すべてのバグp0-p1が修正されるまで反復を延長し、チームにリソースを追加します。



リリースの終わりに向かって、同じチャートに別の行を追加することは理にかなっています。 紫色の線は、開発者チームが修正できるバグの数を示しています。 つまり、リリースが19週の初めに行われる場合、開発者は18週に17週と18週に38個のバグ、16〜17〜18週に79個のバグを修正できます。 -147個のバグなど。

このようなスケジュールにより、開発者のチームがリリースの終了前に修正すべきすべてのバグを修正できない状況を予測できます。 これにより、事前に特定のアクションを実行できます。

• 優先順位を再設定するためにp1-p2バグをソートし、開発は本当に修正が必要なバグのみに焦点を当て、p3-p4バグとp1-p2擬似バグに時間を無駄にしない
• バグ修正に追加のリソースを引き付ける
• リリース日を後で変更するなど。

次に注目する意味があるのは、時間に対して検出および修正されたバグの数です。



この図は、3回の反復のリリースの例を示しています。2回の反復は新機能の開発であり、1回は製品の安定化です。





最初の反復のいずれかの作業時にこのグラフを見ると、現在作業中の機能の品質を監視できます。 たとえば、6週目に37個のバグではなく60個のバグを受け取った場合、これは、反復のこの段階で通常の2倍の問題を発見した理由を理解するためのシグナルとなります。



ほぼ同じことがバグ修正にも当てはまります。 たとえば、4週目と8週目に通常よりもかなり少ないバグが修復された場合、その理由を理解する必要があります。 バグはもっと複雑ですか？ または、バグ修正に割り当てられる時間が予想よりも少ないのですか？



製品の安定化の段階でこのグラフを見ると、製品をエンドユーザーに提供できる状態に持っているかどうかをすぐに確認できます。 答えは簡単だと思われます。見つかったバグの数が減れば、はい、増えれば、いいえです。 しかし、これは常にそうではありません。 このグラフは、見つかったバグの数に関する情報のみを提供しますが、バグの種類を示すものではありません。



同じリリースで検出されたバグの深刻度別の分布を考慮すると、終了日が近づいても見つかったバグの数が減らなくても、リリースが安定していることが明らかになります。





最新リリースで見つかったバグは、有効性の観点からはそれほど重要ではありません。先週、ブロッカーは完全に消え、批評家はほとんど姿を消し、見つかったメジャーなものの数は半分になりましたが、ノーマルとマイナーの数は増加しました。

したがって、見つかったバグの数が減少しないということは、製品が改善されていないことを意味するものではありません。



別の価値ある情報源は、発見された状況に応じたバグの配布です。





これを行うために、バグの特別なフィールド「Found under condition」があり、次の値を取ることができます。

• 顧客-以前のバージョンのいずれかでバグを見逃し、カスタムチームがそれを見つけて登録しました
• 退行-以前のバージョンで機能していた機能は現在のバージョンでは機能していませんでした
• 新鮮な外観-より良いテストを開始し、以前に見逃していた以前のバージョンのバグを発見しました
• 新しいTC-現在のリリースの新機能にバグが見つかりました
• その他

これらのカテゴリによって発見されたバグがどのように分布しているかを理解することで、このような簡単に理解できる表でここに簡単に提示できる多くの有用な情報を得ることができます。

どうした	どうする
現在の反復で作成された新しい機能をテストすると、多くの回帰バグが見つかります	新しい機能を作成する際に、古い機能を分解し、対応する機能の開発者と話し合い、単体テストの数を増やし、追加の回帰テストを計画する理由を理解する必要があります。
多くの新しいTCバグを見つける	機能の低品質の理由について開発者と話し、修正のためにそれらを送信し、コードレビュー手順を改善します。
新鮮な外観のバグをたくさん見つける	一方で、より良くテストし、より深く、より広く見えるようになりました。一方で、なぜこれらの問題を以前に発見しなかったのですか？ リリースの終了時に締め切りが非常に厳しい場合、同様のバグが犠牲になる可能性があります。 製品が悪化することはなく、発見されたバグは誰にも迷惑をかけないかもしれません。

別の有用な情報源は、コンポーネントごとのバグの配布です。これにより、製品のどのコンポーネントがひざに弱いかという質問に対する答えが得られます。





これを重大度分布と組み合わせることで、現時点で最も問題のあるコンポーネントを強調表示し、これが発生した理由と修正方法を理解することができます。



問題のあるコンポーネントが週ごとに変わらない場合は、おめでとうございます。製品のボトルネックを見つけました。 そして、顧客がこれらのコンポーネントについて絶えず苦情を言う場合、その品質、アーキテクチャ、それらに取り組むチーム、開発側とQA側の両方からリソースを追加し、テストの範囲を広げることなどについて考えることは理にかなっています。



もちろん、製品情報の主な情報源の1つはユーザーです。 製品の最初のバージョンで作業していない場合は、サポート、フォーラム、販売、マニュアル、自動レポーター、製品に組み込まれたものなどを通じて受け取ることができるフィードバックを利用する機会があります。



これにより、次のことが可能になります。

• どの機能が需要があるのか​​、何がそうでないのか、何を開発する価値があるのか​​、そして何がそうでないのかを理解する。
• 顧客が製品をどのように使用するか、どのシナリオ（リリース前にすべてをチェックしたように見えるか、リリース後にはそのようなスクリプトが機能しないバグがあり、これは機能しないということがよく起こります）まったく異なるトレイル）;
• リスクベースのテストを使用します（たとえば、最も一般的な構成で完全なテストを実行し、他のすべての構成で調整します）。

別の強力なツールは、現在の状況を以前のリリースと比較することです。





TargetProcessを数年間使用しているため、蓄積された情報の量は非常に多く、これにより、リリースから何を期待するかを正確に予測し、与えられた推定値の誤り、発見したバグの数、修正した数、リスクを把握できます通常、撮影とその回避方法、特定のタスクに必要な時間などがあります。



現在のリリースステータスを分析するとき、他に注目する価値があるものは何ですか：

• 定期的なテスト結果
• 初期推定値と実際に費やした時間の差
• これらの機能をテストする責任者によって付加された機能の品質、
• 重大度優先度別の未解決バグの数、
• 時間に対する時間あたりのバグの数、
• リリース中に見つかったバグの何パーセントが修復されているか、
• コード内のバグの密度など。

ご覧のように、これらのグラフと表はすべて、非常に強力で便利なツールであり、起こりうる問題のほとんどを考慮に入れて、リリースを正確かつ正確に計画し、問題を事前に予測し、時間内に修正するのに役立ちます。



特に、最近リリースされたParallels Plesk Panel 11を開発する際に許可されました。

Splash 11でQAが真のブレークスルーとなったもののリストがあるはずです。 もちろん、それについて大声で話すことができれば。



しかし！ 収集するデータの量や、作成するタブレットやグラフの数に関係なく、 それらは有用な結論を導き出し、製品やプロセスをより良く変更する場合にのみ有用であることを覚えておくことが非常に重要です 。