既存のプロジェクトにソフトウェア開発プロセスを実装する方法は？
私の質問には、ソフトウェア開発プロセスのセットアップが含まれます。正式な方法論やプロセスが設定されていない既存のプロジェクトに参加し、自分で設定するように求められた場合、どのように処理しますか？私はアジャイルのようなさまざまな方法論、またはXPのようなそのサブセットを調査しましたが、これらは主に新しいプロジェクトをセットアップする方法を目的としています。それらを既存のプロジェクトに実装する方法がわからない。
また、これらの多くはWebまたはデスクトップアプリケーションを対象としています。私のソフトウェアプロジェクトは組み込みシステムであるため、それらの多くの側面が適用可能ですが、どちらを使用するか、それを組み込みシステムで使用するために変換する方法を理解しようとするのは少し大変です。組み込みハードウェアでのユニットテスト（特に、シミュレータが存在しないシングルボードコンピューターの場合）は、特にソフトウェアが非常に遠い場合は非常に困難であり、ハードウェアアブストラクションレイヤーを追加してユニットテストを支援するには、コードを劇的に分解する必要があります。
プログラミングの方法は知っているが、ソフトウェア開発プロセス管理は初めてのプログラマーのために、既存のプロジェクトのソフトウェア開発プロセスを設定するためのヒントを教えてください。
まず第一にそれを段階的に行います。古い犬に新しいトリックを教えるのは難しく、一度にすべて実装しようとすると、何も実装されません。
方法論の準備ができているかどうかを判断するのに役立ついくつかの質問を次に示します;）
- コードリポジトリ（コードリポジトリを使用していますか？分岐戦略はありますか？最後の主要なバグ/機能を誰がいつ導入したかを尋ねた場合、その理由は何ですか？
- プロジェクトのロードマップはありますか？リポジトリ内のどのコミットが次の主要な目標の達成に直接関連しているかはわかりますか。
- バグトラッカーはありますか？
- アプリをデプロイするプロセスを知っていますか（書き留めましたか）？いつ展開するかは誰が決めるのですか？変更をコードリポジトリのリリースブランチにマージするのは誰ですか？等..
- コードのガイドラインはありますか？ （変数名、関数名、テスト名など）
多分これはあなたの質問に直接答えていませんが、私は経験から書いています。また、企業に方法論を実装するタスクも割り当てられました。残念ながら、コードがプログラマ間でZipファイルで送信され、バージョンのない数十の共有フォルダに格納され、数年前のコードがどこに格納されているか誰も知らない場合、方法論を構築することは困難です。
上記のすべての質問に答えることができても、物事の状態について気分が良い場合は、方法論を実装するためのヒントは次のとおりです。快適に感じるものを選択してください。
強力な基盤（リポジトリ、ロードマップ、バグトラッカー、展開ワークフロー、コードガイドライン）がある場合は、方法を1つずつテストして、自分とチームに最適な方法を確認します。
私の経験では、ソフトウェアの方法論は、プロジェクトの決定というよりも組織のポリシーです。組織に方法論を実装するには、プロジェクトチーム（つまり、顧客、マネージャー、プロジェクトマネージャー、利害関係者、その他の意思決定者）の障壁を超えるレベルのコミットメントが必要です。
私の経験では、新しい順序を確立することは、ボトムアップによるものである場合はほとんど機能しません。関係するすべての関係者と交渉すると、より効果的に機能します。あなたが何をすべきかを決定する無制限の力がない限り。
すでに適切な方法論が存在している場合、それが良い方法ではない（つまり、良い結果が得られない）場合でも、変更を導入することは常に苦痛であり、抵抗があります。ここで、組織内のマネージャーや意思決定者からのサポートとコミットメントが必要になります。
新しい方法を提案することによって方法論を変更したい場合は、現在の方法論が組織がより良い結果を達成するのをどのように妨げているかを示す証拠を収集する必要があり、1つまたは2つのプロジェクトでパイロットを実行することを提案できます。新しい方法論の方がはるかに優れていることを証明できる結果を収集します。
現状が明らかに機能していないという事実を踏まえて、最初に最も重要な変更を加えることにより、新しい方法論を穏やかに導入することを検討できます。これらの変更は、新しい方法論、新しい順序、貴重です。
たとえば、どのような種類のテストも行わない場合は、TDDのいくつかのプラクティスの導入を検討し、数か月間の統計を収集してから、バグ統計が次第に改善されていることをマネージャーに示すことができます。これをチームに示すこともできるので、チームは興奮し、方法論にさらに妥協します。次に、第2フェーズに移行し、おそらく組織の他の部分からより良いサポートを受けることができます。最終的に、組織全体がこの方法論を採用できます。
プロジェクトマネージャーを新しい方法論に参加させることが最も重要なことだと私は思います。彼らはそれを信じ、それがパフォーマンスを向上させると信じなければなりません。彼らは最初は抵抗を示すかもしれないチームメンバーにそれを強制しなければなりません。そうでなければ、変更は勢いを失い、最終的には使用されなくなり、人々は現状に戻るでしょう。
最終的には、組織のパフォーマンスを改善するために選択する必要のある方法論はすべて、理想的には上司と顧客に示すことができる数値で示す必要があります。そのため、私見では、少しずつ変更を導入し、問題が見られる場所を改善し、方法論自体をあまり気にせず、物事をより良くする方法について説明します。
Personal Software Process または Team Software Process のようなあまり一般的でない方法論を検討しましたか？
ソフトウェア開発プロセス/方法論は通常、企業文化の重要な部分であり、プロジェクトごとに変更されることはめったにありません。また、開発チームが快適で実践できる開発方法論と強く相関しています。
広く知られ使用されている方法論の1つは、組み込みシステム開発向けのモデルベースの設計です。このモデルベースの設計の重要な特徴は、動的組み込みシステムの開発をより迅速かつコスト効率の高い方法で容易にすることです。より詳細な情報はここに提供されています- Embedded 360 。
組み込みシステム開発のもう1つの非常に重要な傾向は、 Agile Methodology を使用することです。これは、さまざまな時点でクライアントから送信された要件に基づいて組み込み製品を開発するためにソフトウェア会社によって広く使用されています。ここでは、組み込み製品のさまざまなイテレーションが、さまざまなクライアント要件のセットに基づいて開発されています。
最終的には、現在の能力よりも短いサイクルでコードをテストできるシミュレータを作成または取得したいと思うでしょう。それまでの間、他のベストプラクティスを確認し、本格的な標準化された方法でそれらを組み込み始めます。
何よりもまず、あなたは確かに定期的なコードレビューを始めることができます。コードレビューを適切に行うことで、他の何よりも多くのバグを防ぐことができます。 http://www.Amazon.com/Peer-Reviews-Software-Practical-Guide/dp/0201734850/ref=sr_1_1?ie=UTF8&qid=1343746666&sr=8-1&keywords=code+reviews はこれを行うための優れたリファレンス。
次に、QAグループと緊密に連携します。開発者がコーディング対象のテストを知っていることを確認してください。
3番目に、アジャイル宣言の原則を心に留めてください。作業中のソフトウェアとプロジェクト全体での簡単なコミュニケーションに集中するためにできることを実行してください。何が間違っているのか、今すぐ何ができるのかについて建設的に話してもらう。じゃやれ。
また、Alistair Cockburnの http://www.Amazon.com/Agile-Software-Development-Cooperative-Game/dp/0321482751/ref=sr_1_7?s=books&ie=UTF8&qid=1343746954&sr=1-7&keywordsもお勧めします= agile + software + development 環境に適した方法論を構築する方法に関する提案。
組み込みシステムとTDDの場合：
私が大学にいたとき、私たちはロジックアナライザーを使用して組み込みシステムの単体テストを作成する必要がありました。しかし、私たちが使用したものはそれぞれ約15000ドルの費用がかかり、私たちはそれらを壊さないようにしっかりと指示されました。反対に、それは素晴らしくて簡単でした：チップをボードに接続し、アプリを起動し、タダダダ、グリーン、バム。
しかし、私はあなたがそれを持っていると思います。
方法論に関して：
方法論は人に関するものです。特に大企業では、私はまだどのような企業文化にも方法論を強制することに成功していません。
最初のRUPカルチャーにいるときに、他のチームよりも速くなるように、チームとXPを行いました。それは成功しました。
私がプライマリにいるときXP（または、新鮮なアジャイル、SCRUMはまだ主流ではありませんでした）、私たちはRUPを行い、モデリングとすべてで、fの内容をよりよく理解するために*プロジェクトで起こっており、はるかに自信を持って行動します。
私がSCRUM環境にいるときに、RUPを実行して（理解を深めるため）、スクラムバックロックが常に壊れていることや、実際の反復がないことなどを認識しました（私たちは「バグと小さな機能チーム」でした）。 ）私たちがやっていることを安定させるために、私はリーン/かんばんに切り替えました。以前はそれほどうまくいきませんでしたが、ほとんどが機能しました（これはエンタープライズでしたが、以前のものにはスタートアップのコアチームがいました）
私がthe SCRUM環境にいたとき（ご存知のとおり、Nテスト）、砂漠の水であるようにRUPに切り替え、そこに数週間滞在しました。私はバグがなく、SCRUMが持っていたすべての言い訳を受け入れなかったからといって、驚くほど高速でした。
しかし、全体として：新しいアジャイルの世界では、プログラマは王様です。プログラマーが混乱を感じている場合は、会社を切り替えるか、プログラマーを切り替えます。
実装について話をする代わりに、プログラマをユーザーとして扱う：問題を解決するにする必要があります彼らが働くのを助ける。私はいつもこのアプローチが好きではありません（または、一部のプログラマーのアプローチが好きではなく、彼らが望むものをサポートするのが難しいと感じます）が、今日のリーダーは、他の人を助けるべき人であり、従うべき人ではありません。