우리의 스크럼 팀은 일반적인 스크럼 역할로 구성됩니다. 우리는 UI / UX 디자이너가 없으며 개발자는 제품 소유자와 UI / UX를 작업합니다. 여기에 문제가 있습니다. 백 로그를 만들려고 할 때마다 스프린트 시작 전에 정확한 UI / UX 디자인을 정의하지 않으면 스프린트 동안 UI / UX 디자인을 마무리하려고 너무 많은 시간을 소비하게됩니다.

이는 피처의 분석 및 아키텍처에 해당됩니다. 스프린트를 시작하기 전에 기능에 대한 가능한 모든 세부 사항을 개발자에게 제공해야하는지 또는 기능 내에서 작업해야한다고 생각하십니까? 이 문제에 대해 경험 한 결과 기준이없는 정의되지 않은 일부 기능이 생성됩니다.

첫째 :이 좋은 봐 가지고 이야기를 , 플로리안 하스는 FROSCON (GER)에서했다. 스크럼을 수행하는 실질적인 불가능에 관한 것입니다.

좋은 소식 : 스크럼이기 때문에 불가능 구현, 당신은 당신이 원하는대로 할 무료입니다.

나쁜 소식 : 그 스크럼을 호출하지 마십시오.

그 질문에서 당신을 해방시켜 줄 것입니다 :»스크럼을 제대로하고 있습니까?«(답변 : 아니오 ) 그렇지 않으면 당신은 인생의 실질적인 질문으로 넘어갈 수 있습니다.

우리는 UI / UX 디자이너가 없으며 개발자는 제품 소유자와 UI / UX를 작업합니다.

이것은 드문 상황이 아닙니다. 그러나 AFAIR 스크럼은 전문화에 위배됩니다. 모든 사람이 동일한 스킬 셋을 가져야하며 상호 교환이 가능합니다.

백 로그를 만들려고 할 때마다 봄이 시작되기 전에 정확한 UI / UX 디자인을 정의하지 않으면 스프린트 중에 UI / UX 디자인을 마무리하려고 너무 많은 시간을 소비하게됩니다.

예, 이제 상황이 너무 좋습니다. 나는 사용자로서, 내가보고 싶어처럼»우리는 매우 광범위 backlogitems 처리했다 팀에 근무 정보 X «이를였습니다. 그런 다음 항목이 스프린트 보드에 도착했습니다. 한 개발자가 가져갔습니다. 해결했습니다. 이를 구현 한 후 첫 번째 동료 검토가 이루어졌으며 UI의 모양에 대한 토론이 시작되었습니다.

그리고 QA-Phase가 와서 논의가 다시 시작되었습니다.

스프린트 후, 우리는 스크럼 이 설계가 PO에 의해 분리 된 곳의 검토 를 요구함 에 따라 수행했다 . 불행히도 우리 고객은 리뷰를 작성하지 않았으므로 그 시점에서 소프트웨어를 보지 못했습니다.

그러나 PO 가 충족 될 때까지주기가 다시 시작 되었습니다.

그런 다음 고객이 와서

이 전쟁 이야기에서 볼 때,이 (특별한 종류의) 프로세스는 지옥처럼 효과가 없습니다.

결국 우리를 위해 일한 것은 보드 위에 스크럼 을 던지는 것이었다 .

그러나 그것은 당신의 질문에 대한 해결책이 아닙니다.)

스프린트를 시작하기 전에 기능에 대한 가능한 모든 세부 사항을 개발자에게 제공해야하는지 또는 기능 내에서 작업해야한다고 생각하십니까?

이 딜레마에 대한 해결책은 a) 고객 자체와 PO 사이의 긴밀한 피드백 루프를 수반 하므로 기준이 비교적 엄격하게 공식화됩니다. b) 도로에서 벗어날 가능성을 최소화하기 위해 스크럼 팀과 PO 사이의 긴밀한 피드백 루프 .

