스프린트를 앞서가는 UX 디자이너

우리의 UX 디자이너는 보통 Sprint X에서 개발자가 Sprint X + 1에서 구현할 이야기를 가지고 있습니다 (UX 디자이너와 개발자 / 테스터는 한 팀에 있습니다). 스크린 모형과 명확한 사양이 없으면 스프린트 계획 중에 실제로 작업을 추정 할 수 없기 때문에 이것이 의미가 있다고 생각합니다.

그러나 Scrum에서는 사용자에게 가치를 제공하는 사용자 스토리 만 있어야합니다. 우리의 경우 UX 디자인 스토리는 그러한 가치를 제공하지 않습니다 (그들은 백 로그 그루밍 활동과 비슷합니다). 또한 일반적으로 스크럼 코치는 스프린트가 시작되기 전에 완전한 사양을 권장하지 않습니다.

우리의 접근 방식에 어떤 단점이 있습니까? 그것은 우리에게는 효과가있는 것처럼 보이지만 스크럼 원칙에 다소 반대합니다.

그러나 Scrum에서는 사용자에게 가치를 제공하는 사용자 스토리 만 있어야합니다.

배송 가능한 코드 줄에서만 값이 측정되지 않습니다.

잘 설계된 UI를 사용하면 아무런 가치도 제공하지 않는다고 암시하는 것 같습니다. 물론 그렇습니다. 분명히 최종 사용자에게는 가치가 있지만, 개발 팀에게는 가치가 있습니다. 업무를 수행 할 도구와 자료가없는 경우 최종 사용자에게 가치를 제공 할 수 없습니다.

스크럼 교리에 매달리지 마십시오. 스크럼은 당신을 더욱 효율적으로 만들어줍니다. UI를 구현하기 전에 UX 스토리를 한 번만 실행하면 더 나은 소프트웨어를 제공 할 수 있습니다.

주요 단점은 다음과 같습니다.

1. 파이프 라이닝입니다. 디자이너가 늦으면 개발자가 일을하지 않아도됩니다. 개발자가 늦을 경우 디자이너는 결국 둘 이상의 반복 작업을합니다. 안정적인 상황이 아니며 지속 가능 하지 않습니다 .

2. 디자이너는 미리 작업하고 있으며, 개발되었거나 개발되지 않은 스토리에 대한 비용을 지불하고 있습니다. 드물게 발생하더라도 여전히 돈을 버리고 있습니다.

3. UX 디자이너는 개발자를 참여시키지 않고 미리 결정을 내립니다. 유용한 통찰력을 잃어 버리고 디자인이 잘못되거나 비현실적 일 위험이 높아집니다. UX 디자인은 "추상적 인"연습이 아니기 때문에 매우 일반적입니다. 응용 프로그램의 특성 (기술적으로 수행 가능 / 권장하지 않는 것을 포함하여)으로 만들어 져야합니다.

4. 개발자를 배제하거나 무력화시키는 것은 프로젝트를 지속 할 수있는 방법이 아닙니다.

5. 디자이너는 가치를 제공하지 않습니다. 이는 불가능하지는 않더라도 자신의 작업에 올바른 우선 순위를 부여하는 것이 어렵다는 것을 의미합니다. 일반적으로 개발자 작업은 다른 관심사, 가치, 다음 스프린트의 타당성, 노력의 양을 사용하여 우선 순위가 결정됩니다. 많은 시간 이야기는 "적합"하거나 유용한 토론으로 인해 협상되고 변경됩니다.이 중 하나라도 UI를 변경하면 (구체적인 세부 사항이 아니라면 가능하다고 가정 할 수 있음) 어떻게해야합니까? 이야기와 함께? 더 이상 재생할 수 없습니다.

6. 디자이너를위한 한 번의 반복에 적합한 스토리가 개발자를위한 한 번의 반복에 적합하다고 가정합니다. 스토리를 어떻게 분할하여이 가정이 정확합니까?

나는 두 가지 이유로 그것을 좋아한다.

1. 그것은 당신을 위해 일하는 것 같습니다; 성공으로 논쟁하기가 어렵습니다!
2. UX 팀은 이야기를 듣고 대화를 일찍 시작합니다. 대화는 일종의 이야기입니다.

스크럼의 기본 요구 사항은 스크럼 팀이 잠재적으로 출시 가능한 제품을 만드는 데 필요한 모든 기술을 갖추고 있어야한다는 것입니다. 당신이 묘사하는 상황에서, 이것은 일어나지 않습니다.

UX 팀은 출시 가능성이있는 제품을 생산하지 않으며 스크럼 팀은 필요한 기술을 모두 갖추고 있지 않기 때문에 수직 기능 조각을 생성 할 수 없습니다. 이것들은 기능 장애입니다.

