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

過去数か月間、私は自由時間にプロジェクトに取り組んできました。最近、友人からスタートアップの立ち上げを依頼されており、このソースコードは私たちにとって非常に価値があります。 共同創設者として、このコードは会社の首都の何かを数え、株式と交換することができます。しかし、どのようにその価値を見積もることができますか？業界標準の賃金に私が費やした時間を掛けるだけですか、それとも他の方法がありますか？

10 estimation  startup 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 4年前休業。 私の職場（大学）で見たほとんどの学生は、COCOMOを使用して、最終的な卒業証書の仕事のソフトウェア見積もりコストを作成しています。私の推測では、このコストの見積もり方法はやや古い（COCOMOの日付は1981）ので、私の質問は次のとおりです。 How do you estimate costs in your software? 私は次のようなものを見てきました： コスト=（HoursOfWork + EstimatedIddle）* HourlyRate それは私が欲しいものではありません、私は適切に（科学的に）定義されたコストモデルを探しています 編集私はSOでいくつかの関連する質問を見つけました： ソフトウェアコストの見積もり方法とモデルにはどのようなものがありますか？ ソフトウェア要件の開発にかかるコストをどのように見積もりますか？

10 pricing  estimation  cocomo 

私はスクラムミーティングで、開発者がストーリーについて現実的な見積もりを行うことが多いことに気付きました。ただし、かなり単純なストーリーであっても、構成、サードパーティコンポーネントのセットアップ、テスト、最終ビルドに多大な労力が必要であり、システムにはかなりの技術的負債が蓄積されているため、製品の所有者や管理者にとって見積もりが高すぎることがよくあります。 POは次のような見積もりを頻繁に打ち消そうとします。たとえば、「このストーリーには13ストーリーポイント[4日間]が必要です。これは不可能です。これを経営者に説明することはできません。誰かがこれをコーディングできるはずです。 3 SP [4時間以内]で！」その結果、開発者は5または8ストーリーポイント（1.5〜2日）の見積もり（スクラムの見積もりは、単なる予測ではなく、コミットメントと見なされます）にコミットするために腕をひねります。 もちろん、（主にテストと品質に関する）期待を排除する計画がなければ、これらのスプリントは頻繁に失敗します。開発者の見積もりは正直で現実的なものであり、見積もりを打ち負かしても実際に行われる作業に影響が及ぶことはありません。 「誰かがあなたにそうするように強いたからといって、あなたは不可能な約束をするべきではありません！」しかし私の意見では、開発者の仕事はソフトウェアの設計とコーディングであり、交渉や圧力に対抗することではありません！すべての取引のジャックが存在する可能性がありますが、通常は外部の顧客と直接取引しますが、これはオフィス開発者の大多数ではありません！ 私にとって、この実践は、プログラマーをぎくしゃくさせ、絶え間ないスプリントの失敗を引き起こし、現実的な見積もりを妨げるだけでなく、実際の改善点も探します。 スクラムガイドラインはこのトピックについて何を言っていますか、または彼らはそれに何を言っていますか？ 編集：時間をストーリーポイントに置き換えました。私は、タスクの詳細計画ではなく、Planning Pokerとストーリーポイントを使用して最初の見積もりフェーズを参照していました。日/時をそこに置いたのは、このような典型的な対話であり、ポイントではなく時間も含まれていたためです。混乱してすみません！ストーリーポイントの例は、時間の例よりも長い期間を表しています。 編集2現在、専用のスクラムマスターはなく、POは見積もり会議に関してその役割を果たします。したがって、中立的なまたは開発者のスクラムマスターではなく、権威として表示されるため、おそらくロールコンフリクトがこの不適切な交渉を悪化させています。おそらく、これが何もない限り、彼を「マスター」ではなく偏った参加者とすることで修正できます。

9 scrum  estimation  planning  sprint 

たとえば、プロジェクトをn個の個別の作業成果物（クラス、関数、コンポーネントなど）に分割した場合、n * tが推定に費やすのに適切な時間になるような時間tはありますか？

9 estimation 

