完成した概念実証。残りの作業を計画/予測/見積もる方法は？

Question

晴れた日のシナリオを実装する実用的な概念実証がありますが、例外パスの処理を開始する必要があります。私たちは請負業者であり、クライアントが契約を更新する前に、この次のフェーズについてクライアントと話し合うために詳細な見積もりをまとめる必要があります。

細部

JavaScriptで概念実証ライブラリを実装するのに10〜20か月の開発者を費やしました。ブラウザAPI、サードパーティライブラリにアクセスし、クライアント独自のサーバーソフトウェアに接続して、双方向のリアルタイム通信を実現します。現在、このライブラリは、クライアントによって作成されたHTML + JavaScriptUIの背後で実行されています。近い将来、彼らはこのライブラリもSDKとしてリリースする予定です。

これまで、概念実証をまとめるために、主に晴れた日のシナリオに焦点を当ててきました。これが完了したので、ライブラリを成熟させ、ライブラリのさまざまな領域で雨の日のシナリオをサポートする必要があります。

sDKユーザーがAPIを介して提供した不正なデータ
コード内のエラーパス
ブラウザAPIおよびサードパーティライブラリからの法的エラー応答
ネットワークの問題（ジッター、帯域幅の制限、一時的な切断など）

質問：サポートすべきではないがサポートすべき雨の日のシナリオの合理的なタスクリストを生成するために、どのようなプロセスに従うことができますか。言い換えると、（1）概念実証アプリケーションと（2）の間に何が欠けているのかを理解するにはどうすればよいですか？）同じ機能を実装する架空の成熟した堅牢なアプリケーション

また、この作業を簡単に項目化できるように概念実証を実装する際に何ができたかについて、遡及的なタイプの提案にも興味があります。

真空中で何をするか

これ以上のアドバイスなしに、私が書いたコードの静的分析と、サードパーティのライブラリとブラウザAPIの仕様を行い、考えられるエラーのケースを特定します。全体から始めて、コンポーネント、サブコンポーネントなどに分割します。十分な粒度に達したら、静的分析を実行するか、仕様を分析して、失敗する可能性のある方法（法的エラー出力、妥当な例外ケース、等。）。次に、各サブコンポーネント、次にコンポーネント、そして全体に戻ってこれらの障害モードを集約し、サポートする必要のある雨の日のシナリオのリストを作成します。

これに関する問題：

どうすれば大きな何かを見逃さないようにできますか？
コードと仕様を1行ずつ分析しないようにする方法はありますか？
これらの雨の日のシナリオに優先順位を付ける必要があります。リストをどのように重要度の高いものと重要度の低いものに分けますか？（それが発生する可能性はありますか？）
特定のメソッド/ APIの特定のエラーケースのリストを、プロジェクトが何/どのくらい/いつ決定するのに十分な高レベルに集約する方法は？（これは、優先順位付けに関する最後の質問と密接に関連しています）

更新：私は FMEA（Failure Mode Effects Analysis）を実行しました。これはシステム境界の分析に役立ちました-雨の日ネットワーキング、パブリックAPIの利用者、および（程度は低いですが）サードパーティのAPIレイヤーでのエラーに関連するシナリオ。 FMEAプロセスでは、さまざまなチームを使用して、考えられる障害のリストを生成することを提案しています。これは、私の問題＃1（主要なものを見逃さないようにする方法）に役立ちます。また、障害の重大度、発生の可能性、および検出される可能性に基づいて優先度メトリックを与えることにより、＃3（優先順位を付ける方法）を扱います。（現時点では）私たちが書いたコードの雨の日のシナリオリストを思いつくのに役立ちませんでしたし、私の問題＃2と＃4に対処しませんでした。

coteyr · Accepted Answer

私は通常、このようなプログラムを開発しないようにアドバイスします。すべてのパスが修正された後、プロトタイプを取得して「販売」することは、通常、小さなエラーごとにROIに発展します。近い将来に耳にすることの1つは、「何人のユーザーがそれを見ることさえあるでしょう。いいえ、私はそれを修正するためにお金を払うつもりはありません」です。

