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

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 私は大規模なソフトウェア会社で働き始め、100万行を超えるコードのプロジェクトに割り当てられました。これはクライアント（社内プロジェクトではなく）に販売されるプログラムスイートの一部であり、必要に応じてソースコードを購入できます（ただし、それに関連する追加料金が発生することはまれです）。彼らは何年にもわたってソフトウェア設計を行っており、現在の製品は近い将来に継続することを目的としています。 驚いたことに、何百万行ものコードがドキュメントにほぼ完全に欠けています。さらに、コードの一部の領域は非常に厄介であり、理解しやすくなるようにリファクタリングを使用できる場合があります（たとえば、プログラミング言語の改善が10年ほど前に行われ、コードの大部分が大幅に増加します）バグが発生しにくいことは言うまでもありません）。これを修正するための努力はなさそうで、私が取り組んでいる部分が抵抗に遭遇したためにそうするようにとの私の申し出は、明確な答えを得ることはできませんでした。 これらのプラクティスは、ソフトウェア業界の大企業で一般的ですか？それとも、リファクタリングやドキュメントが不足しているという点で私の会社はユニークですか？ 補遺：いくつかのコメントに基づいて、私が探しているものを明確にしたいと思います。私の会社には技術的な負債があることを理解していますが、これは悪いことです。これが原因で私の会社が悪化しているかどうかを判断するのではなく、このドキュメントの欠如とリファクタリングへの抵抗が、私が持つプログラミングの世界での現実であるかどうかを知りたいだけです。私がそれで働き続けるならば対処するために。

8 documentation  refactoring  management  business  development-environment 

私が働いている場所では、最近、スクラムを使用してアジャイル開発を切り替えました。典型的な高まる苦痛を経験しましたが、今のところうまくいくように見えるアプローチに達しました（長期的にうまくいくかどうかは別の質問です！）。 明らかに、部門管理者はスクラムへの移行が機能していることに満足しています。しかし、彼らは私にとっては間違っていると感じることを始めています。 経営陣はチームを観察し、彼らにとって何が有効かを確認し、それを部門全体に処方します。のようなもの： 「完了」の定義 ストーリーポイントに使用できるストーリーポイント値（たとえば、1、2、3、5、13などが、スプリント中に使用された唯一の値であるため、fib。シーケンスから8を省略） ストーリーポイント値1を「UIラベルの更新」に調整する必要があることをチームに伝え、上限を20に制限する （すべてのプロジェクトにクライアントがいるわけではなく、すべての開発者がUIの経験があるわけではありません） ストーリーポイントの推定値100を使用して「このストーリーは後で分割する」ことをチームに伝える 無限のストーリーポイントの推定値を使用して、「これは壮大です」または「詳細情報が必要」を意味することをチームに伝える 私は彼らが役に立とうとしていることを理解していますが、上記のすべてがスクラムチーム固有のものではないのですか？つまり、あるプロジェクトの個人のグループで機能するものは、別のプロジェクトの別のグループでは意味をなさない場合があります。 非常に規範的で堅固なアジャイルアプローチに移行しているのではないかと心配しています。私はこれを考えることで正当化されますか、それとも私は過剰反応していますか？ 編集する 明確にするために...「管理」と「マネージャー」によって私は製品の所有者を意味しません。私は、スクラムチーム外の、ソフトウェア部門内のマネージャーを意味します。

8 agile  scrum  management 

次の作業プロジェクトを（Python）に慣れていない言語でコーディングしたいと思います。私の見解からは、なぜそれが良いアイデアなのかを考えることができます。しかし、私のマネージャーはおそらく私に理由を尋ねるでしょう。私は彼の観点からは利点に少し困惑しています。 編集：私は通常C＃でコーディングします EDIT2別の言語でコーディングしたい私の理由。 それは簡単なプロジェクトをはるかに難しくするので、私はもっと学び、それはより興味深いものになります Pythonに関する本を読んだところです。ビジネスアプリケーションに適用する機会が欲しいので、適切に理解します それは私のスキルセットを増やし、私をより雇用しやすくします Pythonは面白そう

8 management 

最高のハードウェアを購入し、最も貴重なボーナスまたは報酬を支払い、それらを丁寧に扱い、改善の機会を提供するなど。 開発チームの生産性を向上させたいと考えています。最大のサポート（または一般的には良いサポート）と見なすことができるものを見たいので、そこから始めることができます。

