일반적으로 모든 기능 부분을 만들거나 UI를 먼저 작동시키는 것이 더 낫습니까?
큰 무언가를 작업하고 있다고 가정하면 일반적으로 모든 기능적 데이터 수집 블롭을 UI보다 먼저 작동시키고 모든 UI를 한 번에 한 조각 씩 또는 중간에 작동시키는 것이 일반적으로 허용됩니까?
우리는 모두 관리 가능한 부분으로 작업을 분류하는 것을 알고 있지만 궁극적으로 UI가 관리 가능한 부분에 포함되는지 여부는 궁극적으로 문제입니다.
예를 들어, 하나의 루트 창이있는 GUI 응용 프로그램을 고려하지만 다양한 도크에있는 수십 개 이상의 탭이 서로 다른 데이터 구성 요소를 분리합니다. 각 개별 탭에는 기능 단위 관점에서 비교적 복잡한 이동 부품 세트가 있습니다.
답변:
이 때 많은 비즈니스 사용자와 클라이언트 사이에 일반적인 개념이 보이는 완료, 거의 완료가. 아시다시피, 이것은 진실과 거리가 멀습니다. 하나는 멋지게 보일 수 있지만 백엔드는 없으며 일부 사용자는 20 % ( 또는 다른 80 % )가 아니라 80 %의 작업으로 생각합니다 .
셀 수없이 많은 개발자들이 이에 대한 공포 이야기를 들려 줄 수 있습니다. 다른 도구의 스크린 샷을 사용하여 Microsoft Word에서 페이지를 모방하고 클라이언트가 "거의 완료 했습니까?"
모든 부품이 완성되면 속도를 조절해야합니다. 모든 백엔드를 먼저 수행 한 다음 모든 프론트 엔드를 시도하면 최종 사용자가 아무것도하지 않는다고 생각하고 표시 할 것이 없을 때 왜 돈을 받고 있는지 묻습니다. 다른 한편으로, 프론트 엔드를 먼저하면 최종 사용자가 변화를 겪고 우리의 시간을 소비한다는 것을 알게 될 것입니다.
'첫 번째와 다른 하나'의 최악의 경우는 다른 부분에 도달했을 때 디자인에 전혀 맞지 않는 것입니다.
따라서 둘 다 빌드하십시오. 프론트 엔드에서 진행 상황을 보여주고, 백엔드가 당신이 만들고있는 것을 사용하도록하십시오. 많은 경우 증분 빌드를 제공하고 클라이언트가 원하는 것을 만들고 있는지 확인하는 것이 좋습니다 (이것은 Agile에 해당). '눈에 띄는 진보'를하지 않고 너무 오래 가면 고객 관계가 손상 될 수 있습니다 ( '모든 것은 조기에 해본 것'과 '끝까지 아무 것도 이루어지지 않은' 두 경우 모두에 해당합니다. 단위 테스트 또는 데이터 위생 처리 진행).
Joel은 이에 대해 빙산의 비밀 에 다음과 같이 기록했습니다 .
중요한 추론 2. 프로그래머가 아닌 사용자에게 100 % 아름다운 사용자 인터페이스가있는 화면을 표시하면 프로그램이 거의 완료된 것으로 간주합니다.
프로그래머가 아닌 사람들은 단지 화면을보고 일부 픽셀을보고 있습니다. 그리고 픽셀이 무언가를하는 프로그램을 구성하는 것처럼 보인다면, "오, 세상에, 실제로 작동시키기가 얼마나 더 어려울까요?"
여기서 가장 큰 위험은 UI를 먼저 조롱하면 아마도 고객과 대화를 나눌 수 있고 모든 사람들이 거의 다 끝났다고 생각할 것입니다. 그리고 내년에 "표지 아래"에서 일할 때, 아무도 당신이하고있는 일을 실제로 보지 못할 것이고 그들은 아무것도 아니라고 생각할 것입니다.
이것은 블로그 포스트에서 다시 한 번 강조됩니다. 이 유용한 그래프가 있는 데모를 완성하지 마십시오 .
여기서 두 가지 옵션은 일반적으로 'ui를 완료하십시오'(그리고 곧 완료 될 것으로 기대합니다)와 '백엔드를 완료하십시오'(고객이 마감 기한을 놓친 것에 대해 걱정합니다)를 반영합니다.
'완료'된 모습이 '완료'된 모습과 일치해야합니다.
모든 소프트웨어 개발자는 경력에서이 경험을 여러 번 경험했습니다. 그러나 데스크톱 출판 도구는 기술 작가들에게도 같은 문제를 야기합니다. 누군가에게 완벽하게 글꼴이 지정되고 서식이 지정된 초안을 표시하면 원하는 것보다 더 완성 된 것으로 간주됩니다. 우리는 우리가있는 곳과 다른 사람들이 우리를인지하는 곳이 일치해야합니다.
이 기사는 또한 사용자 인터페이스의 다양한 수준의 피드백으로 얻는 피드백 유형 에 대한 중요한 요점을 제공합니다 . 완성 된 것으로 보이는 경우 "이 레이아웃이 작동하지 않습니다. 탭이 너무 많습니다"보다 "글꼴을 변경할 수 있습니까?"에 대한 피드백을받을 가능성이 높습니다.
Java Swing 세계에서 이와 싸우고있는 사람들에게는 Napkin 이라는 모양과 느낌 이있어 UI가 완벽하게 보이지 않게합니다.
열쇠는 여기가되지 않도록 그것을 확인하는 것입니다 봐 다. UI가 완성 된 것처럼 보이게하는 것은 많은 비즈니스 사용자에게 응용 프로그램이 완벽하다는 신호입니다 (어떤 로직 페이지 나 인터페이스 빌더에 내장되지 않은 정적 페이지가 몇 개인 경우에도).
추가 자료 (및 기사의 링크) :
그것은 따라 달라집니다 당신이 기능의 가장 중요한 부분 주위에 꽉 피드백 루프를 필요
위험한 부분과 위험한 부분이 내부 엔진 인 경우 콘솔에서 또는 단위 테스트를 통해 핵심 부분을 작동시킵니다. 예를 들어, 프로토콜 파서는 제대로 작동하는지 알기 위해 UI가 필요하지 않습니다.
멋진 작업에 상호 작용 (상호 작용)이 계속해서 문제를 해결하고 버리고 재발견해야하는 경우 UI 우선 접근 방식이 중요합니다. 예를 들어 사람들이 데이터 시각화와 상호 작용할 수 있도록 앱을 만들고 싶습니다. 내가 알아 내야 할 가장 중요한 것은 시각화가 의미가 있는지 여부입니다. 따라서 하나에 정착하기 전에 6 가지 접근법을 버릴 것입니다. 단일 단위 테스트를 작성하기 전에이 모든 작업을 수행하겠습니다.
코드를 가장 잘 상호 작용하고 유효성을 검사하는 방법 (자동 테스트, 실험 UI)에 대한 최상의 조합을 결정하는 영역에는 희미한 회색 영역이 있습니다. 나는 개인적으로 극단과 그 사이의 모든 것을 수행했으며, 그 스펙트럼에 적합한 장소를 결정하는 것은 내가 결정해야 할 가장 어려운 일 중 하나이며 내가 짓고있는 물건의 유형에 100 % 의존합니다.
민첩한 환경에서는 "걷는 뼈대"또는 "얇은 세로 조각"에 대한 토론을들을 수 있습니다. 아이디어는 작동하는 소프트웨어가 사용자에게 중요하기 때문에 작동 방식으로 소프트웨어를 하나씩 구축하는 것입니다.
앞서 언급 한 예제 응용 프로그램에서는 창과 하나의 탭으로 시작하여 모든 방식으로 앞뒤로 작동하게합니다. 그런 다음 시간이 지남에 따라 기능별로 탭을 추가하여 각 기능을 빌드 할 때 작동하도록합니다. 이것은 고객 시연이 자주하는 일 중 하나입니다. 새로운 작업을 보여주고 즉각적인 피드백을받을 수있는 기회입니다.
간단히 말해, UI 작업은 UI가있는 경우 기능 작업 단위의 일부이며 절대적인 부분입니다.
작동하는 작은 것으로 시작하여 기능을 반복하여 전체 소프트웨어를 제공하십시오.
기능과 UI를 혼합하여 피드백 또는 테스트 경험을 최대한 빨리 얻는 것이 좋습니다.
BTW, 가장 큰 GUI 소프트웨어가 개발되는 방식이 아닙니까? 한 버전에서 다음 버전으로 Firefox 브라우저 를 살펴보십시오 . 기능과 사용자 인터페이스가 모두 발전했습니다.
내가 작업하는 대규모 (PHP 웹 기반) 응용 프로그램에서 클래스와 메서드를 먼저 가져 와서 더미 값을 반환 하려고 합니다 . 이것은 다른 개발자가 UI를 구현하는 데 사용할 수있는 의사 계약을 설정하는 것입니다.
이 방법의 두 번째 장점은 모든 코드를 작성하고 전달하기 전에도 UI 요구 사항이 변경 되고 항상 변경 될 때 계약 / 인터페이스를 연마 할 수 있다는 것 입니다.
내가하는 경향이있는 것은 crappy UI 로 시작하는 것입니다 : 화면에서 변수 데이터를 덤프하는 것입니다. 글꼴도없고, 정렬도없고, 실제로 오랫동안 그래픽적인 것도 없습니다. "Welcome user x"와 "load pic"등의 버튼 만 있으면됩니다. 이것에 대한 좋은 점은 백엔드의 무언가가 깨 졌는지 알 수 있다는 것입니다.
개발이 진행됨에 따라 더 많은 작업을 진행해야 할 수도 있습니다. 그러나 어떤 단계에서는 백엔드가 거의 완성 된 것으로 결정합니다. 이제 필요한 모든 첨부 파일이 포함 된 UI가 있으며 모든 그래픽 작업을 수행하는 데 많은 시간을 할애 할 수 있습니다.
그럼에도 불구하고 절대 안전하지 않습니다. 발생하는 특정 문제를 보려면 약간의 예측이 필요합니다. 예를 들어, 합리적인 방식으로 데이터를 표시하기 위해 UI 구성 요소를 조사해야 할 수도 있습니다.
따라 다릅니다. 요구 사항이 얼마나 잘 정의되어 있습니까? UI가 어느 시스템에 직면하고 있습니까?
내 경험에 비추어 볼 때 대부분의 고객은 자신의 앞에 무언가를 볼 때까지 원하는 것을 알지 못합니다. 따라서 일반적으로 주요 UI 측면의 일부 와이어 프레임을 제공하거나 대부분의 UI를 제공합니다 (작동하지 않음). 이를 통해 데이터베이스 설계 및 코드 구조가 여전히 설계 단계에 있기 때문에 고객이 너무 많은 영향을받지 않고 기능 / 기능에 대한 생각을 바꿀 수 있습니다. 설계를 쉽게 수정할 수 있습니다. 프로젝트 초기에 설계를 변경 한 후 나중에 변경하는 것이 훨씬 쉽고 빠릅니다.
애자일은 가장 어려운 품목과 가장 중요한 품목에 대해서도 먼저 작업해야한다고 말합니다. 빨리 실패합니다 . 따라서 고객이 UI를 본 후에는 가장 중요하고 구현하기가 가장 어려운 기능을 갖춘 작은 구성 요소를 만드는 데 중점을 두므로 장애물에 부딪 치면 가능한 한 빨리 알 수 있습니다.
그런 다음 스프린트를 가지고 있고 때때로 UI와 기능적 측면을 모두 개발하는 고객과 지속적으로 의사 소통을합니다.