構造の悪いソフトウェア開発モデルを克服するにはどうすればよいですか？

私は現在、新入生として働いている会社に入社しました。GISソフトウェア開発の熟練者の数が限られているため、私もその中の1人だったので、プロジェクトマネージャーとして直接採用されました。

私はJavaとGISにかなり精通しており、ロケーションベースのサービスに関する自発的な研究を行ってきましたが、プロジェクト管理や構造化ソフトウェア開発は行っていません。地質学の専門家として卒業してから1年後、前年は大学の学者として働いていました。

仕事に興味を持っていたおかげで、機会が現れ、最終的には会社のビジネスインテリジェンス部門の責任者にもなりました。会社は私を信じていました。私自身はデータウェアハウジングとBIの概念を学び、GISとBIを組み合わせることにも成功しました。

また、私は現在、C＃WPFのBIツールで2人の開発者と協力しています。

アジャイルプロジェクト管理で優れたソフトウェア開発手法を採用しようと非常に懸命に努力しましたが、あまり成功しませんでした。また、製品に関する限り、適切に設計されたコードを信じていますが、CEOの技術的知識の欠如（私のすぐ上にいる）のため、通常、それを行うのに必要な時間は得られません。特定のコーディング言語全体（たとえば、JavaではなくWPF）に関する専門知識が不足しているため、所要時間は大幅に短縮されます。また、同様にバージョン管理システムもありません。

私は物事が構造化されていないため、物事の進行方法に非常にうんざりしており、物事を構造化する方法について働くことよりも、ほとんどの時間を考えています。プロフェッショナルな経験のある皆さんがこの状況を克服するのを手伝ってくれることを願っています。

私が2年ほど前に勤務している会社でも同様の問題がありました（もちろん、技術的な詳細はありません）。

一度に1ステップ実行するだけです。アジャイルなソフトウェア開発を急いで採用しようとしないでください。学習して適用するものがたくさんあります。専門知識の不足があなたを落胆させないでください。

ゆっくりと（ただし、できるだけ早く：P）、確実かつ確実にビルドします。

次の手順をお勧めします（これを行うには、しばらくの間管理から開発に切り替えることがありますが、それで問題ありません）

1. 優れたバージョン管理システムを学び、それをよく学んでください。個人的には、gitまたはmercurialをお勧めします。両方に多くのドキュメントがあります。
2. 実践とパターンにしっかりしたコアを構築します。チームメンバーと一緒に本を読んだり、ブログを読んだり、スクリーンキャストを視聴したりできます。これは、開発に新しい空気を与えます。
3. TDD / BDDを学び、それを新しいコード、および新しい機能を実行するときに触れる可能性のある古いコードに適用してみてください。
4. やるペアプログラミングを。2つの頭は1つよりも優れていると考え、4つの目は2よりも優れています:)。
5. 現在開発中の言語のコミュニティで使用されている最新かつ最も一般的なツールについて調べてください。それらについて学び、それらのいくつかをプロジェクトに含めてみてください。これらがどのように構築されたかを見て、学びます。
6. スクラムを使用します。反復、ストーリー、ストーリーポイント、障害は、すべて知っておくべき概念です。私にとって、スクラムはソフトウェアの開発と管理に最適なワークフローであることが証明されています。それを適用し、毎日の経験から学びます。
7. 例で教える。ほとんどの初心者開発者は新しいことを学ぶことに熱心ですが、一部の開発者は非常に怠け者です。とにかく、彼らがあなたが学んで、適用してきた新しいものを彼らに見せてください。

また、可能であれば、プロセスを確認してより良いアドバイスを提供できるように、コンサルタントを雇います。

怠けたり落胆したりしないでください。間違いから学び、さまざまなアプローチを試してください。これは始まりにすぎない！

編集：

ここに私が最近読んだり使用したりしているリンクと本のいくつかがあります...

gitの学習：Pro Git

これらは私がお勧めするブログの一部です（それらのほとんどは.NET指向です）：

• Javaブログ
• Karl Seguinのブログと彼のプログラミングの基礎シリーズ。
• CodeBetter.com
• コード思考
• ロス・テキーズ
• クリーンコーダー
• また、スタックオーバーフローの質問へのこのリンク。

本については、Amazonの「Budding A Solid Programming Core」リストをご覧ください。私もこれらをお勧めします：

• きれいなコード
• アジャイルソフトウェア開発、原則、パターン、および実践
• The Pragmatic Bookshelfのほぼすべての本

マネージャーとして、プロジェクトを適切に完了するために必要な時間を取得するのはあなたの仕事です。CEOに連絡するときは、あなたを裏付けるすべての数字と、見積りが同じくらい長い理由を確認してください。あなたのために経営者としての責任を作ることは時間がかかる理由CEOは理解してn個与えられたタスクを完了するために、時間/日/週。これは難しい場合もありますが、私は彼の会社がまだ失敗することを望んでいるCEOに会ったことがありません。

