스크럼 스프린트에서 추가 미용 기능을 어떻게 처리해야합니까?


11

나는 Scrum 문서를 읽고 있었고 Sprint의 작업은 "잠재적으로 배송 가능해야한다"고 말합니다.

이것이 무엇을 의미하는지 혼동됩니다. Sprint 1에서 목표가 "사용자 등록 양식"이라고 가정합니다.

배송 할 준비가 되려면 세부 정보를 얼마나 추가해야합니까? 예를 들면 다음과 같습니다.

  1. 멋진 스타일링없이 필드가있는 간단한 양식을 표시하고 완료로 표시 할 수 있습니다.
  2. 클라이언트 측 유효성 검사를 완료로 표시 할 수 있지만 서버 측도 옵션 또는 둘 다입니다.
  3. 양식에 jQuery 고급 도구 설명, 마우스 오버, 보안 문자, 색상, 레이블을 추가 할 수도 있습니다.
  4. 그런 다음 화면에 오류 메시지를 표시하는 방법에 대한 많은 스타일이 있습니다.

한 가지 주제로 끝없이 할 수 있습니다. 우리는 어떻게 그것을 나누고 언제 선적 준비가 된 것으로 생각할 수 있습니까?

또는 오류, 팝업 또는 라이트 박스 텍스트를 하위 작업으로 표시하는 것과 같이 가능한 가장 작은 것을 작성하고 스프린트로 넣어야합니까? 이로 인해 전체 프로젝트에 1000 개의 작업이 발생합니다.

다시 말하면 Internet Explorer에서 작동하는 일부와 Firefox에서 작동하는 일부는 다시 작업으로 나눌 필요가 있습니다. 시간은 그들에게 소비되어야하고 관리자가 그 시간에 당신이 한 일을 물으면, 나는 할 일이 없지만 실제로는 모두 사용자 등록의 일부입니다


5
어떤 "스크럼 문서"?
Dave Hillier

답변:


13

인터넷이 아닌 제품 소유자 및 Scrum 팀과 이에 동의하십시오. 이것은 완료 정의에서 결정해야하며 팀의 작동 방식에 따라 크게 달라집니다.

이 기능은 '배송 가능 ' 해야하지만 (스크럼에서이 용어는 싫습니다) UI없이 기능을 제공 할 수 있다고 주장 할 수 있습니다. 많은 사람들이 스크럼에서 이러한 오해를 겪고 있습니다. 스프린트의 목표는 가능한 한 많은 이야기 (이상적으로는 모두)를 '완료'하는 것이지만, 출시 될 수있는 무언가에 내장 될 필요는 없습니다.

이와 같은 것을 조기에 해결하는 것이 중요하므로 팀 전체의 모든 사람들이 공통의 목표를 달성하기 위해 노력하고 있습니다. Scrum의 기풍은 의사 소통이므로 Scrum 팀에 문의하여 논리적 결론을 도출하십시오.

UI를 일반적으로 개별적으로 처리하는 팀 (예 : 다른 팀에 의해 또는 UI 전문가가 양식의 모양 등을 결정한 팀)에서 작업 할 수 있습니다. 또는 소규모 프로젝트 / 팀에서는 UI가 원하는대로 빌드 될 수 있습니다. 가다.

팀이 모두 답을 알고있는 한, 그 답이 무의미합니다.


2
+1 "팀이 모두 답을 알고있는 한, 답이 무엇인지는 무의미합니다."
mattyB

"팀이 모두 답을 아는 한, 그 답이 무엇인지는 무의미합니다". 사용자 스토리로 요구 사항을 문서화하고이를 작업으로 나누는 것은 과학이 아닌 예술입니다. 각 팀 (제품 소유자 포함)은 사용자 정의 수용 조건 또는 개별 작업으로 완료 정의에 문서화 할 세부 수준을 함께 학습해야합니다.
Nick

최신 버전의 Scrum Guide (2013 년 7 월)는 더 이상 배송 할 수 없음을 나타냅니다 . 현재 사용 된 문구는 잠재적으로 출시 가능 합니다.
Derek Davidson PST CST

5

미용 기능이 기능의 일부인 경우 스토리의 일부로 수행해야합니다. 요점은 일단 스토리가 완료되면 특정 기능에 대해 더 이상 코딩을 수행 할 필요가 없다는 것입니다. 그러나 궁극적으로 제품 소유자가 결정하지만 미용 기능을 원할 수도 있고 그렇지 않을 수도 있습니다. 이것은 수락 기준에 설명되어 있어야합니다.

