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

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私の職場の幹部が私と私の開発者グループに質問をしました。 C＃開発者は1か月に何行のコードを生成できますか？ 古いシステムをC＃に移植する予定でしたが、プロジェクトの計画の一環としてこの方法を望んでいます。 ある（明らかに信用できる）情報源から、彼は「10 SLOC / 月」と答えましたが、彼はそれに満足していませんでした。 グループは、状況の長いリストに依存するため、これを指定することはほとんど不可能であることに同意しました。しかし、私たちは彼にもっと合った答えを考え出さなければ、その男性は去らない（または私たちに非常に失望しない）と言うことができました。そこで彼は「10 SLOC / 日」という何倍も良い答えを残しました この質問に答えられますか？（オフハンドまたは何らかの分析を含む）

21 productivity  project-management  c# 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私はソフトウェアエンジニアであり、過去数年間、事実上ソフトウェアプロジェクトマネージャーになりました。そのため、R＆D /エンジニアリング部門の健全性を維持するために、お客様はリクエストに応じて私に来ることに慣れています。私はこの分野での経験がないので、ソフトウェアプロジェクトのプロジェクトマネージャーとして行動するのは初めてです。私は他のものを管理しましたが、ソフトウェアは管理していません。 それでは、ソフトウェアプロジェクトをどのように管理し、優先順位をマークしますか？リクエストはまれにしか届かないため、他の人のために何かに取り組むことができ、その後、別の人が「急いで」仕事をする必要があります。ファーストカム、ファーストサーブと言う方が簡単ですか、それとも最もお金を持っている人ですか？

21 project-management  requirements  feature-requests 

アプリケーションを開発しています。別のコーダーによって開発されたライブラリが含まれ、このライブラリは複数のネットワーク接続を介してサーバーと通信し、これには複数のスレッドが連携して動作する必要があります。サーバー側のコードは非常に複雑であり、ソースコードにはアクセスできません。 最近、時々アプリケーションをクラッシュさせるマンデルバグを発見しました。一度再現してスタックトレースを取得したので、バグレポートを開きました。バグ自体は簡単に修正できます（バックグラウンドスレッドの1つでキャッチされないWeb例外により、CLRはプログラムを終了します）。 問題は、開発者がバグを修正することを拒否していることです。「彼はそれが存在することを確信していない」からです。残念ながら、上司は彼の側にいて、バグの存在を証明するための「堅実なテストケース」を作成し、ユニットテストでそれがなくなったことを確認しない限り、このバグは修正できないと言います。バグの性質上、基本的に不可能なこと。 何かアドバイス？

20 project-management  teamwork  requirements  collaboration 

ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 8年前に閉鎖されました。 この質問はして移行され、それがソフトウェア工学スタック所に答えることができるので、スタックオーバーフローから。 8年前に移行され ました。 現在のプロジェクトアーキテクチャを開発し、独自に開発を開始しました（次のようなものに到達しますrevision 40）。 シンプルな地下鉄ルーティングフレームワークを開発しており、私の設計は非常によくできているようです- いくつかのメインモデル、対応するビュー、メインロジック、データ構造が「あるべき」ようにモデル化され、レンダリングから完全に分離され、アルゴリズム部分も実装されましたメインモデルとは別に、少数の交差点がありました。 私は、その設計をスケーラブルで、カスタマイズ可能で、実装が容易で、主に「ブラックボックスの相互作用」に基づいて相互作用し、非常に素晴らしいと呼びます。 さて、何が行われたか： 対応するインターフェースの実装を開始し、便利なライブラリを移植し、アプリケーションの一部の実装スタブを作成しました。 コーディングスタイルとそのコーディングスタイルの使用例（自分の記述コード）を説明したドキュメントがありました。 コード（スマートポインターでラップ）などC++を含む、多かれ少なかれ最新の開発手法の使用を強制しましたno-delete。 具体的なインターフェイス実装の目的と、その使用方法を文書化しました。 単体テスト（ほとんどの場合、「実際の」コードがあまり多くないため統合テスト）と、すべてのコア抽象化のための一連のモック。 私は12日間休みました。 現在何がありますか（プロジェクトはチームの他の4人のメンバーによって開発されました）： すべてのプロジェクトの上に3種類のコーディングスタイル（私は推測する、それらの2つが同じスタイルを使用することに同意した:)、同じことが私たちの抽象化の命名にも適用される（例えばCommonPathData.h、SubwaySchemeStructures.h）基本的にはいくつかのデータ構造を宣言し、ヘッダーです。 最近実装された部品のドキュメントの絶対的な不足。 私が最近呼び出すことができるものsingle-purpose-abstractionは、少なくとも2つの異なるタイプのイベントを処理し、他の部分と密接に結合しています。 使用されるインターフェイスの半分には、メンバー変数が含まれるようになりました(sic!)。 ほぼすべての場所での生のポインターの使用。 " (Rev.57) They are unnecessary for this project"のため、ユニットテストは無効です。 ... （おそらくすべてではない）。 コミット履歴は、私の設計が過剰であると解釈され、人々がそれを個人用自転車と再実装されたホイールと組み合わせ始め、コードチャンクの統合に問題があったことを示しています。 さて、プロジェクトはまだやらなければならないことのほんの一部をしているだけで、深刻な統合の問題があります。メモリリークがあると思います。 この場合にできることはありますか？ 私はすべての努力が利益をもたらさなかったことに気づきましたが、締め切りはもうすぐであり、私たちは何かをしなければなりません。誰かが同様の状況にありましたか？ 基本的には、プロジェクトの良い（まあ、できる限りのことをすべてやった）ことは良いことになると思いましたが、間違っていることは理解しています。