ただ、現在はウェイバック機が店頭にあるので、いきます。最初に決して「製品は...を除いて完了しました」のようなことを言いません。繰り返しになりますが、製品の開発に15か月を費やしました。これからあなたがやりたいことはすべて「それだけの価値があるのか」ということになるでしょう。代わりに「ポリッシュを追加する必要がある」、「角を丸くする必要がある」などのように言うと、はるかに良い場所になります。家が建てられたがペイントが必要だと説明するのは簡単です。それから、建てられた家を見て、まだ建てられていないことを説明しようとすることです。

このプロトタイプの最初の方法を使用して構築したものは、安っぽい製品であることを理解してください。うまくいきました。それはうまくいかないだけで、それはあなたがこれから進めようとしている戦いです。請負業者として、注意深くなければ、請求可能な時間を食べる場所に自分で取り組むことさえできます。

家をもう一度考えてみましょう。あなたは1つを構築しました。あなたが支払う。今、あなたはツアーに参加します、そしてそれは見栄えが良く、素晴らしいではありませんが、良いです。後で詳しく調べ始めると、壁の1つが本来よりも短いことに気付きます。あなたはそれを持ち出しますが、ビルダーは「私たちは知っています、まだ行われていないことがあると言いました。それはさらに$ Xになるでしょう」と言います。どのように対応しますか。

私が選んでいるように見えることは知っていますが、できるだけ多くの問題を回避するために、状況を正しく組み立てることが非常に重要です。

さて、テクニカルに移りましょう。あなたには2つの目標があります。まず、「ペイントジョブ」の総コストは開発の総コストよりも少なくなければなりません。次に、ライブラリが機能することを確認する必要があります。

したがって、参照プロジェクトを実装します。 https://github.com/lord/slate のようなものを使用し、libの使用方法を文書化します。各メソッドに肯定応答と否定応答があることを確認してください。 foo（1）はこれを行いますが、foo（ "sting"）を呼び出すとエラーがスローされます。参照プロジェクトをビルドすると、多くの場合、そのプロジェクトに対して直接コストをかけることなく、ライブラリの問題を特定して修正できます。これにより、「ペイントジョブのコストを削減する必要がある」という問題を回避しながら、必要に応じて請求する場所を提供できます。

ほとんどの人は、サンプルのプロジェクトとドキュメントにお金を払うほうが喜ぶでしょう。ほとんどの人は、優れたドキュメントにはコストがかかることを喜んで受け入れます。ほとんどの人は、文書化プロセス中にエラーが発見されて修正されることさえ理解します。そのため、請求先の新しいバケットを取得し、ライブラリで最も重要な問題を見つける方法を入手します。

すべてが見つからないことを受け入れます。しかし、それはあなたがプロジェクトを入れた場所です。今、あなたはROIゲームをあなたがそうするべきであるより早くプレイします。これにより、最も重大な問題が見つかります。

あなたの時間を見積もるということに関しては、私はあなたのプロジェクト時間を2倍と言うでしょう。あなたはlibに15か月を費やし、参照プロジェクトとドキュメントに30を費やしました。それは完璧ですか、いいえ、しかしそれは理解しやすく、あなたに始める場所を与えます。

Laiv · Answer

（1）概念実証アプリケーションと（2）同じ機能を実装する架空の成熟した堅牢なアプリケーションの間に何が欠けているのかをどのように理解できますか。

製品の場所

架空の成熟したアプリケーションがすでに存在する場合、それは他の誰かと競合していることを意味します。市場での自分の位置を知ることは私たちにとって良いことです。そして、市場の実情も。

通常、私たちは他の誰も埋めていないギャップを埋めることを目指しています。これが私たちの微分値です。それは何でもかまいません。たとえば、使いやすさ、パフォーマンス、互換性、スケーラビリティ、配布、不足している機能。など。潜在的な消費者にとって実際に重要なもの¹。

