技術を理解していない会社のコンサルタント！[閉まっている]

他に3人のプログラマーがいる会社でコンサルタントとして働きました。私の仕事はすべての古いシステムをJavaやSpringなどで書き直すことですが、スタッフのプログラマーはperlしか知らず、マネージャーはプログラミングを知りません。

私はここに書き直すプロジェクトが6つあるが、誰も設計ドキュメントや仕様を持っていないことを彼らに理解させようとしています。スタッフのプログラマーはドキュメントを書く必要がありませんでした。さらに、私はマネージャーに新しいjava techのものを理解させることができません..彼はスタッフの何人かに物事についての意見を求め続けますが、スタッフはそれを知らないか理解していません。

何を構築するかを知るために、スタッフプログラマーまたは誰かがデザインドキュメントを書かなければならないことをマネージャーに理解させるために、ここからどこへ行くのですか。または、ドキュメントを作成する必要がある場合、どのようにして情報を取得しますか？

スタッフがあなたが彼らの仕事を書き直すように頼まれたプラットフォームを知らないのはちょっと奇妙に思われます。あなたが去った後に何が起こりますか？誰があなたの仕事をサポートしますか？

したがって、適切なドキュメントがない複雑なシステムがあり、別のプラットフォームでシステムを再作成する必要があります。私があなたの立場で行うことは、新しいシステムに「サインオフ」しなければならない1人の人物を特定することです。そこから、ユーザーストーリーを読んで、要件をビットサイズのチャンクに分解し、英語で説明できるようにします。彼らのフォーマットは次のようなものです。「USERROLEとして、システムXでは、目標を達成するために行動を起こしたいと思います。

ユーザーストーリーをさらに説明するには、「条件を指定してから結果が出る」という形式の「成功基準」を追加して、親ユーザーストーリー内のさまざまなアクションで何が起こるかを説明します。これは、機能を個別に理解できる部分に分解する適切な方法であり、さまざまなグループからさまざまなストーリーを作成するのに役立ちます（作業を承認するトップレベルの人が同じであることを確認してください）。

したがって、システムの古い機能をすべてユーザーストーリーとして書き直してから、プロジェクトの所有者にJavaバージョンに必要な新しい機能があるかどうかを尋ねます。ストーリーがあればそれを満たし、コーディングを開始します。

基本的には、スタッフプログラマーの役に立たないことを公開できる必要があります。プロジェクトオーナーに、いくつかのストーリーの成功基準を提供するように依頼してください。そうすれば、不合理な入力があった場合でも、それを公式の要件として保持できます。彼らが残したものはすべてあなたのせいではなく、彼らのせいです。

私はシステム全体がOracle Formsで作成されたプロジェクトに関与しましたが、ドキュメントはありませんでした。テクノロジーは簡単にPerlであった可能性があります。システムをOracle ADFに移行するための攻撃計画は次のとおりです（他のプラットフォームと同じくらい簡単にできます）。

1. ビジネス要件（機能、バグ、検証、UIなど）のコードカテゴリのセットを作成します。
2. 画面のカテゴリのセットを作成します（同様の機能でグループ化します）。
3. アプリケーション全体のすべての画面のリストを作成し、スプレッドシート内で列挙します。
4. 各画面にコードカテゴリとコードタイプ（ビジネスルール、システム要件、技術など）を割り当てます。
5. コードをリバースエンジニアリングしてビジネス要件を抽出し、各要件を1文で記述します。

この時点で、アプリケーションのビジネスルールが文書化されています。これだけで、次にシステムを維持しなければならない人にとっては金になるでしょう。さらに、システムのどの部分が複製されているかを確認する機会が与えられます。（私の場合、コードベースの60％以上が重複していることがわかりました。）

ここから、管理を使用してビジネス要件を分類できます。たとえば、ユーザーストーリーの作成が必要になる場合があります。これにより、高レベルの重複機能が明らかになり、移行中にシステムを簡素化および強化する機会が提示されます。要件の追跡と文書化を行う1つの方法を示すために、スプレッドシートのスクリーンショットを含めました。

Perlをブラッシュアップする必要があるかもしれません。;-)

プロジェクトをリバースエンジニアリングしたら、ソフトウェア開発ライフサイクルを支援する一連のツールを使用できます。（私たちはJIRAを使用していますが、機能する他の多くのソフトウェアスイートがあります。）いくつかの戦いが必要になるかもしれませんが、要件が下がったら、次の環境に移動する必要があります。

