タグ付けされた質問 「estimation」

質問： ソフトウェア業界のコンセンサスは、クリーンでシンプルなコードが、コードベースとそれを所有する組織の長期的な実行可能性の基本であるということです。これらのプロパティにより、メンテナンスコストが削減され、コードベースが継続される可能性が高まります。 ただし、SIMDコードは一般的なアプリケーションコードとは異なります。SIMDコードに特に適用されるクリーンでシンプルなコードに関して、同様のコンセンサスがあるかどうかを知りたいと思います。 私の質問の背景。 さまざまな画像処理および分析タスクのために、たくさんのSIMD（単一命令、複数データ）コードを作成します。最近、これらの関数のいくつかを、あるアーキテクチャ（SSE2）から別のアーキテクチャ（ARM NEON）に移植しなければなりませんでした。 このコードはシュリンクラップされたソフトウェア用に記述されているため、MATLABなどの無制限の再配布権がなければ、独自の言語に依存することはできません。 典型的なコード構造の例： 使用のOpenCVのマトリックスタイプ（Mat）すべてのメモリのため、緩衝液および寿命管理。 入力引数のサイズ（次元）を確認した後、ピクセルの各行の開始アドレスへのポインターが取得されます。 ピクセルカウント、および各入力マトリックスからのピクセルの各行の開始アドレスは、いくつかの低レベルC ++関数に渡されます。 これらの低レベルC ++関数は、SIMD組み込み関数（Intel ArchitectureおよびARM NEON用）を使用して、生のポインターアドレスからの読み込みと保存を行います。 これらの低レベルC ++関数の特徴： 排他的に1次元（メモリ内で連続） メモリ割り当てを処理しません。（一時を含むすべての割り当ては、OpenCV機能を使用する外部コードによって処理されます。） シンボルの名前の長さの範囲（組み込み関数、変数名など）は約10〜20文字で、これは非常に過剰です。（テクノバブルのように読みます。） コンパイラは「単一割り当て」コーディングスタイルで記述されていないコードを正しく解析するのに非常にバグがあるため、SIMD変数の再利用は推奨されません。（私はいくつかのコンパイラのバグレポートを提出しました。） SIMDプログラミングのどの側面が議論を一般的な場合と異なるものにしますか？または、SIMDが異なるのはなぜですか？ 初期開発コストの観点から 優れたパフォーマンスを備えたC ++ SIMDコードの初期開発コストは、カジュアルに記述された C ++コードと比較して、約10倍から100倍（マージンは大きい）であることはよく知られています。 パフォーマンスと読み取り可能/クリーナーコードの選択の回答で述べたように？、ほとんどのコード（カジュアルに記述されたコードとSIMDコードを含む）は、最初はクリーンでも高速でもありません。 （スカラーコードとSIMDコードの両方での）コードパフォーマンスの進化的な改善は推奨されません（ソフトウェアの一種と見なされるため）。コストと利点は追跡されません。 傾向の観点から （例えば、パレート原理、別名80-20ルール） 画像処理がソフトウェアシステムの20％（コードサイズと機能の両方）のみで構成されている場合でも、画像処理は（CPU時間の割合として見た場合）比較的遅く、80％以上の時間がかかります。 これは、データサイズの影響によるものです。典型的な画像サイズはメガバイト単位で測定されますが、非画像データの典型的なサイズはキロバイト単位で測定されます。 画像処理コード内で、SIMDプログラマーは、C ++コード内のループ構造を識別することにより、ホットスポットを含む20％コードを自動的に認識するように訓練されます。したがって、SIMDプログラマーの観点からは、「重要なコード」の100％がパフォーマンスのボトルネックです。 多くの場合、画像処理システムには複数のホットスポットが存在し、同等の割合の時間を消費します。たとえば、5つのホットスポットがそれぞれ合計時間（20％、18％、16％、14％、12％）を占める場合があります。高いパフォーマンスを実現するには、すべてのホットスポットをSIMDで書き換える必要があります。 これは、バルーンをポップするルールとして要約されています。バルーンを2回ポップすることはできません。 バルーンがいくつかあると仮定します。たとえば、そのうち5つです。それらを間引く唯一の方法は、それらを1つずつポップすることです。 最初のバルーンがポップされると、残りの4つのバルーンの合計実行時間の割合が高くなります。 さらに利益を上げるには、別のバルーンをポップする必要があります。（これは、最適化の80-20ルールに反します：ぶら下がりが最も少ない果物の20％が選ばれた後、良好な経済的結果を達成できます。） 読みやすさとメンテナンスの面で SIMDコードは、明らかに読みにくいです。 これは、すべてのソフトウェアエンジニアリングのベストプラクティス（ネーミング、カプセル化、const-correctness（および副作用の明確化）、関数の分解など）に従っても当てはまります。 これは、経験のあるSIMDプログラマーにも当てはまります。 最適なSIMDコードは、同等のC ++プロトタイプコードと比較して、非常にゆがんでいます（注意を参照）。 SIMDコードをゆがめる方法は数多くありますが、10回の試行のうち1回だけで許容可能な高速の結果が得られます。 （つまり、高い開発コストを正当化するために、4倍から10倍のパフォーマンスゲインを調整します。実際には、さらに高いゲインが観察されています。） …

