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

プロジェクト管理は、特定の目標を達成するためのリソースの計画、編成、確保、および管理の分野です。

12
クライアントは現在のプロジェクトのコメントの25%を望んでいますが、どのように対応しますか?[閉まっている]
ジュニア開発者はこちら。 私は現在、私の会社の大顧客向けのWebアプリケーションで単独で作業しています。先月始めました。クライアントは、各ソフトウェアプロジェクトに少なくとも25%のコメントを求めています。 私は以前のアプリケーションのコードをチェックしました、そして私の観察はここにあります: 各ファイルはコメントブロックで始まります(パッケージ、最終更新日、会社名、著作権) すべての変数は名前でコメント化されます // nameOfCustomer public String nameOfCustomer すべてのゲッターとセッターがコメントされます 非常に少数の有用なコメント 開発者は、品質や有用性に関係なく、25%のしきい値に達するためにできるだけ多くのコメントを配置するようです。私の会社は、「クライアントが望んでいるとおりにそれを行う」と言っています。 私はこれについてクライアントと直接話しませんでした。これまでの私の議論は次のとおりです。 読み書きする無駄な行(時間の無駄) コメントが時々更新されない(混乱の原因) 開発者が実際に役立つコメントを使用または信頼する可能性が低い このテーマに関するアドバイスは何ですか?状況をどのように処理すればよいですか?

14
プログラムをゼロから完全に再構築した場合、ずっと改善したいという気持ちを常に避けることができますか?[閉まっている]
私はかなりの量のコーディングを学びましたが、それは常に科学環境(コンピューターサイエンスではない)で行われ、誰も私を正しい方向に導くことなく完全に独学で学びました。したがって、私のコーディングの旅は...面倒でした。ある種のプログラムを構築するたびに、最終的には、はるかにエレガントに、はるかに効率的に、そしてはるかに柔軟性があり、今後の管理が容易な方法でそれを実現できたことに気付きました。状況によっては、実際に戻って一から物を作り直したことがありますが、通常これは実際には実行できません。これまでの私のプログラムのほとんどは比較的小さいものでしたが、何かを作成するたびに大きなプログラムを完全に書き換えることは非常に面倒です。 私はただこれが普通の経験なのだろうか?そうでない場合、これをどのように防止しますか?事前に計画を立ててみましたが、コードを打ち出すまですべてを実際に予測することはできません。

12
単体テストを行うには、プロジェクトの大きさはどれくらい必要ですか?[閉まっている]
私のプロジェクトは、単体テストを可能にするほど十分に分離されていると思います。しかし、単体テストを価値のあるものにするために、プロジェクトは、正確に、クラスと機能の面でどれだけ大きくする必要がありますか? 私たちは皆、間違いを犯し、完璧な人はいませんが、小さなプロジェクトのエラーをステップスルーで処理するための自分はまともなプログラマだと思います。または、プロジェクトのサイズに関係なく、単体テストは非常に必要ですか?

11
DRYはソフトウェアプロジェクト管理の敵ですか?
ソフトウェア開発の最も基本的で広く受け入れられている原則の1つはDRYです(繰り返してはいけません)。また、ほとんどのソフトウェアプロジェクトには何らかの管理が必要であることも明らかです。 では、管理が簡単なタスク(見積もり、スケジュール、制御)は何ですか?正しい反復タスク、DRYに従って回避すべきタスク。 そのため、プロジェクト管理の観点からは、既存のコードを100回コピーしてタスクを解決し、必要に応じて各コピーに若干の修正を加えることは素晴らしいことです。常に、あなたが行った仕事の量と残っている量を正確に知っています。すべてのマネージャーはあなたを愛します。 代わりに、DRYの原則を適用して、重複するコードを多かれ少なかれ除去する抽象化を見つけようとすると、状況は異なります。通常、多くの可能性があります、あなたは決定を下し、研究を行い、創造的でなければなりません。短い時間でより良いソリューションを思いつくかもしれませんが、失敗することもあります。ほとんどの場合、どれだけの作業が残っているかを実際に言うことはできません。あなたはプロジェクトマネージャーにとって最悪の悪夢です。 もちろん大げさですが、明らかにジレンマがあります。私の質問は次のとおりです。開発者がDRYをやりすぎているかどうかを判断する基準は何ですか?どうすれば良い妥協点を見つけることができますか?または、妥協を見つけるだけでなく、このジレンマを完全に克服する方法はありますか? 注:この質問は、前の質問「ソフトウェア開発における日常作業の量と推定への影響」と同じ考えに基づいていますが、それが私のポイントをより明確にするので、繰り返して申し訳ありません:)。

