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

私のキャリアが進むにつれて、技術的な仕事が減り、プロジェクト管理の仕事が増えていることがわかりました。冗談を言っています 技術的な仕事に戻るたびに、物事を進めるのは少し難しいようです。あなたのキャリアを通じて技術的な専門知識を維持するために人々はどのような提案を持っていますか？

16 project-management 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 あなたの多くが悪いクライアントに遭遇したと確信しています。また、将来このような出会いを防ぐための対策を講じたと確信しています。立ち去るように警告するクライアントの最も影響力のある特徴は何ですか？

16 experience  project-management 

私のチームは最近、私たちの仕事のほぼ1年の計画を立てるプロセスを経験しました。計画を3つのフェーズに分けました。各フェーズにはいくつかの起動が含まれます。 あなたの機敏な点から、これは間違っているのだろうか？私たちは最初のいくつかのステップ以外の設計にあまり時間を費やしていないので、それは悪い考えではないと思います。方向を変えることは可能です。同時に、目先の短期だけで行動しないことは素晴らしいことです。

16 project-management  agile 

新しい個人プロジェクト（Python）を開始したばかりで、プログラムの「大まかなドラフト」に相当するものを書いています。私はまだ広範なエラー/例外処理または美的なUI要素を入れていません（これらが最終的に必要になることを知っている場合でも）、ドキュメントは私がやっていることを将来見るのに役立つのに十分です。 プロジェクトの設計/管理の設定原則に反して、大雑把に始めるのですか？私は科学者であり、プログラマーではないので、これらのことを理解していません。したがって、主な問題は、次の2つの両極端のどちらに当てはまるかについてコンセンサスがあるかどうかです。 すべての例外処理を含め、最初から徹底的で高品質のコードを記述し、最終的に必要になることがわかります。 最初から最小限の作業でラフなドラフトを作成し、後ですべての詳細を記入します。 関連する質問：プロジェクトを完成させるために、デザインの「素晴らしさ」を犠牲にしてよいのはいつですか？

15 design  project-management  time-management 

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

15 design  project-management  programming-practices  project  principles 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖。 最近、私のチームの主任開発者が去ったため、私はより高度な計画の割り当てを任されました。長期計画は嫌いです。私の脳は自然に配線されていないように見え、学習するのに時間を費やすほど興味がありません（図のプログラミング側に追いつくのは十分に困難です）。 ハイレベルなプランナーでなくても、優れたプログラマーになることはできますか？ 上級プログラマーとして、製品全体を計画し、完成日を選ぶのが得意な人はいますか？

15 project-management  senior-developer 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 突然、会社を辞める人がいます。今、彼の仕事を完了する必要があり、あなたはそれを割り当てられています。彼が何をしていたのかわからない（90％完了したのか9％だった）、残り物をどのように管理しますか？ 最初から始めましょうか？90％完了した場合はどうなりますか？ 彼が何をしたかを理解しようとしますか？それがナンセンスだったらどうだろう？

15 project-management  efficiency 

バグ追跡システムには「優先度」フィールドと「重大度」フィールドがあります。重大度は「ユーザーへの影響」、優先度は「製品への影響」として定義します。 私の質問は、「コード改善」タスクを重大度と優先度に分類する方法についてです。改善によって動作が変更されることはなく、「より良いコード」になると仮定します。全体的な長期的なメンテナンスの改善が見込まれますが、定量化するのは困難です。 優先度と重大度の定義を使用すると、予測が困難な長期的な利点を図に導入しない限り、コードの改善により両方の値が最も低くなります。したがって、コードの改善は簡単な作業ではなく、決して試みるべきではないことを意味します。 ただし、コードを絶えず改善してリファクタリングすることは非常に重要だと思います。 ソフトウェア開発自体は継続的な学習プロセスであり、コードを改善しなければ、それを上達させることはできません。 チームはコードを誇りに思うべきです。 今後のメンテナンスにかかる時間は短くなり、長期的には大幅な節約になります。 または、そのようなタスクは決して作成されるべきではなく、そのような改善は「オンデマンド」でのみ、「バグに関連する場合」に実行されると思いますか？それがバグに関連しているとしても、それがコードレビューの議論ポイントではないでしょうか？例えば、「なぜあなたはこの構造の劇的な変更をしたのですか？」

15 project-management  refactoring  issue-tracking 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 プロジェクトの内部ドキュメント、仕様、要件などを整理および維持するためのソフトウェアを探しています。現在、すべてのドキュメントを多数のMS Word DOCファイルとしてソース管理リポジトリに保存しています。これによりバージョン管理が可能になります。ただし、この情報を検索したり、それらの間にリンクを作成したり、分類したり、共同作業したりすることはできません。 要件、設定： クライアント側でのゼロインストール（WEBベース）。 ドキュメントのバージョン管理。 ドキュメントの注釈。 ドキュメントのリンク。 完全検索（すべてのドキュメント）。 MS Word（* .doc）import \ export。 WYSIWYGテキストエディター。 これまでに発見して試したシステム： MediaWiki XWiki 合流

15 project-management  documentation  knowledge-management  knowledge-base 

