저는 현재 일하고있는 회사에서 스크럼 프로젝트를 시작했습니다. 관리자가 폭포에서 스크럼으로 이동하도록 설득하는 것은 그리 어렵지 않았습니다. 우리는 처음부터 플랫폼을 재건하는 프로젝트를하고 있습니다. 따라서 (대부분의) 기능이 알려져 있으며 대부분의 기능 향상은 다소 기술적입니다.
여기에서 사용자 스토리가 아닌 기술적 인 작업을하는 것이 정당화 될 수 있습니다. 백 로그에는 다음과 같은 모든 종류의 기술 작업이 있습니다.
스탠드 업 중에 나타나는 것은 긴 "연구 작업"을 원하지만 결코 끝나지 않는다는 것입니다. 또한 팀원들은 스프린트 중간에 계획되지 않은 작업을 추가해야한다고 주장합니다.
스크럼 마스터는이를 어떻게 처리해야합니까? 이런 종류의 프로젝트에서 스크럼이 갈 길이 아닌가?
답변:
스크럼은 사용자 스토리 사용을 의무화하지 않습니다. 그들은 단순히 유용한 민첩한 연습입니다. 제품 소유자는 확실히 사용자 스토리 대신 기술 사양을 사용하여 제품 백 로그를 작성할 수 있지만 다른 프로세스 문제의 대부분은 효과적인 스크럼 및 민첩한 사례를 수용하지 못했기 때문에 발생합니다.
Scrum은 다음을 포함하여 다양한 방식으로 손상되었습니다.
Scrum이 모든 프로젝트에 항상 적합한 것은 아니지만,이 경우 팀이 실제로 Scrum을 수행하지 않기 때문에 Scrum이 작동하지 않는다고 말하는 것이 더 정확합니다. 사용자 스토리에 대한 질문은 팀이 직면 한 큰 프로세스 문제의 일부일뿐입니다.
기술 사양은 기본적으로 요구 사항을 전달하는 방법입니다. 관점에서 벗어나지 않는 요구 사항은 개발자에게 유용한 지침을 제공하지 않습니다. 게시 된 예제 사용 :
개발자의 관점에서 이러한 종류의 질문에 대답 할 수 없으면 정확히 설명하는 프로세스 문제가 발생합니다. 사용자 스토리는 필요한 컨텍스트를 제공하고 특정 기능에 대한 이해 당사자 또는 최종 사용자와의 추가 대화를위한 자리 표시 자 역할을합니다.
사용자 사례는 프레임 워크 요구 사항이라고 생각하거나 널리 받아 들여진 민첩한 관행이기 때문에 사용해서는 안됩니다. 대신, 프로그래밍 작업을보다 쉽게하고 프로그래밍 직업을 더 즐겁게하기 때문에 효과적으로 작성하고 사용하는 작업을해야합니다 . 물론 마일리지는 다를 수 있습니다.
여기 문제가 스크럼이라고 생각하지 않습니다. 문제는 명확하게 정의 된 프로젝트가 없으며 (이번 여러 번 경험 했음) 명확한 방향이 없다는 것입니다.
나는 당신의 기술 작업은 훌륭하지만 아마도 큰 측면에서 측정 가능하고 정의 가능하므로 이야기에는 절대적으로 좋습니다.
연구 작업은 눈에 띄는 이점을 제공하지 못하고 엄청난 범위 크립을 생성 할 수 있기 때문에 스크럼에서 큰 위험 신호입니다. 나는 스프린트에서 이러한 선결제 한을 제한하는 것을 옹호합니다. 그것들을 추가해서는 안되며 분명히 헌신적 인 목표를 희생하여 추가해서는 안됩니다. 합의 된 스프린트 작업을 완료해야하는 경우 계획시 종속성이 명확해야합니다 (그렇지 않으면 예상 한 결과는 무엇입니까?).
필자의 경험에 따르면, "조사 스파이크"가 많은 프로젝트는 실제로 많은 일을하지 않고 비즈니스 가치를 창출하는 것보다 새롭고 반짝이는 멋진 것을 찾기 위해 시간을 보내고 싶어하는 개발자를위한 표지입니다. 귀하의 팀이이 작업을 수행하고 있다고 제안하는 것은 아니지만 프로젝트에는 명확한 목표가 필요하며 개발자가 "연구"할 수있는 자유가 부여 된 경우, 귀하가 허용하는 한 계속 수행 할 것입니다.
스크럼은 고객에게 제공 할 수있는 제품을 더 잘 갖추게 될 것이라고 말합니다. 그러나 여기서 요점은 전달 가능한 제품 과 고객을 지정하지 않는다는 것 입니다.
즉, 특정 경우에 제공 가능한 제품 을 코드 개선, 플랫폼 변경, 재 작성 및 재 설계 등으로 정의하고 기술 관리자를 고객으로 간주 할 수 있습니다.
그것은 나에게 100 % 의미가 있습니다. 제품 사용자의 이야기를 알려주는 백 로그를 작성하고 사용자는 누구입니까? 기술 관리자. 따라서 다음과 같은 항목이 있습니다.
그리고 고객 (기술 관리자)에게 제공하는 것은 로깅 시스템입니다.
그러나 논의한 R & D 작업과 관련하여 스크럼의 급증 에 대해 읽어 보는 것이 좋습니다 . 기본적으로 시간 상자가있는 미니 작업으로, 익숙하지 않은 더 큰 작업을 수행하는 데 필요한 시간을 결정하는 데 도움이됩니다.
스크럼 마스터는 작업의 특성상 더 긴 스프린트를 고려할 수 있습니다. 이렇게하면 "연구"작업을위한 약간의 버퍼가 제공됩니다. 그러나 작업이 코드에서 일종의 작업 제품 / 개념 증명을 생성하는지 확인해야한다고 생각합니다. 프로그래머는 무엇을 기대하십니까? A에게 : 우리가 원하는 일을하는지 B : 더 잘 수행합니다. C : 더 빠른 속도를 얻고 얼마나 오래 생각할 수 있을까요? 무언가를 만들기 위해 가져 가라.
현재 다시 쓰기에 대해 생각한만큼 많이 알지 못하는 경우 더 짧은 스프린트 주기로 이동할 수 있습니다. 당신이 따라갈 때 그들을 조정하는 것을 두려워하지 마십시오. 이것이 민첩하다는 의미입니다. 연구 후 새로운 기술을 사용하기로 결정할 수도 있습니다. 이것은 통제를 너무 멀리하기 전에 스프린트를 단축시키는 또 다른 이유 일 수 있습니다. 스프린트 도중에 새로운 기능이 작동하지 않을 수 있습니다. 스프린트를 중지하고 이전 기술로 조정하십시오. 결국 개발자는 이전 방법과 새로운 방법을 비교하고 대조 할 수 있어야합니다.
개발자의 요구를 다루고 있으며이 경우 응용 프로그램을 다시 작성하십시오. 이 프로젝트가 나중에보다 빨리 완료되기를 원하고 장기적인 변명으로 "연구"의 필요성을 받아들이지 않는 제품 소유자가 있다고 생각합니다.
아래 전략 중 일부가 도움이 될 수 있습니다.
예, 기술 사례 가있는 백 로그를 가질 수 있습니다 .
사용자 스토리와 마찬가지로이 기술 스토리도 최종 사용자에게 제공되는 이점에 중점을 두어야합니다. 여기 에 몇 가지 팁이 있습니다. 더 나은 백엔드로 이동하려는 것처럼 제품에 본질적인 가치를 가져다 줄 이야기입니다.
조사 (연구) 작업의 경우 스파이크 사용
스파이크는 개발자가 사용자 스토리에서 알려지지 않은 내용 (예 : 새로운 기술)에 대해 충분히 학습하여 해당 사용자 스토리를 추정 할 수있는 실험입니다. 스파이크는 타임 박스되어야합니다. 학습에 소요되는 최대 시간을 정의하고 급증에 대한 추정치를 수정합니다.