20
プロジェクトマネージャーをどのように扱いますか
私は現在、最近縮小した会社で働いています。すべての社内作業、クライアントのインストール、ビルド、QA、および基本的にすべての社内作業を行います。 私の直接の上司は非常に非技術的であり、最近、彼の知識不足に対処するのが非常に難しいことがわかりました。 私が抱えていた最大の問題は次のとおりです。 私は一度に多くの締め切りにあります。締め切りに間に合わせることができないため、半分の速さの見積もりをまとめるのをやめます。その間、3つのサポートコールが入り、見積もりを出します。それからベンダーが壊したすべてを修正しなければなりません。最悪なのは、私が参加していなかったプロジェクトで「彼のバッファ」を食べた場合、すでにスケジュールされているすべてを完了し、他のすべてのものが出てくると予想されることです。 問題が発生すると、なぜ問題が発生し、詳細に説明されるのかと尋ねられますが、その詳細は彼にとってまったく意味がありません。 彼が気にするのは締め切りだけですが、彼はすべてをスケジュールする人です。 「私はグラフィックデザイナーではなくプログラマです。彼にとっては何の意味もありません」 私は.NETプログラマーとして雇われましたが、ベンダーは多くのサイトでワードプレスを選択することができました(ええ、私はそれについてすぐに学ばなければなりませんでした) 続けられると思いますが、このタイプのプロジェクトマネージャーに対処しなければならなかった人はいますか?別の仕事を見つける以外のアドバイスは何ですか? 妻がMSに非常にかかっているため、保険を失うことはできないので、現時点では仕事を辞められません。 私はマネージャーに対処する最良の方法を探しています。 事前に感謝し、これをwikiにしたので、閉じないでください。 ここに今日起こった別の状況があります。私には、プロジェクトを支援してくれる友人がいます。彼は「両方」に仕事を引用し、大まかな見積もりを出すように頼みました。私は彼に戻り、「友人をリソースとして使用して、1日7時間、1日6時間」と言いました。彼はそれをクライアントに渡し、10%のバッファーを追加しました(24時間)。彼はその後、私がプロジェクトで私の友人を得るすべてであることを教えてくれます。私は彼が7週間の間にどのくらいの時間空いていたか尋ねられませんでした。最悪の部分は、彼らがすでにクライアントに見積もりを与えていて、私にレビューもしていないことです。彼の見解は、私が彼に言った時間にそれを成し遂げるか、別の仕事を見つけるかのどちらかです。

7
ソフトウェアプロジェクトの偶発的な複雑さを管理する方法
Murray Gell-Mannが、Richard Feynmanがどのように多くの困難な問題を解決したかを尋ねられたとき、Gell-Mannは、Feynmanにアルゴリズムがあったと答えました。 問題を書き留めます。 真剣に考えてください。 ソリューションを書き留めます。 ゲルマンは、ファインマンが別の種類の問題解決者であり、彼の方法を研究することから得られる洞察がなかったことを説明しようとしていました。中規模/大規模のソフトウェアプロジェクトの複雑さを管理することについても、同じように感じています。優れた人々は本質的にそれが得意であり、何らかの方法でさまざまな抽象化を積み重ねて積み重ねることで、無関係な問題を引き起こすことなく全体を管理可能にします。 ファインマンアルゴリズムは偶発的な複雑さを管理する唯一の方法ですか、それともソフトウェアエンジニアが偶然の複雑さを抑えるために一貫して適用できる実際の方法がありますか?

15
開発者は不可能な要件をどのように拒否すべきですか?[閉まっている]
私が直面している問題は次のとおりです。 プロジェクトマネージャーからの引用: こんにちはSparkさん、多くの異なるiOSアプリケーションに使用できるフレームワークを開発するタスクを割り当てています。要件は次のとおりです。 UIの操作に使用されている親指または指の太さを検出できる必要があります。 この情報を使用して、UIのすべての要素を自動的に配置およびサイズ調整する必要があります。 親指を大きくするには、要素を画面の中央近くに配置する必要があります。 親指を小さくするには、要素を画面の角に近づけて配置する必要があります。 親指を大きくするには、すべてのフォントを小さくする必要があります。(この場合、大人を想定しています。) 親指を小さくするには、すべてのフォントを大きくする必要があります。(この場合、若い人を想定しています。) 概要: このフレームワークは、ユーザーフレンドリーなユーザーインターフェイスをプログラムで作成するために必要です。フレームワークは、必要な数のプロジェクトで使用できるように開発される必要があるため、開発者にとっても使いやすいものでなければなりません。 私はこのタスクを与えられた開発者なので、私の質問は次のとおりです。 これらの要件が少しばかげていることをどのように説明できますか? 実際のプロジェクトの開発に専念する方が良いと説明するにはどうすればよいですか? これが可能であったとしても、そのようなものを開発することはお勧めしません。 このプロジェクトに礼儀正しく、優しく、敬意を持ってノーと言うにはどうすればいいですか? 3年の経験を持つ開発者であっても、これは不可能かもしれないことをどのように説明できますか?

