完全な機能を備えたアプリケーションを構築するか、必要最低限​​のアプリケーションを構築してから、徐々に機能を追加する必要がありますか？

私は、製造現場のスケジューリングプログラムの作成をITに任せている製造工場で働いています（これは非常に必要です）。他の経験に基づいて、より少ない時間で利用可能な基本的なフレームワークを構築し、機能を追加することでその上に構築するか、完全に実装されたソリューションをすぐに作成して開始する方が良いでしょうか？私は約1年しかデベロッパーではなく、このサイズのアプリの初期作成の経験はあまりありません。私は、ある種のデジタルスケジュールが非常に必要なため、ベアボーンアプリが最初に行く方法であるという考えに傾いてきましたが、事実の後にランダムな機能を追加すると少し厄介になる可能性があります。あなたが同じ状況にあった場合、あなたはどの道に向かって傾くでしょうか？

経験は間違いなく、小さくてシンプルなものを構築し、できるだけ早くユーザーに提供することにつながります。ユーザーが要求する機能を追加します。

彼らが望んでいる/求めるものは、（もしあれば）自分で構築したものとあまり似ていない可能性があります（確かに境界線があります）。

元のアプリケーションに追加することで面倒になる限り、アジャイル（およびほとんどの同様の方法論）がテストとリファクタリングに重点を置くのはこのためです。リファクタリングとは、変更を加えたときにコードをクリーンアップすることを意味します。また、変更を加えるたびに実行する堅牢なテストスイートにより、バグを導入した場合、またはバグを知った場合は（ほぼ）すぐに、何かをリリースしたときにユーザーは、実際に機能することを合理的に保証します。

彼らがアプリに真剣であるかどうかはわかりますか？

ただし、バランスを見つける必要があります。アジャイル開発では、この段階でアプリに必要なものに集中することをお勧めしますが、これは、基本的な設計を無視して自分を制限する必要があるという意味ではありません。来ていると簡単に見られるものがあります（そして、ここで経験が役立っています）と、この段階では想像できないものがあります（アプリを要求した人々もそれらを想像できないと確信しています）。

スケジュールアプリの詳細はわかりませんが、「予定の種類」はすぐに出会えるものであると想像できます。おそらく、人々はこれを要求しないでしょう、そのような機能を期待することは合理的ではありません。

この場合、次のようにアプローチします：データベースにテーブルを作成して予定タイプを保持することでインフラストラクチャ（あなたが言及したフレームワーク）を構築しますが、タイプを追加または選択するためのインターフェイスを作成することはありません。基本的な型をハードコーディングし、実際の機能に進みます。結局のところ、誰も異なる種類の予定を含めることを求めませんでした。

その後、将来、人々がこの機能を求めて戻ってきたら、あなたはその構造を持ち、ミッド/フロントエンドを構築するだけです。

多くの場合、最初の完全なプログラムを作成するのに十分な情報がありません。テストと顧客からのフィードバックにより、ほとんどの場合、初期設計の一部が理論よりも良くなかったことが明らかになります。

ただし、問題が十分に理解されており、最初に完全なプログラムを作成できる場合は、コードを常にリファクタリングしており、結果が最初から続いた堅実なデザインほどきれいではないため、これはより良い方法です。

少なくとも、プログラムに必要な機能の種類について一生懸命に考えることが重要だと思います。そうすれば、そのような機能を既存の構造内に簡単に追加できるように設計できます。

個人的な経験から：MVP（Minimum Viable Product）を構築し、受け取ったフィードバックに基づいて機能を追加します。たくさんの機能を簡単に入手でき、誰も使用することはできません。

また、問題を解決するために使用するユーザーエクスペリエンスも重要です。実際のユーザーで作成したワークフローを検証し、さらに機能を追加します。そうすれば、構築しているコアバリューに集中できます。