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

組織タグは、従来のソフトウェアアーキテクチャの考慮事項ではカバーされない、物理的、人的、ビジネス、およびデジタルリソースの設計、構造、およびレイアウトをカバーします。

17
プログラミングのパートタイムの仕事が異常なのはなぜですか?[閉まっている]
最近、メガコーポレーションでのフルタイムの開発職を辞めました。アルバイトを探すことにしました。それ以来、私は半ダースの潜在的な雇用者と話をしてきましたが、魔法の言葉「パートタイム」を言ったとき、彼らは皆同じ​​反応を示しました。今、私はそれがただの私かもしれないことを理解しているので、コントロールとして、私は彼ら全員に私がフルタイムで仕事をするつもりがあるかどうか尋ねました、そして、彼らはすべて私がおそらくオファーを受けるだろうと言いました。 私の質問は2つあります。 雇用主として、有能で優秀な開発者をあきらめたのは、なぜ彼が週5日ではなく週3日働きたいと思ったからですか? アルバイトの話をもっと良く売るにはどうすればいいですか?私は通常、現在の人生のバランスを好み、自分のプロジェクトに取り組みたいという理由を挙げていますが、それはさらに疑わしいものになります-自分で何かを始めて終了するのですか?私は怠け者ですか?
164 organization 

7
これらのシニアソフトウェアエンジニアのタイトルの違いは何ですか?[閉まっている]
私は現在、大企業の上級研究ソフトウェアエンジニアであり、「シニアスタッフエンジニア」の役職に就いています。新しい役職のタイトルが横向きの動きなのか進歩なのかわかりません。 したがって、他のすべてのものはほぼ同じです(給与、専門分野など)、これらのソフトウェアエンジニアのタイトルの外部の違いは何ですか(一般に、可能であれば特定の会社に関係なく): シニアエンジニア 上級研究員 シニアスタッフエンジニア 技術スタッフ 主任技師 編集:「技術スタッフのメンバー」について詳しく説明しましょう。これは珍しいことです。私はそれが高い研究タイトルだと思います。Oracle、VMWare、および古いBell Labsにこれらのタイトルがあることは知っています。参照:技術スタッフのメンバー。私はそれが何を意味するか知っているが、それが他のタイトルとどのように重なるかわからないので、私は尋ねた。

17
ソフトウェアエンジニアは技術サポートも務めるべきですか?[閉まっている]
ソフトウェアエンジニアもテクニカルサポートとして行動する必要がありますか?つまり、企業がエンジニアにソフトウェアエンジニアとテクニカルサポートの両方の帽子を着用させる場合です。エンジニアの時間の多くがテクニカルサポートに費やされると、ソフトウェアを書くことができなくなるようです。

13
個々のコードの所有権は重要ですか?[閉まっている]
私は、コードベース全体のチームの所有権が、コンポーネントの個々の所有権よりも優れているかどうかについて、一部の同僚と議論している最中です。 私は、チームのすべてのメンバーにコードベースのほぼ等しいシェアを割り当てることを強く支持しています。これにより、人々は自分の作成に誇りを持ち、バグスクリーナーに着信チケットを割り当てるための明らかな最初の場所を与え、「壊れたウィンドウ症候群」を軽減するのに役立ちます。 また、特定の機能に関する知識を1人(または2人)のチームメンバーに集中させ、バグの修正をはるかに容易にします。 何よりも、委員会ではなく、多くの意見を持っている一人の人との主要な決定について最終決定権を置きます。 他の誰かがあなたのコードを変更したい場合、許可を要求することを支持していません。多分、コードのレビューは常に所有者に委ねてください。また、知識のサイロを構築することもお勧めしません。この所有権について排他的なものはないはずです。 しかし、同僚にこれを提案したとき、私は予想以上に多くのプッシュバックを得ました。 だから私はコミュニティに尋ねます:大規模なコードベースでチームと協力することについてのあなたの意見は何ですか?集団所有権を慎重に維持することに関して私が逃しているものはありますか?