9
再現性のないバグに対処する
チームが(驚くほど!)正常に動作しているソフトウェアシステムを作成するとします。 ある日、エンジニアの1人が、DBデータの一部を変更するいくつかのSQLクエリを誤って実行し、それを忘れてしまいました。 しばらくして、破損した/誤ったデータを発見し、誰もがコードのどの部分がこれを引き起こしたのか、なぜそうなったのかについて頭を掻きます。一方、プロジェクトマネージャーは、それを引き起こしたコードの一部を見つけると主張しています。 これにどう対処しますか?

11
寿命が40年以上のWebアプリケーションの設計に関するアドバイス
シナリオ 現在、私はヘルスケアプロジェクトの一員であり、その主な要件は、ヘルスケアプロバイダーがユーザーが作成したフォームを使用して、未知の属性を持つデータをキャプチャすることです。2番目の要件は、データの整合性が重要であり、アプリケーションが40年以上使用されることです。現在、過去40年間のクライアントのデータをさまざまなソース(紙、Excel、Accessなど)からデータベースに移行しています。将来の要件は次のとおりです。 フォームのワークフロー管理 フォームのスケジュール管理 セキュリティ/ロールベースの管理 報告エンジン モバイル/タブレットのサポート 状況 わずか6か月で、現在の(契約している)アーキテクト/シニアプログラマーが「高速」アプローチを採用し、貧弱なシステムを設計しました。データベースは正規化されず、コードは結合され、層には専用の目的がなく、データベースで「削除」を実行するようにいくつかのBeanを設計したため、データが失われ始めています。コードベースは非常に肥大化しており、データベースが正規化されていないため、データを同期するだけのジョブがあります。彼のアプローチは、欠落したデータを復元するためにバックアップジョブに依存することであり、リファクタリングを信じていないようです。 私の調査結果をPMに提出したので、建築家は契約が終了すると削除されます。このアプリケーションを再設計するタスクが与えられました。私のチームは私と1人のジュニアプログラマで構成されています。他のリソースはありません。このシステムの再構築に集中できる6か月の要件凍結が認められました。 DrupalのようなCMSシステムを使用することをお勧めしましたが、クライアントの組織のポリシー上の理由により、システムをゼロから構築する必要があります。 寿命が40を超えるシステムを設計するのはこれが初めてです。私は3〜5年の寿命を持つプロジェクトにしか取り組んでいません。そのため、この状況は非常に新しいものですが、刺激的です。 ご質問 どのような設計上の考慮事項が、システムをより「将来性のある」ものにしますか? システムをより「将来の証拠」にするために、クライアント/ PMにどのような質問をする必要がありますか?

14
3か月前のプロジェクトで自分が何をしていたのか、どうして覚えているのですか?
私は3か月前にプロジェクトに取り組んでいましたが、突然別の緊急プロジェクトが現れ、注意を向けるように頼まれました。 明日から、古いプロジェクトに戻ります。私は自分が何をしていたかを正確に覚えていないことに気付きます。どこから始めればいいのかわかりません。 振り返るときはいつでも、離れた場所から数分以内にプロジェクトを文書化できます。ベストプラクティスはありますか?

9
受け入れ基準なしでソフトウェアをどのように開発しますか?
テスターが何をテストするかを知らず、製品所有者として行動する複数の(2-3)人と、承認基準なしで4-5人の開発者のチームでソフトウェアをどのように共同で開発しますか? 私たちが持っているのは、いくつかのスクリーンショットといくつかの箇条書きを含む大ざっぱな「仕様」だけです。 簡単だと言われているので、これらは必要ありません。 どのように進むべきか迷っています。 追加情報 厳しい締め切りが与えられました。 顧客は社内にいるため、理論上は製品所有者がいますが、ソフトウェアをテストする少なくとも3人が作業項目を失敗する可能性があります。失敗するまで実際にテストしているもの。 製品の所有者は、質問に答えたり、フィードバックを提供したりすることはできません。定期的な会議や電話会議はありません。フィードバックには数日かかる場合があります。 完璧な仕様を作ることはできないことは理解できますが、各スプリントで実際に取り組んでいるものの受け入れ基準を持つことは「普通」だと思いました。

