研究開発効率の向上を 1 つの記事で理解 | JD Cloud テクニカル チーム

1 研究開発の効率性とは何ですか?

企業にとって、利益、ユーザー規模、顧客サービスの満足度、業務効率などを含む企業パフォーマンスを最大化することは不可欠な目標です。自社開発製品を持つインターネット企業にとって、研究開発の効率はサービス企業の効率を左右する重要な要素です。

ソフトウェア開発の完全なプロセスを次の図に示します。

要件提案から納品までの全プロセスにおける効率性と目的の製品を提供する能力、すなわち研究開発の有効性。

2 なぜ研究開発効率が向上するのでしょうか?

次の 2 つの例は、マクロおよびミクロの観点から、日々の需要の実現に対する研究開発のパフォーマンスの影響を示しています。

(1) 独自の観点からは効率的で効率的だが、グローバルビジネスの観点からは対応が遅い。

上の図は、単一の要件の配信プロセスを示しています。緑色の線はリクエストが処理中であることを示し、赤色の線はリクエストが保留中であることを示します。ワークロードが小さいデマンドの配信サイクルは非常に長くなります。これは、ほとんどの時間、デマンドが待機状態にあるためです。これは、断面が原因であるか、フロント、ミドル、バックグラウンドで作業の優先順位が異なるためである可能性があります。リンクが局所最適で全体効率が高くない これは多くの人が同じように感じていると思いますが、これはプロダクトデリバリーにおける共通のジレンマとなっています。

(2) APIドッキング処理

API インターフェイスのテストのプロセスでは、入力パラメーターの重要な値が適切に処理されないことがよくあります。たとえば、入力パラメーターは String 型ですが、コードの実装では String 変数がヌル。このような問題は通常、デバッグや共同デバッグの後半段階で発見されますが、このときの修復コストは比較的高額であり、修復後の回帰テストのコストも考慮する必要があります。したがって、API 入力パラメータの型をアクティブにスキャンして取得し、パラメータの型に応じてエラーが発生しやすい値を生成し、それらの値を使用して API を自動的に呼び出す仕組みを導入できます。500 エラーまたは例外が発生した場合がスローされる場合は問題が見つかったことを意味しており、そのような問題を早期に発見することができ、その後の開発作業の効率も向上します。

これら 2 つの例から、製品の提供であれ、実際の開発作業であれ、パフォーマンス向上の目標は、継続的かつ迅速に価値を提供する能力であることがわかります従来の開発手法では、ユーザーにとって有効な価値を継続的に生み出すチームの能力に課題があることがわかり、研究開発の効率化による長期的な効果を重視し、局所最適化からユーザー価値への視点の転換が必要である全体的かつ体系的な最適化を確保します。

3 研究開発の効果をどのように測定するか?

マネジメントの父であるドラッカーは、「測定できなければ改善できない」と言いました。

組織やチームが継続的かつ迅速に価値を提供する能力を評価するには、研究開発のパフォーマンスをより深く理解し、改善の方向性を設定し、改善効果を測定するのに役立ついくつかの指標が必要です。

パフォーマンス指標が答える基本的な質問は、組織の「価値を一貫して迅速に提供する能力」とは何でしょうか?

生産性の向上には、人材、プロセス、ツールという 3 つの要素が不可欠であり、これらはすべて不可欠です。以下の 5 つの具体的な指標を通じて、これら 3 つの要素についての理解を深めることができるでしょう。

1 つ目: 連続リリース機能。

リリース頻度: 単位時間あたりの有効なリリースの数。

リリース リード タイム: コードの送信から機能の起動までにかかる時間で、リリースに対するチームの基本的な能力を反映します。

2 番目: 需要応答サイクル。

配信サイクル時間: ユーザーの要求の確認から要求がオンラインになるまでの平均時間。

開発サイクル時間: 開発チームが要件を理解してから、その要件が実用化されるまでの平均時間。

3 番目: 配信スループット。

単位時間あたりに配信されるユーザー要件の量: 単位時間あたりに 1 つのチームによって配信される要件の量。

4 番目: 配送プロセスの品質。

欠陥の作成と修正時間の分散: 欠陥は一貫してタイムリーに発見され、発見後できるだけ早く修正されます。

欠陥在庫: 開発プロセスでは、製品が常にリリース可能な状態に近づくように欠陥在庫の量を制御します。これは、継続的デリバリーの基礎です。

5 番目: 配送品質。

単位時間あたりの問題の数であれ、オンラインでの問題解決時間であれ、システムの可用性が重視されます。

アリババの上級技術専門家チームが提案したこれら 5 つの指標セットは、フロー効率、リソース効率、品質という 3 つの側面から完全なストーリーを伝え、価値を継続的に提供する組織の能力に関する中心的な質問に答えます。このうち、継続リリース能力と需要応答サイクルという 2 つの指標は価値のフロー効率を反映し、スループット率はリソース効率を反映し、配送プロセスの品質と外部配送品質の 2 つの指標は合わせて品質レベルを反映します。 。

4 研究開発効率を高めるには?

まず、大手インターネット企業がなぜ今「研究開発の効率化」に注目しているのか。

ソフトウェアが世界を飲み込んでいます。過去 20 年間でインターネットはゼロから成長しましたが、今後はあらゆる企業がインターネットを基盤としてビジネスを構築することになります。ソフトウェア配信機能は企業の競争力の中核となっており、研究開発の効率化が企業の共通の課題となっています。

