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

私は5人のメンバーからなるチームの開発者であり、私たちのプロジェクトは災害に向かっていると信じています。理由をすぐに説明しますが、私の質問は次のとおりです。 締め切りは1.5か月で、私たちが何をしようとも、このプロジェクトは失敗するでしょう。私はただプロジェクトを終了して時間を無駄にするのをやめるべきだと思うが、政治的に私たちのマネージャーがそうすることは不可能だと思う。 この場合、どうすればよいですか？余分な努力をする必要がありますか、それとも簡単に取る必要がありますか？そして、私はマネージャーに何を言うべきですか？ このプロジェクトが失敗に向かう理由： 期限が近づいているため、必要不可欠な機能の多くは終了していません アプリケーションが不安定で使用が非常に難しい システムは非常に複雑で、コードを理解するのが非常に難しく、変更するのは非常に難しい-データモデルは複雑なリレーショナルデータベース（100以上のテーブル）によって駆動されている 不明確なリーダーシップ。マネージャーは、大きな変更を伴う新しい情報に対応します 自動テストやユニットテストはほとんどありません 他のシステムに大きく依存していますが、統合テストはまだありません 実際、私たちは実際にこのプロジェクトを（混乱と共に）数か月前から同じマネージャーの別の開発チームから1〜2か月前に継承しました。

335 project-management  team  project  failure  legacy-code 

数か月前、私の会社は、プロジェクトの白熱した緊急事態に手を出し、6人のチーム全員が基本的に5週間の「クランチウィーク」を終了しました。本番開始の48時間前に、私はそのうちの41人、2人で徹夜で作業しました。その真ん中に、これまでで最も成功した質問を投稿しました。 その間、「失敗」の話はありませんでした。それは常に「痛みに関係なく、成し遂げられる」ことでした。 事態は終わり、私たちは組織としてしばらくの間、学んだことをじっくりと検討する時間がありましたので、1つの質問がありました。「失敗」したと言うプロジェクトに参加したことがあるとは言えません。予算が遅れたり予算を超過したものもありましたが、悲惨なものもありましたが、私は常に何かを提供することになりました。 それでも、私は常に「失敗したITプロジェクト」について耳にします。私はそれに関する人々の経験について疑問に思っています。「失敗」を定義したパラメーターは何ですか？コンテキストは何でしたか？私たちの場合、私たちは外部クライアントを持つソフトウェアショップです。大企業の内部にあるプロジェクトには、「失敗」する余地がありますか？いつ電話しますか？するとどうなりますか？ 私たちがやったことをやるのは賢明なビジネスの動きだとは全く確信していません。それは私の電話ではありませんでした（私は単なるコードモンキーです）が、損失を削減し、配信しないと言って先に進む方が良いのではないかと考えています。長時間の刺し傷のために、会社はプロジェクトでシャツを王室で失い、さらに従業員の士気と忠誠心に関する会社の無形の費用が大きかったとは言いません。このような注目度の高いプロジェクトを提供できなかったというPRヒットに反する要因は...そして、私は正しい答えが何であるかわかりません。

30 project-management  failure 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 「エンタープライズ」環境では、プロプライエタリなソフトウェアに対する強い偏見を観察しました。Javaを使用する大企業でも、MySQLやPostgreSQLを見つけることはまれであり、WebSphereやWebLogicはJBossやTomcatよりも強く推奨されます。 これは非常に理解しやすいです。多くの開発者はWebSphereやOracle DBよりもTomcatやPostgresを好みますが、これらの問題で最終決定を下すのは開発者ではありません。本番環境でどのDBとアプリケーションサーバーを使用するかを決定する人は誰でも、本当に、本当に、悪いことを引き起こしたフリーソフトウェアを選択したために解雇された場合と比較して、ライセンス料が非常に少ないように見えます。 PostgresがOracleと同じくらい良いかどうかの質問はしていません。それはポイントではありません。Oracleは、機能とベンチマークを慎重に検討した結果、Postgresよりも選択されません。特定の場所ではフリーソフトウェアが信頼されていないため、Postgresは会話に参加しません。 この信頼の欠如が特定の出来事に対応して生じたのではないかと思っています。だから私の質問はこれです：オープンソースソフトウェアの欠陥の結果であることが示されたビジネス災害（障害、収益の著しい損失、企業データの著しい損失など）の文書化された事例はありますか？ 明確化： OSSを完全に採用している企業レベルの企業での経験がある場合は、問題を先入観せず、特定の状況のニーズに基づいて選択する必要があります。あなたの経験は、他の企業が非常に異なる態度を持っているという事実を変えることはなく、これらの企業が少数派であっても私の質問は有効です。