그렇다고 반드시 최종 사용자가 사용할 준비가되었음을 의미하는 것은 아니며 누군가 에게 준비가되었음을 의미합니다 . 누군가 테스터이거나 백엔드 팀과 같은 다른 팀이 될 수 있습니다.

이것을 개발자로 요청하는 경우, 답변은 "제품 소유자가 미용 기능을 원하는지 여부를 알려주기 때문에 알고 있습니다".

이것을 제품 소유자로 요청하는 경우 기능을 둘 이상의 스토리로 나눌 것인지 결정하기 만하면됩니다. 그것이 만족해야 이외의 어떠한 요구 사항도 없다 당신을 만족하기위한 수단으로, 고객은 .

기억하십시오 : 목표는 스크럼을 엄격하게 준수하는 것이 아닙니다. 목표는 최종 사용자에게 고품질 소프트웨어를 제공하는 것입니다. 이와 같은 질문으로 어려움을 겪을 때 가이드로 사용하십시오. 순전히 기능적인 부품과 동일한 스토리에 화장품을 추가하면 고객에게 품질 코드를 전달하는 데 도움이됩니까? 아니면 두 가지 이야기로 나누는 것이 도움이 될까요? 답이 명확하거나 중요하지 않으며 팀에 적합한 모든 것을 할 수 있습니다.


3

"잠재적으로 배송 가능"이란 배송 할 수있는 것은 아닙니다. 예를 들면 다음과 같습니다.

끔찍해 보이고 현장에서 검증되지 않은 웹 등록 양식은 학교 프로젝트와 같은 일부 상황에서는 문제가 없지만 수백만 달러 규모의 사업에서는 최종 사용자에게 브랜드를 손상시킬 수 있습니다. 코드는 배송하고 싶거나 마케팅이나 법률이 제공하지 않아도 배송 가능할 수 있습니다.

프로그래머 (그리고이 시점에서 현재 진행중인 다른 사람들, 예를 들어 디자이너들)는 어떤 이유로 든 실제로 그런 식으로 풀려 나지 않더라도 지금 당장 릴리스 할 수있게되어 기쁘다. 다른 언어로 번역하기 전에 다른 언어로 번역해야합니다. 캐나다는 영어뿐만 아니라 프랑스어를 동등하게 고려하는 정부 구매 소프트웨어에 대한 엄격한 규칙을 가지고 있습니다).

이것은 품질 검사 점입니다. 눈에 보이는 모든 사람을보고 추가 작업없이 바로 배송 할 수 있는지 물어보고 마지막으로 한 일인지 확인하지 않아도됩니다. 나는 이것을 비행기 엔지니어 검문소라고 들었습니다. 당신은 눈에 엔지니어를 쳐다보고 그들이 시험 비행에 기꺼이 동행 할 것인지 묻습니다.

아이디어는 최대한 민첩해야합니다. 실제 사용자에게 더 빨리 무언가를 얻을 수 있습니다. 웹 사이트에서 개인 또는 A / B 테스트를 선택하는 코드의 베타 사본이든 더 좋습니다. 제품에 대한 기대치에 정의 된대로 너무 거칠고 거친 사용자 코드를 표시하면 쓸모없는 피드백을 제공합니다. 그들은 당신이 좋아하지 않는 것에 대해 이야기 할 것입니다 : 그들은 버튼이 노란색이거나 텍스트 상자가 레이블과 일치하지 않는 것을 좋아하지 않습니다. 충분하면 유용한 피드백을 얻을 수 있습니다. 이 피드백을 빨리받을수록 더 좋습니다! 제품 / 시장 적합성과 구축하려는 기능에 대한 가정을 검증 할 수 있습니다.

기능 배송은 이것의 가장 중요한 부분입니다. 개발팀을 옮기고 사용자 스토리를 마무리 하는 것이 중요합니다. 무언가를 주장 할 수있는 시점에 도달하는 것은 훌륭한 동기입니다.


1

나의 이해, 각 이야기는에 의해 소비를위한 준비하는 범위와 "로 선적" "-수 수행"해야 사람 , 반드시 최종 사용자 . 따라서 스토리는 제품 소유자에게 전달할 수있는 일부 기능을 제공 할 수 있으며,이 기능은 최종 사용자에게 릴리스하거나 기능을 다시 반복하도록 선택할 수 있습니다.