14 performance  optimization  estimation 

4人の開発者のチームでアジャイル/スクラムの使用を開始しました。ストーリーの見積もりを行い、ストーリーを注文しました。製品バックログのプライミングストーリー。 まず、通常の1,2,3,5,8,13 ....の代わりに、1から5までの複雑さのポイントベースの推定から始めました。 いくつかのストーリーに取り組んだ後、4ポイントと推定されたストーリーの一部は2のみである必要があると感じましたが、2と推定されたストーリーはもっと複雑で、5と推定されるべきでした。知っている： 繰り返しの途中でストーリーの見積もりを変更しても大丈夫ですか？ 通常の1,2,3,5,8,13 ....の代わりに1から5までの現在の推定ポイントを使用することは問題ありませんか？ 私は個人的には両方のケースでノーであるべきだと感じていますが、自分の理解があまり明確ではないので自分をバックアップする必要があります（良い参考資料は良いでしょう！）

14 project-management  agile  estimation 

毎日、スタンドアップの後、チームと私は各ストーリーの見積もりを更新します。私たちのやり方に何か問題があると感じているので、あなたの助けが必要です。 これが俺たちのやり方です： ストーリーAの見積もり：24時間（1日8時間-基準として「理想的な日」を使用） N日：開発者は午前中にストーリーAの作業を開始します（1日の終わりまでに8時間の作業が完了します） N + 1日目：ストーリーAの再推定= 16時間（N日からストーリーAから1営業日を取り除いた） N + 2日目：ストーリーAの再推定= 8時間（N + 1日目からストーリーAから1営業日を取り出した） N + 3日目：ストーリーAはこれまでに完了する必要があります。しかし、そうではありません。開発者は、完了するまでにさらに3時間かかると考えています。ホワイトボードのストーリーを更新し、それに応じてバーンダウンします。 N + 4日目：ストーリーAは、わずか3時間ではなく終日かかりました！これで完了です。5時間という違いは、計画ではまったく考慮されていません。 ストーリーを毎日再評価する方法を教えてください。

14 scrum  estimation 

HNの記事で、次のアドバイスに出会いました。 不明な場合でも、常に顧客/ユーザーに「はい」と伝えます。90％の時間、あなたはそれを行う方法を見つけるでしょう。10％の時間、戻って謝罪します。大幅な個人的成長のための低価格 しかし、顧客/ユーザーに何らかの約束をする前に、実行可能性分析を行うべきだと常に考えていました。それでは、どのような状況で上記のアドバイスを適用すべきでしょうか？

13 programming-practices  ethics  estimation  feasibility 

