민첩한 조작성 엔지니어링

이 기사의 중립성은 논쟁의 여지가 있다. 관련 토론은 토크 페이지에서 확인할 수 있습니다. 조건이 충족될 때까지 이 메시지를 삭제하지 마십시오. (2013년 12월) (이 템플릿 메시지 제거 방법 및 제거 시기 확인)

신속한 변화를 위한 사용성 엔지니어링은 신속한 변화를 위한 소프트웨어 개발과 사용성 엔지니어링 ^[1]프랙티스의 조합으로 만들어진 방법입니다.신속한 사용성 엔지니어링은 사용자 인터페이스 설계 분야에 신속하고 반복적인 개발 원칙을 적용하려고 시도합니다.

사용자 중심 설계에서 사용적합성 엔지니어링의 초기 구현은 1980년대 중반에 전문적인 실천에 들어갔다.신속한 변화를 위한 소프트웨어 개발의 초기 구현은 1990년대 중반에 발전했습니다.인간-컴퓨터 상호작용 커뮤니티에서 민첩한 사용성 ^[1]엔지니어링이 널리 받아들여진 것은 불과 몇 년 전입니다.

역사

Kent Beck가 극한 프로그래밍 및 테스트 기반 개발 등의 방법을 도입했을 때 신속한 변화를 위한 환경에서 작업하기 위해서는 사용성 엔지니어링이 가벼워져야 했습니다.Kent Beck와 같은 개인은 크라이슬러 포괄적 보상 시스템 등의 프로젝트를 수행함으로써 민첩한 사용성 엔지니어링의 방법론을 형성하는데 도움을 주었습니다.이러한 시간 주도의 프로젝트는 신속한 변화를 위한 환경에서 작업하면서 실천할 수 있는 최상의 방법론을 경험하고 이해하는 데 도움이 되었습니다.

신속한 변화를 위한 소프트웨어 개발 환경에서 사용성 엔지니어링의 초기 예는 브라우저 상주 교실 정보 관리 시스템을 설계한 Larry Constantine과 Lucy Lockwood의 연구에서 찾을 수 있습니다.이 프로세스에서 설계팀은 교육팀과 직접 협력했습니다.교육팀은 주제별 전문가와 대표 최종사용자로서 초기 사용자 역할모델과 태스크 케이스 인벤토리를 개발했습니다.이 프로세스는 참여형 설계를 모방합니다.이 자료에서 목업은 "한 페이지의 ^[2]튜토리얼을 기반으로 시스템을 즉시 생산적으로 사용할 수 있도록 하는 엄격한 설계 목표"라는 원하는 목표를 달성하기 위해 반복적으로 설계되었습니다.

다음 표는 Thomas Memmel이 제안한 ^[1]중량 공정과 비교하여 경량 공정의 차이점과 유사점을 보여줍니다.

고부하 프로세스	경량 프로세스
상세한 최신 문서 및 모델	카드 및 손으로 그린 추상 모델 가벼운 여행 문서가 아닌 커뮤니케이션
충실도가 높은 시제품	추상적인 프로토타입, 가장 간단한 도구 사용
사용자 피드백으로 개념 개발 및 입증 반복	용기. 사용자의 기대가 아닌 니즈(사용자 태스크)를 위한 설계 지속적인 사용자 피드백이 아닌 모델에서 디자인 검색
시간이 많이 걸리는 가용성 평가, 이해관계자와의 긴밀한 통합	신속한 조작성 검사 모델이 올바른지 평가할 필요가 없습니다.

방법들

신속한 변화를 위한 소프트웨어 개발 프로세스에서 사용되는 많은 프로젝트는 신속한 변화를 위한 사용성 엔지니어링의 이점을 얻을 수 있습니다.모델과 대표를 사용할 수 없는 프로젝트는 가능한 한 경량이어야 하므로 민첩한 사용성 엔지니어링 환경에서 문제가 발생합니다.

민첩한 개발의 가용성 엔지니어링 단계에서 사용자는 제품 또는 서비스를 사용하여 피드백, 문제 보고서 및 새로운 요구사항을 개발자에게 제공합니다.이 프로세스는 기본 기능에 초점을 맞춘 후 고급 기능에 초점을 맞춰 대화식으로 수행됩니다.프로세스가 고급 단계로 진행됨에 따라 더 많은 사용자가 제품 또는 ^[3]서비스를 사용하여 작업합니다.솔루션은 중대도에 따라 신속하게 적용됩니다.단계는 마일스톤으로 끝납니다.