市場で私たちを見つけることは、私たちの直接の競争相手を特定し、比較することにつながります。そこには貴重なフィードバックがたくさんあるので、競合他社に関するコミュニティの意見は興味深いものになるでしょう。また、コミュニティが何を求めているのか、何が欠けているのかについて漠然とした概念があります。

製品にストレスを与える

競合他社の有無にかかわらず、製品を強調する必要があります。できるだけ長く。この時点で、ビデオゲーム業界を見ることができます。ビデオゲーム業界では、 オープン/クローズドベータ が非常に一般的です。 OB/CBの期間中、限られた数のプレーヤーが、限られた期間、ゲームをプレイしてストレスを与えるように招待されます。プレイヤーはゲームを「ハック」して自分の考えを共有することをお勧めします。一部のプレイヤーは、開発者の期待をはるかに超えて限界を押し上げることができると私が言ったとき、私を信頼してください。

ベータ版は、開発者と利害関係者の両方にとって貴重なフィードバックを生成します。何が欠けているかを教えてくれるだけでなく、何をすべきかを教えてくれます。何が機能し、何が機能しないか。たぶん、私たちが重要な機能であると考えるものは、侮辱的に無視され、些細なことです。

QA

コードと仕様を1行ずつ分析しないようにする方法はありますか？

私は常に自動テストと静的分析を期待しています。静的分析は無関係に見えるかもしれませんが、それは私たちが参照できる客観的な「品質の尺度」です。基本的に、製品がどのような状態でリリースされているかを示します。ただし、「良い」、「悪い」、「間違っている」、「正しい」がどのように製品であるかはわかりません。この特定のケースでは、SDKが「開発者に優しい」かどうかはわかりません。

手動テストと分析のために、最高のプレーヤーである開発者と一緒に「ベータテスター」チームを設定することを検討する必要があります。

分析

あなたは今のところ良い仕事をしています。ただし、次のステップに進まない程度に固執しないでください。プロジェクトを進める。この時点で、組織に関連するいくつかのアンチパターンをチェックすることに興味があるかもしれません。たとえば、分析麻痺または自転車小屋です。

特定のメソッド/ APIの特定のエラーケースのリストを、プロジェクトが何を、どれだけ、いつ行うかを決定するのに十分な高レベルに集約する方法は？（これは、優先順位付けに関する最後の質問と密接に関連しています）

問題に優先順位を付ける

私見では、これは技術的なビジョンとビジネス戦略に大きく依存するため、これをどのように行うべきかを言うのは私にはナイーブでしょう。競合他社に話を戻しますが、競合他社間でSDKが異なると、SDKは価値が高くなり、これらの違いを優先事項と見なします。²。また、消費者のフィードバックは、この主題に関する決定を下すために必要な情報を提供すると思います。

^{1：競合他社の弱点が私の強みになり得る。}

^{2：自分の弱点を競争相手の強みにしない}

juhist · Answer

捨ててください！

あなたが探していた答えではありませんか？これは奇妙なアドバイスのように聞こえるかもしれませんが、概念実証とプロトタイプは破棄されるように設計されています。プロトタイプを徐々に改良して最終的なシステムを実装すると、プロトタイプと構造が非常に似たものになります。良くない！プログラムの最終バージョンを、プロトタイプから合理的に進化できるものに限定するつもりはありません。私はプロトタイプが最終的なコードにされたプロジェクトに参加してきましたが、その結果は非常に恐ろしいものです。

ただし、すぐに続行してすべてを削除しないでください。おそらく、プロトタイプには、再利用可能なライブラリにすることができる1つまたは2つの良いものがあります。私のプロトタイプには確かに優れたものがあり、コーナーケースの適切な処理を追加することで常に救いました。プロトタイプのパーツは良いですが、パーツは悪いです。あなたの仕事は、どれが良いかを判断し、良いパーツを再利用可能なライブラリにすることです。

