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

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

5
DevOpsとソフトウェア構成管理の違い
開発運用とソフトウェア構成管理の違いは何ですか? 私にとっては、DevOpsとSoftware Configuration Managementの両方に焦点が当てられている限り、同じように思えます。 開発インフラストラクチャの確立-バージョン管理、ビルド管理、展開管理、依存関係管理、継続的な統合と配信などを担当します。 開発者環境を整理するためのベストプラクティスを使用する。 開発プロセスの品質保証 -開発の有効性のメトリックを収集し、開発プロセスのボトルネックの除去に取り組んでいます(単体テストの実行、単体テストのカバレッジの評価、検査の実行など) インフラストラクチャ管理 -ターゲットプラットフォームとその詳細。 リリース管理 -リリースが時間内に顧客/クライアントに配信されたことを確認します。 たぶん私は何かが欠けていますか?このリンクは、「ソフトウェア構成管理」という用語の使用が優先されることを示しています。しかし、それでも、リストされた範囲の活動を説明するために、どのような組み合わせの言葉を使用しますか:開発操作またはソフトウェア構成管理?

6
プロジェクトフォルダーをどのように整理しますか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 こんにちは プロジェクトフォルダをどのように整理していますか? かつて私は、顧客別に組織することを勧めてくれる上司がいました。 Projects | |----Customer 1 |---- A Cool Solution 1 |---- source |---- version1.0 |---- version1.1 |---- docs |---- analysis |---- meetings |---- manuals |----Customer 2 |----Customer 3 私の友人はテクノロジーでテムを整理するように私に言った Projects | |----.NET |---- C# |---- Customer 1 |---- A Cool Solution 1 |---- source |---- …

4
Namepsaces / Packagesのメリット
一部のプログラミング言語(JavaやC ++など)には、「パッケージ」または「名前空間」と呼ばれる言語機能があります。名前空間を持つことは本当に便利ですか?SDLのように(たとえばSDL_BlitSurface())、そのような言語機能を使用せずに、関数とクラスを特定のライブラリに属する​​ものとしてマークすることができます。名前空間は持つ価値があるほど有用ではありませんか?ライブラリでは便利ですが、アプリケーションでは役に立ちませんか?小さなプロジェクトを除いてどこでも便利ですか?考え?

1
複数のプロジェクトを含むCMake(C ++)リポジトリのディレクトリ構成
単一の(git)リポジトリに保存されている一連の関連する独立したC ++プロジェクトの編成に関するアドバイスをお願いします。プロジェクトはCMakeを使用します。 簡単な例として、2つのプロジェクトAとB、Bに依存するAを想定します。Aを開発するほとんどの人は、パッケージングシステムを介してBを取得します。したがって、Aのみをコンパイルします。ただし、開発者がAとBの両方を個別にコンパイル(およびインストール)できるようにする必要があります。 これが提案です: └── Repo1 ├── CMakeLists.txt (1) ├── A │ ├── CMakeLists.txt (2) │ ├── include │ │ ├── aaa.h │ │ ├── aaaa.h │ │ └── CMakeLists.txt (3) │ └── src │ ├── aaa.cpp │ ├── aaaa.cpp │ └── CMakeLists.txt (4) ├── B │ ├── CMakeLists.txt (2) …

9
ソフトウェアを主な事業とする会社では、開発者はまだ「IT」と見なされていますか?
私の考えでは、主要なビジネスを行っている会社は、ネットワーキングやサポートなどを備えたウィジェットグループ開発者を作成しているのです。 あなたの主要なビジネスがソフトウェアを販売している場合、私は開発グループを「研究開発」または同様のものと呼びます。社内アプリに厳密に取り組んでいる開発者がいれば、IT /サポート/通信などに参加することになるでしょう。 Microsoft、Googleなどの企業の標準は何ですか?CIOマガジンなどにこの種の辞書がありますか?あなたの会社は何をしていますか?

29
開発者の速度を低下させるものは何ですか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け付けていません。 開発者が遅くなる傾向があるのは何ですか? 次の回答を投稿しないようにしてください。 現在は低速ですが、この機能では便利です。(TDD、リファクタリング、...) 気晴らしをリストしてください。

1
複数のリポジトリにまたがるプロジェクトのGitHub組織?
GitHubで少なくとも3つのリポジトリを含むプロジェクトを開始しました。 リポジトリの1つは、一般的なドキュメントとサンプルのダンプであり、他の2つのリポジトリには、プロジェクトのバックボーンを形成する2つのプログラムの実装が含まれています。 このような構成を処理するためにGitHub組織を使用する必要がありますか?または、完全に無関係な他の12個のリポジトリとともに、すべてを自分のアカウントにすべてダンプする必要がありますか?