20 c++  project-management  refactoring  teamwork 

マネージャーとして、私は常に最先端の仕事を生み出せるとは限りません。一部のプロジェクトはメンテナンスモードで実行され、会社の健全なフリーキャッシュフローを生成します。 開発者として、このプロジェクトに取り組むには何が必要ですか？私は作品のブランド変更を考えていましたが、ここで多くの助けを借りてできました。 編集：提案をありがとうございました。ここまでは次のとおりです。 開発者の関心ごとの仕事のローテーション 柔軟な作業環境 ペットプロジェクトに取り組む時間を割り当てる 社会と楽しみ プロジェクトのブランディング これを他のプロジェクトの足がかりとして使用してください

20 project-management  motivation 

この質問はして移行され、それがソフトウェア工学スタック所に答えることができるので、スタックオーバーフローから。 8年前に移行され ました。 プログラマーに非常に頻繁に従うことを求めなければならないいくつかのルールがあります。彼らはコードを書き、それがうまくいけば、仕事は完了です。最も基本的なルールは次のとおりです。 変更をコミットする ビューまたはコントローラーでモデルの問題を記述しない ハードコーディングを避ける あなたの経験を教えてください。これをどのように管理しますか？

20 project-management  code-reviews 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 プロジェクトマネージャーがさまざまなタスクを完了するための時間を見積もるように求めたときに、我慢できないことがあります。推定は推測であり、推測は間違っている可能性があります。一般に、要件とドキュメントが適切でないと、推測が誤ってしまいます。 ですから、プロジェクトマネージャーが、XとYのタスクにかかる時間と、クライアントからほとんど知られていないものや収集したものに基づいて番号を割り当てるのがどれだけ難しいかを推測しようとしていたのではないかとよく疑問に思います。 私の質問は次のとおりです。優れたプロジェクトマネージャーにはプログラミングの背景が必要ですか？ あるいは、問題は、優れたプロジェクトマネージャーが以前は優れたプログラマーであった必要があるということでしょうか？ 相関関係はありますか？

20 project-management  experience 

私が取り組んできたより伝統的なプロジェクトでは、プロジェクトマネージャー（および、大規模なプロジェクトでは、1人の担当者が利用できない場合、アソシエイト/代理/アシスタントのプロジェクトマネージャーが存在する可能性があります）は、プロジェクトと顧客とのコミュニケーションの責任者ですヘルスとステータスの更新、スケジューリングと予算の決定、プロセスの管理、チームがタスクを完了するために必要なものを確保するなど。 ただし、スクラムでは、これらの責任はプロダクトオーナーとスクラムマスターの間で分割されます。製品所有者は顧客の声です。顧客と直接やり取りし、ユーザーストーリーを作成し、製品バックログやその他のユーザー/顧客が直面する問題を整理して優先順位を付けます。ScrumMasterはプロセスを処理し、会議（推定と計画を含む）を監督し、障害を取り除き、プロジェクトの全体的な健全性を監視し、必要に応じて調整します。 Wikipediaを含む複数の情報源で、ScrumMasterとプロダクトオーナーの役割は2人の異なる人物が担うべきだと読みました。私は読んだだけでなく、両方のアクティビティが1人の個人によって処理される、成功した「伝統的な」スタイルのプロジェクトに取り組みました。実際、1人から3人の人々がプロジェクト（人事/人員を含む）とプロセスレベルのタスクを処理する責任があることは、彼らがしばしば手をつないで行くので、より理にかなっています。プロセスの変更は、スケジューリング、予算編成、品質、およびその他のプロジェクトレベルの目標に影響を与え、プロジェクトの変更はプロセスに影響を与えます。 スクラムがこれらのアクティビティを2つの役割に分離する必要があるのはなぜですか？これは実際にどのような利点を提供しますか？プロダクトオーナーとスクラムマスターが同じ個人であるスクラムプロジェクトで成功した人はいますか？

19 project-management  scrum  team  roles 