私は年金と投資の面倒を見る銀行の大規模な金融取引システムに取り組んできました。15年間の機能変更後、手動回帰テストのコストはリリースごとに20万ドルに上昇しました。（1,000,000 LOC、1日あたり1,000万ドルの取引）。また、このシステムは、多くのデータを移動する社内の19の他のシステムと連動します。このシステムはJavaで実装されました。 ただし、「再利用」を行うほど、回帰テストのコストが高くなります。（理由は、「タッチするコードをテストする」必要があるためです。また、再利用/共有コードは、タッチされたときに多数の場所に影響を与えます。したがって、「DRY-Do Not Repeat Yourself」 -コードをコピーして貼り付ける金銭的なインセンティブを確認します。これは、回帰テストに大きな影響を与えるため、共有できるコードを変更したくないため、回帰テストのコストを削減するためです。 私の質問は、再利用と回帰テストのコストの関係を説明するソフトウェアエンジニアリングの原則があるかどうかです。 私がこの質問をする理由は、システムをテスト対象のより小さな部品に分解することには、おそらくコスト上のメリットがあるからです。 仮定： 「回帰テスト」とは、「受け入れテスト」を意味します。つまり、環境やデータのセットアップなど、ビジネスに代わってシステムに対して新しいテストを作成したり、古いテストを再利用したりする別のグループです。 大きなリグレッションテストコストに対する大胆な反応は、「より自動化されたテスト」です。これは良い原則です。この環境では、いくつかの課題があります。 （a）自動テストは、システムが高い自動テストカバレッジを持たない限り、システムの境界を越えてあまり有用ではありません。（影響範囲の課題）。 （b）システムが既に大きく複雑な場合、プログラマーの時間や高い自動化されたテストカバレッジへの資本投資に勢いをつけることは文化的に困難です。 （c）自動化されたテストの維持コストはプロジェクトに隠されているため、プロジェクトレベルで簡単に破棄されます。 （d）これは銀行で働くことの文化的現実にすぎません。 （e）私はこの問題を別の方法で解決しようとしています（分解）。

12 code-reuse  acceptance-testing  estimation 

SLIMとソフトウェアの推定に関する職場でのトレーニングマニュアルからの引用を以下に示します。 また、努力と欠陥の間には相関関係があることに注意してください。つまり、特定のサイズのプロジェクトに割り当てられる人が多いほど、欠陥が多くなります。 労力は、プロジェクトの人時間（人年、人月）です。欠陥は、ライフサイクルの任意の時点で検出された欠陥の数です。サイズは、プロジェクトを構成するユースケース、機能ポイント、またはSLOCとして定義されます。 優れたプロセスと有能なエンジニアを想定すると、これは直感に反するように思われます。たとえば、より多くの人がいるということは、すべての成果物（要件の仕様、設計、コード、テスト）に注目することを意味します。より多くの目を持っていることは別として、私の直感は、適切な品質技術を利用するプロジェクトの努力と欠陥の間にはほとんど関係がないことを示唆しています。 欠陥と労力または欠陥とプロジェクトの人数との間の既知の関係を示唆する、Putnam Model（SLIMで使用される）に関するドキュメントを除いて、ドキュメントを見つけることができませんでした。これは既知の関係であり、「より多くの人=より多くの欠陥」という主張は有効ですか？

12 estimation  quality  metrics  measurement 

