애자일 개발의 리팩토링
앱 개발 프로젝트에서 프로젝트의 전체 범위는 앱 디자인에서 고려되지 않았습니다. 따라서 변경 사항을 수용하기위한 코드의 빈번한 리팩토링은 스프린트 중에 필요하게 된 프로젝트 제공 일정에 부정적인 영향을 미치고 있습니다. 이해 관계자가 타협하지 않기 때문에 합의 된 프로젝트 제공 날짜를 초과 할 위험을 최소화하기 위해이를 제어 할 수있는 최선의 방법은 무엇입니까?
답변
TL; DR
모든 프로젝트 관리 프레임 워크의 일부이지만 특히 스크럼과 같은 민첩한 프레임 워크는 이해 관계자의 기대치 를 지속적으로 관리 해야한다는 것입니다 . 사람들은 원할 때 원하는 것을 원하지만 프로젝트 관리의 큰 부분은 프로젝트에 영향을 미치는 다양한 제약 내에서 실제로 가질 수있는 것을 사람들 에게 설명하는 것 입니다. 프로젝트가 발전함에 따라, 특히 실현 가능한 것이 원래 계획된 것과 다를 때 현재의 제약 내에서 현재 가능한 것이 무엇인지 이해해야합니다.
재 작업이 예상됩니다
리팩토링은 외부 동작을 변경하지 않고 구현을 변경합니다. 모든 가능성에서, 당신은 실제로 리팩토링하지 않습니다. 본질적으로 동일한 것이 아닌 기술적 부채를 갚거나 재 작업 및 통합을 수행하고 있습니다.
Scrum과 같은 프레임 워크는 다양한 유형의 작업 (리팩토링 및 재 작업 포함)을 경험적 제어 및 설계에 대한 허용 가능한 절충점으로 취급합니다. 이것은 추정 프로세스에서 처리되며 (올바르게) 기술 부채, 복잡성 또는 변화 속도가 증가함에 따라 속도에 대한 문제로 나타납니다. 이는 둘 모두 예상 하고 바람직 각 적응 검사 및 루프가 변경 범위, 우선 순위, 또는 접근 할 수있는 기회를 제공하기 때문에, 반복적 인 프레임 워크이다.
재 작업은 경험적 제어 비용입니다. 소프트웨어 개발과 같은 복잡한 프로젝트에서는이를 피할 수 없습니다. 스크럼은 재 작업 을 팀과 이해 관계자가 필요하거나 바람직한 변경 비용으로 볼 수 있도록합니다.
고정 된 모든 것은 불가능하다
"철 삼각형"은 예산, 범위 또는 일정을 제어하여 프로젝트를 조정할 수 있으며 다른 세 개의 슬라이더에 의해 영향을받는 암시 적 4 차원 품질을 제공합니다. 다음 그래픽은이를 설명합니다.
Scrum과 같은 애자일 프레임 워크는 일반적으로 범위, 특히 프로젝트 범위 를 기본 슬라이더로 취급합니다.
단일 스프린트의 타임 박스에 얼마나 많은 범위를 포함 할 수 있습니까? 아니면 애자일 릴리스 계획에 어느 정도 맞출 수 있습니까?
현재 프로젝트에서 범위와 일정을 모두 수정하려고합니다. 사용 가능한 슬라이더로 예산 만 남습니다. 이를 잠그려고 시도하면 프로젝트가 실패하거나 품질이 저하되거나 둘 다에 영향을받습니다. 당신은 간단하게 할 수 없습니다 안정적으로 고정 가격, 고정 범위, 고정 스케줄을 어떤 품질을 유지하면서 프로젝트의 프레임 워크; 스크럼은 단순히 그것을 더 분명하게 만들고 장단점을 더 잘 보이게 만듭니다.
스크럼의 요점은 철의 삼각형을 마법처럼 사라지게 만드는 것이 아닙니다. 대신 프로젝트 (이해 관계자 및 후원자 포함)가 내재 된 절충안을 받아들이도록합니다. 스크럼을 사용하면 이해 관계자가 각 스프린트가 끝날 때 배송하기에 "충분한"것이 있는지 판단 할 수 있으며 제품 소유자는 백 로그 수정 및 스프린트 계획 중에 범위와 우선 순위를 조정할 수 있습니다. 이해 관계자는 릴리스 계획 내에서 실현 가능한 최대 가치를 얻을 수 있도록 이러한 이벤트를 활용해야합니다. 고정 된 스프린트 시리즈가 끝날 때 프로젝트가 100 % 완전하거나 목적에 적합하다는 것은 환불 보장 이 아닙니다 .
매몰 비용 감소
애자일 개발의 또 다른 측면은 "일찍 실패"할 수있는 기회입니다. 어떤 이유로 든 프로젝트가 실패 할 가능성이있는 경우 Scrum과 같은 애자일 프레임 워크는 제품 소유자에게 Sprint를 취소하고 변경된 기대치를 기반으로 새로운 것을 계획하거나 이해 관계자가 프로젝트의 나머지 부분을 취소 할 수있는 기회를 제공합니다. 그들의 목적에 부합하지 않을 것입니다. 후자는 프로젝트를 성공시키지 못하지만 프로젝트와 관련된 매몰 비용을 줄일 것입니다.
누구도 프로젝트의 성공을 보장 할 수는 없습니다. 당신이 할 수있는 최선은 그것을 통제하고 성공이 더 이상 선택 사항이 아닐 때 가능한 한 빨리 파멸 된 프로젝트를 죽이는 것입니다.
지금 할 수있는 일
먼저, 당신이 죽음의 행진으로가는 길에 있다는 것을 인정하십시오. 당신이 그 진실을 직시하지 않는다면, 당신이하는 다른 일은 아무것도 중요하지 않을 것입니다.
다음으로, 문제가 디자인인지, 기술 부채인지, 부당한 기대인지 아니면 다른 것인지 파악하십시오. 근본 원인이 무엇인지는 중요하지 않습니다. 팀과 이해 관계자가 공동으로 문제를 해결할 수 있도록 표시하기 만하면 됩니다.
마지막으로 현재 상태를 명확하게 전달 하십시오. 원래 예정된 납품 일로부터 몇주기가 지난 후 완전한 기능을 갖춘 릴리스를 준비하고 있다면 프로젝트가 "시간"정점을 조정할 수 있는지 여부를 논의하십시오. 일정을 조정할 수 없거나 조정할 수없는 경우에도 비용을 늘리거나 범위를 줄임으로써 고정 된 기한을 맞출 수 있습니다. 이해 관계자가 시간이 많이 걸리는 기능을 줄이기 위해 정시 납품을 거래할까요? 물어 보지 않으면 알 수 없습니다.
프로젝트가 위의 작업을 수행 할 수 없거나 수행하지 않을 경우 실패에 대비하십시오. 이력서를 작성하고 다음 프로젝트 또는 다음 작업에 사용할 수있는 귀중한 교훈을 얻었기를 바랍니다. 무엇보다도, 가정, 과제, 프레임 워크 요구 사항 및 절충 사항에 대해 초기에 자주 의사 소통하는 방법을 배우고 이해 관계자 기대치를 지속적으로 관리하는 것의 중요성을 내면화하기를 바랍니다.
스프린트마다 배포 가능한 증분 제품을 생산하고 있습니까? 그렇다면 합의 된 배송 날짜가 이미 충족되고 있으며 이것이 위험을 최소화하고 고객이 수행중인 작업에 대한 확신을주는 가장 좋은 방법입니다. 이해 관계자 (제품 소유자를 통해)는 원하는 것을 언제 원하는지 결정해야하므로 가장 중요한 것은 계속해서 가치를 제공하고 제품에 필요한 개선, 변경 및 수정에 대한 피드백을받는 것입니다. 피드백을받는 것이 여기서 핵심입니다. 타임 라인은 새로운 기능 범위로 확장하지만 곧 최신 개선 사항 등을 시작으로하는 것이 경우 고객은 당연히 해당 될 수 그들은 우선 순위로보고 그들이 유연성의 필요성을 인식 할 가능성이있을 것입니다.