말했다, 당신은하지 않을 배제 은 "최종 사용자로서, 나는 등록 할 수있을 것"이야기 스타일링을 포함에서. 우리 팀에서는 예측 가능성을 높이고 약속 한 내용을보다 잘 전달할 수 있도록 모든 스토리를 최대한 작게 만듭니다. 우리가 미리 준비된 디자인을 가지고 있고 적용하기가 사소한 것이라고 생각한다면, 그것은 이야기에 포함됩니다. 우리는 디자인에 약간의 반복이 있다고 생각한다면 그것은 별도의 이야기입니다.


1

이 질문에 대한 다른 훌륭한 답변 외에도 미용 기능을 범위 리소스 시간 삼각형의 가변 범위 부분으로 생각할 수도 있습니다. 그 이야기의 기본 요구 사항을 충족시키고 시간이 있으면 멋진 것을 추가하십시오.

스크럼은 특정 시간에 특정 기능의 제공을 보장하지 않습니다. 주어진 시간에 가능한 최대의 유용한 작업을 제공합니다. "선택"화장품 기능이 질주하는 동안 수행되지 않은 경우, 그것은 해야 그들이 가능하지 않았기 때문에합니다.


내 조직에서는 "화장품"기능이 릴리스 전에 필수적입니다. 우리는 응용 프로그램이 전문적이고 세련된 견해를 갖기를 원합니다. 내가 궁금한 것은 기능의 개발 또는 프로젝트의 최종 스프린트에서 화장품을 적용 해야하는지 여부입니다. 후자의 경우 우리는 잠재적으로 선적 가능한 제품을 보유하지 않을 것이며, 전자의 경우에는 크게 변경하거나 나중에 떨어 뜨리기로 결정한 기능을 아름답게 만드는 데 시간을 낭비 할 수 있습니다.
유진

좋아, 그것은 흥미로운 제약입니다. 어느 쪽이든 당신을 위해 일할 수있는 것처럼 들리지만, 후자의 경우는 "작업량 최소화"라는 애자일 가치를 지원합니다. 다시 말해 YAGNI는 당신의 친구입니다.
catfood

@Eugene : 제품 소유자가 모든 기능을 최종 세련된 모양으로 제공하기를 원하는 경우 제공해야합니다. 그렇지 않으면 "Make X look good"라인을 따라 추가 스토리를 소개하는 것은 제품 소유자에게 달려 있습니다.
Bart van Ingen Schenau

저는 실제로 "완료된 정의"가 유연하다고 말합니다. 여기에는 "사용자 인터페이스는 최소한 깨끗하고 전문적이어야하지만 시간을 내야 할 경우 추가로 반짝이는 부품이 포함될 수 있습니다."와 같은 내용이 포함됩니다. 그것은 의도적으로 개발자에게 많은 흔들림 공간을 제공합니다.
catfood 2014 년

0

요구 사항을 설정하는 사람, "제품 소유자"에 따라 다릅니다. 프로그래머로서 저는 웹 서비스의 비즈니스 로직이 올바르게 작동하고 등록하면 시스템의 다른 리소스에 대해 인증을받을 수 있음을 증명하는 스타일이없는 "등록 양식"페이지가있는 콘텐츠 일 수 있습니다. 실제로 "잠재적으로 배송 할 수있는"이라는 말은 반드시 고객에게 문자 그대로 배송한다는 것을 의미하지는 않기 때문에, 특히 기술 팀과 디자인 팀은 별도의 백 로그가있는 별도의 리소스입니다.

보다 성숙한 프로젝트에서는 최소한의 스타일링으로 기능의 "개발자 디자인"버전을 파일럿 또는 베타 클라이언트에 제공 할 수 있지만 기능 수정 (피드백 기반) 및 디자인 완료에 대해 동일한 기능을 다시 방문 할 수 있습니다.

애자일 방법론의 목적은 요구 사항이 소프트웨어 개발 프로세스의 반대가 아니라 구동되도록하는 것입니다. 방법론에 대한 한 가지 설명이 참되고 유일한 정통 요구 사항이라고 가정하는 함정에 빠지지 마십시오. 물론 스크럼이 개발 팀에 혼란을 불러 일으키는 구실이 된 대규모 조직에 있다면 특히 그렇습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.