概念実証が実現可能であることを実証した後で実際のシステムを設計するときは、 second-system effect に注意してください。「今回はすべてをうまく正しく実行する」という考え方の場合、コードには非常に複雑なものが含まれているため、何も効果がありません。プロトタイプで得られた経験を使用して十分に優れた製品を構築し、プロトタイプを実装するときに陥った落とし穴を回避するだけです。

autophage · Answer

拡張性を考慮して設計していなかった場合、これはひどく困難な作業になる可能性があります。あなたがそうだったとしても、これはそれほど悪くないはずです。

最初のタスクは、コードの境界を決定することです。つまり、公に消費可能で変更可能なもの、公に表示されているが公に変更できないもの、および完全にレイヤーの内部にあるものです。

そこから、2つの主要な懸念事項があります。

プライベートであることの確認実際にはプライベート。これを許可する言語では、プライベートフィールドは実際にはプライベートとしてマークされます。 JS/ESでは、命名規則に依存する必要があります（たとえば、すべての「プライベート」変数の前に「__」を付け、必要に応じて、そのように前に付けられていないゲッターやセッターを付けることができます）。
すべてのユースケースが何らかの形で説明されていることを確認します。あなたは人々があなたのレイヤーの外にできる彼らがする必要なものにアクセスできるようにしたいのです。

あなたはおそらく、これら2つのことについて明示的なテストを書きたいと思うでしょう。

それが済んだら、おそらくいくつかのことを実装してみてくださいレイヤーのコンシューマーとして。これは、イディオムが他のエコシステムで適切に機能することを保証するのに役立ち、アクセスできないがアクセスできるはずのものを見つけるのに役立ちます。

これと並行して、まだテストがない場合は、テストを追加する必要があります。少なくとも単体テストが必要ですが、理想的にはすでにそれらを取得していることになります。ただし、失敗のケースをカバーするものは多くないようです。今がそれらを追加する良い機会です：間違ってフォーマットされた日付を渡すとどうなりますか？負の数？分数？ SQLを含む文字列？

これは、統合テストの追加を開始するのにも非常に適切な時期です。これらの統合テストは、ネットワークの問題を説明するのに適した場所です。

では、これをどのようにクライアントに提示しますか？それはあなたと彼らとの関係とあなたが現在持っている開発基準に依存します。スプリントで作業していた場合は、探索の1つのスプリントにコミットすることをお勧めします。その出力は、作業が必要な領域と現在見栄えが良い領域のより詳細なリストになります。

クライアントが何日までに何が行われるかについての詳細な記述を期待している場合...それを見積もるためにいくつかの作業を開始する必要があるため、それは問題になる可能性があります。ただし、すべての希望が失われるわけではありません。「予備分析」、「失敗したテストの作成」、「失敗したケースの修正」、さらには一連の受け入れテストの日付を見積もることができます。それらの長さは、アプリケーションのサイズと複雑さによって異なりますが、実際に必要と思われるよりも高く見積もることを常に忘れないでください。彼らが反発した場合は、合意に達することができるかどうかを確認します-「OK、私はこれを行うために（要求された2か月ではなく）1週間を割り当てますが、この1つのサブシステムに対してのみです。それが終わったら、見積もりを変更して他のシステムを再検討し、その1つのサブシステムで作業中に学んだことを使用できるようにします。これはあなたにいくらかの余裕を与えます-あなたはより大きな努力へのいくつかの良い近道を見つけるかもしれません、そしてあなたは最初に要求された2ヶ月が幾分膨らんだことに気付くかもしれません。一方、具体的な問題が発生した場合は、間違いなく2か月全体が必要でしたの場合、そのブロッカーが何であったか（一般的なものではなく）の具体的な記述をクライアントに提供できます。「まあ、それは難しいだろうと私はかなり確信している」）。