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

プログラマとして、私たちは常に「どれくらいかかるか」と尋ねられていますか？ そして、ご存知のように、状況はほとんど常に次のようなものです。 要件は不明です。すべての影響を詳細に分析した人はいません。 この新機能はおそらく、コード内で行ったいくつかの仮定を破り、リファクタリングする必要のあるすべてのことをすぐに考え始めるでしょう。 過去の課題から他にやることがあり、その他の作業を考慮に入れた見積もりを考え出す必要があります。 「完了」の定義はおそらく不明です。いつ実行されるのでしょうか。コーディングを終えたときのように「完了」、または「ユーザーが使用中」のように「完了」 あなたがこれらすべてのことをどれほど意識していても、「プログラマーのプライド」によって、本来考えていたよりも短い時間が与えられたり受け入れられたりすることがあります。締め切りと経営陣の期待のプレッシャーを感じるときは特に。 これらの多くは、組織的または文化的な問題であり、単純で簡単に解決することはできませんが、実際には、見積もりを求められており、合理的な答えを期待しています。それはあなたの仕事の一部です。単純に言うことはできません：私は知りません。 その結果、私はいつも私が後で達成できないことに気づくと見積もりを出すことになります。それは何度も起こりました、そして、私はいつもそれが再び起こらないことを常に約束します。しかし、そうです。 見積もりを決定して配信するためのあなたの個人的なプロセスは何ですか？どんなテクニックが便利だと思いましたか？

652 project-management  development-process  estimation  time-management 

National GeographicのMegaStructuresシリーズを見て、大規模なプロジェクトがどれほど高速に完了するかを知りました。準備作業（設計、仕様など）が紙の上で行われると、巨大なプロジェクトの実現自体はわずか数年、時には数ヶ月かかります。 たとえば、エアバスA380は 「2000年12月19日に正式に打ち上げられました」、「2005年3月上旬に」、航空機はすでにテストされています。同じことは、巨大な石油タンカー、高層ビルなどにも当てはまります。 これをソフトウェア業界の遅れと比較すると、ほとんどのITプロジェクトがなぜこんなに遅いのか、より正確には、なぜ同じ規模で同じ規模で、十分な人数の人がいるほど速くて障害がないのか疑問に思わずにはいられません。 エアバスA380などのプロジェクトは、両方を提示します。 予期せぬ主なリスク：これは最初に製造された航空機ではありませんが、技術の限界を押し広げており、小さな旅客機でうまく機能したものは、物理的な制約のために大きな旅客機では機能しません。同様に、たとえばボーイング747が完成した1969年には利用できなかったため、まだ使用されていない新しい技術が使用されています。 一般的な人的資源と管理に関連するリスク：プロジェクトの途中で辞める人々、休暇中に人に連絡することができない、通常の人為的ミスなど これらのリスクにより、人々はまだこれらの大型旅客機のようなプロジェクトを非常に短い期間で達成しており、配達の遅延にもかかわらず、それらのプロジェクトは依然として非常に成功しており、高品質です。 ソフトウェア開発に関しては、プロジェクトは旅客機ほど大きく複雑ではなく（技術的にも管理の面でも）、現実世界からの予期しないリスクがわずかに少なくなっています。 それでも、ほとんどのITプロジェクトは遅くて遅く、プロジェクトにさらに開発者を追加することは解決策ではありません（10人の開発者から2000人のチームに行くと、プロジェクトをより速く提供できる場合があります。計画し、それをまったく完了しないリスクを高めます）。 まだ配信されているものには多くのバグが含まれていることが多く、連続したサービスパックと定期的な更新が必要です（元の製品のバグにパッチを当てて航空機がcrash落するのを防ぐために、週に2回すべてのAirbus A380に「更新プログラムをインストール」することを想定してください）。 そのような違いはどのように説明できますか？それは、ソフトウェア開発業界が若すぎて、大規模でほぼ完璧な製品を非常に高速に提供するために、単一のプロジェクトで数千人を管理できないという事実だけに起因するのでしょうか？

509 project-management  development-process  time-management  industry 

