大きなプロジェクトにはスクラムを使用すべきですか？[閉まっている]

私は18か月間、プログラマーとして（多くの顧客に再配布される）ガソリンスタンドの汎用ソフトウェア用に設計されたプロジェクトに取り組んできました。プロジェクトは大きいです。現在、約150のテーブルがあります。特定のアプローチは使用していません。適切に管理されていません。

personテーブルには今日約70列ありますが、15か月前には約30列でした。これらの新しいフィールドは、販売、財務、会計などの他のモジュールと統合するために登場しました。また、多くのフィールドが作成されてから削除されました。

その結果、多くのリファクタリングとリワークがありました。常に新しい要件が発生しているため、プロジェクトの準備はできません。

ここに私の疑問があります。通常の仕様アプローチを使用した場合、インタビュー、要件文書、アクティビティ、シーケンス、およびクラス図があり、「人」テーブルには70個のフィールドが必要であることを最初から知っているので、多くのリファクタリングを避けていました。

スクラムはこのプロジェクトに役立ちますか？この場合、スクラムも多くのリファクタリングを行うことになると思います。

私はプログラマーであり、プロジェクトマネージャーではありません。私はそれがどのように行われるべきであったのか疑問に思っています：スクラムまたは大きなデザインを前もって。

編集する

この話の終わりを補足するだけです。8か月後、私はこの質問をしました。プロジェクトをいくつかの「テスト衣装」で生産した後、プロジェクトは公式に失敗しました。製品の所有者はプロジェクトを中止することを決定しました。問題の修正が難しくなり、多くのパフォーマンスの問題が発生しました。

制御されていない開発プロセスに挑戦して、終わりのない開発システムを作成したようです。これはアジャイルシステムでも発生します。

根本的な問題は要件の欠如であり、ソリューションはこれを修正するためにアジャイル手法を使用するように見えるかもしれませんが（アジャイルは要件の変更を中心に設計されているため）、問題は解決しません。

アジャイル手法でも、かなりしっかりとした出発点が必要です。それらは変化する要件によく対応しますが、要件なしで開始した場合、他の方法論と同じように役に立たなくなります。あなたはまだあなたが始める前にあなたが向かっている計画を持っている必要があります。アジャイルは、その目標がドリフトするときに役立ちますが、その目標を定義するのに役立ちません。

現在、何を構築しているのか正確に知らない場合、固定された事前設計が厳格すぎることは事実です。

したがって、現在の「カオス」の方法論からより体系的なものに移行する必要があり、かなりの量の設計と計画を実装する必要があると思います。重い方法で一度にこれを実行するか、アジャイルな方法でより柔軟にすることができます。あなたができないことは、初期計画の欠如を修正するための方法論を期待することです。

ちなみに、かんばんはあなたのニーズにより適切に聞こえます。スクラムは小規模なチームやプロジェクトで最適に機能します。かんばんは大規模なプロジェクトでも機能しますが、スループットの作業アプローチでも機能するため、設計変更は継続的であり、スプリントに分割されません。それでもっと成功すると思います。

18か月、150テーブル、それでもまだ生産されていませんか？私には死の行進のように聞こえます。これを修正できる唯一の方法は、これを保存する可能性がある場合は、プロジェクトの範囲を劇的に狭めることです-少なくとも最初の製品リリースでは。必要なのは、適切なリリース計画、小さくて到達可能な目標、およびシステムをできるだけ早くエンドユーザーに届けることです。

また、本番環境で最初のリリースがあり、要件の10分の1しか実装されていない場合は、次の要件ブロックまで段階的に拡張する必要があり、「リファクタリング」が発生します。また、バグ修正と要件の変更を意味するフィードバックも得られ、リファクタリングも発生します。

さて、質問です-スクラムは役に立ちますか？多分そうでないかもしれません。スクラムは、反復的な開発と変化する要件をサポートし、最初に重要なことに焦点を当てるツールです。他の「アジャイル」メソッドもこれを行い、あまり正式化されていないプロセスもこれを処理する可能性があります。しかし、このようなモンスターを1つの「ビッグバン」でプロダクションに入れようとする限り、「アジャイル」開発と「フロント」開発のどちらを使用しても問題ありません。どちらも失敗します。

したがって、スクラムについて考える前に、まず目標とリリース戦略を再検討し、次にスクラムがそのための適切なツールであるかどうかを確認してください。

要件を管理できず、要件を適切に実装できる人がいない場合、SCRUMは（大いに）役立ちません。これは、直面している本当の問題のようです。
SCRUMは、より静的なプロジェクト管理システムよりも変化する要件への対処に役立ちますが、すべてを魔法のように機能させるための聖杯ではありません。実際、あなたの人々がSCRUMに参加し、進んで能力があり、組織の他の部分もそうでない限り、事態はさらに悪化する可能性があります。

他のシステムとリンクするために非常に大きくなったテーブルがある場合、たとえば、データベース設計に深刻な欠陥があると仮定します。SCRUMがデータベース設計を改善することはありません。チームのデータベース設計に長けている人々を含め、それらの設計変更やシステムの残りの部分に加えられる変更を恐れない限り、データベース設計は改善されません。

この回答を書いたとき、システムがまだ稼働していないことに気づかなかったことに注意してください。

彼らがあなたの製品を説明している方法ですが、私はあなたの当面の問題が要件の管理や開発プロセスの問題だとは思いません。それはあなたのシステムアーキテクチャのものです。

あなたはなんとかモノリスを作成することができました-そしてそれでかなり大きなものを。150テーブルは、1つのシステム*にはたくさんあります。特に、過去15か月の間に、外部システムに統合するためだけに40の新しいフィールドがあると述べました。システムをいくつかの自律サービスに分割することを真剣に検討します。おそらく外部システムへの統合サービスから始めますが、後でモノリスに実装されている個別のビジネス領域を特定し、それらの懸念を個別のサービスに分割することを検討します。

このモノリスを個別の保守可能なコードベースに分割できれば、開発者をビジネスの特定の領域で明確に定義された責任を持つ小さなチームに分割でき、独自のコードベースを維持する多くの小さなアジャイルチームを持つことができます。同じコードベースですべてハッキングするのではなく。

なぜこのようなアーキテクチャに到達したのか、問題の根本的な原因については、多くの答えが考えられます。多分それはあなたの開発プロセスに根ざしているかもしれません、多分あなたのすべての開発者はトランザクション一貫性のあるソフトウェアだけで経験しているかもしれません、または多分それはあなたの組織の構造の結果です（あなたはコンウェイの法則の犠牲者です）。後者の2つの組み合わせである可能性が高いと思います。

スクラムを実装したり、要件の管理を改善したりすることが、差し迫った問題や根本原因の解決に役立つとは思いません。システムの複雑さに合わせてアーキテクチャを調整し、そのようなシステムを構築した理由の根本的な原因に対処します。

* 150のテーブルを持つシステムを維持できると主張する人もいるでしょう-あるいははるかに大規模なシステムを維持してきたと思いますが、ほとんどの開発者はこれを1つのシステムに多数のテーブルと見なすと思います。