一方で、競争の激化に伴い、研究開発の効率に対する企業の期待はますます高まっており、他方では、インターネットの業界への発展に伴い、製品とコラボレーションの複雑性はますます高まっており、研究開発効率は低下傾向にあり、これは期待と理想とのギャップであり、研究開発効率を向上させるために解決しなければならない課題でもあります。

研究開発の効率化を推進する初期段階では、通常、エンジニアリング実践における小さな実務上のペインポイントからスタートし、問題解決を通じて研究開発の効率化を目指すトップダウン戦略が採れます。現段階では「」を追求しています。短く、平坦で、速い」という問題を一つずつ分解していきます。これらの問題には以下が含まれますが、これらに限定されません。

  • ローカルコンパイルには時間がかかり、消費量も多くなります
  • ローカルテストが難しく、テスト環境の準備が複雑で時間がかかる
  • 自動化されたテストケースは維持費がかかる
  • テストデータの準備が難しい
  • 研究開発後期になるとコード提出が集中し、不具合数が急増
  • 研究開発の後期段階で性能上の欠陥が発見され、修理費用が高額になる
  • ……

中期から後期に入ると、ソフトウェアの研究開発の現場に戻り、全体の状況からスタートして作業を最適化します。アジャイル ソリューションを紹介する前に、メトリック グラフを見てみましょう。

上の図では、横軸は日付、横軸の上の赤い縦棒はその日に見つかった欠陥の数を表し、横軸の下の緑の縦棒はその日に解決された欠陥の数を表し、オレンジ色の曲線は在庫を表しています。欠陥の。図の左側と右側は 2 つの配信モデルを比較しています。

左半分はカスケード開発モデルです。反復の初期段階では、チームは設計と開発に集中し、欠陥が生じましたが、検証に間に合うようにそれらを解決しました。欠陥は、テストと統合の後期段階までシステム内に隠されたままになりますが、そこで欠陥が爆発的に増加し、大規模な手戻り、遅延、納品品質の問題が発生します。

右半分は継続的デリバリーモデルです。反復プロセス全体を通じて、チームは粒度の細かい要件を開発し、それらを継続的に統合してテストし、リアルタイムで問題を発見して解決します。欠陥プールは制御下にあり、システムは常に解放可能な状態に近い状態にあります。

実際、継続的デリバリー モデルはアジャイル開発の原則、アジャイル = 価値観 + 原則 + 価値観と原則に沿った一連の手法に非常に似ています。アジャイル チームのイテレーション サイクルは 2 週間です。透明性があり、協力的で規律ある継続的な改善を通じて、はい、その部分が常に動作状態にある場合、各イテレーションでソフトウェアを運用環境に似た環境にデプロイし、ユーザーにデモンストレーションできます。 。アジャイル手法により、「小さなウォーターフォール」問題を効果的に回避し、要件の粒度と優先度に従って要件を分類し、独立してテストできる要件に分割します。時間内に解決し、見直して要約することができます。

個人的な観点から、私たちは現実、原則、そして個人から始めて、価値の流れに焦点を当てる必要があります。つまり、将来 -> 設計 -> 開発 -> 開発セルフテスト -> コードレビュー -> テスト -> 完了。新しい開発スキルを継続的に学習して、開発効率を向上させます。

チームの観点から見ると、チーム文化はチーム メンバーが共通に認識する価値観と行動規範です。優れた効果的な文化は、チームの効率的な成果を確保するための重要な部分です。文化的価値観の実装が勝利をもたらします。アジャイルなチームの効率的な作業を確保するための公式。もちろん個人的な利益が絡む施策であれば後味が悪いのは避けられないが、それがチームを正しい方向に導くことができるか、リスクを上回るメリットがあるかどうかを見極めるしかない。

読んでくれてありがとう。

参考文献:

[1] テンセントテクノロジーエンジニアリングhttps://zhuanlan.zhihu.com/p/202972178?utm_source=tuicool

[2] 川を渡って急ぐhttp://www.360doc.com/content/20/0915/11/31263000_935733089.shtml

[3] Alibaba Cloud Yunqi https://zhuanlan.zhihu.com/p/57029968               

[4] huver2007 https://blog.csdn.net/huver2007/article/details/103260847

[5] 研究開発効率向上とアジャイル実装のための 36 の戦略https://www.sohu.com/a/340050349_612370

[6] 参考書籍: 『継続的デリバリー』、『研究開発効率を打破する方法』

著者: JD Retail 李澤陽

出典: JD Cloud 開発者コミュニティによる転載。出典を明記してください

Microsoft の公式発表: Visual Studio for Mac が廃止 中国の開発者チームが作成したプログラミング言語: MoonBit (Moon Rabbit) LLVM の父: Mojo は Python を脅かさない、恐れるべきは C++ であるべき C++ の父 Bjarne Stroustrup 氏が共有人生のアドバイス Linus も 嫌な略語、TM は「GenPD」と呼ばれています Rust 1.72.0 がリリースされ、将来的にサポートされる最小バージョンは Windows 10 です。 Wenxin 氏は、WordPress を社会全体に開放し、 100- 「 Google の 高水準の関数型インタプリタ型動的プログラミング言語: Crumb を非推奨にするようユーザーに促す
{{名前}}
{{名前}}

おすすめ

転載: my.oschina.net/u/4090830/blog/10106420