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

あなたがソロ開発者である場合、またはソフトウェア会社で主導的な役割を果たしている場合、ソフトウェアの1日あたりの費用を決定する必要があります。なぜこの方法があなたのために働くのですか？

31 estimation  pricing 

私はSourceForgeでホストされているオープンソースプロジェクトの開発者です。 それは小さなアプリとして始まり、いくつかのリリースの後、ますます人気が上がり、私からより多くの時間と責任を消費し始めました。そこで、SourceForgeで寄付オプションを有効にしました。 無料で開発を続けたいと思っていますが、もしお金が入ったら、どうやってチームと分割すべきですか？ チームメンバーの数に均等に配分する必要がありますか？（現在は2人のチームであるため50-50） クラスの数、コミット、またはチームメンバーによるその他の貴重な提出。 他のアイデアは？ そのような状況で何をしますか？ご意見をお聞かせください。 この質問が他の人にも役立つことを願っています。

27 open-source  pricing  team-leader  estimation 

ケースの推定時間が3日間だとしましょう。2日目には、ケースが増えており、時間の推定が行われたときにカウントされなかった新しいシナリオがポップアップしていることに気付きます。新しい調査結果は、2日間余分にかかります（合計5日間）。これは、開発者として遅かれ早かれ直面する典型的な問題です。 プロジェクトリーダーに新しい納期を通知する場合、どの戦略を使用できますか？ 多くの場合、なぜ質問がありますか？新しい配達時間をどのように動機付けますか？ 実際、多くのプロジェクトでは、SDLCの分析と設計にあまり時間をかけていません。 編集： 非常に複雑なプロジェクトでは、分析と設計にどれだけ合理的な時間を費やしても、ビジネスルールが複雑すぎるため、常に驚きがあります。しかし、そのような場合、プロジェクトリーダーは複雑さを認識し、予期しない驚きが生じたときに正しい態度をとる必要があると思います。問題は、複雑さを理解していないプロジェクトリーダーにどのように取り組むかです。

26 project-management  development-process  time  estimation  sdlc 

私は2人の開発者で構成される小さな会社を経営しています。私たちは、クライアントの1人に対して非常に大きなアプリケーションを構築しています。このプロジェクトの開発は1.5年間続いています。 現在、このクライアントは重要なスポンサーを獲得しており、このプロジェクトに関連するイベントを開催しています。だから今、私たちは2ヶ月で期限があり、私たちはそれを見逃すことはできません。 チームに新しい開発者を追加することを考えていますが、彼の統合を支援するために何ができるのかと思います。 これが状況です： ブルックスの法則の限界に近づいています-新しい開発者を追加するときのポイントは非生産的です。 アプリケーションは比較的適切に設計されていますが、実装はいくつかの点で混isとしています（特に古いコード）。 ユニットテストは、より新しいコードに対してのみ行われます。このプロジェクトが始まったとき、私たちは定期的にテストを行いませんでした。 ドキュメントとコメントは不完全です。 アプリケーションは大規模で複雑です。 クライアントは、プロジェクトに関するほとんどすべての詳細を、非常に明確で「プログラマーに優しい」方法で書き留めています。 今すぐ人を追加することをお勧めしますか？もしそうなら、新しい開発者がチームに統合するのを助けるために何ができますか？ 編集： スポンサーは来春にインターネットベースのスポーツイベントを開催しています。年の特定の日に開始する必要があります。変更することはできません。 開発者（私は2人のうちの1人）がする必要があるのは： 既存のアプリケーションを完了します（実行する作業の約25％）。 このイベントの組織に不可欠な新しいモジュールの作成（行う作業の約75％）。この新しいモジュールは、メインプログラムのAPIを理解しないと開発できません。 正確な時間の見積もりはできませんが、私たちは危険な状況にあります。

24 project-management  agile  teamwork  estimation  knowledge-transfer 