これが一般的な質問ではないことを願っています。経験豊富なアドバイスを本当に活用できました。 私は、過去10〜20年にわたって広大なコードベースを一緒に使用してきたかなり小さな科学者の店で、唯一の「SWエンジニア」として新たに採用されました。（実質的に廃止された言語で書かれました：G2 -Pascal with graphicsを考えてください）。プログラム自体は、複雑な化学処理プラントの物理モデルです。それを書いたチームは信じられないほど深いドメイン知識を持っていますが、プログラミングの基礎に関する正式なトレーニングはほとんど、またはまったくありません。彼らは最近、存在しない構成管理の結果についていくつかの難しい教訓を学びました。また、コード自体に文書化されていない「スラッジ」が大量に蓄積されているため、メンテナンス作業が大幅に妨げられています。私はあなたに状況の「政治」をspareしまない（常にある 政治！）、しかし言うことで十分ですが、先の道に必要なものについて意見のコンセンサスはありません。 彼らは、現代のソフトウェア開発の原則のいくつかをチームに提示し始めるように私に頼みました。彼らは、コーディング規約、ライフサイクル管理、高レベルの設計パターン、およびソース管理に関する業界標準の実践と戦略のいくつかを紹介してほしいと思っています。率直に言って、それはかなり困難な作業であり、どこから始めればよいのかわかりません。 最初は、The Pragmatic Programmer、またはFowler's Refactoring（ "Code Smells"など）の中心概念のいくつかでそれらを指導したいと思っています。また、多くのアジャイル手法を紹介したいと思っています。しかし、最終的には、効果的にするために、5〜7の基本的な基礎に磨きをかける必要があると思います。言い換えれば、彼らが現実的に実装を開始できる最も重要な原則または慣行は何であり、それは彼らに最も「大金」を与えるでしょう。 それが私の質問です：スパゲッティをまっすぐにするのに役立つ（そして将来的にそれを防ぐために）最も効果的な戦略のリストに何を含めますか？

470 project-management  agile  development-process  maintenance  sdlc 

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

335 project-management  team  project  failure  legacy-code 

私は、ユーザーがTwitter、GoogleなどのOAuth資格情報を使用してログインできるようにするWebサイトに取り組んでいます。これを行うには、これらのさまざまなプロバイダーに登録し、所有している極秘APIキーを取得する必要がありますさまざまな身体部分からの誓約で保護する。キーがギャンクされると、パーツがヤンクされます。 APIキーは実行時に認証要求を実行するために使用されるため、ソースと共に移動する必要があります。私の場合、キーはアプリケーション内の構成ファイルまたはコード内に存在する必要があります。単一のマシンからビルドして公開する場合、それは問題ではありません。ただし、ソース管理をミックスに組み込むと、事態はさらに複雑になります。 私は安っぽい野郎なので、クラウド内のTFSやGitHubなどの無料のソース管理サービスを使用することを好みます。これにより、若干の難問が残ります。 APIキーがコード内にあり、コードが公開リポジトリで利用可能な場合、どうすれば体を傷つけずに保持できますか？ これを処理する方法はいくつか考えられますが、満足できるものはありません。 コードからすべての個人情報を削除し、展開後に編集することができます。これは実装するのが非常に苦痛であり（多くの方法を詳しく説明しません）、オプションではありません。 暗号化できました。しかし、私はそれを解読しなければならないので、ソースを持っている人は誰でもそれを行う方法を見つけ出すことができました。無意味。 私は個人的なソース管理にお金を払うことができました。LOL j / kはお金を使いますか？お願いします。 言語機能を使用して、機密情報をソースの他の部分から分離し、ソース管理から保護することができます。これは私が今やっていることですが、誤ってシークレットファイルをチェックインすると簡単に失敗する可能性があります。 開発、デバッグ、展開を通じてスムーズに動作し、同様に確実に動作するプライベートを世界と共有しないことを保証する方法を本当に探しています（snapchatを除く）。これは完全に非現実的です。 それでは、現実的に何ができますか？ 技術的な詳細：VS2012、C＃4.5、ソース管理はTFサービスまたはGitHubのいずれかになります。現在、部分クラスを使用して、ソース管理に追加されない別の.csファイルで機密キーを分割します。GitHubには、.gitignoreを使用して部分的なクラスファイルがチェックインされないようにすることができるという利点があると思いますが、以前はそれを台無しにしました。「ああ、よくある問題、これがあなたのやり方です」を望んでいますが、私は「それができる限り吸わない」ために解決する必要があるかもしれません：/