Paul McInerney와 Frank Maurer는 UI 설계 관행의 조정이 필요함을 확인하는 사례 연구를 실시했습니다.특히 반복적인 개발을 조정하기 위해서는 더욱 그렇습니다.그러나 결과 UI 디자인은 표준 중량 ^[4]접근법보다 나쁘지 않다고 결론지었습니다.

Scott Ambler가 설명한 신속한 변화를 위한 모델링의 핵심 관행은 신속한 변화를 위한 사용성 엔지니어링의 초점을 설명하는 데 도움이 됩니다.주요 프랙티스에는 검증, 팀워크, 심플성, 모티베이션, 생산성, 문서, 반복 및 증분 ^[5]등이 있습니다.

사용성 도구를 포함한 민첩한 수정 개발 프로세스가 개발되어 컴퓨터 시스템의 인적 요소에 관한 CHI '08 확장 요약'에 제시되었습니다.가용성 평가용 확장 유닛 테스트, 전형적인 익스트림 프로그래밍 사용자 스토리를 확장하기 위한 익스트림 인물, 현장 고객의 익스트림 프로그래밍 개념을 확장하기 위한 사용자 연구, 임시 문제 해결을 위한 가용성 전문가 평가 및 현장 고객 담당자를 해결하기 위한 가용성 테스트가 포함됩니다.문제가 있습니다.^[6]

문제들

기존의 사용성 엔지니어링 방법을 신속한 변화를 위한 환경에 통합하는 데 어려움을 겪었기 때문에 많은 문제가 제기되었습니다.포괄적인 자원이 없다면, 실무자들은 이전에 ^[7]성공한 다른 사람들의 패턴을 따르려고 노력해 왔습니다.표 2는 Lynn Miller와 Aquisere Sy가 개발하고 CHI '09년 컴퓨터 시스템의 인적 요소에 관한 확장 요약에 제시된 문제, 증상 및 가능한 해결책의 표를 나타냅니다.

다음 표는 Agile ^[7]UCD를 실행하는 동안 사용자 경험 실무자가 겪는 주요 문제를 요약한 것입니다.