8 productivity  management  efficiency  support 

リーンソフトウェアおよびシステム・コンソーシアム2011会議先週開催された、リーンソフトウェア開発のビジョンや価値観を述べました。 参加者の一人が撮影した、無駄のないソフトウェア開発の6つの価値を次に示します。 1つ目は「人間の状態を受け入れる」です。 私はこの発言で人道主義的な、そしておそらく反テイラー主義的なムードさえも感じることができますが、私は専門家にこの原則とそれを私たちの日常の仕事にどのように適用するかを説明するようお願いしたいと思います。

8 management  lean 

IT企業を経営している多くのマネージャーまたは（CEOでさえ）は、ITのバックグラウンドを持つ人ほど上手ではありません。私が例を挙げれば（指で判断したり指を向けたりせずに）、Microsoftの現在のCEOは多くの1人です。これは一部の小規模な組織でも見られます。 IT企業のマネージャー（またはCEO）は、組織で実行するITバックグラウンドを持っている必要がありますか？ITのバックグラウンドを持つマネージャーは、そうでないマネージャーよりも優れたパフォーマンスを発揮しますか？

8 management  organization 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 私の上司は最近、母国にある私たちの国際オフィスに戻って、潜在的な新入社員にインタビューしました。私たちは、プログラマーとして数人を採用することにしました。彼らは大学を卒業したばかりで、非常に限られた経験しか持っていません（私が最初にここで働き始めたときの私と同じです）。彼らは英語を読むことができると言われていますが、私は彼らが申請プロセスの一部として書いたコードを見て、すべての変数名、メソッド名、コメントなどはスペイン語で書かれています。彼らには英語を書く能力があるのか​​疑問に思っています。しかし、彼らは学習者であると聞いています。そのため、小規模なトレーニングプロジェクトを提供することで、時間の経過とともに学習できる可能性があります。 私は彼らと緊密に協力して、彼らが優れた設計原則やその他のことを学ぶのを助け、最終的に私が彼らと一緒にコードを作成するようになるでしょう。 誰かがこの種の状況に対処し、それでうまく終わりましたか？どのような落とし穴に注意する必要がありますか？国際的なコラボレーションとトレーニングに役立つ、どのようなツールを知っていますか？

8 management  tools  training 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 仮説的に言えば、コンピューティングについて非常に浅い理解を持っている同僚がいると想像してください。ステレオタイプ化を避けるために、この同僚にジェンダーに中立的な名前のクリスを与えましょう。 現在、クリスの診断能力は低く、仮想マシンを設定するための正しいIPアドレスを見つけることができません。クリスはまた、コードを適切にマージすることに失敗し、私が何かを修正したコミットを上書きし、それによってバグを再導入します。私はこのスライドを聞かせて、バグを修正し、それについて管理者に音を立てません。 タスクが1つある場合、Chrisは1）十分な情報がないため不満を訴え、2）Chrisに1）を満足させるための過度に詳細な指示を提供します。実行する手順のリストで詳細を指定するほど、指示にエラーが含まれる可能性が高くなります。クリスはこれらの命令を受け取り、それらを実行しようとし、失敗し、命令が十分でないためにそれはあなたの責任になります。これにどう対処しますか？

8 management 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 6年前休業。 ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 そして、なぜほとんどのプログラマーが他の分野に比べてコーディングをやめてマネージャーになるのがそんなに早いのですか？自分の好きなことをやめなくても、一生ではないとしても、何十年も建設労働者、弁護士、研究者、作家、建築家、映画監督として働くことができます。それでも、ほとんどのプログラマーはマネージャー、またはそれ以上に、非コーディングマネージャーはクールなものであり、ソフトウェアキャリアの最終的な目標であると考えています。典型的なソフトウェア会社で40代や50代（または60代！）の普通のコーダーを目にすることは非常にまれです。どうして？ （そして、あなたがそれをするのが好きである限り、私はコーダーであることに賛成です。）

8 management  coding 

プログラマーとして、あなたのマネージャーが主にあなたのモチベーションを下げることは何だと思いますか？ 私のマネージャーは、Webコンテンツのブロックを要求しています（今週はmsdnコンテンツとMicrosoftドメインサイトでした）。そして、それは中小企業ではありません。そのような恐竜がもう存在しないはずの巨大企業です。

