스크럼 프로젝트에서 UX는 누구입니까?

확인. 교과서 스크럼 프로젝트를 진행하고 있다고 가정 해 봅시다. 제품 소유자와 공동 작업하는 스크럼 마스터가 있습니다. 다음 스프린트는 UI가 무겁습니다. 코더가 화면을 구축하기 시작할 때 실제로는 어떤 모습 일지 알고 싶을 것입니다.

와이어 프레이밍은 언제, 언제? 제품 소유자? 제품 소유자를 지원하는 사람이 있습니까? 스크럼 마스터? UX 전문가 인 경우 스프린트가 시작된 후 코더와 함께 작업 하거나 스토리 카드 및 제약 조건과 함께 배치되어 개발자가 수행하는 작업을 안내하고 알려주는 와이어 프레임 및 모형을 제공합니까?

UX 도움말이 필요하다고 확신하지만 적용 할 위치가 확실하지 않습니다 ...

편집 : 질문을 바꿔 보자.

민첩한 프로젝트에서 일관된 고품질 사용자 경험을 어떻게 제공합니까?

인터랙션 디자이너

UX! = UI 프로그래머 가 아닌 대중의 신념과는 달리 좋은 사용자 경험을 제공하려면 숙련 된 상호 작용 디자이너가 필요합니다 . UX (나를 포함)를 할 수 있다고 생각하는 모든 프로그래머에게이 말을하겠습니다. 인터랙션 디자인에 능숙 해지려면 프로그래밍에 능숙 해지려면 최소한 많은 시간이 필요합니다. 순수한 인터랙션 디자인을하는 데 얼마나 많은 시간을 보냈습니까?

초기 단계에서는 상호 작용 설계자가 다음을 수행해야합니다.

1. 제품 소유자로부터 솔루션의 실제 목표 추출
2. 솔루션을 사용할 페르소나를 정의하십시오.
3. 솔루션 사용 방법에 대한 이야기 ​​시나리오를 작성하십시오.
4. UX 관점에서 애매 모호한 공간을 남기지 않는 디자인 문서를 컴파일하십시오.

프로젝트를 진행하는 동안 이러한 지침을 따르고 발생할 수있는 추가 문제를 해결하는 것이 상호 작용 디자이너 작업입니다.

많은 프로그래머들이이 접근 방식에 직면 할 것입니다. 모든 사람들이 "멋진"인터페이스를 디자인 할 수있는 예외라고 생각하기 때문에 아마 그렇지 않을 것입니다. 다른 한편으로, 좋은 인터랙션 디자이너 – 프로그래머 관계는 종종 프로그래머들에게 매우 좋으며 "어리석은 사양"에 맞서 싸울 필요도 없습니다. 불행히도 좋은 인터랙션 디자이너는 내 경험에서 찾기가 어렵지만 외부에 있습니다.

항상 주제에 관해 Alan Coopers의 책을 깊이 추천합니다 ( "얼굴에 대하여"와 "수감자들이 망명을하고 있습니다")

나는 팀의 다른 팀들과 같은 방식으로 UX 남자의 작업을 조직 할 것을 제안합니다. 그는 팀의 평등 한 멤버로 여겨지고, 스탠드 업에 참여하며, 프로그래머와 긴밀한 의사 소통을해야합니다.

이상적으로는 모형을 최소 한 번의 스프린트로 수행해야하지만, 작은 기능의 경우 모형을 현재 반복에 계획된 스토리의 하위 작업으로 만드는 것이 좋습니다.

민첩하게 항상 그렇듯이 상식을 사용하고 다양한 접근 방식을 실험하고 특정 상황에 적합한 방식을 고수하십시오.

제 생각에는 이것은 특별한 방법으로 처리 해야하는 특별한 경우입니다. 스크럼 마스터는 분명히 이것에 참여하지 않을 것입니다-그것은 그의 역할이 아닙니다. 팀은 일반적으로 개발자 그룹이며 대부분은 UX에 대한 경험이 없으므로이를 강제하는 데 시간을 낭비하게됩니다. UX 전문가를 고용하고 전문가는 팀의 일원이되지 않습니다. 팀은 기능이 다양해야하고 UX 전문가는 개발자가 아닐 것입니다. 또한 UX 전문가는 전체 기간 동안 프로젝트에 참여하지 않습니다. UX 전문가는 다음 스프린트에서 수행해야 할 작업을 팀이 알 수 있도록 다음 스프린트에서 수행해야 할 작업을 팀이 알 수 있도록 제품 소유자와 한 번의 스프린트를 진행하여 모의 및 와이어 프레임을 준비합니다.

편집하다:

