Scrum에서 개발 환경 설정 및 기능 개발과 같은 작업을 실제 사용자 스토리 내에서 하위 작업으로 관리해야합니까?

때로는 프로젝트에서 다음과 같은 작업에 시간을 소비해야합니다.

1. 대체 프레임 워크 및 도구 탐색
2. 프로젝트를 위해 선택된 프레임 워크 및 도구 학습
3. 서버 및 프로젝트 인프라 설정 (버전 제어, 빌드 환경, 데이터베이스 등)

User Stories를 사용하는 경우이 모든 작업은 어디로 가야합니까?

하나의 옵션은 그것들을 모두 첫 사용자 스토리의 일부로 만드는 것입니다 (예 : 응용 프로그램을위한 홈페이지 만들기). 또 다른 옵션은 이러한 작업을 급증시키는 것입니다. 세 번째 옵션은 작업을 사용자 스토리가 아닌 이슈 / 장애 요소 (예 : 개발 환경이 아직 선택되지 않음)의 일부로 만드는 것 입니다.

우리는이 문제에 대해 작년에 상당히 많이 생각했습니다.

프로젝트가 시작되기 전에 기본 프레임 워크가 있어야한다는 데 동의하지만 실제로는 프로젝트 자체의 일부가 될 수 있습니다. 그래서 어떻게 든 관리해야합니다.

프로젝트 설정과 사용자 스토리를 혼합하는 것이 합리적 일 수 있지만 때로는 제품 백 로그에 추가하고 사용자 스토리와 동일한 관심을받을 수있는 간단한 작업을 설정 했습니다. 우리는 이러한 기술적 작업이 때때로 필요하다는 것을 알고 있지만, 어떤 경우에도 정당화되어야합니다. 팀이 특정 목표를 달성하기 위해 절대적으로 필요하다고 생각하면 스프린트의 일부가 될 것입니다.

가장 적합한 것이 무엇인지 말하기 어렵 기 때문에 실험 해보십시오 ! 지금은 스파이크만으로 충분할 수 있지만 나중에 같은 문제가 발생할 수 있으므로 미리 계획하십시오. 수행 작업 등의 활동에 대한 자리 표시 자입니다. 이야기 2에서 작업을 분리하기 위해 나는 그들과의 경험을 바탕으로 신속하게 비교합니다.

작업 : 작업은 기술적 필요성입니다. 커밋을위한 리포지토리 설정 또는 개발 프로세스에 가장 인기있는 코드 검토 도구 추가와 같은 구성 관리 또는 일반 프로젝트 설정이 될 수 있습니다. 사용자 스토리와 마찬가지로 계획에서 작업을 고려해야합니다. 팀이 제품 소유자에게 최신 코드 검토 도구가 있으면 오래 지속되는 페어 프로그래밍 세션이나 직접 코드 검토를 제거하여 성능을 높이고 팀 커뮤니케이션을 향상시킬 수 있다고 확신하면 제품 소유자의 관심을 끌 수 있습니다.

스토리 : 비즈니스 관점에만 초점을 맞춘 스토리는 항상 고객에게 가시적 인 가치를 제공합니다. 내부 품질은 비즈니스 가치 창출과 관련이 있습니다.

우리는 스토리 포인트를 작업에 할당하고 때로는 스토리에서와 같은 방식으로 작업합니다.

결국 나는 당신의 경우 에이 솔루션 을 사용할 것입니다 (일반적으로 적용될 수도 있음).

1. "설정"과 기술적 인 항목을 작업 (제품 소유자에게 직접 비즈니스 가치를 창출하지 않는 작업)으로 분리하십시오.
2. 프로젝트 설정 전에 가장 중요한 도구 (SCM, 개발 도구, 프로세스 정의, 코딩 표준 등)를 확보하기 위해 급등을했을 수도 있습니다
3. 이러한 작업은 프로젝트 기간 동안 팝업으로 표시되고 스토리 이외의 별도의 "유형"활동을 통해이를 계획하십시오.