私たちはスクラムではかなりグリーンな4人の開発者の小さなチームです。全国から来て、私たちは家に帰るためにしばしば奇数日休みまたは丸一週間休みます。したがって、私たちのチームのキャパシティは、年次休暇のために、反復ごとに劇的に変化します。これにより、反復ごとに速度が大きく異なります。計画会議で速度を推定するとき、チームのキャパシティをどのように説明しますか？過去のデータは非常に異なる容量を反映するため、推定速度の平均を導き出すのに1年待つことはできません。

9 agile  scrum  estimation 

私たちは皆それを持っています、あいまいなコードと奇妙な予期しない機能によって修正と修正を行うことが難しいことが判明した問題。ゆっくりと、パターン、エラー、間違いを見つけようとして、論理的に作業を進めます。このプロセスには時間がかかり、問題はクライアントによって簡単に理解されないことがよくあります。 特にクライアントがソフトウェア開発の固有の複雑さを理解していない場合、「いつ完了するのですか」という質問に対してどのように答えますか？

9 management  client-relations  estimation 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 私はチームメイトの一部（すべての開発者）に提供するプレゼンテーションをまとめています。見積もりスキルの向上に焦点を当てた短いチームビルディングアクティビティを含めたいと思います。誰かが私に提案できるチーム構築活動を知っていますか？

9 estimation  team-building 

プロジェクトの最初にポーカーの計画を立てる方法が好きです。各ストーリーの詳細を互いに比較して話し合うことができます。 私がこれで気付いた問題の1つは、時間の経過とともに問題ドメインでより多くの経験を積むにつれて、各ストーリー（つまり、最初は5または8の価値があったストーリー）に投票するポイントが少なくなるということですプロジェクトの今の価値があるかもしれません3。 この問題を可能な限り最善の方法で回避または対処するにはどうすればよいですか？推定するより良い方法はありますか？ストーリーは常に同じである必要がありますか、それともこのストーリーポイントは減少しますか？

9 agile  scrum  estimation 

ITプロジェクトでは： 誰が時間の見積もりに参加する必要がありますか？開発者、チームリーダー、スクラムマスターなど？ 誰の投票が最もカウントされるべきですか？

9 project-management  project  time-management  estimation 

変更は珍しくなく、要件の変更、仕様の変更、ワークフローの変更です。変化があることを受け入れましたが、私は疑問に思います。変化が起こることを知っていると、計画期間の短さが短すぎますか？（正当化が奨励されます） 繰り返し（2〜4週間）？ 一週間？ 2〜3日ですか？ 一日？ 1日1/2？ 会社が現在から1 [時間間隔（上から）]を「計画」し、計画が次のように聞こえると仮定します。 「[今朝/今日/今週の/ etc。]あなたは上で動作するでしょう。このと[今日の午後/明日/来週の/ etc。]あなたは上の作業になりますもの。 また、フォーカス/方向の変更が毎秒から3番目の時間間隔で一貫して発生するとします。

9 project-management  time-management  estimation 

何年も前に、私が若くて世間知らずで、言語が付属していない限り、すべてをゼロから作成したとき、私は2つの場所に2人の営業担当者がいて、リードと連絡先を共有しようとしていました。私はピカピカの新しいハンマーであるPHPを発見したばかりなので、もちろん、今日MySQLでサポートされている原始的なCRMシステムと表現できるものを作成しました。彼らはそれを愛していました-この時点で歴史のほとんどで、すべての競争相手はローカルのAccessデータベースを使用していました。 私はそれ以来、あなたが車輪を再発明しようとしない方が人生がどれほど楽になるかを学びました。私は再び、オンラインCRMシステムを必要とする成長している会社に直面しています。もちろんCRMシステムの機能については大まかに認識していますが、MS DynamicsやSAPのような製品が提供する製品についてはあまり詳しくありません。 私はこれらの企業が何千万ドルとユーロの開発に費やしているものを正確に把握しようとするマーケティングの綿毛を整理するのに苦労しています。それらのほとんどは、OutlookとSharepointの統合や、クリックアンドドラッグのインターフェイスを介してワークフローを作成する機能など、私があまり気にしていないかなり簡単なエンタープライズアプリケーションのようです。 だから私の質問は、カスタムCRMシステムをゼロから開発しようとするのはおかしいのですか？

9 estimation  crm 