나는 어딘가에서 이것에 대해 읽은 것을 알았 기 때문에 몇 가지 추가 연구를 수행했으며 마침내 Agile : Succeeding with Agile : Software Development Using Scrum by Mike Cohn 에서 발견했습니다 . Mike는 팀에서 UX 디자이너의 역할을 정확하게 설명합니다. 그의 초기 설명은 내 것과 비슷하며 회사가 폭포에서 스크럼으로 개발 방법을 변경할 때 자연스럽게 전환한다고 생각하지만 나중에는 권장하지 않는 방법으로 결론을 내립니다. 그 이유는 UX 디자이너가 팀의 일부가 아닌 경우 자신을 별도의 팀으로 생각할 수 있고 개발 팀의 약속을 공유 할 필요가 없기 때문입니다.

이 @Adam Byrtek의 답변에도 불구하고 정답입니다. UX 사용자를 팀의 일부로 만들고 현재 구현 된 사용자 스토리에서 개발자와 협력하게하십시오. UX 직원은 항상 시간이 걸리지 않으므로 제품 소유자 또는 고객과 협력하여 다가오는 스프린트를 위해 모형 및 와이어 프레임을 준비합니다.

나는 Jakob Nielsen의 경고 상자 (주로 성가신 웹 디자인 관행에 대한 그의 비판 때문에)에 가입하고 있으며 최근에 주제에 대한 기사를 읽은 것을 기억합니다. 당신을 위해 어떤 사용 :

• 민첩한 사용자 경험 프로젝트
• 민첩한 개발 프로젝트 및 유용성

"교과서 스크럼"의 경우 :

우선, Scrum Masters는 제품 소유자와 협력하지 않습니다. SM 및 PO를 포함한 전체 팀이 시스템 구축을 위해 협력한다는 점 외에는 의미가 없습니다.

둘째, 스크럼 팀은 기능이 다른 팀 구성원과 동 질적이어야합니다. 따라서 "UX Guy"가 없을 것입니다.

또한 기능 코드보다 먼저 UX a Sprint를 빌드하지 않을 것입니다. 기능은 단일 스프린트 내에서 완전히 제공됩니다. 기능과 연관된 UX가 단일 Sprint에서 기능 코드와 함께 전달하기에는 너무 복잡한 경우, 단일 Sprint에서 UX 요소를 포함하여 수행 할 수있는 기능으로 전체 기능을 조각합니다.

폭포 프로젝트에서 UX는 누구입니까? XP 프로젝트에서 메인 프레임 개발은 누구입니까?

프로젝트 방법론은 중요하지 않습니다. 모든 기술 프로젝트에는 특정 전문 역할이 필요합니다. 때로는 라이센스가 부여되고 결합 된 "상호 작용 디자이너"(무엇이든)가 없으면 프로젝트가 사라질 수 있습니다. 때로는 전문적인 사람이 필요할 수도 있습니다. 그러나 다른 모든 역할에서도 마찬가지입니다.

민첩성을 사용하여 고품질의 사용자 경험을 제공하는 방법에 대한 두 번째 질문입니다. 우리는 비즈니스 분석가와 고객을 조기에 자주 참여 시켜서 마지막으로 참여한 스크럼 프로젝트에서 관리했습니다. 또한 우리는 UX에 특히 좋은 개발자를 가졌습니다. 그는 개발자가 커밋을 수행 한 후 작업중인 UI를 약간 조정하는 경향이있었습니다.

우리는 모든 스프린트가 끝날 때 완벽한 UX를 제공하지 않았습니다. 데모는 일반적으로 UX 관점에서 문제를 노출했습니다. 그러나 우리는 다음 스프린트 (고객에게 가치가있는 경우)를 위해이를 고쳤으며 프로덕션에 출시 할 때 UX는 매우 견고했습니다.

UX에서 사용자 인터페이스 디자이너를 의미하는 경우 팀의 다른 역할이나 리소스 일뿐입니다. 모든 디자인과 마찬가지로 사용자 인터페이스 디자인도 프로젝트를 잘 수행합니다. 적절한 양의 아키텍처 / 디자인 작업이 선행되어야하며 진행하면서 수행 할 수있는 양이 있습니다.

UI 디자인 작업은 종종 개발 스프린트와 같은 범위에 맞지 않습니다. UI 구성 요소를 디자인 할 때 디자인을 구현하는 데 많은 스프린트가 필요할 수 있습니다.

실제로 UI / UX 디자이너는 솔루션 전체에서 일관성을 유지해야하는 측면을 처리하기 위해 적절한 리드 타임이 필요하다는 것을 알았습니다. 소프트웨어 아키텍처라고 생각합니다. 특정 구성 요소 디자인은 구현하기 전에 종종 스프린트를 수행 할 수 있지만 일단 디자이너가 진행되면 구현 속도를 훨씬 앞당길 수 있습니다. 나중에 스프린트는 솔루션이 구체화되기 시작함에 따라 모양과 느낌을 구현 / 탐색하고 유용성 피드백을 얻는 좋은 장소 인 경향이 있습니다. 이 연습의 결과는 다음 스프린트 계획으로 피드백됩니다.