회사에서 가장 의미있는 것을하십시오. 다른 사람들이 어떻게 일을하는 것이 상식에 방해가되지 않도록하십시오.

그러나 이러한 모든 작업은 개발을 시작하기 오래 전에 발생해야하는 것처럼 들립니다. 그래서 스크럼이 이러한 작업과 관련이 있는지 여부에 의문을 제기합니다. 소스 제어 및 데이터베이스에 대한 일부 유지 관리가 진행 중이지만 일정이 계획되어서는 안되며 속도 만 발생하는 상황이어야합니다.

프로젝트 중에 프레임 워크 또는 기타를 선택해야 할 때가 있지만 .NET과 같은 프레임 워크가 아닌 nHibernate와 같은 프레임 워크를 의미한다고 말할 때입니다. 그러한 경우에, 연구는 상당히 짧게 언급되지 않고, 급증하고 타임 박스되어야한다. 며칠 동안 개발자가 병에 걸린 것처럼 관리하십시오.

지식 이전은 일반적인 개발 속도를 벗어나서 관리해야하는 또 하나의 진행중인 프로세스입니다.

프로젝트의 "공식적인"시작 전에 가능한 한 많은 디자인 결정을 내린다는 이름이 있습니다. 폭포라고합니다. "개발자로서 프레임 워크를 선택해야하므로 웹 사이트를 시작할 수 있습니다."와 같은 사용자 사례에는 아무런 문제가 없습니다. 반복하기에 너무 큰 경우 "개발자로서 Drupal에서 기본 홈페이지를 구현해야하므로 우리의 요구에 맞는지 알 수 있습니다."

한 가지 옵션은 첫 사용자 스토리의 모든 부분을 응용 프로그램 홈페이지로 만드는 것입니다.

"사용자 스토리"를 개념으로 나눕니다. 어떤 사용자가 여기에 관여합니까? 없음 이것은 이미해야 할 일입니다.

또 다른 옵션은이를 위해 스파이크를 수행하는 것입니다.

나쁘지 않다.

세 번째 옵션은 작업을 사용자 스토리가 아닌 이슈의 일부로 만드는 것입니다 (예 : 아직 개발 환경이 선택되지 않음).

계획과 간접비에 관한 한 급등과 거의 같습니다.

설정은 사용자 스토리 가 아닙니다 .

그것은 당신이 무엇을 해야 당신도이 프로젝트를 시작하기 전에 자리에 있습니다.

프레임 워크 / 도구 및 서버가 설정되어 있고 준비가되어 있지 않으면 프로젝트를 실제로 시작할 수 없습니다.

나는 많은 조직이 정말 때까지 존재하지 않는 것을 잘 알고 있어요 후 계약이 체결된다. 나는 또한 많은 조직까지 기술을 선택하지 않은 것을 잘 알고 있어요 후 계약이 체결된다. 이것들은 모든 사용자 이야기 외부에있는 비효율적 인 것입니다.

직장에서 우리는 환경 준비 작업을 사용합니다. 일부 사람들에게는 혼란 스러울 수 있지만 우리가 사용하는 작업은 사용자 스토리의 작업과 거의 같은 작업입니다. 이 작업은 사용자 스토리에 속하지 않지만 몇 시간 안에 예상되며 특정 스프린트에서 완료하려면 제품 소유자가 동의해야합니다.

또한 "명백한"비즈니스 가치는 없지만 특히 코드 기반이 큰 기존 제품의 품질을 높이는 건축 작업에도이 작업을 사용합니다.

이것들은 당신의 작업 환경에는 적용되지 않을 수도 있지만 우리에게는 잘 작동했습니다.

나는 당신이 두 개의 독립적 인 것을 섞고 있다고 생각합니다. 사용자 스토리에는 기술적 세부 사항이 포함되어서는 안됩니다.

프레임 워크 선택, 리포지토리 및 서버 설정 및 기타 작업은 초기 반복으로 진행되어야합니다.