スクラムの状況は次のとおりです。 特定のタスク（バックエンドのデータテーブルの実装）は頻繁に発生します 多くの場合、テーブルには類似しているがカスタム機能があります 各テーブルの実装には約1週間かかります（8ストーリーポイント） 最終的に、チームは4週間かけて再利用可能なコンポーネントを作成します 新しいテーブルの作成はほぼ瞬時に 私の質問： 出力/複雑度が変更されていないため、新しいテーブルストーリーはまだ8ですか？それとも、労力が最小限なので1ですか？ 私の研究：ジェフサザーランドとスクラムトレーニングを受けたとき、ストーリーポイントは出力を測定するため、ストーリーはまだ8であるという理解を残しました。PMはまだ同じテーブルを取得していますが、5倍速く配信されています。それは本当の速度の改善です（同じ作業を行うがより高速） しかし、私の理解が正しいことを確認したいと思います。何か助けはありますか？正式なスクラムの定義を探しています。私はscrum incのサイトを調査し、「半分の時間で2倍の作業を行うアート」を試してみましたが、私の理解が正しいか間違っているかを示すドキュメントが見つかりません。 ありがとうございました！ 更新 私は本当に正式なスクラム当局による文書へのリンクを探していました。以下の答えの多くは単なる人々の意見なので、この質問は誤解を招くと思います。

8 agile  scrum  estimation 

Pivotal Trackerの技術的負債のユーザーストーリーに対して、私たちは何をすべきですか？これらを特徴（ポイントを与える）または雑用（ポイントを与えず、速度を下げる）と見なす必要がありますか？ 私は雑用と見なされるべきものを混乱しています： コードの重複-複数の場所に同じコードを配置した場合、それはコードの習慣としては非常に悪いことであり、チームの開発者はソフトウェアを保守可能にするためにより多くの検討を行い、リファクタリングを行い、コードレビューに時間を費やす必要があることを示しています。これにはすべて、成熟度、時間、コードレベルの経験が必要になるため、提供するポイント数を少なくして、コードの品質が損なわれないようにすることをお勧めします。したがって、そのようなミスは罰せられるべきであり、雑用にポイントを与えないことによって速度を下げる必要があります。 テクノロジーのアップグレード-JS、HTTP2、React、MVCまたはその他の新しい/より優れたテクノロジーのモジュール化への移行のように。これらの手順により、コードのパフォーマンスとメンテナンスが改善されます。しかし、これは雑用か機能か？これがテクノロジーの世界のあり方であり、新しいテクノロジーが時々やって来て、それに移行する必要があると思います。したがって、そのような作業に対してチームの速度にペナルティを課すことには意味がありません。提案？ レガシーコードの複製/サブスタンダードコード-長い間使用されていないコードや、新しいチームが結成されたがコードベースが少し古い場合、この問題に直面します。チームはこのセクションをコーディングしていないので、なぜそれらの負債を作成したことがないので、なぜそのような技術的負債を選ぶことによって彼らの速度にペナルティが課せられるべきであるとチームは言います。 ビジネスの緊急性が原因の標準以下のコード-競合他社/ターゲット/ビジネス/ユーザーのプレッシャーが原因で、開発者は機能をすぐにライブでプッシュしなければならない場合があります。そのような悪いコードのクリーンアップも雑用（ポイントを与えない）と見なす必要がありますか？今回の開発チームに問題はないので、なぜ彼らの速度を下げなければならないのですか？ 上記のすべてのタイプの雑用は、賢明に行えば、将来的にチームの速度を向上させるはずです。しかし、チームの速度を維持しながらバランスを保ち、チームが悪い決定を下すことで技術的なミスを罰する必要があるでしょうか。 質問は次のようなものです。 技術的な負債は機能または雑用（またはバグ）としてスケジュールする必要がありますか？が、4つのポイントすべてを網羅する説得力のある回答が見つからなかったため、別の方法で再投稿しています。

8 agile  scrum  estimation  technical-debt 

