민첩한 디자인 이해와 중요한 이유
민첩한 개발 프로세스가 몇 년 동안 개발 세계를 뒤덮고있어 더 오래된, 더 복잡한 폭포 개발 방법을 따랐다는 것은 비밀이 아닙니다. 공정성을 기하기 위해, 민첩하거나 다른 어떤 것이 든, 폭포는 위험 회피, 하향식 접근 방식이 오늘날 시장의 요구에 부응 할 수 없기 때문에 실제로 다가 왔습니다.
디자인 세계에서도 비슷한 변화가 일어나고 있지만 민첩한 디자인 프로세스는 민첩한 개발과 모양과 느낌이 약간 달라야합니다. 그들은 결국 다른 학문입니다. 먼저 민첩한 개발이 무엇인지 자세히 살펴보고 프로세스를 디자인 세계에 적용하는 몇 가지 훌륭한 방법을 살펴 보겠습니다.
민첩한 개발에 대한 간단한 입문서
애자일 선언문은 프로세스와 도구에 대한 사람과 상호 작용을 강조합니다. 실제로 이것은 팀 내에서나 고객과 자주 의사 소통하고 매일 스크럼 회의와 같은 일을 수행하여 팀 전체가 구성원의 활동에 계속 집중할 수 있도록합니다. 이를 통해 팀은 고객, 베타 테스터 및 시장이 알려주는 내용에 따라 팀이 조정할 수있는 일관된 피드백 루프를 만들며, 업무가 궁극적으로 진행될 환경에서 업무가 제대로 작동하는지 자주 확인합니다.
무엇보다도 애자일 프로세스는 제품을 항상 도로에서 조정할 수 있기 때문에 완벽하지 않은 정시 및 예산에 맞는 산출물을 강조합니다. 이것은 대부분 반복적이고 짧고 강렬한 생산 기간의 형태를 띠며, 작고 달성 가능한 목표는 길을 따라 더 반복 될 수 있습니다.
디자인 설정에 대해 비슷한 사고 방식을 적용하기 위해 어떤 단계를 수행 할 수 있습니까? 한 번 보자.
고객과의 관계 변경
전통적인 디자인 프로세스는 디자이너들에게 가장 완벽한 제품만을 고객에게 제공하고자하는 공통의 욕구로 작용합니다. 이는 제안 및 연구 단계에서 지나치게 정교한 PSD 모형으로 시작하여 최종 승인 단계까지 계속됩니다. 그러나 가장 복잡한 프로젝트의 경우 클라이언트 입력이 전혀없는 추상적 인 방식으로 몇 개월이 아니라도 몇 주 동안 디자인하는 것은 실제로 의미가 없습니다. 우리가 모두 잘 알고 있기 때문에, 고객들은 종종 사이트가 결합 될 때 원하는 것을 더 명확하게 이해합니다. 또한 시장 수요는 디자이너가 생산할 수있는 것보다 빠르게 변화하는 습관이 있습니다. 경로 재 지정이 노동과 시간 집약적 인 패러다임 내에서 일할 때 이는 실망 스러울 수 있습니다.
클라이언트를 프로세스의 모든 단계에 루핑하는 민첩한 접근 방식을 채택하고 일정한 결과물을 생성하면 클라이언트가 디자인을 원하는대로 진행할 수 있으므로이를 해결하는 데 도움이 될 수 있습니다. 또한 현실 세계에서 실현 된 비전이 어떻게 작동하는지 더 잘 이해할 수 있습니다. 의사 소통이 규칙적 일수록 도로에서 발생하는 놀라움의 가능성이 낮아질수록 팀은 단계를 다시 추적하지 않고 변화하는 요구에 더 잘 적응할 수 있습니다.
한마디로 : 고객을 팀원으로 만드십시오.
팀 간 작업을 자주 컴파일
개발 환경에서 팀 내 및 팀 간 작업의 통합은 모든 프로젝트의 중요한 부분입니다. 가장 큰 조직에서 팀이 수십에서 수천으로 성장함에 따라 이것은 더욱 사실입니다. 그러나 Waterfall 방법의 통합은 간헐적 인 간격으로 발생하므로 개발자가 대량의 코드에서 버그를 찾기가 더 어려워집니다. 또한 많은 역 추적 및 선박 지연으로 이어집니다.
민첩한 연속 통합 방법으로는 그렇지 않습니다. 매일 3 회는 아니지만 코드를 한 번에 통합하는 개발자가 있습니다. 지속적인 통합은 실제로 원치 않는 미스터리를 통합에서 제거하여 개발자는 버그가 발생할 때이를 발견하고 즉시 수정하거나 다음 프로젝트 반복을 위해 백 로그에 추가 할 수 있습니다. 또한 팀 전체의 개발자가 이러한 종류의 오류를 식별하고 수정하기 위해 자주 통신해야하기 때문에 프로세스에 대한 민첩한 상호 작용 권한 개념에 잘 맞습니다.
디자이너는 다른 팀 구성원과 매일 간단한 체크인을하거나 개발자와 더 자주 통신하여 흥미롭지 만 까다로운 디자인 경로를 내리기 전에 기술적으로 구현할 수있는 것을 결정하는지 여부와 상관없이 비슷한 사고 방식을 활용할 수 있습니다. 팀 간 의사 소통 및 작업 컴파일은 설계자가 다른 팀의 작업과 동기화되지 않는 디자인 작업을 과도하게 계획하거나 구현하지 않고 디자인이 필요할 때 디자인에 집중하도록합니다.
테스트, 테스트, 테스트… 항상
비슷하지만 결정적으로 다른 점에서 빈번한 테스트는 반복을 추적하는 데 중요한 부분입니다. "테스트"란 문제 해결 관점을 개발하여 마이크로 및 매크로 수준 모두에서 디자인 기능에 대한 통합을 넘어서는 것을 의미합니다. 민첩한 개발에서 개발자는 더 큰 문제를 더 작은 문제로 세분화하여 빠른 반복 프레임 워크 내에서 더 잘 해결할 수 있습니다. 그런 다음이 작업을 테스트하면 즉시 또는 다음 반복에서 해결 될 문제를 식별 할 수 있습니다. 이렇게하면 개발자가 한 번에 너무 많은 시간에 접근 할 때 마비가 발생하지 않도록 추적 및 정시 상태를 유지할 수 있습니다.
이런 식으로 빈번한 테스트와 문제 해결 사고 방식은 설계 프로세스를 진행 상태로 유지할뿐만 아니라 창의성을 불러 일으킬 수 있습니다. 디자이너가 모든 사람의 가장 큰 문제에 너무 익숙해지지 않도록 막을 수 있습니다. 사이트는 모양과 느낌이 있어야합니다. 작은 문제에 중점을 두어 디자이너는보다 창의적인 창의적 프로세스를 수용하고 자신의 비전을 발견 할 수 있습니다.
즉, 매크로 수준으로 다시 확대하는 값을 무시할 수 없거나 디자인이 너무 어긋날 수 있습니다. 애자일의 작은 문제 해결 초점과 폭포의 전체 론적 관점 사이의 균형이 잘 잡히면 큰 그림의 맥락에서 문제를 해결하고 일관성을 유지하기 위해 여러 반복을 기울일 가치가 있습니다.
한마디로
실제로 생각하면 민첩한 디자인은 단순히 민첩한 개발 원칙을 설계 프로세스에 적용하는 것입니다. 각 디자이너와 디자인 팀이 다르기 때문에 자신에게 적합한 방법을 선택하고 원하는대로 적용하는 것이 가장 좋습니다. 결국, 민첩한 일처럼 보입니다.