저는 최근에 스크럼 과정을 갔으며 강사는 이러한 종류의 문제를 정확하게 해결하기 위해 스프린트 0 이라는 특수 스프린트를 사용해야한다고 제안했습니다 . 코스에 다양한 경험의 스크럼을 가진 사람들이 있었고 거의 모든 경험 많은 사람들이 동의했다. 어떤 경우에는 회사에서 Sprint 0을 사용하여 프로젝트를 평가하고 프로젝트의 실행 가능 여부를 결정했습니다.

나 같은 스크럼 방법론을 처음 접하는 사람에게는 사용자 스토리와 사용자 피드백과 같은 일반적인 스프린트의 다른 모든 측면에서 벗어날 수 있기 때문에 환상적인 솔루션처럼 보입니다.

Sprint 0은 다른 스프린트와 시간이 같기 때문에 나중에 조정할 수 있기 때문에 설정하는 데 너무 많은 시간을 소비하지 않는 방법으로 작용합니다. 요점은 실제로 제품 개발을 시작할 수있는 상태가되는 것입니다.

2-3 개의 대체 프레임 워크 / 도구 탐색

특별한 요구 사항이있는 경우 이러한 문제가 발생할 수 있습니다. 요구 사항을 해결하기위한 최상의 도구를 선택하기 위해 POC를 수행해야합니다. 어떤 프레임 워크를 사용할지 모르면 스토리를 추정 할 수없고 예상치 않은 상점을 계획하고 작업으로 나눌 수 없기 때문에 이것이 스파이크의 원인입니다.

그런 다음 프로젝트를 위해 선택한 프레임 워크를 학습합니다.

잘. 이것은 매우 위험합니다. 고객이 소프트웨어 비용을 지불하면 도구 사용 방법을 이미 알고있는 전문가라고 생각합니다. 고객은 학습 또는 평가판 / 실패 개발 방법에 대해 비용을 지불하지 않습니다. 여가 시간 이나 직원이 아닌 고객이 지불 한 특별 할당 시간에 새로운 도구를 배우는 것은 개발자의 책임 입니다. 고객에게 알리지 않고 학습을 위해 고객에게 돈을 지출하는 것은 전문가가 아닙니다.

실제로 사용하지 않은 특별한 (예 : 일부 고객의 API 또는 툴 고객)을 사용해야하는 경우 고객에게 API 사용법을 배우는 데 필요한 시간이 지남에 따라 가격이 상승 할 것이라고 알려 주어야합니다. 가격 인상이 너무 클 경우 고객이 마음을 바꿀 수 있습니다.

물론, 여러 번 사용한 프레임 워크에서 특정 새로운 문제를 찾아야하는 상황은 아닙니다. 학습에 많은 시간을 투자하지 않고 새로운 API 또는 프레임 워크를 사용하기 시작하는 상황을 의미합니다.

이를 위반하면 반복마다 비즈니스 가치가 매우 적기 때문에 어쨌든 속도로 볼 수 있습니다. 고객이 이유를 모르는 경우 프로젝트를 취소 할 가능성이 높습니다.

내부 프로젝트의 경우에도 여전히 유효합니다. 새로운 API 또는 도구를 배우는 데 필요한 시간을 관리자 / 비즈니스에 알려야합니다. 관리자가 정상적인 생산성으로 계산하고 작업 중에 배우려는 새로운 API로 인해 생산성이 일부에 불과할 경우 일반적으로 매우 나쁜 결과를 초래합니다. 일부 판매 사원이 고객과 계약을 체결 할 때 정상적인 생산성으로 계산하면 더 나빠질 것입니다.

서버 설정시 (SVN, 데이터베이스 등)

이것이 인프라와 내부 비용입니다. 프로젝트를 시작할 때 인프라가 준비되어 있어야합니다. 개발 환경을 설정하는 것은 고객에게 가치가 없으며 Scrum의 속도와 같은 프로젝트 관련 지표의 일부가되어서는 안됩니다. 환경을 설정하고 기본 인프라를 만드는 데 사용되는 특수 사전 프로젝트 반복으로 구현 된 것을 보았습니다.