217 project-management  version-control  development-process  api 

私はこの質問を何度も何度も熟考しています。私は物事を正しい方法でやりたいと思っています：保守しやすい、クリーンで理解しやすい正しいコードを書くことです。しかし、私がやることは、パッチの上にパッチを書くことです。時間がない、クライアントが待っている、バグを一晩で修正する必要がある、会社がこの問題でお金を失っている、マネージャーが一生懸命押すなどの理由で。 長期的にはこれらのパッチにより多くの時間を浪費していることを私は完全によく知っていますが、今回は数か月にわたる作業なので、誰も気にしません。また、私のマネージャーの一人が言っていたように、「今すぐ修正しないと長期になるかどうかわかりません。」 これらの無限の現実/理想の選択サイクルに巻き込まれているのは私だけではないと確信しています。私の仲間のプログラマー、あなたはどのようにこれに対処しますか？ 更新：この興味深い議論に感謝します。非常に多くの人々が、コードの量と品質の間で毎日選択しなければならないのは悲しいことです。それでも、驚くほど多くの人々が、この戦いに勝つことができると考えているので、この励ましに感謝します。

180 project-management  programming-practices  management  workflows  software-schedules 

私は長年ソフトウェア開発者として働いています。多くの開発者が製品の開発に関与するにつれて、プロジェクトがより複雑で維持できなくなるというのが私の経験でした。 開発の特定の段階でソフトウェアが「ハッカー」と「ハッカー」を獲得する傾向があるようです。特に、アーキテクチャを定義したチームメンバーが会社で働いていない場合です。 何かを変更しなければならない開発者が、アーキテクチャの全体像をつかむのに苦労しているのはイライラするものです。したがって、問題を修正したり、元のアーキテクチャに対して機能する方法で変更を加えたりする傾向があります。その結果、コードはますます複雑になり、理解しにくくなります。 何年もの間ソースコードを本当に保守しやすくする方法について何か役に立つアドバイスはありますか？

156 project-management  maintainability 

これは実際には技術的な質問ではありませんが、ソース管理とベストプラクティスに関する他の質問がいくつかあります。 私が働いている会社（匿名のまま）は、ネットワーク共有を使用してソースコードとリリースされたコードをホストしています。開発者または管理者は、ソースコードがリリースされているか、どのバージョンであるかなどに応じて、ソースコードを適切なフォルダーに手動で移動する責任があります。ファイル名とバージョン、および変更内容を記録する場所の周りにさまざまなスプレッドシートが点在しており、一部のチームは各ファイルの先頭に異なるバージョンの詳細も記載しています。各チーム（2〜3チーム）は、社内でこれを異なる方法で行うようです。あなたが想像できるように、それは組織化された混乱です-「正しい人々」は彼らの物がどこにあるかを知っているので組織化されていますが、それはすべて異なっていて、それはいつでも何をすべきかを覚えている人々に依存しているため混乱です。 私はしばらくの間、ある種の管理されたソース管理を推進し​​ようとしてきましたが、社内で十分なサポートを得ることができないようです。私の主な議論は次のとおりです。 私たちは現在脆弱です。いつでも誰かが私たちがしなければならない多くのリリースアクションの1つを行うのを忘れることができます。これは、バージョン全体が正しく保存されないことを意味します。必要に応じて、バージョンをつなぎ合わせるのに数時間または数日かかる場合があります バグ修正と一緒に新機能を開発しており、一部の作業がまだ完了していないため、多くの場合、どちらか一方のリリースを遅らせる必要があります。また、バグ修正だけが必要な場合でも、新しい機能を含むバージョンを使用するようにお客様に強制する必要があります。 複数の開発者が同じプロジェクトを同時に使用しているため、Visual Studioで問題が発生しています（同じファイルではありませんが、依然として問題が発生しています） 開発者は15人しかいませんが、私たちはすべて異なる方法で作業を行っています。私たち全員が従わなければならない標準的な全社的なアプローチをとる方が良いと思いませんか？ 私の質問は： このサイズのグループにソース管理がないのは正常ですか？ 私はこれまで、ソースコントロールを持っていないための唯一の漠然とした理由が与えられている-あなたが示唆している何の理由の可能性のために有効ではない 上記の情報与えられ、ソースコントロールを実装しますか？ 任意のより多くの理由があるため、私は私の兵器庫に追加できるソースコントロールは？ 私は主に私がなぜそんなに抵抗したのか感じてもらいたいので、正直に答えてください。 私は、最もバランスのとれたアプローチを取り、3つの質問すべてに答えたと思う人に答えます。 前もって感謝します