私は4人の開発者のプロジェクトチームに所属しています。単一の作業項目で発生する余分な作業を処理する方法については、長い間議論を重ねてきました。 この余分な作業は通常、タスクにわずかに関連するものですが、アイテムの目標を達成するために必ずしも必要なわけではありません（意見かもしれません）。例には以下が含まれますが、これらに限定されません。 ワークアイテムによって変更されたコードのリファクタリング アイテムによって変更されたコードに隣接するコードのリファクタリング チケット周辺のより大きなコード領域を再構築します。たとえば、アイテムで単一の関数を変更した場合、クラス全体を再実行してこの変更により適切に対応できるようになることに気付きます。 変更したフォームのUIを改善する この余分な作業が小さい場合は問題ありません。問題は、この追加作業により、元の特徴点の推定を超えてアイテムが大幅に拡張されることです。5ポイントのアイテムは実際には13ポイントかかる場合があります。あるケースでは、振り返ってみると80ポイント以上であった13ポイントのアイテムがありました。 これをどのように処理するかについての議論では、2つの方法が考えられます。 同じ作業項目で余分な作業を受け入れ、誤推定としてそれを書き留めることができます。これに関する議論は次のとおりです。 この種のことを考慮して、スプリントの最後に「パディング」を計画しています。 常にコードを見つけたときよりも良い形にしてください。中途半端な作業をチェックインしないでください。 リファクタリングを後で行う場合、スケジュールを立てることが難しく、完了しない可能性があります。 あなたはすでにコードの奥深くにいるので、あなたは今この仕事を処理するのに最高の精神的な「状況」にいます。後で戻ってきたときにそのコンテキストを失うよりも、今それを邪魔にならないようにして効率的にする方が良いでしょう。 現在の作業項目に線を引き、追加の作業は別のチケットになると言います。引数は次のとおりです。 個別のチケットがあると、新しい見積もりが可能になるため、実際のポイント数について自分自身に嘘をついたり、見積もりの​​すべてがひどいことを認めたりする必要はありません。 スプリントの「パディング」は、チケット要件を完了するための直接的な障壁である予期しない技術的な課題のためのものです。これは、「便利な」だけの副次的なアイテムを対象としたものではありません。 リファクタリングをスケジュールする場合は、バックログの先頭に配置してください。 それが出てきたときにいくぶん恣意的であるように思われるので、私たちが推定においてこのことを適切に説明する方法はありません。コードレビューアは、「これらのUIコントロール（実際にはこの作業項目で変更しなかったもの）は少し混乱します。それも修正できますか？」これは1時間のようですが、「このコントロールが他のコントロールと同じ基本クラスから継承するようになった場合は、この（数百行の）コードをすべてベースに移動して、これらすべてを再配線しないでください。 、カスケード変更など？」そして、それは一週間かかります。 これは無関係な作業をチケットに追加することで「犯罪現場を汚染」し、元の特徴点推定を無意味にします。 場合によっては、余分な作業がチェックインを延期し、開発者間のブロッキングを引き起こします。 追加のものが2 FP未満の場合は同じチケットに入れられ、それ以上の場合は新しいチケットにするなど、一部の人はカットオフを決定する必要があると今言っています。 私たちはアジャイルを使用して数ヶ月しか経っていないので、これをどのように処理するかについて、この辺りの経験豊富なアジャイル退役軍人の意見は何ですか？

12 agile  refactoring  estimation  sprint 

ストーリーの推定についての私の理解では、法律の「合理的な傍観者」の概念に少し似た、想像上の平均的な開発者の場合のように、ストーリーのサイズを推定する必要があります。つまり、ストーリーのサイズを推定するべきではありません。 例を挙げると、以前の仕事で、私はチームの一部であり、最も自信のあるRuby開発者でした。私のチームメイトは、「XがRubyでどのように機能するかわからないので、何年もかかるだろう」というような議論をして、Ruby関連のストーリーを私よりはるかに大きく見積もっています。 これに対する私の議論は、スプリント計画がチームの能力の出番であるという事実から来ています。これが正しいフォーラムです。「タスクの大半はRubyベースであり、強力なRuby開発者は1人しかいないため、このスプリントの能力は通常よりもわずかに低くなります。」推定中にこれを考慮すると、この側面が倍になります。 回答に権威ある参考文献があれば感謝しますが、単純な意見も素晴らしいでしょう。

11 agile  estimation 