하나의 백 로그 항목을 정의하기 위해 (더 많은) 스크럼 규칙 을 위반합니다 :»작업 더미«. PO 및 고객 이 빠른 검토 를 통해 간단한 항목에 소요되는 개발자 시간을 최소화 할 수 있습니다 .

tl; dr

스크럼 팀의 의견은 무엇입니까?

가능한 한 짧은 시간 내에 사양을 충족시킬 수있는 충분한 정보.

주제를 벗어:

우리는 더 이상 스크럼을하지 않습니다. 우리는 추정하지 않습니다. 스프린트 보드를 유지했습니다. 우리는 스프린트를하지 않습니다. 기능을 개발하고 버그를 수정하고 최대한 빨리 릴리스합니다. 새로운 기능이 구현되면 가능한 한 밀접하게 고객과 추가 설계를 논의 할 수있는 공용 서버로 최대한 빨리 이동합니다.

정식 답변은 "당신에게 효과가있는 일"입니다.

스크럼은 민첩한 방법론 중 하나입니다. 팀과 프로젝트를 변경하고 적응하도록 명시 적으로 설계되었습니다. 당신의 초점은 :

프로세스 및 도구를 통한 개인 및 상호 작용
포괄적 인 문서를 통한 소프트웨어 작업
계약 협상을 통한 고객 협업
계획에 따라 변경에 대응 ( Agile manifesto )

팀 이 어떤 이야기를 시작해야하는지에 대한 질문이 아니라 특정 팀이 특정 비즈니스 요구를 해결할 수있는 입력에 대한 질문입니다.

내 개인적인 경험에서 그것은 사업 목표에 달려 있습니다. 일부 스토리에는 이미 UI / UX 리서치 및 전체 디자인이 포함되어 있습니다. 비즈니스에는 문제 해결이 필요하기 때문에 일부 스토리에는 모호한 요구 사항이 있습니다. 괜찮습니다.

물론 다른 요인들도 있습니다. 디자이너가 개발자 팀의 일부인지, 마케팅 또는 제품 개발 등의 요소와 같은 요소입니다. 비즈니스를 만족시키고 융통성을 유지하기 위해 필요한 것을 수행하고 회고 중에 이러한 사항을 논의하고 필요에 따라 프로세스를 조정하십시오.

개발자로부터 비슷한 푸시를 받았습니다. 그들의 관점에서 문제는 UX 부분이 구현하는 데 시간이 얼마나 걸릴지주의해야한다는 것입니다. 스프린트에서 N 스토리를 전달하는 데 동의하지만 UX에서 앞뒤로 이동하여 일부 스토리가 예상보다 훨씬 오래 걸리면 그 스토리가 잘못 반영되었다고 느꼈습니다.

우리를 위해 일한 것은 :

1. 누군가가 제품 소유자와 협력하여 개발할 화면의 모형을 만듭니다. 이들은 스토리가 스프린트로 진행되기 전에 일반적인 스토리 개선 프로세스 중에 검토되어 모든 사람이 정직한 토론을 할 수있는 기회를 제공합니다.
2. 코딩하기 전에 디자인을 마무리 짓지 말고 디자인을 끝내고 변화가 필요한 것에 대해 대화하십시오. 그러면 변경 비용이 더 명확 해 지므로 제품 소유자 / 고객은 가치가 있는지 판단 할 수 있습니다.
3. 제품 소유자 / 고객과 개발자 간의 신뢰. 결국 모든 사람들이 고객에게 물건을 전달하려고합니다. PO는 스프린트에서 모든 것을 전달하지 않는 팀에 대해 신음 할 수 없습니다. 개발자는 제공하지 않을까 걱정하기 때문에 의도적으로 방해 할 수 없습니다.
4. 연습. 우리는 추정 스토리 크기와 더 나은 문제를 발견 할 수있게되었습니다.

Tl; DR : 코딩하기 전에 UX를 완전히 정의하지 마십시오. 사용자가 볼 때까지 기다렸다가 재생하십시오.

스프린트를 시작하기 전에 기능에 대한 가능한 모든 세부 사항을 개발자에게 제공해야하는지 또는 기능 내에서 작업해야한다고 생각하십니까?