6
QAは開発部門の一部ですか?
私はかなり長い間製品開発部門を持っていた小さな会社で働いています。ただし、これまでになかったのはQA /テストグループです。 テストグループの追加を検討していますが、会社の組織構造のどこに配置するのが最適かを判断するのに苦労しています。具体的には、「リードテスター」のポジションを採用します。それらは製品開発部門の一部として配置されるべきですか、それとも新しい部門になるべきですか?彼らはどこか別の場所にいるべきですか? 当社は大まかに次のように構成されています。 最高経営責任者(CEO CTO 製品開発ディレクター ディレクターカスタマーケア 開発者 VPオペレーション ネットワークエンジニア セールス/セールスエンジニア 大統領 コントローラ

5
*専用*のテスターの役割を持たない開発チームの実行可能性[終了]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 私は最近、無駄のない開発チームを構築する方法について多くのことを考えています。最終的には、志を同じくする少数の人々と私自身の小さなソフトウェアハウスをオープンしたいと思います。目標は金持ちになることではなく、健康的な職場環境を作ることです。 これまでのところ、無駄のないチームを次のように定義しています。 小さい; 自己組織化; すべてのメンバーはQAを念頭に置く必要があります。 メンバーは複数の役割を実行できる必要があります 最後のポイントは、私が少し心配しているところです。マントラが進むにつれて... 開発者は悪いテスターを作ります。 多くの場合、開発者は自分のコードまたは同僚のコードに「近すぎ」て、品質のより高いレベルの評価を行うことを理解していますが、彼らが事実上悪いテスターであるとは確信していません。それどころか、優れた開発者の資質は優れたテスターの資質と非常に重なっていると私は考えています。 これが正しいと仮定して、私は開発者/テスターの問題を回避するさまざまな方法を考えてきましたが、私は実行可能なモデルを考え出したと思います。 私のモデルには以下が必要です: 2つ以上のプロジェクトがある小さなソフトウェアハウス 開発と配信に対するアジャイル(反復)アプローチ プロジェクトごとに1チーム すべてのチームメンバーはソフトウェア開発者になります 彼らの職務記述書には、開発、品質保証、テスト、および提供が責任として明確に記載されています これらの前提条件がすべて満たされている場合、プロジェクトは次のように編成できます(この例では、2つのプロジェクトAとBを参照します)。 すべてのチームメンバーが開発者の役割とテスターの役割を交互に行います チームメンバーがプロジェクトAの開発者である場合、チームメンバーはプロジェクトBのテスターに​​なります メンバーは、一度に1プロジェクトで作業しますので、として機能することが期待されているいずれかのDev やテスター。 ロールサイクル(二つの異なるプロジェクトで、再び)Devのような3回の反復及びテスターとして2反復で構成されてい プロジェクトチームには、常に3つの開発者と2つのテスターがいます。 メンバーの役割サイクルは、1反復だけフェーズがずれている必要があります。 これにより、チーム変更の突然の発生を最小限に抑えることができます。各反復で、2つのDevsと1つのテスターが前の反復と同じままです。 上記を考えると、次の長所と短所がわかります。 長所 会社全体にプロジェクトの知識を配布します。 チームメンバーが記述に役立つコードをテストしていないことを確認します。 フェーズが異なるロールサイクルとは、100%メンバーの切り替えを行うプロジェクトがないことを意味します。 交互の役割は退屈なプロジェクトの単調さを壊します。 短所 両方のプロジェクトのイテレーションは密接に結合されています。1つのプロジェクトが途中でイテレーションをキャンセルして再開した場合、2つのプロジェクトは同期しなくなります。これは、役割サイクルの管理を困難にします。 開発者を採用する際のヒンジは、テスターとしても活躍しています。 このアプローチについて友人や同僚と話し合ったとき、私はさまざまなレビューを受けました。一部の開発者はこのような役割を代替したいと考えていると信じていますが、他の開発者は個人的に試してみたいと言っています。 だから私の質問です: そのようなモデルは実際に機能するでしょうか?そうでない場合は、作業モデルに調整できますか? 注: 簡潔にするために、私はDevおよびTesterの役割のみに焦点を当てました。必要に応じて、他の役割について詳しく説明します。

3
これら3つのマネージャーの役​​割の違い[終了]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか? 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 3年前休業。 役割: 開発マネージャー プログラムマネージャー プロジェクトマネージャ 私は少し読みましたが、独立してそれらを十分に理解しています。しかし、それらを組み合わせると、いくつかの責任が重なって、誰が何に責任を負うのかがはっきりしないように思えます。 各役割が他の役割とどのように区別されるかを明確にする方法を誰かが持っていますか?または、主にどのタスクがそれぞれに排他的ですか?責任の重複を避けたい。 この件に関して他にも同様の質問があることは知っていますが、まったく同じものはありません... ありがとう 編集: この2つの質問は少しは役に立ちますが、一緒に押したときに各役割を配置することはできません。 プログラムマネージャーとプロジェクトマネージャーの違いは何ですか? ソフトウェア開発マネージャーの書かれた役割

1
プログラミングファイルをディレクトリに整理するにはどうすればよいですか?[閉まっている]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか?質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 場合によっては、探索的なプロトタイプを作成し、ディレクトリの構造を忘れることがあります... (いくつかのレベルの)ディレクトリにプログラミングファイルを分割する上での良いヒントは何ですか?

1
マイクロサービスベースの環境で「フロントエンド」をどのように処理しますか?
私たちは最近、モノリシックWebアプリをマイクロサービスに分割し始め、ゆっくりと機能をスライスして個別のマイクロサービスに書き直しました。フロントエンドの作業を整理する最善の方法がわからない場合を除いて、すべて順調に進んでいます。私たちは製品チームに分かれて、少数のマイクロサービスのコードをそれぞれ管理し、検索、CMS、チェックアウトなどの機能領域を提供します。各チームには製品所有者、技術リーダー、スクラムマスターがいます。 問題は、これらの製品チームがそれぞれ独自のバックエンドコードベースを持っている一方で、フロントエンド開発者が各製品チームに座っている単一のフロントエンドReact.jsコードベースがあることです。これは多くの問題を引き起こしています: フロントエンド開発者間の製品チーム間のコミュニケーションの欠如 他のチームの新機能をサポートするために他のチームが「所有」しているフロントエンドコードに変更を加える際の問題 フロントエンドチームを代表する単一の技術エキスパートは存在しませんが、他の製品チームには技術的なリードがあり、フロントエンドでこの役割を果たしている人はいません。 私たちは他の人がこれをどのように扱っているのか疑問に思い、フロントエンドコードベースの分割、ビジネスユーザーが新機能のために通常従事するフロントエンド製品チームの作成、データ/サービスのリクエストなど、フロントエンドチームの他の製品チームですが、どちらにも独自の問題があります。

5
個人のライブラリにどのように名前を付けますか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私は物事に名前を付けるのがかなり苦手です。 私が一般的に思いつくことができる唯一の名前は「ヘルパー」です。たとえば、パスを操作するための支援関数を含むヘッダーファイルがある場合、それを「ヘルパー」ディレクトリ内に置き、「path-helper.hpp」などの名前を付ける傾向があります。 明らかに、それは悪い命名規則です。:) 自分のヘッダーとライブラリを常に参照するために使用できるフォルダー(および名前空間)に一貫した名前付けスキームを設定したいのですが、入力や覚えやすい名前(などboost)を見つけるのに問題があります...それらの一部を「ヘルパー」や「stdext」などと呼ぶことになってしまいますが、これは素晴らしいアイデアではありません。 覚えやすくタイプしやすく、一般的ではないライブラリの名前をどのようにして見つけますか(「ヘルパー」、「std」、「stdext」など)。 これを行う方法についての提案はありますか?