私は、ソフトウェア開発における日常的な作業の量は、無視できないとはいえ、比較的小さく、そしてそうあるべきであり、これがソフトウェア推定の基本的な問題であると確信しています。 この結論に至った経緯を説明し、議論に重大な欠陥があるかどうかを教えてください。 高精度で推定できるのは、以前に行われたことを意味する日常業務です。研究と創造性を含む他のすべての種類の作業は、少なくとも+/- 20％の精度では、実際には推定できません。 ソフトウェア開発とは、繰り返し作業を避けることです。その基本原則の1つはDRYです（繰り返さないでください）。プログラマーが繰り返し作業をしていることに気づいたときはいつでも、この繰り返しを回避する抽象化を見つける時が来ました。これらの抽象化は、繰り返しコードを関数に抽出したり、ループに入れたりするような単純なものにすることができます。また、ドメイン固有の言語を作成するなど、より複雑にすることもできます。いずれにせよ、それらの実装には、研究（これを以前に行ったことはありますか）または創造性が伴います。 これらの2つのポイントから、上記の結論を導き出します。 実際、私はこの関係が他のすべての議論、ブログ投稿、またはソフトウェア推定に関する記事で言及されていない理由をかなり長い間疑問に思っていました。理論的すぎますか？私の仮定は間違っていますか？それとも、ささいなことですが、なぜ私が知っているほとんどの開発者は、+ /-20パーセント以上の精度で見積もることができると信じているのですか？

11 development-process  estimation 

技術、概念、およびクライアントについて事前に何も知られていない研究開発プロジェクトがある場合があります。ただし、マネージャーにはまだ時間の見積もりが必要です。有用な見積もりを作成するにはどうすればよいですか？

11 estimation 

反復はすでに開始されており、新しいプログラマーがチームに参加しています。タスクXは別の開発者によって既に30時間と見積もられています。 この状況でのベストプラクティスは何ですか？ 新しい開発者は指定された推定値で実行します（速度の計算時に矛盾が修正されるという考えですか？） 新しい開発者はタスクを再評価しますか？（もしそうなら、それが著しく高く、反復にもはや適合しない場合はどうなりますか？） 手を上げて滝に戻る？ 完全に何か他のもの？

11 agile  estimation 

会社のコスト削減目標のメトリックを生成しようとしています。これを行うには、ゼロから構築したり、COTSソリューションを購入したりするのではなく、オープンソースのWebアプリケーションを使用することで実現した節約を見積もります。プロセスの1つのステップは、アプリケーションを自分で開発するのにどれだけの費用がかかるかを見積もることです。残念ながら、完全な推定プロセスを経ずにこれを実行するための非常に簡単な方法に私は困惑しています。 私はソースコードを持っているので、それを書くのに必要な開発者の時間の非常に大まかな見積もりを与えることができるいくつかの経験則があると思うでしょう。残念ながら、トピックに関する私のWeb検索では、ほとんどの場合、コード行が生産性や品質の良い指標ではないという記事や意見が出されます。 これまでの私の最善の解決策は、開発者が1日に書き込むことができる行数を選択し、そこから開発者の時間数を計算することです。その方法を使用する場合、開発者の生産性の主張を裏付けるいくつかの（できれば研究に基づく）証拠を持ちたいです。 私が行っていることの1つは、最終的なメトリックを生成するために必要なのは、開発者の時間またはプロジェクトのコストの下限のみです。推定値が高ければ高いほど、メトリックは良くなりますが、数値を大きくするよりも推定手法の方が攻撃しにくいでしょう。 オープンソースプロジェクトの価値を推定するより良い方法はありますか？

11 open-source  estimation  metrics 