私はソフトウェア開発者で、小さなWeb開発会社で働いています。なかなか時間がかかるとミドルマネージャーから聞かれるのはよくあるテーマのようで、見積もりを出すと高すぎると思います。それがより技術的なマネージャーまたは別の開発者である場合、彼らは通常、自分自身の見積も​​りをすでに心に留めており、より速く実行できると考えているため、独自の方法でそれを実装しようとします。 ただし、他の開発者が見積りよりも大幅に多くの時間を費やしてしまう傾向があります。彼らは予算の半分を経て、実装計画では適切に対応できないビジネス上のニーズがあることを認識します。たいていの場合、私の計画はこの必要性に対処するはずでしたが、「あなたはそれを必要としない」機能として肩をすくめられました。 さらに悪いことに、彼らがこの壁にぶつかったとき、彼らは通常、彼らが自分たちが描いたコーナーから抜け出すのを手伝うために私のところに来ますが、私の一日にはほんの数時間しかありません。 最良の場合：これらの中断は、自分の開発作業に割り当てた時間に割り込んだため、他のプロジェクトが遅れたり、「Xを実行できる唯一の人」であるため、残業しなければなりません。 最悪の場合：私は自分でタスク/プロジェクトを引き継ぐ必要があり、その時点では予算に「私の」やり方でそれを行う時間は残っていません。彼らが始めた方法で彼らが始めたものを終わらせなければならないので、「会社はこれ以上お金を失うことはありません」。「私の」ハッキーコードになるので、これはいつも私に噛み付きます。それが壊れると、なぜそれがそのように作成されたのか、人々は私に尋ねます（結局のところ、誰が実際にそれを作成したのかわかりません）。 ですから私の質問は次のとおりです。物事が想像しているほど単純ではなく、クライアントのニーズに対する理解を再評価する必要があるときに、これらの同僚がどのように理解できるようにすることができますか？ [既存の]技術的負債に対処するための経営陣の説得に関するこの同様の質問とは異なり、私の質問は、それが最初から起こらないようにするために、チームが技術的負債を負おうとする前に[積極的に]実現するのを助けるための戦略を求めています。これら2つは密接に関係していますが、私の考えでは明らかに異なります。他の質問の答えは、将来の機能の見積もりにリファクタリング時間を追加することを提案しています。他の開発者（したがってマネージャー）が、将来の機能は実際よりも時間がかからないといつも考えている場合、これは決して機能しません。また、私の見積もりがより現実的であると彼らに納得させることができません。

8 project-management  teamwork  estimation  technical-debt 

数年前、私は社内のフレームワークの開発にこれまで取り組んできた小さな会社で働いていました。彼らは彼らの最上級の開発者とそのアーキテクトをカスタムMVCフレームワークとORMをゼロから開発することに専念していました。これらの2つは、コア製品と直交しています。残念ながら、このフレームワーク主導のアプローチのサポートは上から来たものであり、収益を生み出すソフトウェアの配信を遅らせました。そして、生成されたフレームワークは、既製の代替品よりも著しく劣り、遅延をさらに悪化させました。会社はすぐに現金を使い果たし、最終的には全員が解雇された。 後の雇用主も同様のミスを犯しました-彼らは非常に技術的に熟練した開発者-完璧主義者を手に入れました。このソリューションは、他の顧客に合わせて拡張することができます。プロジェクトは大幅に実行されました。しかし、他の潜在的な顧客は少しもしません。金運の戦略的失敗、それは少額の財産です。 どちらの場合も、かなりの量のオーバーエンジニアリングがありました。どちらの場合も、会社とプロジェクト管理は、プログラミングのバックグラウンドではなく、ドメインまたは分析のバックグラウンドを持つ人々でした。どちらの場合も、ソフトウェアアーキテクトは過度に複雑なソリューションを構築して、かゆみを掻き消し、履歴書を強化しました。どちらの場合も、アーキテクトはコストを抑えることに利害関係がありませんでした（会社が倒産した場合に仕事を失うリスクは別として、それは彼らの高いエンプロイアビリティを考慮するとそれほどリスクはありませんでした）。 私の経験によれば、開発ショップが陥るのは珍しいことではありません。 正式な内部または外部の技術的な敵対的な役割-「量測量者」-建物のアナロジーを使用して、無駄なオーバーエンジニアリングを呼び出したり、防止したりするためのソフトウェアプロジェクトの場所はありますか？この役割を果たすのに最適なのは誰ですか？

8 complexity  methodology  estimation