완전한 기능을 갖춘 응용 프로그램이나 베어 본을 만든 다음 천천히 기능을 추가해야합니까?

작업 현장 예약 프로그램을 만드는 데 IT 업무를 맡은 제조 공장에서 일하고 있습니다 (매우 필요합니다). 다른 경험을 바탕으로 사용 시간을 줄이고 사용 가능한 기본 프레임 워크를 구축 한 다음 기능을 추가하거나이를 기반으로 완전히 구현 된 솔루션을 구축하여 시작하는 것이 좋습니다. 나는 약 1 년 동안 개발자 였으며이 크기의 앱을 처음 만든 경험이별로 없습니다. 나는 일종의 디지털 일정에 대한 극단적 인 필요성 때문에 베어 본 앱이 가장 먼저 갈 길이라는 생각에 기울어지고 있지만 사실 이후에 임의의 기능을 추가하면 약간 지저분해질 수 있습니다. 만약 당신이 같은 상황에 있다면 당신은 어떤 길을 기대합니까?

경험은 분명히 작고 단순한 것을 구축하고 가능한 한 빨리 사용자에게 전달합니다. 사용자가 요청한대로 기능을 추가하십시오.

그들이 원하는 것 / 요청한 것이 당신이 아주 많이 쌓은 것과 닮지 않을 가능성이 매우 높습니다 (특정 경계선).

원래 애플리케이션에 추가 할 때 문제가 발생하는 한, 이것이 바로 애자일 (및 가장 유사한 방법론)이 테스트 및 리팩토링에 중점을 둔 이유입니다. 리팩토링이란 변경 작업을 수행 할 때 코드를 정리하는 것을 의미하며, 테스트 할 때마다 실행하는 견고한 테스트 스위트를 사용하면 버그를 발견 한 경우 (거의) 즉시 버그를 발견 할 수 있으므로 사용자에게는 실제로 작동한다는 합리적인 확신이 있습니다.

그들이 앱에 대해 진지한 지 여부를 알고 있다면 프레임 워크 등을 구축하고 싶지 않을 수도 있습니다.

그러나 균형을 찾아야합니다. 애자일 개발은이 단계에서 앱에 필요한 것에 초점을 맞출 것을 제안하지만 이것이 기본 디자인을 무시하여 자신을 제한해야한다는 의미는 아닙니다. 다가오는 것으로 쉽게 볼 수있는 것들이 있습니다 (예 경험이 여기에서 중요한 역할을합니다).이 단계에서 상상할 수없는 것들이 있습니다 (앱을 요청한 사람들도 상상할 수 없습니다).

예약 앱의 세부 정보를 모르지만 "약속 유형"이 곧 나올 것이라고 상상할 수 있습니다. 아마도 사람들은 지금 이것을 요구하지 않을 것입니다. 그러한 기능을 기대하는 것이 합리적이지 않습니다.

약속 유형을 보유하기 위해 데이터베이스에 테이블을 생성하여 인프라 (사용자가 언급 한 프레임 워크)를 구축하지만 유형을 추가하거나 선택하기 위해 인터페이스를 만들지 않아도됩니다. 기본 유형을 하드 코딩하고 실제 기능으로 넘어갑니다. 결국, 아무도 다른 유형의 약속을 포함하도록 요청하지 않았습니다.

그런 다음 나중에이 기능을 요청하는 사람들이 귀하에게 다시 와서 구조를 가지면 중간 / 프론트 엔드 만 구축 할 수 있습니다.

초기에 완전한 프로그램을 빌드하기에 충분한 정보가없는 경우가 종종 있습니다. 테스트 및 고객 피드백은 거의 항상 초기 설계에서 이론적으로 좋지 않은 부분을 보여줍니다.

즉, 문제를 잘 이해하고 처음에 완전한 프로그램을 작성할 수 있다면 코드를 리팩터링하고 결과가 처음부터 따라온 견고한 디자인만큼 드물기 때문에 더 좋습니다.

최소한 프로그램에 필요한 기능 유형에 대해 열심히 생각하는 것이 중요하다고 생각합니다. 이러한 방식으로 기존 구조 내에 이러한 기능을 쉽게 추가 할 수 있도록 설계 할 수 있습니다.

개인적인 경험에서 : MVP (최소 실행 가능 제품)를 구축 한 다음 수신 한 피드백에 따라 기능을 추가하십시오. 수많은 기능을 쉽게 사용할 수 있으며 다른 사람이 사용하지 않아도됩니다.

또한 문제 해결에 사용하는 사용자 경험도 중요합니다. 실제 사용자로 작성한 워크 플로우를 검증 한 후 추가 기능을 추가하십시오. 그렇게하면 구축중인 핵심 가치에 집중할 수 있습니다.