同僚が問題の解決と機能の実装に費やす時間を追跡するように奨励するにはどうすればよいですか？これを行うソフトウェアがありますが、数字を入力しません。 過去の見積もりと実際に費やした時間を比較することで、チームがプロジェクトの見積もりをより上手にできるようにしたいと考えています。同僚はプロジェクトのスケジューリングにあまり関与していないので、同僚には個人的な利益が見られないと思われます。

24 project-management  time-management  time-tracking  estimation  scheduling 

私が働いている会社は、最大10％のエラーマージンを目指しています。 私はそれを比較するものが何もなかったので、私はそれについてどう考えるべきかわかりません。 多かれ少なかれ、私たちがあまりにも間違って推定している場合、測定するための良いベースラインは何でしょうか？どのように（％で）ずっとあなたがあると思います大丈夫ミスに？

23 project-management  estimation 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 プランニングポーカー 要約、wiki記事を読みたくない場合： 次のイテレーションで実行したいタスクのリストを取得します 各タスクについて： 2.1グループが必要とするものについて話し合う 2.2全員がタスクに必要な労力の見積もりを書き留める/選択する 2.3誰もが見積もりを明らかにする 2.4最高と最低の外れ値 がコンセンサスに達するまで繰り返す2.5 通常、0、½、1、2、3、5、8、13、20、40、100のようなフィボナッチ数列の数字に似た値が許可されているので、23のような近い値に対して長い引数を取得しません。 27。 さらに、数字は努力の単位のない値を表し、その値は、誰もが約1に等しいことに同意するベースラインタスクによって決定され、他のすべてはそれに関連しています。 最終的に、目標は、特定のチームの「速度」、つまり特定の反復で完了することができるこれらのポイントの数について良い感触を得ることです。これにより、特定の機能にかかる時間をかなり正確に見積もることができます。 私が働いていたある会社でのイテレーション計画会議でこれを行いましたが、それはその特定の会社にとって数少ない良いことの一つだと思いました。だから、私が思っているのは、誰かがこれを使ったことがありますか？推定に役立つツールだと思いますか？すべての状況で機能しますか、それとも特定のチーム、プロジェクトなどに役立ちますか？

22 agile  estimation  iterative-development 

でアンドリュー・ヘイにより、ブログ記事、以下の公理を仮定しました。 プロジェクトの最後に同じバグを修正するよりも、プロジェクトの最後にバグを修正する方が大幅にコストがかかります。 しかし、特にLess Wrongのブログ投稿を読んだ後、これは確実ではないようで、私がそれをバックアップするのを見たデータは非常に古いです。 これは今日でも公理は正確ですか？

21 project-management  debugging  estimation 

ポーカーを計画することでプロジェクトの見積もりの​​精度が向上するというのが一般的な意見ですが（この質問でその小さなサンプルが実証されています）、このテーマに関して明確な研究が行われていますか？ 具体的には、ポーカーのプランニングが従来の推定手法よりも改善されることを示す非状況情報を探しています。

20 agile  estimation  planning  research 

最近、私が知らないフレームワーク（および潜在的に別のフレームワークの一部）を使用しなければならないプロジェクトの見積もりを提供するために、新しい問題が提示されました。私が慣れ親しんでいるものを自由に使用できる場合、見積もりを提供することははるかに簡単ですが、慣れていない領域での作業について見積もりが要求されたときに、分析による障害のある麻痺が生じたかのようでした。 振り返ってみると、私の解決策は間違っていました。私はただ働き始めました。 なじみのない言語/技術/フレームワークを使用する必要がある場合、プロジェクトとタスクをより適切に見積もるにはどうすればよいですか？

19 estimation 

