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

一方では、「捨てる人を作る」というアドバイスがあります。ソフトウェアシステムを完成させて最終製品を確認した後にのみ、設計段階で何がうまくいかなかったかを理解し、実際にそれを行う方法を理解します。 一方、設計されている同じ種類の2番目のシステムは通常、最初のシステムよりも悪いという「2番目のシステム効果」があります。最初のプロジェクトには収まらず、2番目のバージョンに組み込まれた多くの機能があり、通常は非常に複雑で過度に設計されています。 ここで、これらの原則の間に矛盾はありませんか？問題に対する正しい見解は何ですか？また、これら2つの境界はどこですか？ 私は、これらの「良い習慣」が、フレッド・ブルックスによる独創的な本「The Mythical Man-Month」で最初に宣伝されたと信じています。 これらの問題のいくつかはアジャイル方法論によって解決されることを知っていますが、根本的には、問題は依然として原則のままです。たとえば、重要な設計変更を3回スプリントすることはありません。

15 design  project-management  programming-practices  project  principles 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 何年も変更されておらず、最終的に製品とチームの障害につながる現在のソフトウェア開発プロセスに対処する方法を知りたいと思っています。はい、おそらくこれを解決するより簡単な方法は仕事を変えることですが、この経済では言うよりも簡単です。ただし、特定の例があり、同じ状況で複数回見たり、経験したことがあり、これらの問題に対処する最善の解決策が会社を辞めることだと思う場合は、回答をサポートしてください。重要なのは、特にこの問題に関する複数の専門家が最終的なルートがルートAであることを示す場合、この質問には本当に答えがあるということです。 私は、多くの開発者が同じような状況にあったことを知っています。これは、企業が市場で第1位から最後に、あるいは市場から外れてしまう主な理由の1つです。この投稿の回答が、同様の障害に直面している他の開発者の助けになることを願っています。小規模または大規模な開発チームでは、通常これが発生します。 一部の開発者は気にせず、フローを採​​用することを決め、多くのコードをそのまま残し、開発プロセスをそのままにすることを好むようです。 他の人は変化に飽きて辞任し、別の会社に移動します。 他の人は話をすることを恐れて静かに過ごすことを好むようです。 時には非常に少数の開発者またはたった1人の開発者が製品の改善について意見を表明し、クライアント、ユーザー、およびチームのコーディングのベストプラクティスとその利点に従うことの重要性をチームに伝えます。これらのタイプの開発者は通常、会社が提供するメリットが非常に少ないソフトウェア会社や製品に多くの可能性があるなどの理由により、チームに留まることを決定します。 私たちのチームの製品は、製品の傘を持っているため、会社が収益を得る場所のほんの一部です（この会社はソフトウェア/ハードウェア会社ではないため、少なくとも今のところ、雇用を創出する継続的な特許訴訟はありません）不安定）。ここ数年、他の開発者の経験からこれまでに学んだことと、私の経験では、開発チームを本当に知るには、数日でも数週間ではなく、数か月かかるということです。チームがあなたを雇いたい、またはあなたを必要とする場合、面接プロセス中。彼らはすべてを素晴らしい音にし、あなたが聞きたいことをあなたに伝えるかもしれません。ただし、そのチームで作業を開始し、コードの内部を掘り始めて、完全なSDLCプロセスに移行するときの現実は異なります。これは、開発者として、あなたが仕事に就いたことの現実を見始めたときです。この現実により、ある会社から別の会社に移動したいと思うのは難しくなります。なぜなら、あなたが移動する会社が良いか悪いかを知るのは難しいからです。はい、Glassdoorのレビューなどを読むことができますが、HRからではなく、実際のオンラインレビューの数はどれくらいですか？ マネージャーは最初から常に変化に抵抗しており、以前の開発者は何年も同じことをしてきたことを考慮して、以下に概説する問題に取り組む最良の方法は何でしょうか？ 長年にわたる製品革新の欠如：製品には多くの可能性があり、会社に良い収益をもたらしますが、製品は20年前に作られたように見えます。一部のユーザーは、製品が使いやすくも直感的でもないと不満を述べ、他の人は、Gmailのようなアプリに使用され、同様の機能がないために製品を使用するときにイライラすることを述べています。ここでの主な問題は、開発者として製品に変更を加えて、製品の主要な要素を数ピクセル離れたところに移動しようとすると（ユーザーフレンドリまたは直感的に）、マネージャーがパニックして、元の場所に戻します。ユーザーの生産性を向上させる機能を追加しようとすると、「ユーザーはプロセスを行うのに慣れているなどの理由で」削除するように求められます。あなたは、変化、改善、革新に対する抵抗のポイントを得たと思います（開発者としてあなたが利益の強い議論を提供したとしても、マネージャーは変化に対して開かれていません）。同社はこの分野でいくつかの競合他社を抱えていますが（そのうちのいくつかの製品ははるかに競争力があります）、何とかして現在の顧客を何年も維持しています。 プロジェクト管理の調整の欠如：この結果、一部のプロジェクトがバグで遅れて配信され、一部のクライアントから苦情が寄せられたり（クライアントからもバグが報告されたり）、プロジェクトの配信前に予算が早すぎたりするなど。いくつかのプロジェクト調整のヒントとアイデアが、プロジェクトと実行するタスクの進捗を追跡するために定期的に使用されています。 悪いソフトウェア開発プラクティス：コードの臭いは、すべてではないにしてもほとんどのファイルに見られ、ドキュメント、コードの冗長性、フロントエンド層とバックエンドが同じファイルに混在している、古い開発ツール、実際のテスト環境もテストツールもありません（コピーアンドペーストのみ）開発環境から本番環境へのファイルを作成してから、手動でテストして問題が発生していないことを確認してリリースします）。チームがコード開発とソース管理に2つのIDEのみを使用しているため、チームが知らないところで開発とテストに使用する開発ツールのほとんどは、開発環境でのみ使用できます。他の開発者は最新のフレームワークを使用して現在の問題を改善しようとしましたが、マネージャーは「あなたが去ったら、そのコードを維持するのは誰ですか？、そのままにしておきましょう」という理由でそれを好まない去り、別の会社に移った。 要約すると、他の会社の多くの開発者にも同様の状況が起こると確信していますが、状況が異なるため、開発者は（仕事の都合、仕事の柔軟性、会社の利益、またはより良い機会が届いていないという理由だけで）。私が知っている完璧な会社はありませんが、開発者としてあなたがどのように行動し、物事をポジティブに保ち、最終的に製品の改善とソフトウェア開発プロセスの改善のための変更を促進するためにこれらの問題に対処しますか？長年の開発経験またはほんの数年）？これは投稿が長いことは知っていますが、より有用なフィードバックを得る可能性を高めるために、詳細を追加することを好みました。 フィードバックと時間をありがとうございました