문제	증상	생각할 수 있는 해결책
설계 시간이 부족합니다.	• 설계 대기 중인 개발자 • 설계 품질 저하 • 고객에게 검증되지 않은 설계	• 별도의 병렬 UX 설계/개발자 트랙[8][9][10][11][12] • 범위 UX 액티비티는 소규모로 증분한다[8][9]. • RITE 형성적 가용성 테스트 • 신속한 상황별[15] 설계 • "디자인 스튜디오"[16] • 설계 청킹[8] • 서로 다른 UX 액티비티를 하나의[17] 세션으로 통합 • 사용자(및 데이터)를 가져오다[17] • 요건 수집[8][9][10][11][18] 프로세스 경감 [8][9][10][11][18]
스프린트가 너무 짧다.	• 설계를 제시간에 완료할 수 없다 • 사용성 테스트 시간 없음 • 고객 연락처를 설정할 시간이 없다	• 별도의 병렬 UX 설계/개발자 트랙 • 범위 UX 액티비티는 소규모로 증분한다[8][9]. • RITE 형성적 가용성[13][14] 테스트 • 신속한 상황별[15] 설계 • "디자인 스튜디오"[16] • 설계 청킹[8] • 서로 다른 UX 액티비티를 하나의[17] 세션으로 통합 • 사용자(및 데이터)를 가져오다[17] • 요건 수집[8][9][10][11][18] 프로세스 경감
사용자 피드백이 부족합니다.	• 피드백이 불충분하다 • 조치할 데이터가 없음 – 의견 규칙 • 제품이 검증되지 않음	• 별도의 병렬 UX 설계/개발자 트랙[8][9][10][11][12] • 범위 UX 액티비티는 소규모로 증분한다[8][9]. • RITE 형성적 가용성[13][14] 테스트 • 신속한 상황별[15] 설계 • "디자인 스튜디오"[16] • 설계 청킹[8] • 서로 다른 UX 액티비티를 하나의[17] 세션으로 통합 • 사용자(및 데이터)를 가져오다[17] • 요건 수집[8][9][10][11][18] 프로세스 경감
민첩성이 약한 '고객'[16]	• 최종 사용자 및 클라이언트 참여 안 함 • 나머지 팀원으로부터 매수할 수 없다 • 정보에 근거한 의사결정이 이루어지지 않음	• UX 담당자가 신속한 고객 역할[19] 수행 가능 • 각 UX 담당자는 1개의 스크럼[19] 팀에서 작업합니다. • 현명하게 협력할[18] 스크럼 팀 선택 • 검증된 설계를 개발자에게 전달하여 구현[8][9] • UX가 사이클 [9]계획에 참여하여 적절한 사용자[8] 피드백을 제공 • 어떤 것이 나오지[18] 않는 한 기능은 들어가지 않는다.
UX는 민첩한 단일 팀에서 풀타임으로 기능하지 않음	• 설계와 반복이 아닌 많은 회의에 소비하는 UX 시간 • UX 품질 저하로 사기가 저하	• UX 담당자가 신속한 고객 역할[19] 수행 가능 • 각 UX 담당자는 1개의 스크럼[19] 팀에서 작업합니다. • 현명하게 협력할[18] 스크럼 팀 선택 • 검증된 설계를 개발자에게 전달하여 구현[8][9] • UX가 사이클 [9]계획에 참여하여 적절한 사용자[8] 피드백을 제공 • 어떤 것이 나오지[18] 않는 한 기능은 들어가지 않는다.
스프린트/사이클 계획 없음	• 대량의 기능/버그 잔량 • 우선순위 부여 피드백 무시 • 설계 타이밍에 대한 통제 없음	• UX 담당자가 신속한 고객 역할[19] 수행 가능 • 각 UX 담당자는 1개의 스크럼[19] 팀에서 작업합니다. • 현명하게 협력할[18] 스크럼 팀 선택 • 검증된 설계를 개발자에게 전달하여 구현[8][9] • UX가 사이클 [9]계획에 참여하여 적절한 사용자[8] 피드백을 제공 • 어떤 것이 나오지[18] 않는 한 기능은 들어가지 않는다.
사용자 피드백이 무시됩니다.	• 피처 세트를 석재로 주조 • 변경을 도입할 시간이 없다 • 기능의 순서를 변경할 수 없습니다.	• UX 담당자가 신속한 고객 역할[19] 수행 가능 • 각 UX 담당자는 1개의 스크럼[19] 팀에서 작업합니다. • 현명하게 협력할[18] 스크럼 팀 선택 • 검증된 설계를 개발자에게 전달하여 구현[8][9] • UX가 사이클 [9]계획에 참여하여 적절한 사용자[8] 피드백을 제공 • 어떤 것이 나오지[18] 않는 한 기능은 들어가지 않는다.
'큰 그림'을 놓치다	• 비전이나 최종 목표가 공유되지 않음 • 디테일에 너무 치중하다 • 설계 우선순위 부여/결정 어려움	• 민첩한 팀이 Cycle[8][9][10][11][20] Zero를 채택하도록 설득하다 [8][9][10][11][18] • 다양한 세부 수준(제품, 출시, 기능, 설계[12] 청크)에서 설계 목표를 고려합니다.
의사소통이 원활하지 않음	• 잘못된 설계 • 민첩한 팀은 설계에 의존하지 않는다 • 중요한 정보가 손실됨	• 설계 프로세스에[8][9] 개발자 포함 • 수용기준에[8][9] 포함되는 사용성 • 진척상황을 확인하기[8][9] 위한 일일 연락 • 스탠드업[8] 미팅용 설계 카드 • 사용성[8] 보고용 카드 발급 • 설계팀용[8] 문서
팀이 함께 배치되어 있지 않다	• 팀의식이 없다– 신뢰의 결여 • 언어 및/또는 시간 장벽 • 충분한 커뮤니케이션이 없다	• 원격 작업 도구(전화 및 웹 기반 대체[11][18]) • 사이클[11][18] 계획을 위한 공동 위치 결정
의존 관계 문제	• 민첩하지 않은 팀(예: 마케팅 사인오프, 변호사)의 의견을 요구합니다.	• 설득력이 강한 스크럼 리더나 퍼실리테이터는 일을 빠르게 [18]진행할 수 있다.

레퍼런스

추가 정보

• 인터랙션 설계 백과사전