特定のプロジェクトを成功させるために必要なプログラマーの人数をどのように知っていますか？ 私が働いている会社は、クライアント企業の注文を処理します。場所に基づいた在庫管理、注文処理、船荷証券の生成、請求書作成、貨物監査、レポート作成（おそらく50件のレポート）を処理する社内倉庫管理システムを作成しました。また、バーコードスキャン機能とクライアントポータル、およびその他の多数の小さな機能も備えています。また、従業員のフルタイムクロックも含まれています。Quickbooks、UPS、FedExと統合します。機能がわずかに異なる少なくとも50台のクライアントの作業を処理します。たとえば、顧客が送信したファイルから注文をインポートしますが、各顧客は異なるファイル形式（csv、excel、フラットファイル、およびWebサービス）を送信するため、十数個を超える注文変換方法がセットアップされています。輸出も同じ話です。 このプロジェクトは複雑で、毎日25万行を超えるコードで複雑さを増しています。これは、約250,000行のVB.NETコード、6,200行のRubyコード、そしておそらく5,000行のPHPです。また、約200のテーブルを持つMySQLデータベースもあります。 絶えず変化する要件と多数のクライアントの異なるニーズのために、コード自体の品質は非常に貧弱なコードから比較的良いコードまで大きく異なります。 現在、このプロジェクトにはプログラマーが1人しかいません-私です。私は現在、75人ほどの会社のすべての製品サポートも行っています。これには、トラブルシューティングと新しいクライアントのセットアップ、および必要な新しい機能が含まれます。さらに、私たちは全体を100％Ruby on Railsベースに書き換えようとしています。また、来年中にシステム全体を市場に出し、他の企業に使用したいと考えています。 現在、私たちにはプログラマーとしての自分しかいませんが、それで十分だとは思いません。この規模のプロジェクトに必要なプログラマの数や、その質問への答えをどのように決定すべきかについて、誰にも推奨事項がありますか？特に、経営者が来年までに製品の商業品質を望んでいるという事実を考えると？

18 project-management  estimation  resources  scope  effort 

チケットの推定時間を作成するとき、テスター（QA）にかかる時間をチケットの推定に含める必要がありますか？以前は、テスターの時間なしで常に見積もっていましたが、常にそれを含めることについて話し合っています。チケットがあと1週間でかかる合計時間を知る必要があるため、現在のスプリント、リリース前の最後のスプリントには意味があります。 チームのリソースを制限する傾向があるため、見積もりは開発者向けの時間であると常に理解していました。同僚は、テスターの時間より前に働いていた場所はどこでも含まれていると言っています。 明確にするために、これは、開発者が適切なカバレッジでユニット、統合、およびUIテストを記述しているプロセスのためのものです。

17 agile  scrum  estimation  qa 

私は数か月間、（特にジュニアではなく一般の人々のために）タスクを見積もる会社で働いていました。その後、タスクを与えられ、それを解決し、2つのテストを経て、最後に見積りがやや会った。 見積もりの​​いくつかは、私が満たすことが単に不可能であるため、私はストレスを超えています。私はまだシステム全体を知らないので（非常にかなり大きいので）、時には半分の時間が私が何をする必要があるのか​​を見つけるのに費やされ、どこでそして終わるまでに時々見積もりが終わり、まだテストがあります完了（および、誤りがある場合は修正）。 似たような機能を二度と処理しなければならない場合、すべてがずっと速く動作しますが、今のところプログラミングが苦手だと感じています。 このステージを乗り越えるのに役立ったのは、始めたばかりのときに何かしたことはありますか？コードを作成する時間があまりにも少ないので、自分がやっていることにきちんと焦点を合わせることができず、それがさらに悪化することがあるのを見ると、私はとてもストレスを感じます。

16 junior-programmer  estimation 