14 project-management  programming-practices  team  project  legacy-code 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 私たちのチームは「Project In A Week」（ブートキャンプ）を行うことを考えていますが、他の誰かがこれを行った経験があるか、何かアドバイスがあるかどうか知りたいですか？ その背景にあるアイデアは、短期間で革新的で収益性の高い製品を考案するために、オフィスの気晴らしから逃れ、お互いに動機付け、チーム内で絆を築くことです。 計画では、開発チーム全体（約5人の開発者）、デザイナー、プロジェクトマネージャー、1週間のカンファレンスセンター/ホテルに1週間滞在するセールスおよびマーケティングのカップルを獲得します。1つのWebアプリ（事前に計画済み）を構築し、それを1週間以内にライブで市場に投入することに完全に集中します。私たちはかなり長い日働きますが、夕方にはチームとして一緒に楽しい時間を過ごします。日々のクライアントサポートに気を取られないように、チームのメンバーがオフィスに数人残っています。同様の「没入型」アプローチは、Firebrandなどのトレーニング会社で使用されています。 良いアイデア？ひどい考えですか？チームにインセンティブを与えるにはどうすればよいですか？ どんな考え/経験/アドバイスも大歓迎です。 乾杯

14 project-management  project  motivation  teamwork  team-building 

私の会社のチームリーダー\アーキテクトは、「ロジックで接続されたエンティティ」が1つの.csファイルに配置されていると、大規模プロジェクトの方が理解しやすいと主張しています。 私は引用する： 「ロジックとインターフェースとクラスの構造全体を1か所で見ることができます。これは反論の余地のない議論です。同じことを見るために、ツールを使用するために必要なファイルがたくさんあります図、ナビゲーション用のR＃など」 「貧弱な理論に従って、分離したファイルの軍隊はクールだと叫ぶかもしれませんが、既存のコードに変更を加えることになると、特にこのコードの作成者ではない場合、たくさんの散在するファイルを理解することは非常に困難です。フォーラムでは、「1つの列挙-1つのファイル」と書くことができますが、実際にはこのアプローチは決して使用すべきではありません 「...開発者間でのコードベースの分離に関しては、現在では同じファイルを同時に編集することは問題ではありません。マージは問題ではありません。」 列挙型、クラスなどごとに1つの.csファイルを作成する必要があることを何度も耳にし、読んでいます。これがベストプラクティスです。 しかし、私は彼を納得させることはできません。彼は、Jon Skeetのような有名なプログラマーを信頼していないと言います。ところで、このトピックに関するスキートの意見は次のとおりです。列挙型を見つけるのに最適な場所はどこですか？ どう思いますか？本当の問題はありますか？または、それは趣味の問題であり、組織のコーディング標準によって規制されるべきですか？

