이것은 내가 일하는 논점의 포인트 인 것 같습니다. 어떤 이들은 스크럼 프로젝트의 검증 구조의 부족에 대해 불평하지만, 스크럼의 순수 주의자들은 스크럼에 관한 것이 아니라고 말합니다. 양쪽 모두 좋은 점이 많지만, 내 원 밖에는 사람들이 그 주제에 관해 무엇을 말하고 있는지보고 싶습니다. 당신의 생각은 무엇입니까? 왜?스크럼 프로젝트에서 테스트 및 동료 검토가 각 스프린트에 개별 작업으로 수행되어야합니까?
스크럼 프로젝트에서는 수행해야 할 모든 작업을 작업으로 입력해야합니다.
스크럼의 핵심 포인트 중 하나는 팀이 스프린트에서 수행 할 수있는 것을 정확히 예측할 수 있다는 것입니다. 이를 위해서는 개발자의 시간을 소비 할 모든 것을 고려해야합니다.
이것은 문서 작업, 테스트 및 동료 검토와 같은 작업을 모두 작업으로 고려해야한다는 것을 의미합니다.
편집 : 멘델 트 (Mendelt)의 게시물을 바탕으로 조금 더 명확하게 설명 할 것입니다. Wikipedia에서
:
제품 백 로그 : 제품 백 로그는 전체 프로젝트에 대한 높은 수준의 문서입니다. 여기에는 필요한 모든 기능, 위시리스트 항목 등의 광범위한 설명이 포함되어 있습니다. 작성되는 것은 "무엇"입니다. 누구든지 공개하고 편집 할 수 있습니다. 대개 일 내에 대략적인 견적을 포함합니다. 이 예상치는 제품 소유자가 타임 라인을 측정하고 제한된 범위에서 우선 순위를 정하는 데 도움이됩니다 (예 : '맞춤법 검사 추가'기능이 3 일 또는 3 개월로 예상되는 경우 제품 소유자의 희망에 영향을 미칠 수 있음).
스프린트 백 로그 : 스프린트 백 로그는 앞으로 나올 스프린트에 대한 요구 사항을 구현하는 방법에 대한 정보가 담긴 매우 상세한 문서입니다. 작업은 16 시간을 넘지 않는 작업으로 몇 시간으로 나뉩니다. 작업이 16 시간을 초과하면 더 이상 세분화해야합니다. 스프린트 백 로그의 작업은 할당되지 않으며 오히려 팀 구성원이 원하는대로 작업을 등록합니다.
문서 또는 테스트 등을 표시하지 않습니다 제품 백 로그의 항목 만 가장 확실해야 스프린트 백 로그에 작업.
예를 들어 보겠습니다. 제품 백 로그에 "Feature A"가 있으며 예상 소요 시간이 1 주라고 가정합니다.
Initial design document: 4 hours Development of subset 1 of Feature A: 8 hours Peer review of subset 1 of Feature A: 2 hours Testing of subset 1 of Feature A: 6 hours Development of subset 2 of Feature A: 8 hours Peer review of subset 2 of Feature A: 2 hours Testing of subset 2 of Feature A: 6 hours User Documentation for Feature A: 4 hours --------------------------------------------- Total time 40 hours
편집 # 2 : 스프린트 백 로그의 뒤에 아이디어는 당신이 당신의 시간을 낭비 할 필요가 정확한 위치에 대한 특정 인간적으로 가능합니다 스프린트 백 로그에, 그 다음 작업으로 분할 될 수있다 . 이 때문에 작업 시간이 16 시간을 초과 할 수 없으며 일정 예측에서 매우 안정적 일 수 있습니다.
당신이 종교적으로 스프린트 백 로그의 지침을 따르십시오 그리고 당신은 당신이 당신의 예약이 연습의 몇 달리기 후에 할 수있는 방법을 정확하게에 놀랄 것입니다에 개발 시간을 보내고 모든을 포함해야합니다.
나는 전체적으로 진심으로 동의한다. – Kilhoffer
지금 동의합니다. 제 대답은 제품 백 로그에 넣은 것에 기반했습니다. 내 (혼란스러운) 답변을 삭제하고 명확한 답변을 다음과 같이 변경했습니다 .- – Mendelt
이 수준의 세부 정보가 항상 필요합니까? 예를 들어, 커밋 전에 코드를 피어 리뷰 한 문화권에서는이를 별도의 항목으로 캡처 할 필요가없는 것으로 보입니다. 엔지니어링 관행을 둘러싼 문화가 아직 그와 같은 시점으로 진화하지 않은 새로운 팀에서 필요하다는 것을 알 수 있습니다. TDD 및 자동 피어 검토가 뿌리깊은 이유가없는 한 여분의 오버 헤드처럼 보인다. – mch
작업으로 명시 적으로 입력하지 않으면 작업이 수행되지 않을 수 있기 때문에해야합니다. 저것과 같이 쉬운.
수평 층이 아닌 수직면을 생각해보십시오. 당신이 개발 케이크에서 층로 등 디자인, 프로그래밍 및 단위 테스트, 테스트를 고려하면
, 난 당신이 각각의 구성, 당신은 케이크 조각으로 제공하는 기능 (이야기를) 볼 수있는 것 같아요 작은 조각의 디자인, 코드, 테스트, 성능 등이 있습니다. 이것은 Pragmatic Programmer의 "추적 총알"과 같습니다.
스크럼 이전에는 버전 관리에 커밋하기 전에 코드 검토가 포함 된 폭포 개발 패러다임을 따랐습니다. 스크럼 (scrum)으로 옮겨온 이후, 우리는 개발 스토리에 암시 적이므로 코드 리뷰를위한 별도의 태스크를 할당하지 않습니다.
스크럼에 내장 된 주요 확인 구조 중 하나는 제품 소유자가 이야기를 수락해야한다는 것입니다. 팀은 비즈니스 가치 제공에 기반한 속도에 대해서만 신뢰를 얻습니다.
스크럼 팀의 공통 도구는 제품 백 로그 항목 (종종 이러한 백 로그 항목은 사용자 사례의 형태로 제공됨)에 대한 승인 테스트를 정의하는 것입니다.
당신이 팀은 높은 품질의 제품을 제공하는 데 사용할 것입니다 무엇 엔지니어링 관행의 질문에 대답 할 필요가 스크럼 팀으로 함께 앞으로의 일환으로. 스크럼 자체는 이러한 관행에 대해 조용합니다. (나는 더 나은 방법을 배우면서 이러한 관행이 시간이 지남에 따라 진화 할 수 있도록 의도적으로 생각합니다.)이 사례는 종종이가 할 수 뭔가 무엇을 의미하는지의 팀의 정의의 일부가 등 단위 테스트, 페어 프로그래밍, 동료 평가, 같은 것들을 할 수있다. 팀이 견적을 작성하거나 완료하는 데 어려움을 겪고 있다면 스프린트 백 로그에서 작업으로 호출하는 것이 도움이 될 수 있습니다. 내 권장 사항은 프로세스를 경량으로 유지하는 것입니다. 모든 작은 일을 부르지 않아도됩니다 (단, 견적에서 일상적인 항목을 수행하는 데 소요되는 시간을 고려해야합니다).
프로그래밍에 관한 것이 아니기 때문에이 질문을 주제로 끝내기로했습니다. –