7
ソフトウェア会社で「リファクタリング/保守グループ」の役割のようなものはありますか?
したがって、私は組み込みソフトウェア開発を行う会社で働いており、他のグループはさまざまな製品のソフトウェアのコア開発に焦点を合わせており、工場にある私の部門(別の地理的な場所にある)もソフトウェア開発に対処する必要があります、しかしすべての製品にまたがるので、製品のソフトウェアの問題が原因でラインがダウンした場合にも迅速に修正できます。 つまり、私たちはジェネラリストであり、他のグループは各製品に特化しています。 地理的に分散していると、コア開発に参加するのが少し難しくなります(まあ、それはそれほど難しいことではないのですが、リモートで協力するということになると、意図しない文化的/政治的な障壁があるかもしれません) )。 だから、私たちは現在、火を消しているだけで、ややアイドル/サブ活用されているので(新しい部門であるか、それが理由かもしれません)、領域を検出することは、私たちにとって良い役割であると考えましたコードのリファクタリングと再設計の機会、および保守性とモジュール性の管理に関連する可能性のある他のすべての実装。他のグループは、時間がないため積極的な期限があり、コードの品質を損なうため、これに焦点を合わせていません(ソフトウェアプロジェクトの永遠の物語) 私のグループ/部門がこの役割を持つ管理職や他のグループによって公式に認識されることを望んでいるということです、そして私はこの問題のために私たちのグループの良い定義/アイデンティティを思いつくのに苦労しています。 だから私の質問は:この役割はすでに存在するものですか?または私はこのようなものを最初に作成したのですか? 編集:つまり、すべてのリファクタリング作業を自分で行うのではなく、リファクタリングイニシアチブを推進するグループです。オープンソースコミュニティーとオープンソース製品のように、今考えてみると、

2
クロスファンクショナルなチームとドメインベースのチームの比較(たとえば、プロジェクトベースとソフトウェア/メカニックスなど)はありますか?
私は多くの統合システム製品を作成する組織で働いています。つまり、機械/システム/電子機器/ソフトウェアが設計および製造されている完全な製品です。現在のところ、ほとんどのチームはプロジェクトを中心に機能横断的に編成されています。このような組織の利点は、共通の目標のために緊密に協力している人々が近いことです。 不利な点は、エンジニアが同僚から孤立していることです。通常、プロジェクトには1人のソフトウェアエンジニアのみが割り当てられます。つまり、プロジェクトには高いトラック係数、最小限の知識の共有、ベストプラクティスがあり、技術開発は限られています。 だから私の質問です:これら2つのアプローチのコスト/利点を比較する研究はありますか?

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