開発者は、次のif/elseような1行のコードステートメントでブロックを記述します。 if (condition) // Do this one-line code else // Do this one-line code 別の方法では、すべてに中括弧を使用します。 if (condition) { // Do this one-line code } else { // Do this one-line code } 開発者は最初にオブジェクトをインスタンス化してから使用します。 HelperClass helper = new HelperClass(); helper.DoSomething(); 別の開発者は、オブジェクトを1行でインスタンス化して使用します。 new HelperClass().DoSomething(); 開発者は配列とforループを使用する方が簡単です： string[] ordinals = new string[] {'First', 'Second', …

15 project-management  productivity  coding-style 

作業中のコードレビューでは、コードベースの全体的な品質や保守性を必ずしも向上させるわけではありませんが、「賢い」と考えるコードとパターンを見てきました。私はフィードバックでこれを指摘し、反論に納得しません。このコードがレポジトリになり、後にプロダクションに移行するとき、私は少し心配です。 私は団結力のあるチームを維持したいので、自分の留保について口論しすぎて緊張を引き起こしたくありません。私はまた、あまりにも寛大にならずに、お客様に素晴らしい製品を作りたいです。 伝統的に、誰がどのようにチェックインされ、どのように「ベト」パワーを持っていますか？ コードはどのように機能しますが、つま先を踏まずに複雑すぎる/巧妙なコードを削除できますか？

15 project-management  code-quality 

雇用主に進捗を報告するのに問題があります。私はパートタイムプログラマで、学校の（非技術）部門のソフトウェアプロジェクトを担当しています。 担当者： 1.実際にソフトウェアを使用し、機能要求を提起するスタッフ 。2.私の上司（プログラマーではない）。彼女はソフトウェアのユーザーではありません。 プロジェクトの性質： サードパーティから購入した既製のソフトウェアです。部門のニーズに応えるために、このソフトウェアの機能を変更または追加する必要があります。これは学期を通して使用する必要があるソフトウェアです。すべての機能を最初に使用する必要があるわけではありません。 そのため、アジャイルモデルを使用しています。スタッフが特定の機能を必要とするとき、リクエストを出し、変更を加えます。学期の終わりまでに、必要なすべての機能が引き上げられ、実装されると思います。 問題： 上司が進捗状況を尋ねるたびに、答える方法がわからないので、答えられません。すべての必要な機能の完全なリストがありません。先週提起された機能を完了しましたが、上司に「完了」したことを伝えることはできません。新しい機能も追加されており、その程度はわかりません。「％の完了率があります」や「xxxで完了します」とは言えません。3つのリクエストのうち、2を完了することができたので、上司に「2を完了しましたが、まだ完了していない機能が1つあります」と伝えます。長い時間を経て、「長い間、いつも終わらない何かがあります」と聞こえます。 進捗状況を報告できないことは、私にとって本当に悪いように見えます。それは私がどれだけやったかではなく、人々に知らせる方法です。私がマネージャーであり、私のスタッフが何ヶ月も進捗を報告し続けない場合、この男も能力がないと感じます。 「ソフトウェア変更のステータス/進捗状況」と同じくらい簡単に報告する方法、または質問に答える方法がありますか？ 更新 私の上司は開発タスクに直接関与していないため、私が何をしているか、またはプログラムがどのように機能するかについて、手がかりがありません。彼女は忙しいので、定期的に会うことはありません。彼女はメインユーザーではなく、プログラムの詳細を知らないので時間の無駄になると思います。 私はソフトウェアを使用し、ソフトウェアについてよりよく知っているスタッフと定期的に会います。 上司に進捗を説明するのは難しいと感じています。

15 project-management  agile  reporting 

お金を稼ぐために取り組んでいる「本物の」プロジェクトと、非常に興味深い副プロジェクトがあります。 「本当の」プロジェクトに取り組むたびに、私の側のプロジェクトのアイデアしか考えられないという問題があります。どうやって対処しますか？本当の仕事を通して力を発揮しますか？

15 productivity  project-management 

私は友達と一緒にソフトウェアプロジェクトに取り組んでおり、テクニカルリーダーに任命されました。これらの人はどれも悪いプログラマーではありませんが、私は彼らよりもかなり多くの経験を持っています。チームの全員に作業を分散できるようにする必要があります。また、お互いのつま先を踏まないようにする必要があります。彼らがこのプロジェクトを成功させるために必要な品質とスケーラビリティの比較的高い基準を満たしていること、彼らがコミットするすべてをレビューする必要はありません。 マイクロ管理を避けながら標準を維持するにはどうすればよいですか？ダイアグラムを作成し、コードレビューをスケジュールし、壊れる可能性のあるものを修正できると信頼するだけで十分ですか、それともTDDルートに行ってチームが満たす明示的なテストを作成する必要がありますか？

15 productivity  project-management  code-quality 

理想的な世界では、バグの少ない期限に間に合うことが望ましいです。しかし、より好まれ/受け入れられるあなたの経験から： 期限に間に合いますが、開発者が物事に突入するため、多くのバグがあります 開発者はコードの記述が非常に厳密であるため、バグは少なくなりますが、期限には間に合いません

15 project-management