민첩한 환경에서 스파이크를 수행해야하는 경우

Question

현재 회사에서 애자일 사례를 도입하기 시작했으며 좋은 출발을 보았습니다. 우리는 첫 번째 릴리스를 끝내고 곧 두 번째 릴리스를 시작할 예정입니다. 경영진은 반복 작업 중에 새로운 작업을 도입하지 않기로 동의했지만 릴리스/기능 계획의 범위 지정은 진행중인 작업입니다. 즉, 다음 반복을 위해 반복 실행 중에 수행해야하는 스파이크를 어디에/언제 맞출 것인지에 대해 고심하고 있습니다.

현재 관리/프로젝트 관리자는 스파이크를 수집하고 개발자가 다음 수요일까지 스파이크에 대한 작업을 생성 할 것이라는 개념으로 반복이 시작될 때 필요한 각 스파이크를 제공합니다. 작업은 다음 반복으로 예약 될 수 있습니다.

이 방법이 효과가 있지만 스파이크 주위의 요구 사항을 수집하는 더 좋은 방법이있는 것처럼 보입니다. 다른 사람들이 스파이크를 수행 할 시간을 어떻게 계획하고 있습니까? 우리는 모든 개발자가 일정 시간 동안 반복적으로 80 시간을 계획하지 않기 때문에 회의/이메일/스파이크 등을위한 약간의 숨쉴 공간이 있습니다.

에이 있음을 알지 못하면 스파이크를 묻습니다. 다음 반복 작업이 수행 될 것입니다. 두 번이나 그들은 수행 할 작업을 계획하지 않기 위해 많은 스파이크를 요구했습니다.

의견을 보내 주시면 대단히 감사하겠습니다.

Answer 1

Google의 반복 계획에는 직접 스파이크가 포함됩니다. 우선 순위가 정해져 있기 때문에 주로 일정 시간이 걸리기 때문에 완료해야합니다. 스파이크가 반드시 더 많은 개발로 이어질 필요는 없다는 것을 기억하십시오. 경영진이 특정 아이디어의 가치가 있는지 여부를 알기보다는 오히려 빠른 방법입니다. 개발자가 각 반복에서 스파이크 반복에 소비하는 시간을 제한하여 토끼 후행 (토끼를 꼬박 꼬박 꼬박 꼬박 꼬박 꼬박 꼬박 걷기)을 막습니다. 또한 개발자는 언제 중지해야하는지 알고 있어야합니다. 스파이크는 추정치를 결정하기위한 것이지 추정치에 대한 코드를 전달하는 것이 아닙니다. 다른 목적을위한 프로토 타입과 같습니다. 당신은 그것에 대해 더 많이 알고 싶어하는 것을 사용하고 싶지 않습니다.

Answer 2

작업을 실제로 계획하고 추정하기에 충분하지 않은 것을 조사해야 할 때 스파이크를 사용합니다. 그래서 스파이크는 대개 시간이 모자라게됩니다. 즉, 스파이크에서 얻은 지식으로 인해 다시 생각할 수 있기 때문에 후속 작업을 예약하지 않는 것이 좋습니다. 또한 전제 조건 또는 중요한 작업이 완료 될 때까지 실제 구현을 지연시킬 수도 있습니다. 기본적으로 나는 말하고있다 : 당신의 스파이크로도 민첩 해지고, 끊임없이 상황을 재평가해라. 한 가지 더 : 우리는 일반적으로 개발자가 문제와 적절한 해결책을 이해했는지 확인하기 위해 실제 구현 작업 전에 검토 작업을 수행합니다.

Answer 3

새로운 스토리가 들어오고 팀에서이를 예상 할 수 있도록 스파이크가 필요한 경우 제품 소유자는 스파이크와 스토리를 모두 백 로그에 추가하고 우선 순위를 정합니다.

우리 스파이크는 반복되는 다른 백 로그 항목으로 계획됩니다. 우리가 스파이크를 계획하고 같은 반복에서 백 로그 항목을 구현하기 시작한 일은 결코 일어나지 않았습니다.

귀하가 온 사이트 고객이나 제품 소유자가 아닌 관리에 대해서만 언급하는 것이 놀랍습니다. 스파이크는 프로젝트의 일부이므로 프로젝트 시간은입니다. 따라서 팀 시간을 스파이크 나 이야기에 소비하는 것은 PO 결정입니다.

Answer 4

내가 일하는 곳에서 스파이크는 예상하기 쉽지 않은 무언가를 시간에 맞춰 조사하는 경향이 있습니다. 1 시간이 걸릴 수도 있고 100 시간이 걸릴 수도 있습니다. 스파이크 작업을하기 전에는 명확하지 않습니다. 시간이 끝나거나 작업이 제대로 예측되면 스파이크가 완료됩니다.

버그는 어떻게 처리됩니까? 어떤 점에서 버그는 스파이웨어와 유사 할 수 있습니다. 예를 들어 무엇이 오래 걸릴지 모르는 것과 같이 변경해야 할 것이 명확하지 않기 때문입니다.

Answer 5

스파이크는 충분하지 않거나 제품이나 기능을 해결, 향상 또는 달성하기위한 여러 가지 방법이있는 경우 수행되는 조사 사례입니다.

스파이크는 스파이크를 수행해야하는 최종 사용자 기능의 관점에서 정의해야합니다.

스파이크는 스파이크의 결과, 즉 완료의 정의를 정의하는 허용 기준을 가져야합니다.

스파이크는 박스로 포장해야하며 일반적으로 40 시간 미만이어야합니다. 무언가가 더 많은 시간을 필요로한다면 첫 번째 스파이크가 끝날 때 제공된 정보에 따라 얼마나 많은 추가 스파이크가 필요한지를 결정하기 위해 초기 스파이크가 수행됩니다.

스파이크는 시간 박스 이벤트의 끝에서 수행되고 수용 기준이 충족 될 때 수행됩니다. 내가 수행을 감안할 때 : 사용자 역할 나는 내가 XYZ

수용 할 수있는 ABC 에 스파이크를 수행 할 으로 :

스토리 - 아래

는 스파이크 이야기의 예입니다 ABC에 대한 스파이크 스파이크를 완성 할 때 그렇다면 스토리에 XYZ를 적용한 프로토 타입/아티팩트를 제작/첨부해야합니다.

참고 : 스파이크에 허용 기준을 더 구체적으로 지정하도록 요구 한 기술 설계자 또는 제품 소유자와 함께 XYZ를 달성하기 위해 어떤 이슈 유형 및 해당 아티팩트에 나열되어야 할 세부 정보를 명확하게 나열 할 수 있습니다.