8 management  motivation 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 3年前休業。 私はこの管理行動のリストに出くわしました（http://suven.posterous.com/dos-and-donts-leading-software-development-te）。 いくつかの宝石があると思いますが、それらのいくつかは100％ではありません。斜体と私の名前でそれらをマークしました。 ソフトウェア開発者として、これらは魅力的だと思いますか？あなたの経営陣からのあなたのトップの「お奨め」アイテムはどれですか？ しない 人を追加してチームを垂直方向に拡張しないでください 10人を超えるチームを作成しないでください 人のリソースを呼び出さないでください、それはクールではなく、本当に不快です チームのメンバーが交換可能であると思い込まないでください 弱点を強調するときにチームを互いに比較しないでください チームを互いに対戦させないでください 偽の締め切りを作らないでください チーム間でツールとプロセスの標準化を強制しないでください（これは、状況によっては議論の余地があると思います-Todd） ソフトウェア開発の手掛かりがない製品マネージャーを雇わないでください KPIを排他的に使用してチームを推進しないでください（効果がないだけでなく、開発者はKPIメトリックを推進する方法を見つけます-「コード行が必要ですか？コード行を持っています！」-トッド） チームに時間外労働を強要しないでください。要求は緊張を生み出すものです。 人々の2倍が半分の時間に等しいと仮定しないでください 行う 約5〜8人のチームを作成して、水平方向にスケーリングします。 製品とチームのビジョンを持っていますか チームごとに違いがあるため、プロジェクトを適切に割り当ててください。 チームをやる気にしてください（うわー、これは滑りやすく、定義が難しいものです。私はその意見に同意しますが、それはガイドラインなしで「効果的である」と言っているようなものです。-トッド） チーム間の移動を許可する 製品のビジョン、戦略、テクノロジー、プロセスについて話し合うセッションを持っている チーム/製品名を決定するときにチームを関与させる チームが専門知識を持つチームである場合は特に、チームが独自に決定できるようにする チームがどのように、または何に取り組むかに影響を与える決定にチームを関与させる チームとプロジェクトに合った開発方法論を奨励する すべての個人の自己啓発計画に注意を払う

8 management 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 イベントソーシングは、速度、パフォーマンスのスケーラビリティ、透過的な永続性、透過的なライブミラーリングを提供する手段としてLMAXによって普及しました。イベントソーシングと改名される前は、このタイプのアーキテクチャパターンはシステム普及率と呼ばれていましたが、LMAXチームが公開されるまでは、このパターンに慣れていませんでした。 このパターンは多数の本番システムで証明されていますか？したがって、保守的な個人でさえ、このパターンを受け入れる力があると感じる必要がありますか、それともイベントソーシング/システムの普及は、恐れを知らない人のために残されたエキゾチックなパターンですか？

8 java  architecture  performance  management  event-sourcing 

私の仕事の本質は、数週間ごとにプロジェクトを切り替えなければならないことです。私の生産性に対する最大の障害の1つは、関連するすべてのコードを一定期間表示しなかった後、再び「頭の中で」元に戻すための立ち上げ時間であることがわかりました。これは、より短い休憩/より長い休憩では、より小さな範囲で発生します。 明らかに、優れた設計、ドキュメント、コメント、および物理構造がすべてこれに役立ちます（プロジェクトの切り替えをできるだけ頻繁に行うことは言うまでもありません）。しかし、私が見逃している可能性のあるプラクティス/ツールがあるかどうか疑問に思っています。これを改善するための具体的な方法は何ですか？

8 project-management  programming-practices  management  patterns-and-practices 

私は、累積的なエラーの影響と、絶対計算を使用することがなぜ重要であるのかを、技術的でない用語で説明する必要があるレポートに取り組んでいます。 dictionary.comからの「累積エラー」の定義： 一連の測定または計算中に次第にまたは重要度が徐々に増加するエラー。観察中に増大するエラー 理想的には、実際の例を挙げて、具体的なことを知らなくてもその概念を理解できるようにすることができます。 私が最初に考えたのは、かなり有名な「チャイニーズウィスパーズ」ですが、「現実の世界」として正確に分類することはしません。誰かがより良い例を知っていますか？

8 documentation  terminology  management