는 개폐 된 경우처럼 보입니다.
코드 동결은 유물입니다. 엄밀한 폭포 방법론이 제품 개발과 방출을 위한 유일한 선택권을 제안한 일에서 먹다 남는. 버그 및 기타 기능적 문제를 테스트하기 위해 생산 중지 및 릴리스 지연이라는 전체 개념은 현대적이고 민첩한 제품 관리에는 적합하지 않습니다.
적어도 그것은 많은 민첩한 전문가들 사이에서 합의 된 견해 인 것 같습니다.
그러나 그것은 유지합니까? 코드 정지를 민첩한 제품 관리에 통합하는 것에 대한 가장 일반적인 주장의 표면을 긁으면 여전히 고풍스럽게 보일 것입니까?
이 작품에서는 애자일 제품 관리에 코드 얼기를 통합하는 것에 대한 세 가지 주요 주장을 살펴보고,이러한 논쟁이 무너지는 곳을 분석해 보겠습니다.이 모든 것은 애자일 제품 관리에 코드 얼기를 통합해야하는지 여부에 대한 더 나은 결정을 내릴 수 있도록 도와줍니다.
인수 1: 코드 정지는 관련이 없으며 불필요한
이 인수는 매우 간단하고 구체적입니다.
피어 코드 검토,쌍 프로그래밍 및 시스템 상태의 지속적인 모니터링과 같은 민첩한 방법론을 통해 응용 프로그램 또는 기능이 개발되는 동안 성능을 훨씬 더 잘 파악할 수 있습니다. 버그 및 문제는 개발 과정에서 더 쉽고 가능성이 높으며 전용 테스트 및 품질 보증 활동 전에 해결됩니다.
새로운 도구도 많은 테스트를 자동화했습니다. 그들은 항상 깨끗하고 생산 준비가되었는지 확인하기 위해 코드를 지속적으로 평가합니다. 문제는 실시간으로 식별되고,경고는 즉시 최대한 빨리이를 해결하기 위해 발송됩니다. 자동화 된 테스트의 수는 이미 광범위하고 지속적으로 증가하여 수행해야하는 수동 테스트의 양이 크게 줄어 듭니다.
이러한 새로운 민첩한 방법론과 도구의 결과는 쉽게 알 수 있습니다. 코드 동결 중에 수행되는 대부분의 핵심 테스트 및 품질 보증 활동은 개발 중에 수행되거나 소프트웨어에 의해 수행됩니다. 애자일에서는 소프트웨어 및 기능이 예전보다 훨씬 높은 수준의 신뢰로 개발을 종료하여 전용 코드가 고정되는 것을 정당화하기가 점점 더 어려워졌습니다.
인수 2:코드 정지 핵심 애자일 원칙
이 두 번째 인수는 조금 더 높은 수준입니다. 기본적으로 코드 동결은 애자일 방법론의 핵심 원칙 중 하나 인 개발과 릴리스 사이의 시간을 줄이기 때문에 애자일 방법론에 집이 없다고 주장합니다.
애자일에 대한 접근 방식이 세련될수록,이 시간 창을 더 축소하려고 노력할 것입니다. 현재 애자일에 대한 가장 세련된 접근 방식은 지속적인 통합과 지속적인 개발이며,가능한 한 빨리 코드 변경 사항을”해제”하기 위해 개발을 작고 점진적인 변경으로 나누는 것을 목표로합니다. 새로운 코드는 거의 완료되는 즉시 응용 프로그램에 통합됩니다.
반면 코드 정지를 배포하려면 고유한 개발 및 릴리스 단계를 유지해야 합니다. 코드 동결이 사는 곳 결국,그건-에서 그 두 가지 단계 사이. 대부분의 애자일 방법론처럼 개발 및 릴리스 사이의 시간을 최소화하거나 제거하는 대신 코드 정지로 인해 개발 및 릴리스 일정을 구축해야 하는 지점까지 이 창을 공식화해야 합니다.
코드 정지가 핵심 애자일 원칙과 일치하지 않으면 여전히 방법론에 속한 사례를 만드는 것이 어렵습니다.
인수 3:코드 정지 속도가 느린 낮은 품질의 릴리스로 이어질
이 마지막 인수는 큰 하나이며,그것은 몇 가지 다른 각도를 포함한다.
시작하려면 코드 정지가 로드맵에 많은 복잡성과 추가 움직이는 부분을 추가하고 자연스럽게 무언가가 잘못되어 타임 라인에서 벗어날 가능성을 높여 준다고 주장합니다. 아무 것도 잘못되지 않더라도 코드 정지와 관련된 작업은 시간이 많이 걸리고 예측할 수 없으며(어떤 버그를 발견할지 또는 문제를 해결하는 데 얼마나 걸릴지 모르기 때문에)로드맵에 코드 정지를 추가하는 것만으로도 개발 및 릴리스 주기가 느려집니다.
다음으로 코드 정지가 개발 팀의 생산성을 떨어 뜨릴 것이라고 주장합니다. 코드 정지는 개발자가 미리 정의된 간격으로 작업을 중지하도록 강제합니다. 이렇게 하면 가장 생산성이 높은 흐름을 찾고 유지하는 대신 리듬을 깨고 코드 고정 정책을 해결하도록 강요할 수 있습니다.
마지막으로,비즈니스 요구 사항 수신을 중지하는 전용 창을 만들면 릴리스의 기능과 기능이 동결 전에 완료 될 수있는 것으로 제한되어보다 품질이 낮고 포괄적 인 소프트웨어 및 응용 프로그램으로 이어질 것이라고 주장합니다.
코드 정지 사례 만들기:지는 전투?
이 시점에서 여전히 민첩한 방법론에 코드 정지를 포함시키려는 사람에게는 꽤 황량 해 보입니다. 이 연습을 비방하는 사람들은 매우 설득력있는 주장과 현대적인 애자일 방법론의 개발 이후 코드 동결이 된 전반적인 견고한 사례를 만듭니다:
그러나 이러한 주장은 설득력 있고 정확한 정보를 많이 포함하고 있지만 방탄이 아닙니다. 그리고 애자일 제품 관리의 유용한 요소로 코드 동결에 대한 책을 닫기 전에 논의 할 필요가 각각의 내 근본적인 결함이있다.
인수 1 의 문제점:자동화 된 테스트는 포괄적 인 것이 아닙니다
자동화 된 품질 보증 및 애자일 개발 관행은 코드의 품질을 향상 시켰습니다. 그러나 코드 조각이 단위 테스트를 통과했다고해서 실제로 생산 준비가되었음을 의미하지는 않습니다. 회귀 테스트와 같은 중요한 단계를 항상 포함하는 것은 아닙니다. 코드 조각이 프로덕션 환경에 있는 동안 테스트 및 해결할 수 없는 몇 가지 사항이 있습니다.
코드 정지를 사용하기로 선택한 경우 자동 품질보증 및 민첩한 모범 사례의 이점을 포기하지 않을 것입니다. 당신과 당신의 팀은 단순히 당신의 새로운 소프트웨어 또는 기능의 전반적인 안정성과 신뢰성으로,당신의 동결 동안 더 큰,더 높은 영향 문제를 포착에 초점을 데크를 삭제,생산 동안 코드의 작은,더 사소한 문제를 잡을 것입니다.
인수 2 의 문제점:
“제거”가 아닌”감소”애자일은 개발과 릴리스 사이의 시간을 줄이기 위해 설계되었습니다. 하지만 이 창을 줄이려고 하는 것과 완전히 없애려고 하는 것 사이에는 큰 차이가 있습니다. 이렇게하면 다음-투-불가능,특히 큰 프로젝트에 대한 것입니다.또는 다른 브랜치에서 개발이 계속되는 동안 특정 브랜치에만 적용될 수 있지만 여전히 존재합니다. 애자일이 얼마나 세련되었든,모든 개발 및 릴리스 로드맵에서 새로운 소프트웨어 또는 기능이 실제 사용자에게 전달되기 전에 고정된 상태로 평가되는 지점은 거의 항상 있을 것입니다.
인수 3 의 문제점: 속도 및 품질 재검토
코드 정지를 사용하는 경우 개발 및 릴리스 주기에 새 단계를 추가합니다. 그것에 대해 의심의 여지가 없습니다. 그리고 모든 프로세스에 새 단계를 추가할 때마다 해당 프로세스의 속도를 늦추고 새로운 잠재적인 오류 지점을 만듭니다. 코드 동결도 예외는 아닙니다.
그러나 한 걸음 물러서서 둔화와 생산성 손실에 대한 더 넓은 시각을 갖는 것이 중요합니다.
기능에 버그가 있는 경우 코드 동결 중에 해당 버그를 발견했는지 또는 릴리스 이후에 알려졌는지에 관계없이 해당 버그를 수정해야 합니다. 순수한 개발 관점에서 볼 때,이를 수정하는 데 필요한 시간은 두 시나리오 모두에서 거의 동일합니다.
그러나 라이브 환경에서 버그를 다루는 경우 다음을 포함하여 처리 할 시간이 필요한 기타 문제가 있습니다:
- 버그 기능을 롤백 또는 라이브 떠날 것인지 여부를 결정.
- 개발자가 작업을 시작한 후 새 프로젝트에서 벗어납니다.
- 버그의 영향을 받은 실제 사용자들에게 전달.
- 당신의 문제가 릴리스에 대해 너무 행복하지 않은 내부 이해 관계자에 응답하고 관리.
목록이 계속됩니다. 깨진 기능이나 제품을 출시하는 것보다 귀하와 귀하의 팀을 위해 생산성에 더 복잡하고 시간이 많이 걸리고 파괴적인 것은 없습니다. 코드 정지는 이러한 발생 가능성을 최소화합니다.
그리고 그들은 당신이 수집 할 수있는 비즈니스 요구 사항의 양을 줄이기 때문에 코드가 낮은 품질의 기능과 제품으로 이어질 정지 인수에 관해서는? 귀하의 비즈니스 요구 사항은 항상 귀하의 제품 또는 기능이 어떻게 작동해야하는지에 관해서는”최선의 추측”보다 조금 더 많을 것입니다. 가장 중요한 요구 사항은 항상 실제 시나리오에서 제품 또는 기능을 배포하는 실제 사용자가 제공합니다. 또한 사용자에게 가능한 한 유동적으로 버그 없이 배포할 수 있는 기능 릴리스를 제공하여 이러한 요구 사항만 수집할 수 있습니다.
애자일 제품 관리에서 코드 정지를 활용해야합니까?
궁극적으로 코드 정지는 많은 민첩한 제품 관리자에게 여전히 중요한 역할을합니다.
이제 덜 중요한 역할을하는 경우가 있습니다. 매우 작은 프로젝트에는 전용 코드 동결 기간이 필요하지 않을 수 있습니다. 그들이 불완전하게 발송하는 경우에 상대적으로 작은 결과가 있는 새로운 특징은 동결의 값이 있는 이지 않을지도 모르지 않았다. 카나리아 릴리스와 같은 단계적 릴리스 계획에 대해서도 마찬가지입니다-버그가 있고 불완전한 경험을 기대하는 따뜻한 청중과 함께 새로운 기능을 테스트 할 때.
그러나 대부분의 경우,새로운 기능이 가장 중요한 사람들,즉 실제 사용자의 손에 넣기 전에 새로운 기능이 완벽하다는 것을 확인하는 데 시간이 걸릴 가치가 있습니다.
이 기사는 처음에 게시되었습니다.flagship.io