これは珍しいテーマではないと確信しています。ストーリーポイントを使用してユーザーストーリーを推定する大丈夫な仕事をしている2つのスクラムチームがあります（チームメンバーは数年のスクラム経験がありますが、現在のチームの星座はわずか8か月です）。しかし、会社のビジネス部門がユーザーストーリーに関連することは困難です。実際の時間単位（または「ストーリーポイントを時間に変換する式」）が必要なため、いつ準備が整うかを計画できます（「Feature Xが生産中であることを顧客に伝えることができる時期を知る必要があります」 "）。 私と私のスクラムマスターの前任者は、もちろん、「ストーリーポイントと実際の時間の間に明確な関係はない」と「ストーリーポイントはチームがスプリントにどれだけフィットできるかを決定するために使用される」と説明しました。彼らがその答えにどれほど満足しているか推測できることを確認してください。彼らは、カレンダーの時間に、バックログの27番目のユーザーストーリーに到達する時期を知りたがっています。 いずれにせよ、私はいくつかの統計情報をコンパイルされている、と私たちのSP推定値はに変換乱暴に異なる実時間費やした結果（チケットは列「に取り組ん」に費やすどのくらいの時間を追跡し、当社のスクラムボードソフトウェア、によって測定されます）。1-SPユーザーストーリーの場合、もちろん非常に短い期間（ときどき爆発する）への大きなバイアスがありますが、特に2-SPストーリーの場合、それらはいたるところにあります。 「最速」と「最遅」の完了間。3、5、および8 SPストーリーの場合、スプレッドも2倍以上です。 これは、（a）チームが（同様の）複雑さのユーザーストーリーの推定においてはるかに一貫性を保つ必要があること、および（b）チームが時間レポートの精度を向上させる必要があることを示します（つまり、会議中、昼食時、またはフーズボールをプレイしているときに「作業中」）。 私は（a）と（b）の両方を改善する計画がありますが、これらのイニシアチブがもたらすものよりも「具体性」をビジネスが期待しているだけでは不十分だと感じています。 ビジネス側を和らげるいくつかの良い戦略は何ですか？それは私たちがどのように仕事をするかをあまり邪魔しないようにするためです（たとえば、個別の時間追跡の使用を課すことによって現在の「自動」追跡）、同時にストーリーがいつ行われるかについての具体性のある程度の測定値を取得できるようにしますか？ （歴史的に、計画中にユーザーストーリーをワークアイテムに分割し、実際の作業時間で個別に推定しましたが、ここで話しているのはバックログのユーザーストーリーで、そのレベルの詳細やブレークはありません-ダウン。） 更新：私のマネージャーは、ストーリーポイントごとの時間のベル曲線分布のようなものがあるという予感がありましたが、私が照合したデータと彼が作成したグラフは、彼の考えを徹底的に否定しました。:-)

15 scrum  estimation 

ソフトウェア開発に対するより伝統的なアプローチとは対照的に、プロジェクトの要件と設計が自動化された受け入れテストと単体テストによって駆動される場合、ソフトウェアプロジェクトに対するリソース計画の全体的な影響を知りたいと思います。 あなたの経験では、「従来の」開発方法論とは対照的に、TDDの下でソフトウェアプロジェクトを完了するためのリソース要件に対する全体的な影響は何ですか？品質が向上し、テストが早期に行われるため不確実性の量が減少することは自明のように思えますが、事前にテストを行う必要があるため、開発者により多くの時間を費やす必要があります。バグを事前に排除することにより、開発の労力はどの程度増加しますか、実際に減少しますか？ 顧客からどれだけの労力が必要ですか？特に前もって大きなデザインに慣れている場合は、プロジェクトとの関係を変える必要がありますか？顧客全体の所要時間は増加しますか、それとも実際に減少しますか？ TDDプロジェクトの開始時の反復TDDプロセスでは、ソフトウェア開発計画がないため、時間の見積もりが非常に曖昧になると思います。たとえば、プロジェクトに20％のポイントがあり、ある程度安定した時間とお金の見積もりを最終的に顧客に提供できるほど信頼性が高まりますか？ 注：ここでは主観的な意見や理論を探しているわけではありませんので、推測しないでください。TDDでの実際の経験をもっと探しています。

15 tdd  estimation