21 open-source  business  enterprise-architecture  failure  proprietary 

会社が現在のプロセスをSCRUMに置き換えることを決定したときに発生した単一障害点は何ですか？ 会社がSCRUMを導入しようとしたときに本当にうまくいかなかったものの例をいくつか教えていただけますか？あなたの逸話、あなた自身が経験した何か、あなたが来るのを見たが防ぐことができなかった大きな失敗を聞きたいです。 実装の詳細、およびストーリーのサイズとストーリーの詳細レベルに関する決定に関するドキュメントがないことについて、多くの懸念を聞いています。

20 scrum  failure 

システム/プログラム/分散アルゴリズム/ ...は、多くの場合、述語堅牢またはフォールトトレラントで記述されています。 違いはなんですか？ 詳細： + robust + "fault-tolerant"でGoogleを検索すると、2回しかヒットしませんが、どちらも役に立ちません。 Googleで学者の用語を検索すると、タイトルに両方の用語が含まれている多くの論文が見つかります。残念ながら、彼らは用語を正確に定義していません:(しかし、彼らは両方の用語を使用しているので、どちらも他方を意味しないようです。

12 architecture  error-handling  errors  definition  failure 

プロジェクトが失敗することは珍しくありません。 プログラマーとして、失敗したプロジェクトにどのように対処しますか？ 失敗のいくつかの定義： 締め切りがありません。 コードと機能は本来のことをしていません。 ソフトウェアはベーパーウェアまたは無限の数のフェーズになり、基本的には配信できません。 あるいは、あなた自身の失敗の定義があるかもしれません。 指差し始めますか？要件、技術、管理、クライアントなどを自分自身のせいにしますか？チームとしてレッスンを学びましたか？

12 team  project  failure 

私が取り組んでいるAPIには、IDの配列を受け入れる一括削除操作があります： ["1000", ..., "2000"] 削除操作は自由に実装できたので、すべてをトランザクション対応にすることにしました。つまり、1つのIDが無効な場合、リクエスト全体が失敗します。これを厳密モードと呼びます。 try{ savepoint = conn.setSavepoint(); for(id : IDs) if( !deleteItem(id) ){ conn.rollback(savepoint); sendHttp400AndBeDoneWithIt(); return; } conn.commit(); } 別の方法（ソフトウェアスイートの別の場所で実装）は、バックエンドでできることを実行し、アレイでエラーを報告することです。ソフトウェアのその部分はより少ないリクエストを扱うので、理論的にはレスポンスが巨大な配列になることはありません。 リソース不足のサーバーで発生した最近のバグにより、コードを再度確認し、今は元の決定に疑問を抱いていますが、今回はベストプラクティスではなくビジネスニーズによって動機付けられています。たとえば、リクエスト全体が失敗した場合、ユーザーは再試行する必要がありますが、いくつかのアイテムが削除された場合、ユーザーはアクションを終了し、管理者に残りの作業を依頼できます（バグの修正に取り組んでいる間） ！）。これが許容モードになります。 私はこの問題に関するガイダンスをオンラインで探してみましたが、手ぶらで出てきました。だから私はあなたに来ます：この種のバルク操作で最も期待されることは何ですか？もっと厳しくするべきですか、それとももっと寛容にすべきですか？

11 user-experience  application-design  transaction  failure 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 悪いマルチスレッドのためにほぼ/実際に失敗したプロジェクトからどのような教訓を学びましたか？ フレームワークは、特定のスレッドモデルを課すことがあるため、物事を1桁正しくするのが難しくなります。 私に関しては、最後の障害からまだ回復していないため、そのフレームワークでマルチスレッドに関係することは一切しない方が良いと感じています。 私は、単純な分岐/結合があり、データが一方向にしか移動しない（信号は円形方向に移動できる）マルチスレッドの問題に長けていることがわかりました。 一部の作業は厳密にシリアル化されたスレッド（「メインスレッド」）でのみ実行でき、他の作業はメインスレッド（「ワーカースレッド」）以外のスレッドでのみ実行できるGUIを処理できません。データとメッセージは、N個のコンポーネント間で全方向に移動する必要があります（完全に接続されたグラフ）。 そのプロジェクトを別のプロジェクトに任せたとき、どこにでもデッドロックの問題がありました。2〜3か月後、他の開発者がデッドロックの問題をすべて解決し、顧客に出荷できるようになったと聞きました。不足している知識の一部を見つけることができませんでした。 プロジェクトに関する何か：メッセージID（スレッドに関係なく、別のオブジェクトのメッセージキューに送信できるイベントの意味を表す整数値）の数は数千になります。一意の文字列（ユーザーメッセージ）も約1,000になります。 追加しました （過去または現在のプロジェクトとは無関係に）別のチームから得た最高の例えは、「データベースにデータを置く」ことでした。（「データベース」は集中化とアトミック更新を指します。）すべてが同じ「メインスレッド」で実行され、すべての非GUIヘビーリフティングが個々のワーカースレッドで実行される複数のビューに断片化されるGUIでは、アプリケーションのデータはデータベースのように動作する単一の場所に格納され、「データベース」が重要なデータ依存関係を含むすべての「アトミック更新」を処理できるようにします。GUIの他のすべての部分は、画面の描画のみを処理します。UIパーツはデータをキャッシュする可能性があり、ユーザーが適切に設計されていれば、ほんの数秒で陳腐化していることに気付かないでしょう。この「データベース」は「ドキュメント」とも呼ばれます ドキュメントビューアーキテクチャ。残念ながら、いや、私のアプリは実際にはすべてのデータをビューに保存します。なぜそうだったのか分かりません。 仲間の貢献者： （貢献者は実際の/個人的な例を使用する必要はありません。逸話的な例からの教訓は、自分で信頼できると判断された場合も歓迎します。）

11 failure  frameworks  multithreading 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 8年前に閉鎖されました。 私の会社は、進行中のプロジェクトに不満を抱いていたため、作業中のプロジェクトをキャンセルしました。プロジェクトが順調に進んでいると思い、時間の制約のためにソフトウェアが持つ制限についてすでに説明したので、私はそれに非常に失望しました。私は今、新しい仕事を探すことにしましたが、プロジェクトがひどく終了して、私にいくつかの困難を与えるかもしれないと心配しています。不誠実にならずに私が引き起こす困難を最小限に抑える方法に関するアドバイスはありますか？

11 failure 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 去年のどこかで、かなり複雑なプロジェクトを唯一の開発者/プロジェクトマネージャーおよびテスターとして引き継ぎました。 昨年11月には、いくつかの新機能を提供するための期限がありました。 私が引き継いだシステムは、使用する準備ができていたと思われていましたが、まだ準備が整っていませんでした。 顧客のユーザーの1人と一緒に座って、彼は必要な新しい機能と要件を考え出しました。彼らが求めた機能は実装されたが、それは要件で指定されたものとは異なると彼は主張した。 それで、私は製図板に戻って、システムに大幅な変更を加える必要がありました。 約束の後の約束、これは私自身の責任です。さまざまな理由により、次の期限を逃しました。私の代わりに楽観的な計画を立てている、病気の子供、その他さまざまな個人的な問題です。 そして、顧客側にも障害がありました。私が彼らの肩越しに見守るときだけテストするなどです。 昨日、ユーザーがアプリケーションを承認した場合、ライブに移行することに同意しました。 もちろん、いくつかの問題が発生しましたが、今日、お客様に電話をかけようとしたところ、電話が切れて、どのメールにも返信していませんでした。 これは本当に私を疲れさせており、これに費やされた時間と時間は通常の労働時間をはるかに超えており、私の家族にも負担をかけています 明らかに、この状況にはこのプロジェクトに固有のものがありますが、全体的なパターン（複数の小さな問題、プロジェクトの故障につながる）は珍しいとは思いません。 同様のシナリオで何をしますか？

8 failure