152 version-control  project-management  management  release-management 

ソフトウェア業界で流行している最悪の偽りの経済（それは最終的に貯蓄以上の費用がかかるお金を節約する方法）とは何ですか？

126 programming-practices  project-management 

プロジェクトがソース管理に最初にコミットするのに十分であるかどうかはわかりません。プロジェクトが「フレームワーク完了」になるまでコミットを延期する傾向があり、それ以降は主に機能をコミットします。（これには大きすぎるコアフレームワークを持つほどの個人的なプロジェクトは行っていません。）これがベストプラクティスではないと感じていますが、何が間違っているのかわかりません。 たとえば、1つのコードファイルで構成されるプロジェクトがあるとします。約10行のボイラープレートコードと、プロジェクトを非常に基本的な機能（1つまたは2つの機能）で動作させるために100行かかります。最初にチェックインする必要があります： 空のファイル？ 定型コード？ 最初の機能は？ 他のポイントで？ また、特定の時点でチェックインする理由は何ですか？

118 project-management  version-control  development-process 

私の友人はソフトウェア会社のプロジェクトマネージャーです。彼にとって最もイライラすることは、彼のエンジニアが頻繁に仕事を辞めることです。同社は、新しいエンジニアの採用、プロジェクトの移管、および安定した品質の製品の維持に努めています。人々が去るとき、それは私の友人を狂わせます。 これらのエンジニアは非常に若くて野心的で、より高い給料とより良いポジションを求めています。大ボスは金銭的な観点からしか考えておらず、彼の理論は「3人の初心者は常に1人のベテランよりも優れている」ということです（経験豊富なエンジニアとしては間違っていると思います）。私の友人はその理論が嫌いです。 彼へのアドバイスは？

114 project-management  quality 

以前の雇用では、プロジェクトマネージャー（PM）は、私のプロジェクトのコードの納期に満足していませんでした。プロジェクトリーダーから、PMはタスクと納期に与えた時間の見積もりをロックインする契約に署名することを検討していると言われました。 プロジェクトの状況は、新しいテクノロジー、コードベース、コーディング標準、および非常に変更しやすい要件を扱っていたということでした。私は新しいことを学び、変化し続ける要件にできる限りそれらを適用していました。反復全体の要件は2〜3倍に増加し、完了までの見積もりは約5〜8倍に増加しました。変更されなかったのは、見積もりと納期のみでした。 はい、私はほとんどの締め切りを逃してしまいました。そして、私は開発チーム全体の誰もそれを知らないので、本当に助けてくれないいくつかの非常に新しい技術に取り組んでいました。少なくとも簡単ではありません。 そのとき、私は、PMが彼の数字を加算することを望んでいたように思えたので、私は常に作業コードを時間通りに配信することを「保証」する契約に署名することを望みました。期限内に納品できなかった場合、PMは署名済みの契約でそれを使用できると思います。 次に起こったことは、他のプロジェクトマネージャーやプロジェクトリーダーが私を弁護し、それを起こさせなかったことだと思います。 私の質問は、これはマネージャーについて赤旗を上げるべきですか？マネージャが契約書に署名してソフトウェア開発者の時間の見積もりを確定するのは一般的な慣行ですか？またはこの場合、試してみてください。 私はフルタイムの従業員であり、独立したコンサルタントではないことに注意してください。 更新：毎週新しい見積もりを行ったことを付け加えたいと思いますが、元の見積もりと納期はPMが修正したものだったようです。