• ドキュメンテーション環境を作成します（例：wiki）。
• 開発（DEV）環境を作成します。Webサーバー、データベースサーバー、ソースリポジトリなど
• 開発を反映したテスト（TEST）環境を作成します。
• 本番環境を正確に反映し、本番システムのフェイルオーバーとして機能できる本番前環境（PREPROD）を作成します。
• 実稼働（PROD）環境を作成します。

コミュニティ指向のサービスを使用して、エンドユーザーのドキュメントの要件に取り組むことを検討してください。StackExchangeスイートに似た優れたソフトウェアパッケージはOSQAです。ユーザーにヘルプシステムを構築させます（これは非常に賢い戦略です）。

SDLCは次のようになります。

1. 開発者はDEVでアプリケーションの変更を行い、テストします（リポジトリを使用）。
2. システムツールは、通常のビルドをTESTに自動的に展開します。
3. テスターがアプリケーションに満足したら、アプリケーションはPREPRODにデプロイされます。これにより、展開プロセスもテストできます。PREPRODでさらにテストが行​​われます。
4. テスト担当者がPREPRODに満足すると、アプリケーションは最終的にPRODに組み込まれます。

これは、さまざまな開発方法論でうまく機能する高度に組織化されたアプローチであると思います。ここで説明した最初のパスは、「幅広いブラシストローク」と見なす必要があります。この時点では、テクニカルマニューシャで細かくなりすぎないようにしたくありません。（たとえば、ユーザーインターフェイスの要件は各画面でキャプチャされます。画面が列挙されている限り、すべての入力フィールドを繰り返す必要はありません。スクリーンショットまたは作業URLにリンクするだけです。）

最後に、ソースコードを確認するために、一連のWebページ（機能的な「画面」ごとに1つのWebページ）を自動生成しました。PL / SQLコードを個別のファイルに分割し、構文を強調表示して自動的にHTMLに変換できるため、これはうまくいきました。Perlの場合、これはうまく機能しない可能性があります。ただし、アイデアは、ビジネス要件を適用するコードのセクションに戻るアンカーリンクをスプレッドシート内に作成できるということです。（余談ですが、これにより、複数の開発者がシステム要件を並行してリバースエンジニアリングすることもできます。各開発者が同時に異なる画面に取り組むことができるためです。）

ソースコードスニペットの例（+はアンカーリンクです）：

分析タスクを支援するために、いくつかのPerlグルを雇うことをお勧めします。

他の人が「くだらない仕事」をしていることを指摘するのはあまり生産的ではないと思います。むしろ、製品を改善し、人々にこの目標を手助けする機会を与えるべきです（そしておそらく、プロセスにおけるスキルを改善する方法を学ぶべきです）。つまり、他の開発者が何を知っているのか、システムを開発したときにそこにいなかったのです。このアプローチにより、プロセス全体がオープンになり、誰もが貢献できるようになります。

正直に言うと、マネージャーは自分が本当に役に立っていて、改善したいと思っていることを自分で確かめます。

彼らはドキュメンテーションを持っていません、そして彼らのコードはとても貧弱で、彼らは別の言語でそれを書き直すために他の誰かを雇いました。ソースから要件の収集を開始します。多くの機能が使用されなくなったか、正しく機能しない可能性があります。何を構築しないかを知ることも同様に重要です。

ユーザーが必要とするものを見つけたら、現在のアプリケーションにすでにあるものと、最初から何を構築する必要があるかを判断します。既存の部分は、コードを見て開発者と話すことができる場所です。

すべてが必要だと宣言する人は誰もチェックする必要はありません。アプリケーションを絶対に書き直さないという議論がありますが、それはすべてがユーザーの望みどおりに機能することを前提としており、常にそうであるとは限りません。彼らは代替手段がないのでそれを使用します。彼らにもっと良い選択肢を与える。

まず、マネージャーと話をして、要件を収集し、仕様を定義する責任を引き受けます。これらの文書の必要性とそれらが提供するものを彼に納得させる必要があります。オンラインで例を見つけるでしょう。次に、システムの要件と仕様の組み立てを担当します。その後、マネージャーと再度会ってドキュメントを確認します。最初のドキュメントを表示したら、他の5つのドキュメントの作成を支援できる可能性があります。それ以外の場合、それが効果的であれば、おそらくそれらの要件の収集も担当しますが、少なくとも誰かがそれを実行します。