최근 스크럼 프로세스로 전환하여 스프린트 내에서 작업 및 사용자 스토리를 작업하고 있습니다. 우리는 코드 검토를 자주 수행하여 덜 까다롭게 만들려고합니다. 우리는 그것들을 사용자 스토리 수준에서 수행한다고 생각하고 있지만 이것을 설명하기 위해 코드를 분기하는 방법을 잘 모릅니다.
우리는 VS와 TFS 2010을 사용하고 있으며 6 명의 팀입니다.
현재 기능으로 분기하지만 스크럼의 분기로 변경하기 위해 노력하고 있습니다.
현재 선반 세트를 사용하지 않으며 사용 가능한 다른 기술이있는 경우 실제로 구현하고 싶지 않습니다.
사용자 스토리 당 코드 검토를 어떻게 구현하도록 권장합니까?
답변:
사용자 스토리의 특성에 따라 다릅니다.
각 사용자 스토리에 대한 브랜치를 생성하는 것이 효과적 일 수 있으며, 다른 스토리에 대한 진행률이 표시되며, 필요에 따라 전달 될 수 있으며, 스프린트에서 스토리가 완료되지 않은 경우 다음 스프린트를 위해 브랜치에서 진행 상태를 유지할 수 있습니다. . 그런 다음 사용 스토리 분기의 사용자 스토리 끝에서 최종 검토를 수행하고 코드가 표준 인 경우 병합 할 수 있습니다.
방식대로 작업하려면 스프린트 종료시 관리 할 수없는 병합 작업을 방지하기 위해 스토리를 세분화해야합니다. 작은 스토리는 다른 사용자 스토리를 작업하는 개발자가 지속적으로 가져와야하는 스프린트 (기본 VCM)를 통해 dev 분기를 꾸준히 업데이트 할 수있게합니다.
이로 인해 브랜치를 지속적으로 생성하고 병합해야하는 프로세스 오버 헤드가 발생하며 일부 경우 자동화 스크립트로 해결할 수 있지만 팀은 여전히 VCS에 매우 익숙해야합니다.
스프린트가 끝나면 개발자 브랜치를 통합 / 프로덕션 등으로 병합합니다.
또한 모든 사람이 하나의 개발 지점에서 일하는 팀에서 근무했으며 사용자 스토리를 완료하면 코드가 해당 지점으로 푸시되어 검토 및 테스트되며 누군가가 개발 빌드를 방해하는 무언가를 푸시하면 팀 맥주를 가져와야합니다.
코드를 검토하는 가장 효과적인 방법은 일어 서서 누군가를 찾은 다음 방금 개발 한 코드에 대해 토론하도록 요청하는 것입니다.
코드를 로컬에서 검토 할 사람을 찾을 수 없으면 도구를 사용하지 마십시오.
페어링하여 코드 검토를 피할 수 있습니다.
코드 검토는 SCRUM의 공식적인 부분이 아니라고 생각하지만, 개정은 품질을 달성하고 프로젝트 / 팀을 개선하기위한 독립적 인 전술입니다.
따라서 SCRUM (또는 기타 민첩한 개발 방법론)을 사용하여 PROJECT 품질을 보장 / 향상시키고 일정을 지키십시오. 또한 일반적인 QA / 테스트 작업에서 제품 수정 (코드가 아님)을 독립적으로 수행하는 것이 좋습니다. 이 활동을 팀 / 파트너 / 클라이언트 / 청중 앞에서 수행 할 수 있다면 더 좋습니다.
TEAM을 개선하기 위해 주로 중 / 장기 결과를 기대하는 코드 (또는 기타 특정) 개정판을 사용해야합니다. 이것은 프로젝트에 영향을 주지만 장기적으로 TEAM 개선의 결과물입니다.
따라서 귀하의 질문에 대답하기 위해, 나는 당신이 스크럼에서 너무 많은 것을 추진하려고한다고 생각하며, 수정은 그대로 유지하는 것이 좋습니다.
코드를 체크인하기 전에 코드 검토를 수행하는 것이 분명하지 않습니까?
TFS는 GIT처럼 작동하지 않으므로 지점이나 트렁크에 코드를 체크인 할 때마다 누구나 사용할 수 있습니다.
즉, 체크인시 검토가 이루어져야 변경 사항이 모든 작업 사본에 전파되지 않습니다.