1. プロジェクト立ち上げの品質指標
プロジェクトを反映するためにどのような品質指標を使用できると思いますか? オンラインの品質とは何ですか? 品質指標はたくさんあると思われるかもしれませんが、そのほとんどはバグの数、バグの再オープン数、バグの解決にかかる時間など、バグに関連したものです。すべてがオンラインの品質を反映しているようです。しかし、よく考えてみると、オンライン リリースの品質を測定するとき、単にバグだけを見て判断するわけにはいきません。
2. 研究開発プロセスの品質
結果だけを見ることはできないので、ソースから始めましょう。1つ目は要求の質です。最終的な品質を高くしたいのであれば、ソースからの要求の質が低すぎてはなりません。そうでないと、その後の研究開発作業がどれほど優れていても、それは良いとはみなされず、品質が低下する可能性があります。最初から道を誤る。
要件検討の段階で、ユーザーの利用シーンを踏まえた要件を質問形式で段階的に明確にし、受入条件（マインドマップとして記録可能）と制作・研究・開発の三者で作成する必要があります。テストは共同で確認し、
全員のニーズの理解が逸脱していないことを確認し、コンセンサスを形成することで、後続のチームが正しいことを行うための貴重な指針を提供します。ユーザー ストーリーの基本的な特性 (以前、プロジェクト管理に jira を使用していましたが、ユーザー ストーリーは当時のアジャイル チームによって提案されました。要件をストーリーに分割することができます) に従って、ビジネスに受け入れられ、研究開発が実現できます。展開をオンラインにする準備が整いました。
研究開発プロセスの品質を見てみましょう。コードの品質については、独自のコード仕様を開発しています。主にマクロ的な視点で見ていますが、個人的に注目すべき指標は「施工成功率」と「不具合傾向図」の2つだと考えています。
ビルドの成功率は、研究開発の提出物の品質を大きく反映する可能性があります。コンパイルが頻繁に失敗したり、自動テストが失敗したりする場合は、ビルドの失敗は最も基本的なビジネス セキュリティが重要であることを意味するため、注意を払って原因を理解し、解決策を見つける必要があります。問題。
欠陥傾向チャートは、欠陥の全体的な変化傾向と処理欠陥の適時性をよく反映できます。以下の図に示すように、一般に、反復欠陥の変化プロセスがわかります。より多くの欠陥が反復の途中で集中して除去され、後の反復まで遅延されません。これは、テスト回帰やその他の検証方法に役立ちます、リスクを軽減します。
立ち上げから実稼働までの品質評価を見てみましょう。ここでは、立ち上げ期間と欠陥保持という 2 つの主要な側面について説明します。ローンチ時間はチームのローンチ能力やユーザーが期待する時間内にローンチを完了できるかどうかを反映しており、ローンチ時間が長すぎてユーザー満足度が低下すると、ローンチの品質が高いとは言い難くなります。 。最終的な評価基準はユーザーが使ったときだけなので、良いものだと考えられます。
残りの欠陥について話しましょう。以前、20以上の問題が残ったバージョンに遭遇したことがありますが、テストレポートにもテストに合格したことが記載され、その後オンラインで公開されました。それらの問題は軽微ではありますが、多くの問題が残っているため、ユーザーがそれらに遭遇した場合、どのような不快な経験をすることになるでしょうか。
一部の問題については、修復のために次のイテレーションに延期することはできますが、最終的な結論がなければなりません。
3. ユーザーの質
研究開発チームの観点からのみ見れば、上記の指標で十分だと思われます。しかし、私たちは「目的を念頭に置いて開始する」とよく言いますが、増分機能の起動が終点ではなく、ユーザーの使用が反復起動の終点となります。したがって、プロジェクトの立ち上げの質を評価するときは、この分野の指標も追加する必要があります。
オンライン欠陥省略率: オンラインで見つかった欠陥を指します。どんなに研究開発プロセスが優れていても、テストでどれほど多くのバグが見つかったとしても、オンライン上の欠陥が簡単に発見されるようでは、オンライン製品の品質が非常に優れているとは言えません。さまざまな理由が考えられますが、同様の状況は避けたいと考えています。
私のリーダーを含め、私は強調してきました。ただ今立ち上げを完了するだけでなく、部門プロセスまたはコラボレーションプロセス全体の改善に関連して、レビュー、追跡、要約、改善できるプロセスを追求する必要があります。改善の見直しは品質管理力の向上につながります。
これは本当に要点を述べています。私はオンラインの品質にも注力しています。私のチームにはまだ改善の余地がたくさんあると信じています。ユーザーのフィードバック: これはユーザーの実際のフィードバックを指します。私にはユーザーの声を聞く機会があります
。声。常に自分自身について良い気分にならないでください。ユーザーが使いにくい、または受け入れにくいと報告した場合、私たちのリリースの品質はあまり良くない可能性があります。この点は、需要品質の最も直観的な表現であるため、前述の需要品質に関連する可能性があります。
データ埋め込みポイント: ユーザーのフィードバックが主観的すぎる場合、必要なデータ埋め込みポイントは、より客観的な分析に役立ちます オンライン品質 (改訂前後の比較、新機能のクリック率、クリティカル パスの変換率、エラー率など) 、など待ってください。あなたが反復処理している関数を誰も使用しなかったら、誰がもっと恥ずかしいことになるでしょうか? 埋もれたデータには遅延が発生する可能性があることに注意してください。この種のデータを参照する場合は、タイムラインを長くする必要があります。
4. 非事業特性指標
理論的には、上記の指標は、反復の開始の品質に関して比較的客観的なフィードバックを提供できます。しかし、アジャイル シナリオでは時間が短く、タスクは重いです。ウォーターフォール モデルではより重要なもの、つまり製品以外の機能の品質が無視されます。
最も典型的なものは保守性と拡張性です。ウォーターフォールモードでは、オンライン時間が長いため、この 2 つの問題に注意を払いますが、注意しないと、後の運用とメンテナンスが非常に困難になります。アジャイル環境では、オンラインタスクが重く、アジャイルがリファクタリングを促進するため、研究開発はコードの保守性とスケーラビリティについてあまり考えません（誰もがリファクタリングについて考えますが、多くの場合そうしない）時間）、および対応する時間はありません時間が経つにつれて、コードの山がゆっくりと現れます。現在、私のチームには多くの技術的ニーズがあります。
5。結論
以上、プロジェクトとローンチの品質についての個人的な考えを 3 つの側面からお話しました。研究開発側の学生としてはプロセスの品質が気になるかもしれませんが、コードや研究開発を進めている場合は、ビジネス以外の機能の品質にも注意を払う必要があります。結果の質に関しては、チームの追求にかかっています。でも、何かをやるには、ただやり遂げるだけでなく、きちんとやり遂げなければならないと感じています。
[全 200 エピソード] エンタープライズ プロジェクトの実戦を真にシミュレートする、Python インターフェイスの自動テストに関する非常に詳細な高度なチュートリアルのコレクション。