あなたが巨大な会社で働いていて、その会社が突然カスタムの社内ソフトウェア開発を行うことにしたとしましょう。さらに、顧客 (もしあれば) にも成功した開発を提供できるようにしたいと考えています。
今、あなたはそれを担当しています。
成功するソフトウェア開発インフラストラクチャを構築するために最も重要なことは何だと思いますか?
更新:適切な人材と適切なツールが必要だと答えないでください。これはまさに私が探しているものです.適切なツールは何ですか?また、チームに参加するために最初に採用するのはどのようなタイプの人ですか? あなたがその開発のリーダーになると考えてください。
Joel Testに 10 点以上で合格する準備をしてください。
適切な人材を確保することが最も重要になると思います。プログラマーが悪臭を放っていても、他に何も問題はありません。
彼らが何をしているかを知っている担当者。
もちろん、多くの要因がありますが、重要な要因は次のとおりです。
私はギョームに同意します: 部門をゼロから構築したい場合は、集中する必要があります。チームを構築し、全員を新しい責任に成長させ、お互いを知る必要があります。一度に多くの方向に進みすぎると、失敗につながります。
したがって、開発したいテクノロジーを特定します。この例の主な目標は社内開発であるため、社内要件によって決定が決まります。その主な目標を念頭に置いてチームを構築してください。
社内開発の場合、会社とそのプロセスをすでに知っている人が少なくとも 2 人必要です。(2 つは、最初の大きな危機があなたを襲ったときに、1 つは間違いなく病気になるか、休暇中になるためです)。一方で、「私たちはいつもこのようにしてきた」という考え方に固執せず、既成概念にとらわれずに考えることができるアウトサイダーが必要です。上記の理由から、それらも少なくとも2人である必要があります。チーム リーダーとしてのあなたの仕事は、これら 2 つのグループのバランスを取り、チームに統合することです。
将来の成長のために、常に有機的な成長の観点から考えてください。チームの規模を 200 % 増やさないでください。ここで新しい人を 1 人雇い、別の人 (またはギャル) を雇ってください。ゆっくりとチームを構築してください。新しいプロジェクトに取り組むときは、チームの専門知識を拡大することを常に考えてください。すべてのプロジェクトで何か新しいことを試してください。それは、新しいソース リポジトリ、自動化された毎日のビルド プロセス、仕様やドキュメントを作成するための新しいシステム、さらには別のテクノロジ (たとえば、通常 .Net、Delphi、または C++ で開発する場合の Java) である可能性があります。 重要なプロジェクトで大きな飛躍を遂げようとしないことを確認してください. (私はかつて、VB 6.0 から .Net に切り替えることを決定した会社で働いていました。その会社は、これまでに試みたことのない最大のプロジェクトでした。彼らは生き残りました。かろうじて。)
そうすれば、部門はゆっくりと、しかし絶えずその能力を拡大していきます。その後、外部の顧客のために開発を行う機会が訪れたとき、それを成功させるために必要な知識のほとんどはすでに蓄積されています。
そうそう、smacl も正しいです。部門が長期的に存続するためには、しっかりした QA/QM が必要です。
初日から QA ルールの作成 (および遵守) を開始します。できるだけ短く柔軟にします。不足しているとわかったものを追加し、不要または非現実的であることが判明したものを破棄します。
これがあなたが知りたかったことかどうかはわかりませんが、私はそれを言う必要があると感じました;-)
テクノロジーに柔軟になろうとしないでください。最初に 1 つのテクノロジ (Java、.NET など) に焦点を当てることから始め、必要に応じて他のテクノロジに移行します。どんな技術でも問題を解決することはできますが、多くの技術を得意とする人を見つけるのは非常に困難です。
インフラストラクチャ レベルでは、ソース管理は必須です。継続的インテグレーションはプラスです。時間をかけて、進化できる標準的なプロジェクト レイアウトを導入してください。これにより、開発者はプロジェクトを簡単に切り替えることができます。時間をかけて適切なビルド プロセス (Java の世界では Ant、Maven) を導入します。ビルド プロセスを IDE と統合して、開発者がコードの変更をテストするたびにプロジェクトをデプロイするのに 5 分待たなくて済むようにします。
もちろんすべて重要なチーム、バージョン管理、qaなどに関する以前の回答に加えて、コーディングと開発者/アーキテクトの役割に特に焦点を当てた回答を提供します。
決定の多くは、特定のビジネスおよびソフトウェア構造（単一の製品コードベース、SOA、多くのプロジェクトなど）に大きく依存しますが、一般に、コアソフトウェアインフラストラクチャの開発には常にかなりの時間を費やす必要があります。 SDLC。
コーディング命名規則の例外
処理戦略ロギング
戦略の設定と構成
基本クラスとヘルパークラス
一般的なアーキテクチャとレイヤー
（プレゼンテーション、ファサード、ドメインエンティティ、データストアなど）
UML2.0要件などの設計ツール
管理/エンドユーザーの相互作用
まだまだたくさんありますが、これらは確かに考えるべきいくつかの基本です。私が関わってきた成功したプロジェクトはすべて、まともなソフトウェアインフラストラクチャに組み込まれています。また、失敗したプロジェクトの多くには共通のテーマがあります...共通のインフラストラクチャが整っていません。ほとんどの場合、これらの失敗したプロジェクトは、技術者ではない人が主導し、数人のプログラマーにたくさんのアイデアを投げかけ、数週間で実現することを期待できます。
結論として、長期的な成功を確実にするために、事前の計画とプロトタイピングに投資する必要があります。
幸運を。
レイフォード
www.blacksaber.com
受け入れ基準や変更管理など、強力なQA戦略を策定します。できれば、内部クライアントに合わせて軽量に保つことをお勧めします。さらに、要件分析、期待管理、およびリソース管理を実行する方法を理解します。
言い換えれば、節約するよりも多くの時間を浪費し、維持することが不可能な安っぽいソリューションを作成するためにそれを翼にするだけではありません。時間をかけて、何が必要で何が必要か、どのようにそれを達成できるか、そして何がかかるかについて考えてください。
あなたが最初に雇うべき人は経験豊富な上級レベルの専門家でなければなりません。次に、それらから/それらの入力を使用して構築します。後で後輩を追加します。