릴리스 열 동안 효율적인 코드 검토를 수행하는 방법은 무엇입니까?

릴리스 마감일은 내일이며, 동료가 마침내이 릴리스에 중요한 작업을 완료했으며, 프로젝트 관리자가 어깨 너머에 서서 최종적으로 빌드하도록 압력을 가하며 검토하는 동안 동료 코드의 결함을 발견했습니다. 중요한 것은 아니지만 내일 출시되지 않으면 놓치지 않을 것입니다. 그리고 상황을 악화시키기 위해서는 최대한 빨리 끝내야 할 일이 있습니다. 그래서, 당신은 무엇을합니까? 압박에도 불구하고 이의를 제기합니까?

내가 찾은 한 가지 방법은이 커밋을 다른 지점에 일시적으로 병합하고 나중에 검토를 남기는 것입니다. 문제가 단지 외관상의 문제이고 여전히 코드 검토를 기다리는 유일한 문제인 경우 작동합니다. 그러나 이것을 처리하는보다 효율적인 방법이 있습니까? 예를 들어 한 사람이 코드 검토 및 테스트 만 수행하도록 권유 하시겠습니까?

대답은 여기에 있습니다.

1. 기술 / 팀장에게 문제에 대해 알리십시오.
2. 잠재적 영향에 대해 품질 관리팀에 문의
3. 프로젝트 관리 담당자 (바로 뒤에있는 사람)에게 릴리스가 지연 될 수있는 문제가있을 수 있으며 최대한 빨리 (몇 분 또는 몇 시간 안에) 복구 할 수 있다고 알려주십시오.
4. 이 문제가 릴리스의 쇼 스토퍼인지 평가

문제가 쇼 스토퍼가 아닌 경우 릴리스를 계속하십시오. QA 및 사용자에게 문제를 알리고 문제가 해결 될 후속 날짜를 약속합니다. 이것은 생산에 또 다른 위험이된다.

이 경우 입니다 쇼 스토퍼 (는 결론이나 사람의 건강에 부정적인 영향을 줄 것입니다 의미) 회원님의 추천 출시를 지연 이유를 이야기하는 것입니다 체인까지이 통신합니다. 그런 다음 개발자에게 연락하여 문제를 해결하는 데 걸리는 시간을 알아 내고 X 분 / 시간 / 일이 필요하다고 관리자에게 알립니다.

경기 후반에 쇼 스토퍼에 대해 경영진이 기뻐하지 않을 것이지만, 프로덕션에서 출시되기를 원하지는 않을 것입니다.

의사 소통하고 의사 소통을하게합니다.

문제를 전달하지 말고 문서화하십시오

지금까지 다른 답변에 대한 나의 큰 관심 : 임박한 마감 기한에 직면 한 전형적인 프로젝트 관리자 에게이 라인을 따라 말하는 것은 무시되거나 잊혀 질 것입니다. 그런 다음 문제가 발생하면 위험 을 충분히 전달 하지 못하고 여전히 위험에 빠질 수 있습니다.

발견 한 문제에 대해 프로젝트 관리자에게 알리고 문서화 할 것이라고 알려 주십시오. 당신은 당신의 실사를 가리킬 수 있어야합니다.

문서화 할 위치와 담당자는 작업 환경에 따라 다르지만 보스를 반드시 포함 시키십시오.

위험 과 영향 식별

문제가 중요 하지 않다고 말하지만 그 의미를 실제로 정의하지는 않습니다. 그것을 플레 싱하는 것은 다음 단계입니다.

문제를 식별 하는 빠른 위험 및 영향 분석 , 문제를 일으킬 가능성 (위험) 및 위험이 실현 될 경우 그 결과의 심각도 (충격). 위의 링크에서 찾은 것과 같이 잘 정의 된 용어 (프로젝트 관리자가 알아야 함)를 사용하고 분석을 뒷받침하는 설명을 제공하십시오.

문서에는 권장되는 행동 과정 도 포함되어야 합니다. 예 , 우려 사항을 제기하고 릴리스를 진행하는 것이 좋습니다. 위험 을 식별하는 것이 맞습니다 .

다음 릴리스는 언제입니까?

위험 / 영향 분석을 완료 한 후에도 여전히 권장 할 사항이 결정되면 릴리스 일정을 고려하십시오. 2 주 내에 수정 프로그램을 포함시킬 것으로 예상되는 경우 일부 불완전한 코드를 해제해도됩니다.

