코드 검토가 전달 / 테스트주기보다 뒤 떨어짐

14

민첩한 프로세스에는 2 주 스프린트가 있습니다. 작업은 매일 제공되며 (일일 빌드) 테스트 팀은 다음 날 또는 같은 날에 테스트를 완료합니다.

또한 개발자 코드 검토가 있으며 시간이 필요하며 (1-2 시간) 일주일에 3 번, Mon-Weds-Fri로 예약됩니다. 개발자들은 함께 모여 코드를 개선 / 리팩터링하는 방법을 제안합니다.

우리의 문제는 코드 검토 후 작업 항목이 나타날 때까지 대부분의 작업이 이미 테스트 된 것입니다. 테스터는 이미 테스트를 통과 한 내용을 다시 테스트하고 싶지 않습니다. 그들은 내부 개발 변경에 신경 쓰지 않습니다.

우리는 애자일 프로세스를 오해하고 있습니까? 코드 검토가 일일 릴리스 / 테스트주기와 호환되지 않습니까? 코드 검토는 매일 시간이 걸리므로 매일 코드를 검토 할 수 없습니다.

— 유전자 b.
소스

도움이 될만한 몇 가지 제안을 찾았 습니다. Agile Teams의 코드 검토 – 2 부 (빠른 Google 검색에서 찾았습니다.

— Dukeling

1

테스터가 "릴리스 된"작업을 수행하고 있습니까? 팀의 "릴리스 된"정의에 코드 검토 및 작업 항목 해결이 포함됩니까? 아니면 코드 검토가 팀의 완료 정의 외부에서 발생합니까?

— Kent A.

1

테스트 팀에 자동 회귀 제품군이 없습니까?

— Telastyn

5

"코드 리뷰"는 어떻게합니까? 검토자가 전체 품질 측정 항목 (노력 : 여러 사람 시간)의 전체 점검 목록을 수행해야하는 긴 공식적인 프로세스입니까? 아니면 다른 팀원이 코드를 살펴보고 무언가 문제가있는 경우 질문을합니까 (노력 : 코더 및 검토 자의 경우 10-30 분)? 왜 코드 리뷰를합니까? 코드 품질을 보장하려면? 버그를 잡으려면? 여러 사람에게 시스템에 대한 지식을 전파하려면? 코드 검토 메커니즘이 이러한 목표를 달성하는 데 도움이됩니까, 아니면 아무도 관료적이지 않습니까?

— amon

나는 모든 대답을 좋아하지만 중요한 것으로 생각되는 점을 추가하겠습니다. 당신은 애자일을 잘못 해석하고 있는지 묻지 만 어떤 방법론을 말하지 않습니다. Scrum 님을 팔로우하고 계신가요? 가장 중요한 : "완료"의 정의가 있습니까? 나는 그것을 매우 찾기 때문에 묻고있다.. 당신이 실제로 작업을 마치기 전에 "전달 된"것을 고려하고있는 것이 이상하다. 코드 검토와 같은 소리는 바로 "추가"입니다.

— Lorenzo Dematté

8

테스터는 다시 테스트하기를 원하지 않습니다. "코더는 리팩토링을 원하지 않습니다." 그것은 일의 일부입니다. 프로세스는 다음과 같이 복원 될 수 있습니다. 작업이 생성됩니다. 코드가 생성됩니다. 코드가 테스트되었습니다. 코드가 검토됩니다. 코드에서 결함이 발견되었습니다. 이러한 결점을 해결하기 위해 새 작업이 생성됩니다 (예 : 코드 리팩터링). 이러한 새로운 작업에는 새로운 테스트가 필요합니다.

— 남자
소스

2

+1 일일 릴리스 민첩한 방법에서는 작업을 다시 열지 마십시오. 발견 된 문제를 해결하고 팀의 우선 순위에 따라 예약 할 새 작업을 만듭니다. 새로운 작업 = 새로운 QA 작업 (같은 테스트를 다시 실행해야 함). QA가 마음에 들지 않으면 다른 직업이 많이 있습니다.

— Kent A.

그것은 분명히 작동하지만 비효율적 인 것 같습니다.

— usr

7

어떤 시점에서 코드를 검토하려는 경우, 검토를 일찍 수행하는 것이 더 이상 비용이 들지 않습니다. 테스트 프로세스가 비싼 것 같아서 두 번 테스트하고 싶지 않습니다. 따라서 테스트하기 전에 코드를 검토하는 것이 더 저렴합니다. 테스트 후 코드를 검토해도 작업 속도가 빨라지지는 않습니다. 느리게 작성되고 잘못 작성되었지만 성공적으로 테스트 된 코드를 제공하도록 유혹합니다. 시간이 지남에 따라이 검토되지 않은 모든 코드는 작업 속도를 늦추고 느리게 만듭니다. 그런 다음보다 효율적인 경쟁 업체는 적은 비용으로 더 나은 제품을 제공하고 게임을 끝냅니다.

또한 테스트를 자동화하십시오. 수동 테스트는 1970 년이되었습니다.

— 케빈 클라인
소스

5

현재 QA 이전에 코드 검토 를 수행하기 어려운 경우에는 @Dukeling이 게시 한 Part II의 Agile Teams의 코드 검토에서 논의한 것처럼 코드 검토를 더 가볍게 만드는 것을 고려해야 합니다.

코드 검토라고 할 수있는 가장 간단한 것조차도 이점을 얻었습니다. 코드를 커밋하거나 DVCS를 푸시하기 전에 다른 개발자에게 전화하여 변경 사항을 안내하십시오. 5 분에서 10 분 정도 걸릴 수 있습니다. 이 코드 검토의 목표는 "다른 개발자에게 이치에 맞습니까?"입니다. 목표는 디자인 구현을 결정하거나 검토 방법에 대한 검토 자의 개인적인 아이디어를 완전히 따르지 않는 것이 었습니다. 다음과 같은 이점이 있습니다.

코드 작동 방식에 대한 향상된 공유 지식
코드를 설명하는 행위로 인해 저자가 사물을 다시 생각하게 만들 수 있기 때문에 혼란 스럽거나 잘못된 코드가 발견되었습니다.
팀 관용구와 스타일을 점진적으로 발전시키는 데 도움이되었습니다.
팀에서 아주 조금 불평

더 깊은 코드 검토는 문제를 찾기 위해 절대적으로 더 잘 작동합니다. 그러나 가치를 얻으려면 그들에게 행동하고 행동 할 수 있어야합니다. 항상 수행 할 수있는 가벼운 프로세스는 계속 진행되거나 단순히 백 로그에 항목을 추가하는 무거운 프로세스보다 도움이 될 수 있습니다.

— 앨런 셔코
소스

1

이 문제에 대한 한 가지 해결책은 사용자 스토리가 완료되면 다른 피어가 코드를 빠르게 검토하여 코드에 기본적인 / 명확한 실수가 없도록하는 것입니다.

그러나 이것은 테스트주기 전에 발생해야합니다. 그런 다음 모든 팀과 함께 더 많은 검토를 수행하면 테스트 후 코드 변경이 줄어 듭니다.

— 낮은 비행 펠리컨
소스

1

그것의 소리에서 테스터는 테스트가 고통스럽고 비싼 과정이기 때문에 다시 테스트하기를 원하지 않습니다.

개발자와 테스터의 테스트 자동화는 민첩하게 작업하려는 팀에게 큰 보너스입니다. 테스트가 더 저렴하고, 쉽고, 재현 가능할수록 테스트를 더 많이 실행할 수 있으며, 변화에 대한 저항이 줄어 듭니다.

일부 개발자 피드백을 기반으로 빠른 리팩터링을 수행 했습니까? 회귀 / 연기 스위트를 실행하는 큰 빨간색 버튼을 누르고 빠른 수동 작업을 수행하여 잘릴 수있는 시각적 문제가 있는지 확인하십시오. 쉬운!

그런 장소에 있으면 다시 테스트하는 것이 번거롭지 않습니다. 두 번째 성격이 될 것입니다.

— f1dave
소스