私はプロジェクトに取り組んでおり、定期的（通常は毎週）の非公式の会議を開いて、プロジェクトのステータスとGUIについて話し合っています。 私はそこにいる唯一の開発者です。他の4〜5人はIT以外の経歴を持っています。 この会議にはいつもより長い時間がかかりましたが、ある時点で、私の同僚の1人がプログラムのいくつかのフィールドと、それらがどのように満たされるかについて質問しました。私は答えて、私が気付いたディスカッションで、私のプロセスは完全に間違っていると思いました。 しかし、それについて事前に話し合ってエラーを見つけたので、かなり迅速に変更できます。 このことを考えながら、開発時間を節約することに関して、会議時間の間に要因があるかどうかを自問しました。 たとえば、会議時間を1分にすると、開発時間をX分節約できます。 もしそうなら、これは私たちの会議がどれくらいの頻度でどれくらいの長さであるべきかを定義するのに役立ちます。 （明確にするために：会議の長さを大まかに決定することさえできても、より良い会議をしたくありません。会議時間と開発時間の間に関係がある場合、私は主に興味があります！質問の理由：好奇心！ ）

10 estimation  meetings 

私は、XPを実行するという真の意図を持つ非常に優れた会社で働いています。コミュニケーションは良好で、経営陣は建設的な議論を受け入れることができますが、差し迫った時間の制約があるため、RUPで議論することができないものもあると見なされています。 現時点では、ストーリーの実装中に必要となる変更の量に少し悩んでいます。これらの発見の多く（もちろん時間と労力がかかります）は、ストーリー作成者（顧客、エンドユーザー、製品所有者）の責任であり、開発者の責任ではないかと思います。簡単に言うと、ユーザーストーリーは概念的すぎて、根本的な意図を伝えているだけですが、十分な詳細（特に、前提条件と事後条件、他のストーリーとの関連性、依存関係など）が不足しています。開発者は、XPの開発者がデザイナーとアナリストを兼ねているため、独自の裁量で空白を埋めることが期待されています。問題は、これらの空白の多くが、最初の予想よりも複雑さが増していることに気付いてから、いくつかの誤った仮定が評価時間とコードに組み込まれた後に発見されることです。それでも適切な項目を見つけるには時間がかかります。これは、さまざまな程度で、初期の見積もりからの逸脱と見なされます。 私は、これらの影響を経営陣に伝える建設的な方法を探しています。不必要に物事を複雑にしようとしている人として私を装うような方法ではありません。私は新しいですが、まだ信頼性を確立していません。 あなたの洞察は大歓迎です。 密接に関連し、どういうわけか答えを与える：開発者はユーザーストーリーの詳細をどのくらい期待できますか？

10 user-story  extreme-programming  estimation 

タスクレベルの見積もりと時間の報告を処理するために、ソフトウェアの見積もりの第10章でSteve McConnellが説明している手法を（大まかに）使用しています。。具体的には、タスクレベルの見積もりを作成するとき（プロジェクトでコーディングを開始する直前）に、かなり細かいレベルでタスクを決定します。これにより、可能な限り、単一ポイントのタスクがないようにします50 4時間を超える信頼度推定値。このようにして、タスクの見積もりプロセスは、ソフトウェアの構築に役立ち、見積もり中にタスクを忘れないようにします。また、各タスクで可能な時間範囲を考え出し、McConnellが記述した統計計算と履歴精度データを使用して、必要に応じて他の信頼水準で推定を生成できます。この方法は私にはかなりうまく機能しているように感じます。タスクとその推定値を追跡のためにTFSに入れる必要があるため、使用するように言われた信頼度の割合で推定値を使用します。 しかし、仕事を忘れたときどうすればいいのか、あるいは、自分が見積もった仕事の1つにきちんと収まらない仕事をしなければならなくなってしまいます。もちろん、この状況を回避しようとするのが最善ですが、忘れられた/変更されたタスクをどのように説明しますか？将来の見積もりに役立つように、できる限り最高の履歴データが欲しいのですが、今は基本的に、50％の信頼性の見積もりを行ったかどうか、および範囲の見積もりの​​範囲内で行ったかどうかを計算しています。 必要に応じて、質問内容を明確にさせていただきます。不明確な点をお知らせください。

10 estimation