12 c#  .net  project  code-organization 

この2つの違いを理解していますが、同僚から、要件を機能的または非機能的（または移行的）としてラベル付けすることの利点について疑問に思います。なぜそうするのですか？彼は、あるプロジェクトの要件のリストを2日間調べたが、最終結果は「すべてをやる」という命令で別のビジネスエンティティにドキュメントを提出することだったため、彼が言ったことを費やしました。 私が恐れているのは、要件が1つのドキュメントにまとめられていることです。実用的な用語でメリットを説明しようとしましたが、売れませんでした。機能している要件と機能していない要件を文書化する利点を販売するにはどうすればよいですか。

12 documentation  project  management  requirements 

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

12 team  project  failure 

技術的なユーザーストーリーはスクラムで許可されていますか？もしそうなら、技術的なユーザーストーリーをスクラムで書くための標準テンプレートは何ですか？同じAs a <user> I want to do <task> so that I can <goal>ですか？ 私はいくつかのブログでas-a- de -veloper-is-not-a-user-storyを読んだことがありますが、スクラムはこれらを義務付けていないことも読んでいます。彼らは共有しているいくつかのブログがあるユーザーとしてシステムにユーザーストーリーを、そのようにas a <user who is not end user> i want to <system functionality> so that <some techinical thing>。それで、どれが標準ですか？ たとえば、次のようなユーザーストーリーがあります。 レビュー担当者として、ホテルや食べ物の写真をアップロードして、他のユーザーが見たり気に入ったりできるようにします ユーザーとして、写真のコメントを追加して、自分の意見をよりよく説明できるようにします これら両方のユーザーストーリーには、大きな技術項目があります-画像の保存と取得 次の説明とともに、「画像の保存と取得のメカニズム」というタイトルの技術的なストーリーを追加できますか？ 開発者として、ユーザーが必要に応じて画像を追加/表示できるように、画像を保存および取得するメカニズムを開発したい

11 project-management  agile  scrum  project  user-story 

私はプロジェクトの計画段階にあり、プロジェクトマネージャーを募集しています。コーディングを行い、プロジェクトのすべての部分に注目したいと思います。しかし、私はプロジェクトマネージャーがより良い結果を得るだろうと感じています。次のオプションがあります：1）コードではなくプロジェクトを管理する2）プロジェクトマネージャーを雇って自分でコーディングする 私は、プロジェクトマネージャーが開発チームにプロジェクトオーナーを置くことによって妨げられるのではないかと心配しています。プロジェクトを実行すると、チームがバラバラになり、プロジェクトが失敗する可能性があります。予算内に収まるためには、何らかの能力に関与する必要があります。 誰でもこの状況を経験したことがありますか？ 詳細：それぞれが特定の領域を担当する4人の社内開発者。開発者は、プロジェクトマネージャーの同意がある場合、作業を外部委託することもできます。

11 project-management  teamwork  project  project-planning 

私はかなり新しい開発者です。専門的には、インターンとして2年間、ジュニア開発者として6か月間、C＃でプログラムを作成しました。私の家族の友人は、VB.netで書かれたプロジェクトの助けを必要としています。私はVB.netを使用したことがないので、少し心配しています。 しかし、本当の疑問は、プロジェクトのドキュメントを見ると、本当に良いものは何もないと感じているという事実にあります。私は、現在の私の人生で望んでいるよりも多くのストレスを引き起こすと感じています。 経験豊富な開発者は、プロジェクトを採用するのか、それとも手放すのかをどのように決定しますか？決定を容易にするための良い指標は何ですか？ 編集 これは実際に彼が私に働きかけたい非常に大きなERPのようであり、彼はプログラミングについて何かを知っているとは思わないので、私は非常に後輩であるという事実さえ彼の心を越えたとは思わない。

11 project  contract 