간단히 말해, 제품 소유자가 스프린트 전에 ui / ux 디자인을 제공 할 수 없다면 ui / ux의 개발은 이야기 가 아니라 이야기 가되어야합니다 .

스프린트 결과물이 항상 작업 코드 일 필요는 없으며 팀 자체가 스토리의 "누가"가 될 수 있습니다. "개발 팀의 구성원으로서 UI를 구현하려면 UI 모형이 필요합니다"와 같은 스토리를 가질 수 있습니다. 그런 다음 팀이 모형을 배달하는 데 걸리는 시간을 추정하면 작업 한 첫 번째 이야기 중 하나가됩니다.

UI를 설명 할 필요는 없으며 기능적 요청 (스토리)을 수락하고 UI에 대해 생각해야한다는 점을 인정하면됩니다. 클라이언트가 UI를 지정하도록하면 문제가 발생합니다.

이제 UI를 통해 더 나은 계획을 세우는 데 어느 정도의 시간이 소요될 것임을 알았으므로 다음에 UI 작업이 포함 된 작업을 수행 할 때는 몇 가지 추가 스토리 포인트를 할당해야합니다.

스크럼이라면 누구나 UI / UX 디자이너가 될 수 있습니다.

UI / UX는 나중에 생각해서는 안됩니다. 결과물이어야합니다. 제품 소유자가 승인해야합니다. 전달할 때 GIF로도 표시되어야합니다.

그렇다고 변경할 수 없다는 의미는 아닙니다. 자주 바뀌는 것입니다. 또한 초기에 피드백을 원하는 것입니다. 코드가 UI 디자인을 주도하게하지 마십시오. 고객이 운전하게하십시오. 고객이 마술을 요구할 때만 뒤로 밀으십시오. 그렇지 않으면 요청한 작업량과 비용이 얼마인지 알려주십시오.

완성 된 유일한 UI / UX는 죽은 소프트웨어에 있습니다.

귀하의 의견에서 :

"제품 소유자가 승인해야합니다." 이것이 바로 문제가 발생한 곳입니다. 이 승인 프로세스에 많은 시간이 소요되며 처음에는 몇 시간이 아닌 하루를 소비하게됩니다. - 라시드

불필요하게 속도를 늦추는 모든 것을 제거하십시오.

당신은 아이디어가 있습니다. 제품 소유자에게 알리십시오. 그들은 당신 옆에 앉아 있어야합니다.

그들이 싫어? 어서 좋아? 해. 이해가 안 되나요? 보여주세요.

예정되지 않은 짧은 회의. 이야기. 화이트 보드 또는 종이에 낙서하십시오. 스크린 샷을 사용하여 페인트 프로그램에서 조롱하십시오. 아이디어를 신속하게 전달, 승인, 구현 및 검토합니다.

제품 소유자가 주변에 있지 않은 경우 편리한 사람을 잡고 물어보십시오. 반복을 시작하기 위해 무엇이 든. 가능한 빨리 제품 소유자를 다시 연결하십시오.

예쁘게 만들기 위해 1 초를 소비하지 마십시오. 요점을 알려주세요. 아이디어를 작고 점진적으로 유지하면 누구나 견적을 요청하기 전에 완료 할 수 있습니다.

내 경험상 :

• 선행 분석이 너무 적 으면 비효율적 인 중지 시작 개발이 발생합니다.
• 선행 분석이 너무 많으면 분석 마비가 발생 합니다 (스프린트는 시작되지 않습니다)

우리가하는 일 :

• " 개발 준비 "기준 정의
• UX 스토리의 경우 "팀에서 잘 이해하는 와이어 프레임이 있습니다"

스프린트 계획 중 :

• 개발 준비가되지 않은 모든 스토리는 폐기됩니다 (팀에 너무 혼란스러워 더 많은 분석을하기 위해 되돌아갑니다)
• 모든 경계선 이야기는 "높은 위험"으로 선언되며 스프린트 시작시 바로 수행됩니다.
• 잘 이해 된 이야기는 스프린트로 추정되고 허용