113 project-management  contract  estimation 

私はジュニア開発者であり、変更を正当化することができ、チームが作業を完了するのに役立つ場合、チームのプロセスを形作るのに役立つ能力を与えられています。私の過去の企業は、管理から来るプロセスを多かれ少なかれ厳密に定義していたので、これは私にとって新しいものです。 私のチームはかなり小さく、やや新しい（<3歳）です。彼らは欠けています： 明確に定義されたソフトウェア開発/作業管理フレームワーク（スクラムなど） 強力な製品所有権 明確に定義された役割（たとえば、ビジネススタッフが手動テストを行う） 定期的なスタンドアップミーティング 統合された問題追跡プロセス（ツールがあり、プロセスはまだ開発中です） ユニット、システム、リグレッション、または手動テストスイートまたはリスト ビジネスロジックとプロセスに関するドキュメント 社内および顧客向けのヒントを文書化するナレッジベース そしてリストは続きます。経営陣は、価値が正当化され、最も重要な作業（開発）が完了するのを助ける限り、改善の実施に対してオープンです。ただし、基本的な前提は、誰もあなたのためにそれをするつもりはないので、実装の所有権を取る必要があるということです。そして、言うまでもなく、上記のプロジェクトのいくつかは、時間のかかる疑いもなく、重要なものであり、明らかに開発作業ではありません。 時間が経つにつれて上記のことを試してプッシュする（後輩の）開発者の努力の価値はありますか？または、「自分のレーンにとどまり」、開発に集中し、プロセスの定義と最適化の大部分を管理者に任せることが最善でしょうか？

108 project-management  scrum  development-process  process  product-owner 

異なるバージョンの命名規則は異なるプロジェクトに適していますか？何を使用し、その理由は？ 個人的には、16進数のビルド番号（11BCFなど）を好みます。これは非常に定期的に増やす必要があります。そして、顧客向けにシンプルな3桁のバージョン番号、つまり1.1.3。 1.2.3 (11BCF) <- Build number, should correspond with a revision in source control ^ ^ ^ | | | | | +--- Minor bugs, spelling mistakes, etc. | +----- Minor features, major bug fixes, etc. +------- Major version, UX changes, file format changes, etc.

107 project-management  development-process  naming  versioning 

私は常に仕事で厳密にDRYの原則に従うようにしています。怠inessな状態からコードを繰り返すたびに、後でそのコードを2か所で維持する必要が生じたときに戻ってしまいます。 しかし、多くの場合、互いに参照できない 2つのプロジェクトで再利用する必要がある小さなメソッド（10〜15行のコード）を記述します。この方法は、ネットワーク/文字列/ MVVMなどに関連するものである可能性があり、元々のプロジェクトに固有ではない一般的に有用な方法です。 このコードを再利用する標準的な方法は、再利用可能なコード用に独立したプロジェクトを作成し、必要なときにそのプロジェクトを参照することです。これに伴う問題は、2つの理想的ではないシナリオのいずれかになってしまうことです。 最終的に、数十/数百の小さなプロジェクトになります-それぞれが再利用する必要のある小さなクラス/メソッドを収容します。.DLLほんの少しのコードだけでまったく新しいものを作成する価値はありますか？ 関係のないメソッドとクラスのコレクションが増え続ける1つのプロジェクトになります。このアプローチは、私が以前働いていた会社がやったことです。彼らには、base.common前述のようなネットワーク、文字列操作、MVVMなどのフォルダーを持つプロジェクトがありました。それは信じられないほど便利でしたが、不要なすべての無関係なコードを不必要にドラッグして参照しました。 だから私の質問は： ソフトウェアチームは、プロジェクト間で少量のコードを再利用するのに最適な方法を教えてください。 特に、この分野でポリシーを持っている会社で働いている人や、私のように個人的にこのジレンマに直面している人に興味があります。 注：「プロジェクト」、「ソリューション」、および「参照」という言葉の私の使用は、Visual Studioでの.NET開発の背景から来ています。しかし、この問題は言語とプラットフォームに依存しないと確信しています。

102 project-management  code-reuse  projects-and-solutions  dry