この質問は、フリーランスからウェブデザイン会社に転職して以来、過去3か月間私を悩ませてきました。 営業担当者は、次の一連の質問によく似た質問をします。 ウィジェットをプログラムするにはどれくらいの費用がかかりますか このWebサイトをこのソフトウェアに変換するのに何時間かかりますか。 （ウェブサイトが現在何を実行しているか知らずに） 等 情報なしで見積もりを行うにはどうすればよいですか？（いいえ、詳細情報を求めることはできません！） プロジェクトが予算を超えている場合、それは悪いことです。最近、ウェブサイトを新しいプラットフォームに移行するコストを計算するときに、メニュー全体を見逃してしまったため、プロジェクトは予算を超えました。私の上司はまったく満足していませんでしたし、このようなことは避けられないというのが私の意見です。 2.予算超過を処理するための一般的な慣行は何 ですか？Web開発などのプロジェクトは予算超過することがよくありますか？ Web開発/デザイン/類似会社で働いている場合： 3.請求可能時間システムはどのように機能しますか？ 私にとっては、どのプロジェクトに何時間を費やし、それらが請求可能または内部（請求不可）であるかを記録する時間追跡アプリケーションがあります。週にxx時間の請求可能時間を満たしていない場合、最終的にトラブル/解雇になります。あなたが会社のためか、請求可能ではないクライアントのために行う作業は、このシステムの一部ではない、と私たちはしばしば持っている任意の代替システムが存在する場合、私は思ったんだけどので、内部の作業を行います。 編集： OK私はデザイナーではなく、この会社の開発者です:) 第二に、私は給与を支払われていますが、経営陣がそれをどのように見ているかを以下に示します。週に35時間働く必要があります。その35時間以内にクライアントに請求する仕事をしている可能性があります。プロジェクトが50時間かかり、私が55時間かかる場合、その5時間は予算を超えていない別のプロジェクトに費やされた可能性があるため、お金を「失いました」。 別の例として、プロジェクトが1つしかない場合、2週間で期限が来て、社内で仕事をすることに1日費やします。もしその日働いていたら、一日を早く終えても仕事はありません。いずれにせよ、仕事は契約であるため、私が仕事をする日に関係なく、同じ金額が支払われます！

11 project  budget 

この場合はNetbeansで作成されたプロジェクトを追加したいのですが、この質問はほとんどのIDEで一般的です。それは単に、リポジトリに何を含めるべきかということです。たとえば、Netbeansはnbprojectフォルダーを作成し、eclipseは.settingsフォルダーを作成します。これらをリポジトリに含めた場合、プロジェクト固有の設定を含めるか含めないことの利点/欠点は何ですか。 この場合、それは個人的なプロジェクトなので、他の人がプロジェクトに取り掛かることはないと思いますが、最小限のプロジェクト設定を追加して、プロジェクト自体が別のマシンで簡単に作業を開始できるようにするとよいでしょう。

10 programming-practices  git  project  maintainability 

私のグループのほとんどの人が、関数型プログラミングをほとんどまたはまったく理解していないオブジェクト指向プログラミングのバックグラウンドを持っている状況にあります。クロージャーのような基本的なことすらありません。 それらを関数型コーディングスタイルに導入する良い方法とは何かについて何か提案はありますか？私たちが行う多くのコーディングは、特定のケースに対して機能的な方法を実行する場合、短縮することができます。 機能とコーディングのパラダイムについては、すでにいくつかのプレゼンテーションを行っています。残念ながら、Haskell（基本的にレガシーコードはC、C ++、Java）のような適切な関数型プログラミング言語を使用していないため、これらを使って何でもする必要があります。

10 functional-programming  project 

私はソフトウェア開発方法論を含む小さな研究論文を書いています。私は利用可能なすべての方法論を調べていましたが、すべての方法論から、他の方法の基礎を提供しているものはあるのでしょうか。 例として、 アジャイル、プロトタイピング、クリーンルーム、反復、RAD、RUP、スパイラル、ウォーターフォール、XP、リーン、スクラム、Vモデル、TDDの方法論を見てみましょう。 私たちはそれを言うことができます： プロトタイピング、反復、スパイラル、ウォーターフォールは他のものの「基礎」です？ それとも「基礎」などはなく、それぞれの方法論には独自の歴史がありますか？ もちろん、私は自分の論文ですべての方法論について説明したいと思いますが、それを行う時間がないので、どの方法論を代表として見ることができるかを知りたいのです。

10 project-management  language-agnostic  project  development-methodologies  methodology 

ここで何が質問されているのかを理解することは困難です。この質問は、あいまいで、あいまいで、不完全で、過度に広い、または修辞的であり、現在の形では合理的に回答することができません。再開できるようにこの質問を明確にするヘルプについては、ヘルプセンターに アクセスしてください。 7年前休業。 私は複数のAndroidプロジェクトに取り組んでいるインディーデベロッパーです。異なるプロジェクトで同じ機能を維持することに問題があります。たとえば、私のアプリのうち3つは同じ2つのクラスを使用しています。これらは異なるプロジェクトであるため、これらのクラスを変更する必要がある場合は、3回変更する必要があります。この種の一般的な問題に対する簡単な解決策はありますか？

9 project  personal-projects  code-organization 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 数年前に私の過去のプロジェクトの詳細を覚えようとするのに苦労した後、プログラマーは通常それを追跡する方法を疑問に思っていましたか？ このような情報は、就職の面接などで役立ちます。 使用している技術、直面している課題などを「ジャンボCV」のようなものに書き留めていますか？それともあなたはあなたの記憶を信頼していますか？

9 interview  resume  project