5
あなたがやったことのないプログラミングタスクに直面したとき、何をしますか?
私は3か月前に.NET開発者としてキャリアを始めました。さまざまな技術、パターン、概念に関する長いトレーニングプランの後、私を監督していた開発者は、会社が扱う多くのプロジェクトの1つに参加する準備ができたと判断しました。 最終的にコーディングを開始できることを非常に楽しみにしています。私が参加したチームは、新しいプロジェクトから始めていたため、今のところかなり小さいです。これは、プロジェクトのライフサイクル全体に関わることができるので素晴らしいことです。これは、ASP.NET MVC / ASP.NET Web APIを使用し、フロントエンドでDurandalフレームワークと関連ライブラリを使用するWebベースのSPAプロジェクトです。 私の問題は、同僚と会議を行い、翌月のタスクと見積もりを確立した後、自分がタスクを実行できるかどうかわからない立場にいることです。 作成したタスクを一度も実行したことがないため、どのようにすればよいかわかりません。 たとえば、作成されたタスクの1つは、アプリケーション全体の一般的なエラー処理メカニズムの作成です。 彼がやったことのないタスクに直面したとき、通常どのように進めますか?

3
複数のサブプロジェクトでプロジェクトを分離する場合
私が取り組んでいるプロジェクトを1つではなく2つのリポジトリに分割することが理にかなっているかどうかを知りたいです。 私が言えることから: フロントエンドはhtml + jsで記述されます .netのバックエンド バックエンドはフロントエンドに依存せず、フロントエンドはバックエンドに依存しません フロントエンドは、バックエンドに実装された安らかなAPIを使用します。 フロントエンドは、任意の静的httpサーバーでホストできます。 現在、リポジトリは次の構造を持っています。 ルート: フロントエンド/* バックエンド/ * 両方のプロジェクトを同じリポジトリに保持するのは間違いだと思います。両方のプロジェクトは相互に依存関係を持たないため、個々のリポジトリと、必要に応じてサブモジュールを持つ親リポジトリに属する​​必要があります。 私はそれは無意味であり、それを行うことで利益を得ることはないと言われました。 私の議論のいくつかを以下に示します。 相互に依存しない2つのモジュールがあります。 長期的に両方のプロジェクトのソース履歴があると事態が複雑になる可能性があります(探しているバグとはまったく関係のないコミットの半分がある間にフロントエンドで何かを探してみてください) 競合とマージ(これは起こらないはずですが、誰かがバックエンドにプッシュすると、他の開発者がバックエンドの変更をプルしてフロントエンドの変更をプッシュすることになります。) 1人の開発者はバックエンドでのみ作業するかもしれませんが、常にフロントエンドを引っ張る必要があります。 長い目で見れば、いつ配備するのか。何らかの方法で、フロントエンドを複数の静的サーバーにデプロイし、バックエンドサーバーを1つ持つことができます。いずれの場合も、バックエンド全体を複製するか、すべてのサーバーにフロントエンドのみをプッシュするか、バックエンドを削除するカスタムスクリプトを作成する必要があります。1つだけが必要な場合は、両方よりもフロントエンドまたはバックエンドのみをプッシュ/プルする方が簡単です。 反論(1人が両方のプロジェクトで作業する可能性があります)、サブモジュールで3番目のレポを作成し、それで開発します。履歴は個々のモジュールに分けられており、バックエンド/フロントエンドのバージョンが同期して実際に連携するタグをいつでも作成できます。フロントエンドとバックエンドの両方を1つのリポジトリにまとめても、それらが連携して機能するわけではありません。両方の履歴を1つの大きなレポにマージしているだけです。 サブモジュールとしてフロントエンド/バックエンドを使用すると、プロジェクトにフリーランサーを追加する場合に物事が簡単になります。場合によっては、コードベースへの完全なアクセス権を実際に与えたくないことがあります。「外部者」が表示/編集できるものを制限したい場合、1つの大きなモジュールがあると事態が難しくなります。 バグの紹介とバグの修正のために、フロントエンドに新しいバグを挿入しました。その後、誰かがバックエンドのバグを修正します。1つのリポジトリで、新しいバグの前にロールバックすると、バックエンドもロールバックされ、修正が困難になる可能性があります。フロントエンドのバグを修正しながらバックエンドを動作させるには、別のフォルダにバックエンドをクローンする必要があります...その後、物事を再マージしようとします... 1つのリポジトリのHEADを移動するので、2つのリポジトリを作成するのは簡単です他を変更しないでください。また、異なるバージョンのバックエンドに対するテストは簡単です。 誰かが私を説得するためにもっと議論をすることができますか、少なくともプロジェクトを2つのサブモジュールに分けるのが無意味な(より複雑な)理由を教えてください。プロジェクトは新しく、コードベースは数日前のものなので、修正するのに早すぎません。

16
開発者のチームにはマネージャーが必要ですか?
バックグラウンド: 私は現在4人のチームの一員です。1人のマネージャー、1人のシニア開発者、2人の開発者です。約3500人のスタッフを抱える組織のために、さまざまな特注の社内システム/プロジェクト(6〜8週間など)を実施しているほか、以前に作成されたシステムに必要なすべてのメンテナンスとサポートも行っています。潜在的に私たちがやってくるすべての仕事をするのに十分な人はいません-人員が不足しています。経営陣はこれを認めていますが、予算の制限により、チームに追加のメンバーを採用する能力が制限されています(たとえ給与を貯金に戻したとしても)。 変更 これにより、現在の場所に残ります。私たちのマネージャーは、牧草地の役割を新しいままにして、チームに空席を残す予定です。経営陣はこの機会を利用してチームを再構築し、チームマネージャーの役​​割が別の開発者と別の上級開発者に置き換わるようにします。彼らの論理は、より多くの開発者が必要であるということなので、ここに資金提供の方法があります(役割の1つは、別の空いているポストから部分的に資金提供されています)。 チームには直接的なラインマネージャーはなく、役割と責任はシニアと(比較的新しいポストの)サービスマネージャーに分けられます(技術知識がほとんどない開発知識/経験があり、焦点が共有されています)他の多くのチームや個人の中で)-フードチェーンの次の実際のマネージャーになる人。 最後の質問は: マネージャーなしで開発チームを実行することは可能ですか?これを経験したことがありますか?そして、どのようなことがうまくいかない/私たちに利益をもたらす可能性がありますか? 理想的には、「光を見る」ことと、この方法で物事を行うことの利点、またはそれに対する議論のためのいくつかのポイントを考えたいと思います。

3
ソフトウェアアーキテクト、ソフトウェアエンジニア、ソフトウェア開発者(プログラマー)の違いは何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私はアメリカで最高の給与のかかる仕事についてのCNNの記事を読んでいます。ソフトウェアアーキテクトは、#1と表示されています。#9として記載されているソフトウェアエンジニア。また、ソフトウェア開発者(プログラマー)は#35にリストされています。コンピューター科学者をプログラマーに置き換えることは有効だと思いますか? これに先立ち、私は常に「ソフトウェアエンジニア」が経験豊富なプログラマーとチームリーダーの肩書きであると考えていました。しかし、「ソフトウェアアーキテクト」はどこに収まり、正確に何をするのでしょうか?私はCNNの説明を読みましたが、それらは本当に私を満足させないので、ここで素晴らしいユーザーベースからより徹底的で経験豊富な説明を得ることができると思います。 受け取ったすべての回答に事前に感謝します。

8
チームにおけるシニアWeb開発者の役割は何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 他の3人のWeb開発者のチームで、私は1年間主任Web開発者としての肩書きを持っています。これがリードとしての最初の仕事です。 私は自分の役割が経営陣から何であるかについてかなり設定されています。他の上級レベルの開発者が何をしているのか興味があります。私は主に、他の組織のリーダー/シニア開発者として他の人々の責任が何であるかについて興味があります。私は中小企業でしか働いていなかったので。 (a)組織のシニア/リードWeb開発者に何を期待しますか(サイズに関係なく)。 (b)Web開発リーダーとシニアWeb開発者に違いはありますか? 私はいくつかのスレッドをレビューしましたが、自分自身をシニア開発者と呼ぶべきであるが、シニア開発者が彼/彼女のチームですべきことの役割を包括的に議論していない場合について議論したものがありました。

5
作業中の開発環境で過去のプロジェクトを維持する効果的な方法は?
過去のプロジェクトを実行したいときはいつでも、それを見つけることができるようになり、実行できるようにすべてをセットアップするまでに時間がかかることがわかりました。 たとえば、Linuxで作成したpythonプロジェクトがあり、Linuxに簡単にインストールできるソフトウェアパッケージに依存していますが、使用しているLinux VMはもうありません。私の他のプロジェクトのいくつかは、Webサーバー構成、PATH変数、sdk、IDE、OSバージョン、デバイスなどの他の変数に依存しています。 誰かがこの問題を処理する効果的な方法を持っていますか?今のところ、ソースコードのバックアップを維持することだけに関心がありますが、動作中の開発環境を再構築することは難しく、動作中の開発環境を維持することも困難です。

3
チームのシニア開発者とジュニア開発者の理想的な組み合わせは何ですか?
どのチームでも、より多くの灰色の開発者と若い子犬が必要になります。いくつかの理由が含まれます: お金。多くの場合、同じレベルの経験を必要としないタスクが提供されるため、これらのタスクを遂行するために最高額を支払わないことが理にかなっています。 エネルギー。新しい人々がチームにもたらすことができるエネルギーと熱意があり、チームが古くなりすぎないようにします。より多くの高齢者がもたらすことができる落ち着きと知恵もあります。 知識の伝達とキャリアの成長。プロジェクトとスキルの両方の面で、人々に教えることや新しいことを学ぶことは便利で楽しいことが多いです。新しいチームメンバーの「参加」を支援することは満足です。 ジュニアよりもシニアの方が多いことが重要かもしれない最先端のプロジェクトがあることを理解していますが、一般的に、チームでの経験の理想的な組み合わせはありますか、それともプロジェクトに完全に依存していますか?

5
「クロスファンクショナルチーム」とは実際には何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 「クロスファンクショナルチーム」の一般的な意味は、目標を達成するために必要なさまざまな分野の専門家を組み合わせたチームです。 しかし、アジャイルのクロス機能性とは、異なる専門家を組み合わせるだけでなく、それらを混合させることを意味するように見えます。Henrik Kniberg は、クロスファンクショナルチームを次のように定義しています。 しかし、線はどこに描かれていますか?必要な場合、開発者に反復のテスターに​​なるように依頼するのは普通ですか?

10
なぜ非記述的な内部コードネームを使用するのですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 コードネームの使用はかなり普及していると思います。当社もそれらを使用しています。 しかし、私の主な懸念は、これらの名前が通常どこにも文書化されていないことです。そしてその意味は口コミによって広まります。また、名前は、ツールの機能や名前が付けられたエンティティとは関係ありません。 内部のテストマシンは星座にちなんで名付けられ、公共のサーバーはギリシャの神々にちなんで名付けられているというパターンがあります。また、プロジェクトは、場所またはランダムに選択された映画スターの名前またはキャラクター名にちなんで命名されます。しかし、マシンがWindowsであろうとLinuxであろうと、名前から直接入手できる情報はありません。32または64ビットサーバー。またはプロジェクトの目的は何ですか。 誰かが「Gandalf」プロジェクトや「Callanish」プロジェクトなどのプロジェクトを分岐させたというVCSのコミットメッセージを見ると、私はただひどい気持ちになります。同じ理由で、通常、関数や変数にそのような名前を付けません。 少なくとも新しいエンティティについては、よりわかりやすい名前を使用することを提案しましたが、非常に強い反対に直面しました。明らかに、私以外の組織の誰もがそのようなものを命名するのが大好きです。 では、なぜ記述的でないコードネームを使用するのでしょうか? 誤解しないでください。プログラムのバージョンやマイルストーンの命名に問題はありません。また、マーケティング上の理由から素晴らしい製品名を持っています。しかし、他のすべての場所は説明的な名前を見たいと思います。 編集: コンテキストを提供するために:Gandalfは、コードを64ビットに移植するプロジェクトです。CallanishはAndroidに移植するものです...前者のブランチを64bitporting、後者のandroidportingを呼び出したいです。添付するターゲットバージョンを示すサフィックスが添付されている場合があります。だから誰もがそれが何であるかを名前で知っているでしょう。 問題のサーバーは、製品をテストする仮想マシンイメージです...しかし、実際に実行されている物理マシンはわかりません。したがって、それらをwindowsxp_32、windows7_64、debian_32またはsolaris_64と呼ぶのはまったく問題ありません。

2
重い企業通信、構成管理およびテスト要件を備えたMercurialリポジトリ構造
私は、分散バージョン管理のタオで自分自身を再教育するのに苦労している別のSubversionユーザーです。 Subversionを使用するとき、私はプロジェクトマイナーアプローチの大ファンであり、以前の雇用主のほとんどと一緒にリポジトリブランチを構築しました。次のようなタグとトランク: branches-+ +-personal-+ | +-alice-+ | | +-shinyNewFeature | | +-AUTOMATED-+ | | +-shinyNewFeature | +-bob-+ | +-AUTOMATED-+ | +-bespokeCustomerProject +-project-+ +-shinyNewFeature +-fixStinkyBug tags-+ +-m20110401_releaseCandidate_0_1 +-m20110505_release_0_1 +-m20110602_milestone trunk 実際のソースツリー内では、次のような構造(のようなもの)を使用します。 (src)-+ +-developmentAutomation-+ | +-testAutomation | +-deploymentAutomation | +-docGeneration | +-staticAnalysis | +-systemTest | +-performanceMeasurement | +-configurationManagement | +-utilities +-libraries-+ | …

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