이 시스템을 통해 모든 스프린트 대부분을 실행에 전념 할 수 있습니다. 즉,보다 효율적으로 작업합니다.

스크럼의 모든 작업에는 관련된 총 작업에 대한 추정치와 검증 가능한 결과가 있어야합니다.

스크럼에 "제품 관리자가 만족하는 사용자 인터페이스로 구현 기능 X를 구현"한 작업이 검증 가능한 결과를 가져다 주지만 관련된 작업량을 추정하는 것은 분명히 불가능합니다. 따라서이 작업 은 합리적으로 스크럼에 넣을 수 없습니다 .

이제 나는 당신의 스크럼에 "특징 X를위한 사용자 인터페이스 디자인"에 작업을 넣었다. 추정 할 수 있고 결과를 확인할 수 있습니다. 그것은 스크럼 내의 Ok 작업입니다. 작업이 완료되면 완료된 것입니다.

이제 작업이 완료되면 제품 관리자가 결과가 마음에 들지 않는다고 말할 수 있습니다. 괜찮아. 스크럼에 작업이 있었고 작업을 마쳤습니다. 그는 다음 스크럼에 다른 작업을 넣을 수 있습니다. 어쩌면 좀 더 많은 방향으로 그가 실제로 원하는 사용자 인터페이스의 종류. 그것이 그의 직업입니다. 유용한 결과 를 제공 하는 작업 설정 . 때로는 힘들고 쓸모없는 결과가 나옵니다. 그것이 그들이 "민첩한"이라고 부르는 이유입니다. 쓸모없는 것으로 판명 된 작업을 수행 한 다음 더 나은 방향으로 변경합니다.

또한 UX 디자인, 특히 우수한 UX 디자인은 UX 디자인을 연습 한 사람에게 정규직입니다. 많은 훌륭한 소프트웨어 개발자는 UX를 생성하는 훌륭한 일을 할 수 있지만, 훌륭한 UX 디자이너만큼이나 비용 효율적이지는 않습니다 (만약 가능하다면 UX 디자인을 만들고 소프트웨어를 개발하지는 않을 것입니다). 따라서 UX 디자이너가없는 것은 비효율적입니다. 다시 한 번 제품 소유자에게 문제가됩니다.

민첩한 원칙을 따르고 있는지는 확실하지 않지만 여기에서이를 처리하는 방법이 있습니다.

스프린트 시작 전에 정확한 UI / UX 디자인을 정의하지 않습니다

이 시점에서 목표는 완벽하지 않습니다. 개발자가 가능한 한 가깝게 요청한 내용과 일치하는 것을 만들 수 있도록 요구 사항에 대한 많은 정보를 얻습니다. 많은 조정을하거나 요구되지 않은 것을 디자인하려고하지 마십시오. 당신은 당신의 시간을 낭비합니다.

스프린트 중에 UI / UX 디자인을 마무리하는 데 너무 많은 시간을 소비하게됩니다.

작업이 완료되는 시점을 결정하는 방법으로 작업하십시오. UI / UX에 대한 많은 평가를 계속하고 있습니다. 너무 많은 사람들이 UX / UI에 대한 의견을 가지고 있으며, 고객의 가정을 뒷받침 할 내용이 없습니다.

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

이런 종류의 일은 영원히 계속 될 수 있습니다. 스크럼 결함이 아닙니다. 스프린트 중에 누군가가 요구 사항을 방해하고 있습니다. 고객이 원하는 것을 결정하고, 시간이 얼마나 걸리는지 결정하고 우선 순위를 정하기 위해 고객과 협력하십시오. 그들이 너무 오래 걸릴 것이라고 생각되면, 무엇을 제거해야하는지 물어보십시오.

정액 요금으로 로고를 디자인하는 회사가 있습니다. 그들은 일부 클라이언트가 변경 사항이있는 수천 컷에서 사망으로 죽임을 알기 때문에 변경 요청 수를 제한합니다. 그만 두거나 더 충전하십시오. 비즈니스라고합니다.