문제를 해결하는 것이 "우선 순위"가 될 가능성이있는 경우 (즉, 다음 번의 개선을 위해 무시되는 경우), 문제를 발견 한 후 가능한 빨리 문제를 문서화해야하는 또 하나의 이유입니다. 문제에 대한 시계.

이 경우 모든 사람에게 알리고 결정하게하십시오. 아마도 여러분이 처음 발표 한 버그가 아닐 것입니다.

마감일은 내일이지만이 상황에서 자신을 찾으십시오.

프로젝트 관리자가 어깨 너머에 서서 최종적으로 빌드를하도록 압력을가합니다.

이것은 예외 일 수 있으므로 하나의 버그가 발생하여 프로세스를 크게 변경하지 마십시오. 당신이해야 할 일은 몇 가지 조치를 취해 마지막 순간에 빌드를하지 않는 것입니다. 바라건대, 당신은 그것이 성공할 것이라는 확신을주기 위해 정기적으로 충분한 빈도로 빌드하고 있습니다. 그것은 여전히 ​​마지막 순간에 그들을 실행할 충분한 이유가 아닙니다. 일을 잘 테스트하는 것은 자신감을 높이는 또 다른 부분입니다.

이 일을 이끌고있는 사람에게이 시나리오를 제시하십시오.

• 어떤 유형의 문제를 제시해야하는지 결정하십시오.
• 옵션을 식별하십시오.
• 누가 결정을 내리는가
• 이 모든 것이 언제 결정되어야합니까? 아마도 출시일에 상대적 일 것입니다.

이것이 마지막 순간의 문제로 무엇을해야하는지에 대한 답은 아니지만, 앞으로 문제를 해결할 수있는 방법을 제공합니다. 특히 해방의 압력이있을 때, 당신은 감정에 의해 생각되지 않고 생각하는 방식으로 물건을 다루는 방법을 원합니다.

기한이 있고 관리자가 어깨 너머로보고있는 바로 뒤에 있다면, 그에게 떠나라고 말하십시오. 그는 사라지거나 당신은 떠납니다. 압력을 받아 강제로 검토하면 코드를 검토하지 않을 수도 있다고 설명합니다.

이와 같은 상황에서는 치명적인 버그가 발생할 수 있습니다.

Apple의 App Store에 제출하는 것과 같은 운이 좋은 상황 일 수 있습니다. 여기서 새 버전을 철회 할 며칠이 있습니다. 그러나 코드가 고객에게 제공되는 경우 이는 재난의 요리법입니다. 다음에는 관리자가 더 잘 계획하기를 바랍니다.

다른 답변은 품질 프로세스를 구부리려는 관리자의 문제에 중점을 둡니다.

그러나 내가 생각하는 것은 코드 검토에 최소 2 명이 필요하다는 사실을 처리하는 방법이므로 상당한 지연이 발생합니다. 예를 들어, 작업을 구현하는 데 2 ​​시간이 걸리고 검토하는 데 2 ​​시간이 걸리는 경우 종종 두 활동간에 시간이 오래 걸립니다. 실시간으로 작업을 완료하는 데 2 ​​~ 3 일이 소요될 수 있습니다.

이는 처리량 대 대기 시간의 고전적인 문제입니다. 소프트웨어 생산 기계 (인간) 컨텍스트 스위치는 비싸므로, 누군가의 작업을 즉시 검토하는 것을 선점하는 것이 일반적인 관행이되어서는 안됩니다.

다음은 문제를 완화하기위한 몇 가지 팁입니다.

• 작업을 수행하는 동안 검토자가 긴 연속적인 시간을 예약 할 필요가 없도록 작은 부분으로 코드를 보냅니다.
• 코드 검토에 우선 순위가 높은 문화를 홍보하십시오. 요청을받을 때 현재 작업 단위를 중지하지 말고 다음에 수행 할 작업이 궁금 할 때는 항상 대기열에서 검토를 선택하십시오.
• 팀의 시간대 차이가 있으면 활용하십시오.
• 한 사람 만 코드 검토 만하도록 커밋하지 마십시오. 설득력이 있습니다. 그는 자신의 작업에 대해 진지하게 생각한다면 부하를 처리 할 수 ​​없습니다. 관리자는 누군가 유휴 상태라는 아이디어를 받아들이지 않고 하루를 절약 할 수 있습니다.