Sklivvz는 위의 기능 장애로 인해 발생할 수있는 문제에 대해 훌륭한 글을 작성했습니다. 요약하면, 나는 당신이 스크럼을 연습하고 있다고 생각하지 않습니다.

그러나 그것에 아무런 문제가 없습니다. 모든 사람에게 가치를 제공하는 일하는 방법을 발견하고 모두 만족한다면 계속 노력하십시오. 저의 유일한 조언은 자주 점검하고 적응하는 것입니다.

그러나 Scrum을 사용하여 소프트웨어를 제공하는 것이 목표라면 식별 된 기능 장애를 해결해야합니다.

여기에는 사용자 중심 설계와 스프린트 정렬에 관한 두 가지 문제가 있습니다.

첫째 : 사용자 스토리는 백 로그뿐만 아니라 사용자 요구와도 일치해야합니다. UX 스토리는 사용자에게 분명한 가치가 있어야합니다. 이것은 완전한 사양을 요구하지 않으며,

"사용자는 여러 페이지로 나누지 않고 단일 페이지에서 계정 활동에보다 쉽게 ​​액세스 할 수 있습니다."

다양한 구현에 적합하고 적용 가능하지만 여전히 사용자에 대한 가치 (계정 활동에 대한보다 쉬운 액세스)에 대해 명확합니다.

둘째 : 스프린트 정렬. UX는 개발자가 스프링 X + 1에서 구현하는 스프린트 X의 기능을 설계합니다. 실제로 이것은 많은 상점에서 발생하며 때로는 스프린트 X + 2 또는 X + 3의 구현과 비슷할 수 있습니다. 타이트하고 숙련 된 팀이 있으면이 설정을 사용할 수 있습니다. 새로운 팀이나 다른 팀원의 기술, 선호도, 습관, 작업 스타일 및 경향에 익숙하지 않은 새로운 팀이 있으면 도전이됩니다. 6 개월 미만 동안 함께 일한 경우 이것이 문제가 될 수 있습니다.

물러서서 다시 평가하십시오. 긍정적 인 측면에서 UX 디자이너와 개발자가 나란히 일하고 있습니다. 이야기가 사용자에게 분명한 가치가 있는지 확인하십시오.

내가 볼 수있는 가능한 문제 중 하나는 스크럼에서 스프린트 N + 1의 범위가 시작되기 직전에 결정된다는 것입니다. 따라서 어떤 스토리가 적용되는지 알기 전에 스프린트 N에서 스프린트 N + 1 스토리에 대한 UX를 어떻게 수행 할 수 있습니까? 스프린트 N의 시작에서 스프린트 N + 1의 범위를 수정하기로 결정하면 약간의 유연성을 잃게됩니다.

그러나 Scrum에서는 사용자에게 가치를 제공하는 사용자 스토리 만 있어야합니다. 우리의 경우 UX 디자인 스토리는 그러한 가치를 제공하지 않습니다 (그들은 백 로그 그루밍 활동과 비슷합니다).

내가 보는 방식으로, 그들은 사용자에게 많은 가치를 제공하고 있습니다. 문제는 : 사용자는 회사의 최종 사용자가 아니며, 사용자는 스프린트 X + 1에서이 기능을 구현할 개발 팀입니다.

프로세스의 종교에 갇히고 스크럼 / 애자일이 잘못 사용되고 사용자가 잘못 표시되는 방식을 봅니다. 스크럼은 보편적 인 도구가 아니라 목적을위한 수단입니다.

귀하의 그룹에 사용자가 누구인지 잘못 표시하고 잘못된 잠재 고객을 계획하고 있다고 생각합니다.

UX 그룹은 고전적인 방식으로 스크럼을 사용하고 있으며 사용자 가치와 일부 마법 같은 최종 사용자의 입력에 민첩하게 적응합니다. 그들은 사용자와 하나입니다. 기존 설계 작업을 수행하기 위해 기계를 채우는 것만으로 민첩성이 필요하지 않으며 스크럼이 관리 추적 역할을 수행하기 때문에 그룹에서 스크럼을 잘못 사용하고 있습니다.

그렇기 때문에 이것이 당신에게 잘못 느끼는 이유입니다. 서비스 그룹에 속해 있고 민첩 / 스크럼 부분을 이미 수행 한 UX 직원들로부터 작업이 진행되기 때문에 실제로 어떤 방식 으로든 스크럼이 필요하지 않습니다.

실제로 나쁜 점은 없습니다. 여러분이 들었던 것과 다른 과정이 있습니다.