大きなプロジェクトにはスクラムを使用すべきですか？
私は18か月間、プログラマーとして（多くの顧客に再配布される）ガソリンスタンドの汎用ソフトウェア用に設計されたプロジェクトに取り組んできました。プロジェクトは大きいです。現在、約150のテーブルがあります。特定のアプローチは使用していません。適切に管理されていませんでした。
Personテーブルには今日約70列ありますが、15か月前には約30列でした。これらの新しい分野は、販売、財務、会計などの他のモジュールと統合するために登場しました。また、多くのフィールドが作成されてから削除されました。
その結果、多くのリファクタリングとリワークがありました。常に新しい要件が発生しているため、プロジェクトの準備はできません。
ここに私の疑問があります。通常の仕様アプローチを使用した場合、インタビュー、要件文書、アクティビティ、シーケンス、およびクラス図があり、「人」テーブルには70個のフィールドが必要であることを最初から知っているので、多くのリファクタリングを避けていました。
スクラムはこのプロジェクトに役立ちますか？この場合、スクラムも多くのリファクタリングを行うことになると思います。
私はプログラマーであり、プロジェクトマネージャーではありません。私はそれがどのように行われるべきであったのかと思っています：スクラムまたは大きなデザインを前もって。
編集
この話の終わりを補足するために。 8か月後、私はこの質問をしました。プロジェクトをいくつかの「テスト衣装」で生産した後、プロジェクトは公式に失敗しました。製品所有者はプロジェクトを中止することを決定しました。問題の修正が難しくなり、多くのパフォーマンスの問題が発生しました。
制御されていない開発プロセスに挑戦し、終わりのない開発システムを作成したようです。これはアジャイルシステムでも発生します。
根本的な問題は要件の欠如であり、ソリューションはこれを修正するためにアジャイル手法を使用するように見えるかもしれませんが（アジャイルは要件の変化を中心に設計されているため）、問題は解決しません。
アジャイル手法でも、かなりしっかりとした出発点が必要です。これらは変化する要件によく対応しますが、要件なしで開始した場合、他の方法論と同じように役に立たなくなります。あなたはまだあなたが始める前にあなたが向かっている計画を持っている必要があります。アジャイルは、その目標がずれた場合に役立ちますが、その目標を定義するのには役立ちません。
現在、何を構築しているのか正確に知らない場合、固定された事前設計が厳格すぎることは事実です。
したがって、現在の「カオス」の方法論からより体系的なものに移行する必要があり、かなりの量の設計と計画を実装する必要があると思います。重い方法で一度にこれを実行するか、アジャイルな方法でより柔軟にすることができます。あなたができないことは、初期計画の欠如を修正するための方法論を期待することです。
ちなみに、かんばんはあなたのニーズにより適しています。スクラムは小規模なチームやプロジェクトで最適に機能します。かんばんは大規模なプロジェクトで機能しますが、スループットの作業アプローチでも機能するため、設計変更は継続的であり、スプリントに分割されません。あなたはそれでもっと成功すると思います。
18か月、150テーブル、それでもまだ生産されていませんか？ 死の行進 のように聞こえます。これを修正できる唯一の方法は、これを保存する可能性がある場合、プロジェクトのスコープを劇的に狭めることです-少なくとも最初の製品リリース。必要なのは、適切なリリース計画、小さくて到達可能な目標、およびできるだけ早くシステムをエンドユーザーに届けることです。
また、最初のリリースが本番環境にあり、要件の10分の1しか実装されていない場合は、次の要件のブロックまで段階的にそれを拡張する必要があり、「リファクタリング」が発生します。また、バグ修正と要件の変更を意味するフィードバックも得られ、リファクタリングも発生します。
さて、質問です-スクラムは役に立ちますか？多分そうでないかもしれません。スクラムは、反復的な開発と変化する要件をサポートするためのツールであり、最初に重要なことに焦点を当てています。他の「アジャイル」メソッドもこれを行い、あまり正式化されていないプロセスもそれを処理する可能性があります。しかし、このようなモンスターを1つの「ビッグバン」でプロダクションに入れようとする限り、「アジャイル」開発と「フロント」開発のどちらを使用しても問題ありません。どちらも失敗します。
ですから、スクラムについて考える前に、まず目標とリリース戦略を考え直してから、スクラムがそのための適切なツールであるかどうかを確認してください。逆もまた同様です。
要件を管理することができず、要件を適切に実装できる人がいない場合、SCRUMは（多くの）助けにはならず、それがあなたが直面している本当の問題のようです。
SCRUMは、より静的なプロジェクト管理システムよりも変化する要件に対処するのに役立ちますが、すべてを魔法のように機能させるための聖杯ではありません。実際、あなたの人々がSCRUMに参加し、進んで能力を持ち、他の組織もそうである場合を除き、事態はさらに悪化する可能性があります。
他のシステムとリンクするためのものが収まるほど大きくなったテーブルがある場合、たとえば、データベース設計に深刻な欠陥があると仮定します。 SCRUMがデータベース設計を改善することはありません。チームのデータベース設計に長けている人々を含め、それらの設計変更や、システムの残りの部分に生じる変更を恐れない限り、データベース設計を改善することはできません。
この回答を書いたとき、システムがまだ稼働していないことに気づかなかったことに注意してください。
彼らがあなたの製品を説明する方法であり、私はあなたの差し迫った問題が要件の管理や開発プロセスの問題であるとは思いません。それはあなたのシステムアーキテクチャのものです。
あなたはなんとかモノリスを作成することができました-そしてそれでかなり大きなものを。 150テーブルは、1つのシステム*にはたくさんあります。特に、過去15か月の間に、外部システムに統合するためだけに40newフィールドがあると述べました。システムを複数の自律サービスに分割することを真剣に検討します。おそらく外部システムへの統合サービスから始めますが、後でモノリスに実装されている個別のビジネス領域を特定し、それらの懸念を個別のサービスに分割することを検討します。
このモノリスを個別の保守可能なコードベースに分割できた場合、開発者をビジネスの特定の領域で明確に定義された責任を持つ小さなチームに分割することもでき、独自のコードベースを維持する多くの小さなアジャイルチームを持つことができます。同じコードベースですべてハッキングするのではなく。
なぜこのようなアーキテクチャに到達したのか、問題の根本的な原因については、多くの答えが考えられます。多分それはあなたの開発プロセスに根ざしているかもしれません、多分あなたのすべての開発者はトランザクション一貫性のあるソフトウェアでのみ経験されているかもしれません、あるいは多分それはあなたの組織がどのように構造化されたかの結果です（あなたは コンウェイの法則 の犠牲者です）。後者の2つの組み合わせである可能性が高いと思います。
スクラムを実装したり、要件の管理を改善したりすることが、差し迫った問題や根本原因の解決に役立つとは思いません。システムの複雑さに合わせてアーキテクチャを調整し、そのようなシステムを構築した理由の根本的な原因に対処します。
* 150のテーブルを持つシステムを維持できると主張する人もいるでしょう-あるいははるかに大規模なシステムを維持してきたと思いますが、ほとんどの開発者はこれを1つのシステムに多数のテーブルと見なすと思います。