CEOがタスクを完了するのに必要な時間をあなたに与えたくない場合、私見、別の仕事に移るか、継続的な死の行進に備える準備ができています。最後の手段として、間違いなく非現実的な期待から生じる燃え尽き症候群をCEOに説明してください。

それを言って、あなたはまた、必ず、あなたの開発者は（なしほぼ不可能、途方もなく困難な正確な見積もりをご提供していることを確認する必要があり、適切にもどこかにする必要があります行わ技術的なデザイン、）。

すべての開発ドメインでアジャイルが良いとは限りません。一部のプロジェクトタイプでは機能しますが、他のプロジェクトタイプでは惨めに失敗します。あなたが動作するものを見つける前に、いくつかの異なる方法を試してみる必要がある場合があります十分に。

バージョン管理の設定を取得します。実際、Gitをセットアップするのに5〜10分かかり、基本的な操作を停止するのにさらに数分かかり、さらに高度な概念を停止するのに1〜2日かかります。

うーん、トロントのアジャイル/ XPイベントで会ったかどうかわからない-これはおなじみのようだ

休憩が必要なようです。長い週末を過ごし、あなたが好きなら酔って、数日間仕事を忘れてください。

自分を楽にします。自己教育は良いことであり、方法論が関係する人格とうまく機能しないからといって、それが間違っていることを意味するわけではなく、個人的な失敗でもありません。

Project Managementをターゲットにした（ベータ版）pm.stackexchange.comサイトがあります。そこで役に立つアドバイスやサポートを得ることができます-しかし、必ずここにも質問を残してください。

技術的なものに移ります：

バージョン管理システムがありません

1つを最優先事項として入れます。盗まれたラップトップはローカルにそれほど多くの履歴を持たないため、git / mercurialよりもSVN（Subversion）のような集中型システムを好みます。パスワードやsshキーなどの極秘のものが誤ってチェックインされた場合、特に重要です。しかし、それは好みの問題です。「手動バージョン管理」のバグほど時間を無駄にしません。たとえば、コードを元の状態に戻します。

幸運を

いくつかの問題があるようです。2.成功のための改善プログラムの推進。

ナンバー1の最も難しい部分は、上級管理職が作業内容の詳細に関心を持たないことが多いことを単に覚えていることです。（もしそうなら、彼らはあなたにそれを渡すのではなく、自分でそれをやっているでしょう！）大きなハードルが「なぜ」であるように聞こえます。プロセス改善のビジネス上の利点の説明については、CMM 1.1プログラム。実際にプロセスを改善するためにCMMを使用するか、他の何かを使用するかは、この議論には関係ありません。

プロセス改善の成功への道はたくさんあり、それらはすべて非常に長くなる傾向があります。CMMの経験では、レベル1から5に移行するのに8〜10年かかることがあります。6シグマの経験では、各反復である程度の改善が見られますが、潜在的な問題のほとんどを除去するには複数の反復が必要であり、 6シグマの品質で、すべてを一度に交換しようとするリスクを冒すことなく、まったく異なる方法で作業が行われています。

業界で一般的に使用されている品質改善のアプローチがある場合は、時間をかけてソフトウェアに適用する方法を確認し、それを使用して、会社の他の人々が既に慣れ親しんでいることについて耳を傾けるようにします。特定のソフトウェアツールとプラクティスについて何時間も話すことができますが、ソフトウェア以外のCEOはすぐにそれを調整します。業界の標準的な慣行について話すと、あなたは彼の言語を話しているので、彼は元気になります。業界の一般的な用語でソフトウェアについて話すと、関連する質問をして、企業の結果を改善するための課題と計画をよりよく理解するようになります。

このようにサポートを求めるたびに勝つわけではありませんが、おそらく空っぽの見た目はずっと少なくなり、勝ちます！

頑張ってください！

あなたの提案はすべて賢明であり、多くの企業に行く方法です。しかし、彼らは普遍的ではありません。特に経験のないチームではそうです。彼らがそうでない理由は、彼らがセットアップと保守にいくらかの作業を必要とすることです-バージョン管理さえ-多くがソフトウェアプロジェクトのテーブルステークスであると仮定します。彼らはいくつかの作業を必要とするため、彼らもいくつかの利益を提供する必要があります。そして、それはあなたの特定の状況ではそうではないかもしれません！または、少なくとも意思決定を任された人々には利益がありません！

他の人が指摘しているように、次のことが必要です。

• プラクティスを順番に採用してみてください。それらを一度にすべて試してはいけません。人々を圧倒するからです。
• このための適切な順序を把握する必要があります。バージョン管理から始めます。その後も簡単なものを使用してください。あなたが良い決定を下すことを人々が信頼し始め、彼らが利益を見ると、彼らはより危険な変更を採用する可能性が高くなります。
• なぜ何かを実装する必要があるのか​​、しっかりとしたケースを作りましょう。常に進歩をエンドユーザーに見えるようにしている2〜3人の開発者にとって、例えば、より複雑な開発方法論を採用することを正当化するのは困難です。結果重視ではなく、プロセス重視とみなされます。
• 誰を説得する必要があるかを念頭に置いてください。開発者？CEO？