8
発見してパッチを適用したバグを記録する必要がありますか?
これは一般的な状況だと思います:いくつかのコードをテストし、バグを発見し、それを修正し、バグ修正をリポジトリにコミットします。多くの人がこのプロジェクトに取り組んでいると仮定して、まずバグレポートを作成し、自分に割り当てて、コミットメッセージで参照する必要があります(たとえば、「バグ#XYZを修正します。バグはXおよびYによるものです。 Q and R ")?または、バグレポートをスキップして、「BのときにAを引き起こしたバグを修正しました。バグはXおよびYによるものでした。QおよびRで修正しました」などのメッセージでコミットできます。 より良いプラクティスと考えられるものは何ですか?

9
ドキュメントとプロジェクト管理にGitを使用する必要がありますか?コードは別のリポジトリに配置する必要がありますか?
グループプロジェクトのGitリポジトリを起動しています。コードと同じGitリポジトリにドキュメントを保存するのは理にかなっています -これはgitリビジョンフローの性質と矛盾するようです。 ここに私の質問の要約があります: コードとドキュメントの両方が同じリポジトリにチェックインされている場合、Gitリビジョンスタイルは混乱するでしょうか?これでの経験? Gitはドキュメントのリビジョン管理に適していますか? 私はありません一般的にはリビジョン管理システムは、またはマニュアルのために使用すべきではないかどうかを尋ねる-それがなければなりません。 これまでのフィードバックに感謝します!

11
レガシーコードを引き渡すためのベストプラクティス
数か月後に同僚が新しいプロジェクトに移り、私は彼のプロジェクトの1つを引き継ぎます。準備するために、私はすでにMichael FeathersのLegacy Codeでの効果的な作業を注文しました。 しかし、この本は、私がこれまで見つけたレガシーコードに関するほとんどの質問と同様に、コードをそのまま継承する場合に関係しています。しかし、この場合、私は実際に元の開発者にアクセスでき、秩序あるハンドオーバーのための時間があります。 私が継承するコードの一部の背景: 機能している:既知のバグはありませんが、パフォーマンス要件が上昇し続けるにつれて、それほど遠くない将来にいくつかの最適化が必要になります。 文書化されていない:メソッドおよびクラスレベルでの文書化はほとんどありません。しかし、私は長年そのAPIに対して(ブラックボックスとして)書いてきたので、コードがより高いレベルで行うことになっていることはよく理解されています。 上位レベルの統合テストのみ: APIを介した他のコンポーネントとの適切な相互作用をテストする統合テストのみがあります(再び、ブラックボックス)。 非常に低レベルで速度が最適化:このコードはアプリケーションシステム全体の中心であるため、その多くは長年にわたって数回最適化され、非常に低レベルです(一部には特定の構造体用の独自のメモリマネージャーがあります) /記録)。 コンカレントおよびロックフリー:コンカレントおよびロックフリープログラミングに非常に精通しており、実際にこのコードにいくつかの部分を提供しましたが、これにより複雑さがさらに増します。 大規模なコードベース:この特定のプロジェクトは1万行を超えるコードであるため、すべてを説明する方法はありません。 Delphiで書かれています。この問題を言語に依存しないと信じているので、私はこれをそこに置くつもりです。 彼の出発までの時間をどのように費やすのが最適か疑問に思いました。ここにいくつかのアイデアがあります: マシン上ですべてをビルドする:すべてをソースコード管理にチェックインする必要がありますが、たまにファイルをチェックインすることを忘れていないので、これがビジネスの最初の順序になるはずです。 より多くのテスト:変更を行うときに導入したバグを早期にキャッチできるように、より多くのクラスレベルの単体テストが必要ですが、現在のコードはテストできません(巨大なクラス、長いメソッド、多すぎる相互依存関係)。 何を文書化するか:まず最初に、低レベル/高度に最適化された性質などのために理解するのが難しいコードの領域に文書を集中するのが最善だと思います。見苦しくてリファクタリング/リライトが必要なものがいくつかあるのではないかと心配していますが、実際には私が見逃すかもしれない正当な理由でそこにあった最適化です(Joel Spolsky、Things You Should絶対にしない、パートI) 文書化の方法:いくつかの散文を伴うアーキテクチャのクラス図と重要な機能のシーケンス図が最適だと思います。 誰が文書化するのか:私は彼に文書を書いてもらうか、彼にそれを私に説明してもらうために、何が良いだろうと思っていたので、文書を書くことができます。私は、彼には明らかであるが私ではないものが適切にカバーされないことを恐れています。 ペアプログラミングを使用したリファクタリング:これは時間の制約のために実行できない場合がありますが、多分私は彼のコードの一部をリファクタリングして、物事がそうである理由についての入力を提供するために彼がまだいている間にそれをより保守可能にすることができます。 これにコメントして追加してください。このすべてを実行するのに十分な時間がないため、特に優先順位を付ける方法に興味があります。 更新:引き渡しプロジェクトが終了したので、以下の回答で自分の経験を使ってこのリストを拡張しました。

12
非プログラマーに開発プロセスを理解させる
主にプログラミング会社ではない会社のためにプロジェクトを開始するとき、期待の1つは、すべてのバグのない完成した製品があり、必要なすべてをすぐに行うことです。ただし、そうなることはめったにありません。 期待を管理し、非プログラマーにソフトウェア開発が他のタイプの製品開発とどのように異なるかを説明するいくつかの方法は何ですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.