私のPivotal Trackerボードにいくつかの技術的負債に対処するユーザーストーリーをいくつか追加しました。それらを機能（速度レベルを維持）または雑用/バグ（速度を低下）として考慮する必要がありますか？どちらか一方を一貫してやったとしても、長期的には何の違いも生じないことは理解していますが、技術的な負債のストーリーを追加するたびに判断しなければなりません。 いくつかの考え： それらは実際にはバグではなく、何も壊しません ユーザーに影響を与えないのは低レベルの実装であるため、ユーザーは何も要求していませんが、長期的な開発を容易にします あなたもユーザに付加価値を話、などの機能を定義した場合）彼らは、ユーザーが行うすべての直接的な利益が、その後B）は表示されませんしない限り、彼らはその可能な将来の開発/メンテナンスを行うために行い、追加値を、ちょうど今ではない 私は実際に作業を行うかどうか、またはいつスケジュールするかを決定していません。プロジェクト管理ツールで技術的負債と呼ぶべきものとその理由を知るだけです。

19 project-management  agile  technical-debt  kanban 

私たちはプロジェクトでスクラムをフォローしています。ほとんどの場合、スクラムマスターがタスクを割り当てます。しかし、私は多くのスクラムの本を読んで、スクラムが逆に機能し（「プル」アプローチ）、チームメンバーがタスクや機能を取り上げることを読みました。スクラムマスターはタスクに正しいアプローチを割り当てていますか、それともアジャイルイデオロギーに反していますか？

19 project-management  agile  scrum 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 保守性の問題を抱えたコードプロジェクトを担当しました。プロジェクトを安定した足場にするために何ができますか？ 私は、単体テスト、IOC、MEF、静的クラス、純粋なデータセットなど、多くの重要なものが欠けている非常に大きな多層.NETシステムで作業している場所にいることに気づきました。わずか24年ですが、私はここに3年近く滞在しました（このアプリは5年間開発中です）。主に時間の制約により、他のがらくたに合うようにたわごとを追加しています。空き時間に多くのプロジェクトを行った後、これらすべての概念がどれほど重要かを理解し始めました。また、従業員の交代により、私はこのプロジェクトのチームリーダーになりました。このアプリを改善するためのスマートな方法を考え出したいと思います。経営陣に価値を説明できる方法。私は何をしたいのかというアイデアを持っていますが、それらはすべて前もって大きな利益を得ることができず、とても圧倒的です。人々がどのようにこれに対処したか、または対処したかについての物語は、非常に興味深い読み物です。ありがとう。

19 .net  unit-testing  project-management  patterns-and-practices 

特定のプロジェクトを成功させるために必要なプログラマーの人数をどのように知っていますか？ 私が働いている会社は、クライアント企業の注文を処理します。場所に基づいた在庫管理、注文処理、船荷証券の生成、請求書作成、貨物監査、レポート作成（おそらく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 

Joel Spolskyは、有名なブログ記事「ヒューマンタスクスイッチが有害だと考えている」を書いています。 私は前提に同意し、常識のように思えますが、タスクスイッチのオーバーヘッドを計算するための研究やホワイトペーパーがありますか、それとも証拠は単なる逸話ですか？

18 project-management  performance 

私が現在取り組んでいるプロジェクトには問題があります。バグやタスクは、あまりにも新しい人や経験の浅い人に割り当てられることが多く、彼らの仕事は将来的にさらにバグを生み出すことになります。問題は、コードの品質の問題のために、ソフトウェアの一部が他の部分よりも「危険」であるということです。私は、タスクに関連するリスクを推定し、どの開発者にどのタスクが割り当てられるかに細心の注意を払うことで、この問題に対処しようとしています。 JIRAを使用しているため、この推定を追跡するために問題のラベル付けを開始しました。バグ/タスクを分類するためにいくつかのメトリックを使用することになったことに気付きました： それがどれほど明確/単純か。たとえば、多くの設計作業が必要なのか、単純なUIのバグ修正が必要なのかなどです。 コードの影響を受ける領域の保守性。うまく設計されたエリアなのか、泥だらけの大きなボールなのか。 必要な変更の影響を受けると思うプログラムの量。 考えられるカテゴリが何であるかを始めたとき、私は明確な考えを持っていなかったので、私のラベルは少し厄介です。仕事を誰かに割り当てる前に見積もりを要求できるように、新しいフィールド（「リスク」のようなもの）の追加を要求することを考えています。 誰もこのようなことを以前に扱ったことがありますか？

17 project-management  task-organization  jira 

私は自分のキャリア全体にわたって実践的な開発者であり、コードを扱うことが大好きです。私は常に、特定の技術に関する専門知識がほとんどまたはまったくないチームリーダーにleadしているが、特定の実装を主張しています。 今、私は見ているガラスの向こう側にいることに気づきました。私はC＃で実装されるファットクライアントの主な開発者ですが、私の専門はJava Webアプリケーションの構築です。どの言語でもデザインパターンとオブジェクト指向パラダイムを活用できることは知っていますが、コーディング標準、プロジェクトライフサイクルツール、リリース/配布手順に関しては私は迷っています。1〜2か月以内に基本を習得できることは間違いありませんが、時間とともにしか収集できない特定の経験があります。 どうすればよいですか？開発中に嫌っていたプロジェクトリーダーにならないようにするにはどうすればよいですか？

17 project-management  coding-standards  continuous-integration