2015년 8월 28일 금요일

사용자경험 분석 시 범하기 쉬운 5가지 흔한 실수

애자일 소프트웨어 개발 방법론을 사용할 때, User Story를 사용해서 대부분의 요구사항을 수집합니다. User Story는 "의사소통 대상과 대상별 요구사항“의 간결한 형태와 수락기준으로 구성됩니다. User Story는 간결하지만 잘 작성하는 것이 무척 어려운 작업입니다. User Story 작성 시 흔히 범하는 5가지를 실수를 검토해봄으로써 올바른 User Story 작성법을 살펴보도록 합니다.

[5 가지 흔한 실수들]

1. 단일 사용자를 위한 User Story
  • 예 : “ 사용자로써 나는 광고를 관리할 수 있기 원한다 . 왜냐하면 기한이 만료되고 실수가 있는 광고를 제거할 수 있기 때문이다 .”
  • 언뜻 보면 모든 요소가 있어서 User Story 로 별 문제가 없어 보임
  • 특색에 맞게 사용자를 살펴보면 광고관리를 이해하고 수행하는 사용자는 광고 조정을 하는 포탈 관리자나 모든 광고 목록을 가지고 상황에 따라 광고들을 교체하는 광고주들을 뜻함
  • 페르소나나 역할을 놓치고 있음
2. 제품 소유자를 위한 User Story
  • 예 : “ 제품의 소유자로써 나는 광고를 지울 수 있는 시스템을 원한다 . 왜나하면 사용자들이 광고를 지울 수 있기 때문이다 .”
  • 모든 요소들이 있지만 뭔가 어색함
  • ‘ 당신이 무엇을 원한다 . 당신은 그것을 가지고 있다 ’ 는 형식으로 User Story 를 쓰는 사람이 단지 하고 싶은 행위에 초점을 두고 있으며 , 사용자 기대에 대한 단서를 주는 역할이나 페르소나가 없음
3. 개발자를 위한 User Story
  • 예 : “ 개발자로써 나는 폴더 위젯을 재배치하기를 원한다 . 왜냐하면 나는 폴더 위젯을 유지하고 싶기 때문이다 .”
  • 기술적인 백로그 (Technical backlog) 나 기술적인 요구사항의 대표하는 예임
  • 이와 같은 User Story 는 기술적 채무 (Technical Debt) 으로도 불리며 , 기술적 채무는 소프트웨어 업데이트 , 리팩토링 (Refactoring), 프레임웍의 교체와 같은 유지보수 관련 필수적인 일을 포함함
  • 고객을 위한 가치를 대변하지는 않고 , 애자일 관점에서 매 주기의 마지막에 비즈니스적 가치를 수반해함
  • 역할에 페르소나를 붙여 사용자관점에서 기술하는 예로 ‘ 상업적인 사용자로서 나는 동시에 여러 검색을 할 수 있는 시스템을 원한다 . 왜냐하면 나는 일을 좀 더 빨리 하고 싶기 때문이다 .’ 를 둘 수 있음
  • 수락기준들은 향상을 측정 가능하고 테스트 가능하도록 정의해야 함
  • 예 : ‘ 한 사용자가 동시에 5 가지 검색을 할 수 있음 ’
4. 고객을 위한 비즈니스 가치나 혜택이 없음
  • 예 : “ 상업 광고주로써 나는 필터링 옵션을 원한다 ”
  • 역할도 있고 니즈도 있지만 이유와 비즈니스 가치가 없음
5. 수락기준이나 만족조건이 없음
  • 수락기준이 없는 것은 개발업무를 잘못 정의하거나 잘못된 평가로 시작해서 전체를 오류덩어리로 만들 수 있음
  • 이해부족으로 Story 가 테스트를 통과하지 못할 수도 있고 Test Case 가 다른 기준들을 적용할 수도 있음
  • 수락기준은 요구사항을 명확하게 이해하고 주기별 결과물을 받아들일지는 결정하는 중요한 역할을 함
  • 수락기준을 만드는 좋은 방법은 '~ 한다면 어떻게 될까 ?(What if ... ?)', ' 어디서 (Where) ...?', ' 언제 (When) ... ?', ' 어떻게 (How) ... ?' 와 같은 질문을 해보는 것임
  • 예제들을 사용해서 가정들을 제거해서 간결하게 만들어보면 Story 가 세련되어지고 재구성되고 좀 더 작은 Story 로 나뉘어질 것임 

애자일 프로젝트 매니저가 갖춰야 할 3가지 필요기술

애자일 프로세스의 도입은 SW공학과 IT 프로젝트 측면에서 폭발적으로 늘고 있습니다. 애자일 프로젝트 매니저는 팀을 성공적으로 이끌기 위해서 애자일 기법들에 제대로 이해하고 사용해야 합니다. 사용자 경험 분석 등 요구사항분석을 통해 업무를 정의하고, Burn-down, Burn-up 차트 등을 이용하여 일의 진행사항을 체크하고, 용어의 통일이나 클라우드 컴퓨팅 등을 활용하여 팀 전체간의 의사소통을 원활하게 등 애자일 기법과 툴을 잘 활용해야 합니다.

*애자일 기본사항 (Agile fundamentals)
애자일 ALM 에서 프로젝트 매니저는 개발팀이 사용하고 있는 개발 프레임웍 (Scrum, XP, Kanban or 애자일 기법 조합 ) 에 대해 잘 이해하고 있어야 함.

추적 (Tracking) 과 척도 (Metric)
애자일 ALM 에서 프로젝트 매니저 훈련의 중요한 부분은 일의 진행사항을 추적하는데 사용되는 척도를 명확하게 이해하는 것임.

협업 (Collaboration)
애자일 기법들을 제대로 이해하고 진행상황을 올바로 측정하고 추적하는 것과 더불어 애자일 ALM 환경 상에서 프로젝트 매니저는 협업의 중요성을 잘 이해해야 함.

성공적인 요구사항관리를 위한 3가지 커뮤니케이션(협업) 유형

협업은 요구사항을 관리하는데 매우 중요한 요소입니다. 협업은 SW 개발자와 최종 사용자간의 협업, 고객 그룹들 사이의 협업, 회사 내부적인 협업의 3가지 형태가 있습니다. 이 3가지 형태의 협업을 잘 활용하여 요구사항을 효과적으로 관리하는 것은 경쟁력 있는 SW를 개발하는 데 도움이 됩니다.

◆ 세 가지 형태의 협업유형
  • 첫 번째 형태는 SW 개발자와 최종 사용자간의 대화임.
  • 두 번째 형태는 고객 그룹 사이에 활발하게 나타나는 의사소통임.
  • 세 번째 형태는 회사 내부적으로 발생하는 의사소통임.