애자일 프로젝트 관리의 소프트웨어 비용 추정

소개

소프트웨어 개발에서 가장 어려운 일 중 하나는 새로운 소프트웨어 제품을 제공하는 데 얼마나 오래 걸리고 얼마나 걸릴지 결정하는 것입니다. 그렇게 힘들다고 해야 할까요? 답은 간단하지 않습니다.

소프트웨어 비용 추정은 본질적으로 어렵고 인간은 절대 결과를 예측하는 데 매우 서툴다. 두 개의 프로젝트가 동일하지 않습니다. 각각은 달성하고자 하는 것이 고유하고 존재를 구성하는 수많은 매개변수에서 고유합니다. 표면적으로는 단순한 문제처럼 보이는 것이 현실에서 구현하기가 훨씬 어렵거나 기술적으로 어려운 경우가 많습니다. 그리고 의심할 여지 없이 프로젝트에는 '알려지지 않은' 부분이 있을 것이며, 이러한 일이 발생했을 때만 식별할 수 있습니다.

또한 고객이든 개발자든 사용자든 똑같은 사람은 없습니다. 우리는 우리 자신의 지식, 경험, 가치, 기대, 위험에 대한 태도 및 적응 능력을 미리 갖추고 있습니다.

좋은 품질의 소프트웨어를 작성하는 것은 선임 엔지니어에게 빵과 버터입니다. 멋진 소프트웨어 제품을 만드는 것은 관련된 모든 사람들에게 훨씬 더 어려운 노력이 될 수 있습니다.

그러나 소프트웨어의 경우 기간과 비용을 이해하는 것이 전략적 비즈니스 결정을 내리는 데 중요하며 이는 스타트업을 만들거나, 새로운 비즈니스 기회를 실현하거나, 비즈니스를 더 잘 수행할 수 있도록 지원하는 경우에 해당됩니다. 타이밍, 투자 수익률 및 제공되는 이점은 비즈니스를 성사시키거나 흔들거나 무너뜨릴 수 있습니다. 당신은 스스로에게 물어볼 것입니다: 우리가 돈을 위해 무엇을 얻습니까? 비용을 예측할 수 있습니까? 우리가 원하는 제품을 만드는 데 드는 비용은 얼마입니까? 언제 출시할 수 있나요? 우리의 투자에 대해 양질의 제품을 얻을 수 있습니까? 우리 사업과 함께 성장할 것인가? 비즈니스 가치를 제공할 것인가?

그렇다면 프로젝트의 규모, 기간 및 비용을 어떻게 추정합니까? 애자일 프로젝트 추정 및 소프트웨어 개발 비용, 그리고 Toptal에서 이를 수행하는 방법을 살펴보겠습니다.

전통적인 계약 가격 책정 및 추정

전통적으로 소프트웨어 프로젝트는 애자일 방식이 아닌 방식을 사용하여 기능이나 범위를 수정하고 시간과 비용을 가변적으로 유지하려고 했습니다. 이로 인해 문제가 발생합니다.

1. 프로젝트 초기에 수정한 기능이 실제로 귀하의 비즈니스 또는 고객에게 가장 적합한 기능인지 어떻게 알 수 있습니까? 종종 기능이나 범위가 변경되기 때문에 프로젝트 수명 주기를 통해 원하는 요구의 결과를 식별하고 필요하거나 필수로 결정하는 '범위 크리프'에 대해 듣게 됩니다.

2. 비용이 변수가 되면 달성하고자 하는 투자 수익(ROI)에 대한 통제력을 잃게 됩니다. 비용 증가는 종종 확인되지 않은 위험이나 변화하는 요구 사항의 산물입니다. 즉, 동일한 시간 프레임에 더 많은 작업을 수행하거나 더 오래 유지하려면 팀원을 추가해야 합니다. 어느 쪽도 바람직하지 않다

3. 시간이 변수일 때 우리는 시장에서의 위치에 대한 통제력을 잃습니다. 아마도 우리는 중요한 산업 날짜를 놓치거나 경쟁업체가 우리보다 먼저 제품을 내놓아 우리 프로젝트가 가질 수 있었던 경쟁 우위를 잃을 수 있습니다.

가변 시간과 비용의 다른 많은 결과가 있으며, 이는 종종 부정적이고 바람직하지 않습니다.

물론 많은 고객과 조직은 이 '마법의 삼각형'의 세 가지 구성 요소를 모두 수정하려고 합니다. 불행히도 현실적으로 달성하기는 거의 불가능합니다. 이 이상을 뒤흔들 공모하는 요소가 너무 많아 결국 요구 사항을 충족하지 못하는 제품으로 귀결되고, 고객에게 이익이 되는 데 너무 오래 걸리거나 비즈니스 가치를 실현하는 데 너무 많은 비용이 듭니다.

소프트웨어 프로젝트를 위한 애자일 계약

비용은 시간과 사람(팀원)의 곱입니다. 시간을 더 추가하면 직원을 더 오래 고용하는 데 비용이 추가됩니다. 더 많은 팀원을 추가하면 동일한 비즈니스 가치를 제공하는 데 비용이 증가합니다. 우리가 정말로 피하고 싶은 것들. 이것이 Agile 원칙이 시간과 팀 구성원을 고정하고 범위를 가변 구성 요소로 허용하는 것을 믿는 이유입니다.

고정 비용과 변동 비용 중 어느 것이 더 좋게 들리고 이해 관계자의 신뢰를 높입니까?

물론 제품이 약속과 고객의 요구를 이행하는 것이 중요합니다. 결국 아무도 원하지 않거나 효과적으로 사용할 수 없는 제품이 생긴다면 정확한 시간과 정확한 돈을 쓰는 것은 좋지 않습니다.

따라서 애자일 계약은 다음에 중점을 둡니다.

• 고정 가격 작업 패키지 - 전체 프로젝트는 전체 제품 결과에 기여하는 논리적 '미니' 릴리스로 나뉩니다. 각 릴리스는 그에 따라 가격이 책정되는 작업 패키지입니다. 작업 패키지가 완료되면 이전 작업에서 학습한 내용을 기반으로 향후 작업 패키지를 재평가합니다. 이렇게 하면 불필요한 우발 상황을 방지하고 고객이 정의할 새로운/개정된 기능 및 우선 순위 재지정 수준을 허용합니다.

• 조기 종료 - 이를 통해 고객은 제품이 충분히 인도되었고 계속해서 한계 이익만 제공할 프로젝트 팀을 유지함으로써 달성할 ROI가 없는 경우 프로젝트를 조기에 종료할 수 있습니다. 이 조항은 일반적으로 언제든지 허용되며 프로젝트 팀과 고객이 강력하고 신뢰할 수 있으며 긴밀한 협력 관계를 유지하는 한 유효합니다. 고객을 위한 이점은 제품을 실행 가능하게 만드는 데 필요한 모든 가치 있는 기능을 제공한 프로젝트가 조기에 완료된다는 것입니다. 그 대가로 공급업체는 나머지 계약 금액의 20%를 지불하고 직원을 유지하는 위험을 상쇄합니다.

• 유연한 변경 - 변경은 Agile 소프트웨어 제공의 정맥을 통해 강력하게 실행되는 테마입니다. 우리는 처음부터 제품을 성공적으로 만드는 데 필요한 모든 것을 알지 못할 것으로 예상합니다. 따라서 적절한 제품이 제공되도록 관련 데이터 및 피드백을 기반으로 변경을 촉진합니다. 반복이 끝나면 변경 사항을 더 이상 필요하지 않거나 우선 순위로 간주되지 않는 이전 기능으로 교체할 수 있습니다. 변경 가치가 동일한 한 추가 비용은 없습니다. 변경 값이 더 낮으면 남은 백로그에서 추가 작업을 식별하거나 앞으로 가져올 수 있습니다. 이 조항은 프로젝트 팀과 고객이 프로젝트 전반에 걸쳐 강력하고 신뢰할 수 있으며 긴밀한 협력 관계를 유지하는 한 유효합니다.

• 추가 작업 - 프로젝트의 수명 동안 기존 고정 가격 계약에서는 달성할 수 없는 더 많은 기능이 식별될 수 있습니다. 이 시나리오의 경우 새로 가격이 책정된 작업 패키지를 프로젝트 끝에 추가하거나 시간 및 재료로 되돌릴 수 있습니다.

• 범위 추정치 - 애자일 프로젝트 계약에서 추정치의 범위를 지정하는 두 가지 방법이 있습니다. 기간 범위 또는 기능 범위입니다. 기간 범위는 프로젝트 또는 작업 패키지가 주어진 범위 세트에 대해 12주에서 16주가 소요될 것이라고 추정할 수 있도록 합니다. 그러나 기간을 추가하면 프로젝트 팀 구성원을 더 오래 유지하기 때문에 비용이 추가되거나 다른 개발 프로젝트에서 작업하도록 릴리스될 수 없음을 의미합니다. Toptal에서 우리는 범위를 변수로 유지하면서 작업 패키지 또는 전체 프로젝트의 고정된 시간 프레임 내에서 고객에게 최소 수준의 가치를 제공할 것을 약속하면서 스토리 포인트 범위에 걸쳐 기능의 범위를 지정하는 것을 선호합니다.

나중에 언제든지 범위를 더 추가할 수 있다는 점을 기억할 가치가 있습니다. 수익을 올리기 시작했거나 사용자를 늘리거나 비용을 줄였을 수 있습니다. 어느 쪽이든, 이미 수익이나 개선을 보여주고 비즈니스 가치를 제공하고 있다면 더 많은 돈과 시간을 요구하는 것이 훨씬 쉽습니다.

소프트웨어 비용 및 가격 책정에 대한 당사의 접근 방식

Toptal에서 우리는 고객 및 엔지니어와 긴밀히 협력하여 프로젝트 기간 및 비용에 대한 이해 관계자의 신뢰를 높이는 기술을 사용합니다. 우리는 낭비를 방지하고 관리된 변경을 가능하게 하는 것이 적절하고 필요할 때 초기의 높은 수준에서 보다 세부적인 세부 사항까지 계획을 지속적으로 정교화하고 조정하기 위해 노력합니다.

견적 및 고정 가격 프로젝트를 정교화하기 위해 다음 단계를 수행합니다.

1. 초기 상위 수준 범위

프로젝트를 시작할 때 우리는 최종 결과에 대해 가장 적게 알고 있습니다. 처음부터 고객과 사용자가 필요로 하는 기능을 정확히 아는 것이 가능하다고 상상하는 것은 어리석은 일입니다.

따라서 우리는 건전한 비전과 목표를 기반으로 프로젝트의 방향을 안내하는 프로젝트 헌장과 높은 수준의 "서사시" 기능으로 시작합니다.

ㅏ. 비전과 목표 설정 무엇을 구축해야 합니까? 달성해야 하는 것은 무엇이며 비즈니스 목표는 무엇입니까? 이러한 질문을 이해하면 프로젝트의 규모를 설정할 수 있습니다. 초기 아이디어, 개념 또는 기술을 테스트하기 위해 프로토타입이 필요합니까? 시장에서 테스트한 명확한 제안을 확인했으며 첫 번째 MVP(Minimal Viable Product)를 구축할 준비가 되었습니까? 아니면 기존 비즈니스나 제품을 다음 단계로 끌어올리기 위해 확장하고 있습니까?

비. 높은 수준의 "에픽" 기능 너무 자세히 설명하지 않고 제품이 고객의 요구를 충족시켜야 하는 기능을 정의하고 싶을 것입니다. 이것은 제품의 핵심을 설명하는 구조화된 "쇼핑 목록"입니다. 종종 이것을 "사용자 스토리" 또는 에픽이라고 합니다.

씨. MoSCoW 분석 MoSCoW 분석은 간단히 말해서 제품을 실행 가능하게 만드는 데 실제로 필요한 것과 있으면 좋은 것을 식별하는 데 도움이 되는 기술입니다. "필수"로 식별된 항목은 사용자가 제품에 참여하고 채택하도록 권장하는 사항을 충족합니다. "해야 함"으로 식별된 이러한 기능은 고객을 놀라게 하고 기쁘게 하지만 나중에 구축할 수 있습니다. "가능" 항목은 종종 중요한 비즈니스 가치를 추가하지 않고 수익을 증가시키지 않을 수 있으며 가장 낮은 우선 순위입니다. "하지 않을 것" 기능은 언젠가는 중요할 수 있지만 이 프로젝트 반복의 범위를 벗어납니다. 그러나 지금 이러한 항목을 식별하면 향후 제품의 잠재적 규모와 크기를 염두에 두는 데 도움이 될 수 있습니다.

2. 제안

프로젝트를 진행할지 여부를 결정하려면 비용과 기간과 같은 충분한 정보에 근거한 데이터를 기반으로 결정을 내려야 합니다. 다음은 스스로에게 물어봐야 하는 최소한의 것입니다. 원하는 제품을 만드는 데 무엇이 필요한가요? 언제 출시할 수 있나요? 이것이 우리의 비즈니스 전략 및 재정과 일치합니까?

위의 세부 사항으로 우리는 제안을 제공할 수 있는 위치에 있습니다. 당사의 엔지니어는 특정 프로젝트 요구 사항에 맞게 선별되며 프로젝트 관리자와 협력하여 알려진 범위를 제공하는 예상 기간 및 프로젝트를 완료하는 데 필요한 예상 비용을 도출하기 위해 프로젝트 관리자와 협력합니다.

이전에 언급했듯이 프로젝트 초기에는 전달될 내용에 대해 최소한 알고 있습니다. 우리는 의도적으로 기능과 범위를 모호하게 유지합니다. 그렇지 않으면 필요한 것이 정확히 무엇인지 알 수 있기 때문입니다. 이 단계의 추정치는 가장 정확하지 않지만 프로젝트를 진행할 가치가 있는지 여부에 대한 지침을 제공합니다.

제안서는 프로젝트의 기간과 비용을 자세히 설명하는 첫 번째 도구입니다. 제안이 수락되면 고정 가격 견적을 제공할 수 있습니다.

3. 출시 계획

추정 정교화의 다음 단계는 주어진 기간에 다양한 기능을 제공할 릴리스 계획을 만드는 것입니다. 우리는 기능 목록, 프로젝트 규모, 우리 팀이 고객의 기대를 충족하는 고품질 소프트웨어를 얼마나 빨리 개발할 수 있는지, 불확실성 위험을 관리하기 위한 기술에서 이를 도출합니다.

ㅏ. 제품 백로그 제품 백로그는 단순히 제품에 필요한 기능을 나타내는 "Epics" 또는 "User Stories"의 정렬된 목록입니다. 이 목록은 이전에 논의된 에픽처럼 시작되지만 할당된 프로젝트 팀, 프로젝트 관리자 및 고객 사이에서 이제 이를 보다 의미 있는 항목으로 나눕니다. 각 항목은 고객에게 비즈니스 가치의 일부를 나타냅니다. 이 단계에서는 더 자세히 설명하지 않습니다. 허용 기준을 알 필요도 없고, 버튼이 파란색인지 녹색인지 알 필요도 없고, 일부 작업을 허용하는 버튼이 있다는 것만 알면 됩니다. 수행됩니다.

비. 추정 사용자 스토리로 설명된 기능 목록이 있으므로 팀은 "Planning Poker"라는 기술을 사용하여 이러한 개별 기능 항목을 추정합니다. 이것은 전문가의 의견과 유사한 크기 조정을 기반으로 빠르고 안정적인 결과를 보장하는 유용한 기술입니다. Planning Poker는 크기와 복잡성을 나타내는 합의된 숫자를 각 항목에 할당합니다. 이것을 스토리 포인트라고 합니다. '이상적인 날'과 같은 기타 애자일 추정 기술 및 크기를 사용할 수 있습니다.

이 프로세스가 끝나면 프로젝트의 크기와 기능 간의 종속성이 결정됩니다. 크기는 제품 백로그에 있는 항목의 모든 스토리 포인트를 합산하여 결정됩니다. 그 숫자가 120이라면 우리 프로젝트의 크기는 120 스토리 포인트입니다.

씨. 우선 순위 지정 이제 프로젝트에 대한 백로그와 규모가 있으므로 고객과 함께 우선 순위를 정할 수 있습니다. 이것은 실제로 원하는 결과를 달성하기 위해 고객에게 가장 가치 있는 것이 무엇인지 식별하는 것입니다. 목록의 맨 위에 있는 항목이 가장 중요한 것으로 간주되고 두 번째 항목이 첫 번째 항목보다 덜 중요한 식으로 목록 전체에서 계속됩니다. 어떤 두 항목도 다른 항목만큼 중요할 수 없습니다. 각 항목의 우선 순위는 다른 항목 각각에 대해 상대적으로 중요하거나 가치가 있습니다.

우선 순위 지정에 대한 이러한 접근 방식은 소프트웨어 프로젝트를 계획하는 데 있어 중요한 이정표입니다. 이제 우리는 고객에게 무엇이 중요한지, 어떤 순서로 작업을 완료하고, 종속성을 처리하고, 기대에 맞는 제품을 제공하는지 알고 있습니다.

디. 출시 계획 지금까지 우리는 제품이 무엇이며 얼마나 큰지 결정했습니다.

이제 출시 가능한 제품을 제공하는 데 걸리는 시간을 결정합니다. 디자이너, 엔지니어, 테스터, 스크럼 마스터 및 프로젝트 관리자를 포함한 고객과 팀은 릴리스 계획을 작성하기 위해 달성할 수 있는 것과 작업을 얼마나 빨리 수행할 수 있는지 확인하기 위해 함께 작업합니다.

릴리스 계획은 또한 프로젝트가 고객의 전략적 계획과 어떻게 일치하는지에 대한 통찰력을 제공합니다.

마지막으로, 이 계획은 프로젝트 팀이 개발의 논리적 끝점을 정의하고 길을 안내하는 안내등을 갖도록 합니다.

시작하기 전에 "완료"에 대한 합의된 정의를 이해했는지 확인합니다. 이것은 고객이 완전한 것으로 받아들이고 릴리스 가능한 것으로 간주되는 모든 엔지니어링 요구 사항을 충족하는 주어진 기준 세트입니다.

기본 시나리오를 취하기 위해 백로그 크기를 조정하여 얻은 총 스토리 포인트 수를 팀의 예상 속도로 나눕니다. (NB 속도는 일반적으로 범위로 표현되지만 단순함을 위해 여기에서는 단일 숫자를 사용합니다.) 우리는 2주 동안 반복 작업을 하므로 속도는 사용 가능한 팀의 능력. 스토리 포인트가 총 120이고 반복당 20포인트를 완료할 것으로 예상되는 경우 총 개발 기간은 12주 또는 6회 반복이 됩니다. 여기에 2주의 스프린트 0과 2주의 릴리스 준비 스프린트를 추가합니다. 총 프로젝트 기간은 16주입니다. 나중에 논의할 계획에 적절한 위험 완충 장치를 구축하는 데 사용할 수 있는 기술이 있습니다. 그러나 간단히 말해서, 우리는 불확실성의 위험을 관리하고 전달될 예상 스토리 포인트에 대한 최소한의 합의에 도달하기 위해 버퍼를 사용합니다. 결과는 90~150개의 스토리 포인트 범위가 될 수 있으며, 90은 실행 가능한 제품을 만드는 데 허용되는 최소값입니다.

또는 프로젝트가 지정된 날짜(예: 10주)까지 완료되어야 하는 경우 팀에서 해당 시간에 완료할 수 있는 백로그의 양을 결정합니다. 스프린트당 20개의 스토리 포인트와 Sprint 0 및 릴리스 스프린트를 예상한다면 프로젝트가 끝날 때까지 완료되는 60개의 포인트를 목표로 삼을 것입니다. 다시 말하지만, 우리는 적절한 버퍼를 추가하여 위험을 관리할 것입니다. 그러면 45~75개의 스토리 포인트가 완료되고 출시 준비가 완료될 수 있습니다. 45개의 스토리 포인트는 실행 가능하고 가치 있는 제품을 제공하기 위해 허용되는 최소값과 일치합니다. 이것은 적절한 경우 속도를 높이기 위해 팀 구성원을 추가할 것으로 예상할 수 있는 시나리오 중 하나입니다.

물론 위의 모든 것은 달성 가능하고 현실적이며 고객이 수용할 수 있는 릴리스 계획을 도출하기 위해 모든 당사자 간의 양질의 커뮤니케이션과 협력으로 지원됩니다.

4. 고정 가격 계약

출시 계획에 동의하면 고정 가격 프로젝트 계약에 대한 견적을 작성할 수 있습니다. 앞서 언급했듯이 프로젝트 기간과 팀을 고정하고 범위 변수를 유지하는 것이 좋습니다.

고정 가격 계약에 대한 견적은 작업 명세서 및 합의된 지불 일정과 함께 제공됩니다.

신뢰, 커뮤니케이션, 협업 및 애자일 소프트웨어 프로젝트 정신에 들어갈 준비가 되어 있는 한, 위의 모든 단계를 통해 프로젝트가 정시에 제공될 것이라는 현실적인 확신을 가지고 견적을 전달할 수 있습니다. 예산에. 물론 프로젝트가 일찍 또는 늦게 전달되는 경우가 있으며 이러한 변경 사항을 최대한 투명하게 처리합니다.

추정 기법

애자일 계획 및 추정은 개발 팀이 규모, 노력, 기간 및 비용에 대한 확신을 얻기 위해 사용할 수 있는 여러 기술에 의해 지원됩니다. 다음은 우리 팀이 소프트웨어 프로젝트의 규모와 비용을 추정하는 데 사용하는 몇 가지입니다.

크기 추정

프로젝트의 규모는 실제로 범위, 복잡성, 차원, 위험 및 규모에 대한 감사입니다. 비유하자면, 우리가 에펠탑을 짓고 있는지 중국의 만리장성을 짓고 있는지 이해하는 것입니다. 에펠탑은 빽빽한 도시 환경에 지어진 크고 무겁고 복잡한 구조물입니다. 만리장성은 비교적 단순하지만 기복이 있는 수 마일의 지형에 걸쳐 있는 길고 견고한 구조입니다.

둘 다 전달해야 할 큰 프로젝트이지만 범위, 복잡성, 차원, 규모 및 크기가 다릅니다.

견적으로 기대치를 관리하는 것이 중요합니다. 그것들은 결코 예측, 약속 또는 보증이 아닙니다. 총 크기, 총 기간 및 총 비용을 논의할 때 위험, 불확실성 및 알 수 없는 것을 완화하기 위해 항상 범위 내에서 작업합니다.

제품의 특징을 나타내는 스토리는 스토리 포인트 또는 이상적인 요일을 사용하여 개별적으로 크기가 지정되고 추정됩니다. 이러한 단위의 총 수는 프로젝트의 총 크기를 정의합니다.

스토리 포인트

스토리 포인트는 사용자 스토리의 전체 크기를 나타내는 측정 단위입니다. 스토리의 크기는 추정할 때 디자인, 엔지니어링, 테스트, 코드 검토, 통합 등의 모든 측면을 포함합니다.

스토리의 각 크기는 다른 스토리에 상대적입니다. 예를 들어, 스토리 A는 1포인트로, 스토리 B는 2포인트로, 스토리 C는 3포인트로 크기 조정될 수 있습니다. 여기에서 이야기 C는 이야기 A의 크기의 최소 3배이고 다시 이야기 B의 크기의 절반 이상입니다.

제품 백로그의 다음 스토리에 관련 크기가 있는 경우:

프로젝트의 전체 크기는 12개의 스토리 포인트입니다.

이상적인 날들

이것은 일 단위로 표시되는 크기의 척도입니다. 중단, 민첩한 계획 활동, ​​이메일 읽기 및 기타 비 프로젝트 활동과 같은 오버헤드 개념을 제거합니다. 처음부터 끝까지의 경과 시간이 아니라 중단 없이 지속적으로 작업을 수행할 경우 걸리는 시간에만 집중합니다.

일반적으로 프로젝트에 대해 가장 적게 알고 있을 때 높은 수준에서 추정할 때 스토리 포인트와 같은 추상적인 숫자보다 과거의 역사 및 경험과 상관 관계가 더 쉬운 개념이므로 이상적인 날짜에 추정합니다. 특히 높은 수준의 이야기가 세부 사항이 거의 없고 나중에 분해할 때 추가 요소를 포함할 가능성이 있는 더 큰 서사시일 때 특히 그렇습니다.

보다 세분화된 수준에서 추정할 때 확립된 제품 백로그의 이야기를 말하여 두 가지 접근 방식을 모두 사용할 수 있으며 엔지니어링 팀에서 결정합니다. 두 접근 방식 모두 장점이 있으며 각 팀마다 선호하는 방식이 있습니다.

추정 기법

공유 견적 견적은 개별적으로 수행되지 않습니다. 설계, 데이터베이스, 서버, 프런트 엔드 UI, QA 및 기타 교차 기능 전문가를 포함하여 전체 엔지니어링 팀이 함께 공동 작업을 수행합니다. 이렇게 하면 기능을 완성하기 위해 관련된 작업의 모든 측면을 고려하지 않는 문제를 피할 수 있으며, 어느 누구도 기능의 크기를 과대평가하거나 과소평가하는 부담이나 불행이 없도록 합니다. 결합된 팀은 모두 논의하고 동의할 수 있는 견해를 갖게 됩니다.

Analogous Estimates 여기에서 우리는 두 개의 개별 기능을 고려하고 하나가 다른 것보다 상대적으로 작거나 크다고 결정합니다. 주어진 이야기를 보고 크기가 작다는 데 동의할 수 있으며, 스토리 포인트를 사용하는 경우 크기를 2로 지정할 수 있습니다. 다음 이야기는 첫 번째 이야기에 비해 큰 것으로 간주될 수 있으며 크기는 5입니다. 이것은 큰 것이 작은 피처의 크기의 최소 두 배임을 시사합니다.

우리는 모든 이야기를 가지고 이 연습을 계속할 것입니다. 완료되면 모든 소형, 중형, 대형 및 초대형 스토리를 나란히 놓고 크기를 교차 확인하여 추정에 일정 수준이 있는지 확인할 수 있습니다.

계획 포커 계획 포커 에 대해 많은 글이 작성되었습니다. 이전 블로그에서도 언급했습니다. 이를 이해하는 데 가장 좋은 리소스 중 하나는 여기에 있습니다.

본질적으로 전문가의 의견, 유추 및 팀 협업을 쉽고 빠르고 신뢰할 수 있는 프로세스로 결합합니다.

기술 및 영역 경험, 생생한 대화 및 타당한 근거를 기반으로 견적을 작성하는 데 가장 적합한 여러 전문가를 모았습니다.

속도

속도는 주어진 반복(또는 스프린트)에서 작업을 완료하는 팀의 능력을 측정한 것입니다.

예를 들어 스프린트당 23~32개의 스토리 포인트, 특히 프로젝트 수명 초기에 범위로 표현됩니다. 일반적으로 같은 팀이 이전에 같은 문제에 대해 작업한 적이 없는 한 팀의 속도가 정확히 무엇인지 설명하기 어렵기 때문입니다. 참고로 우리는 개인의 속도가 아니라 팀의 속도를 나타냅니다!

우리는 속도를 사용하여 릴리스를 계획하고 프로젝트를 진행하면서 계획 및 작업 패키지를 조정하므로 실행을 통해 완료 예측을 정기적으로 정확하게 조정할 수 있습니다.

시작할 때 매우 적은 데이터로 속도 범위를 정의해야 합니다. 팀과 문제 공간이 동일한 경우 역사적 값을 사용할 수 있으며, 이는 가능성이 가장 낮습니다. 반복을 실행하여 실제로 프로젝트에서 작업하는 팀으로부터 속도에 대한 아이디어를 얻을 수 있지만 이는 비용이 많이 들고 프로젝트 시작에 대한 동의에 대한 결정이 아직 내려야 하는 경우 작동하지 않습니다. 또는 예측할 수 있습니다.

속도 예측에는 스프린트 분량의 스토리를 가져와 스토리를 완료하기 위해 수행되는 작업으로 나누는 작업이 포함됩니다. 설계, 개발, 테스트 등을 포함하여 각 작업에 소요되는 시간을 추정하고 주어진 스프린트에서 팀이 가질 수 있는 용량을 평가합니다. 방해받지 않는 팀의 경우 70%의 용량이 좋은 기준선입니다. 따라서 간단한 상황에서 팀이 사용할 수 있는 총 시간은 다음과 같습니다.

• 4명의 팀원 * 2주 * 주당 40시간 = 320시간
• 70% 용량을 곱한 값 = 224시간
• 모든 기능 작업을 추가하고 224에서 계산을 중지합니다.
• 완성된 모든 기능을 가져오고 스토리 포인트를 추가하면 속도가 빨라집니다(예: 36).
• 양쪽에 20%를 적용하여 최저 및 최고 범위를 얻고 29~43층의 예상 속도에 도달합니다.

속도는 일반적으로 처음 2~4회 반복에서 변한 다음 작은 범위의 점 내에서 안정화됩니다. 따라서 스프린트 1 이전의 초기 범위가 29에서 43이었지만 스프린트 4에서는 34에서 38로 정체될 수 있습니다. 그러면 최종 완료 날짜를 예측하는 데 더 큰 확신을 갖게 됩니다.

위험 및 불확실성에 대한 버퍼링 계획

모든 소프트웨어 프로젝트에는 일정 수준의 불확실성이 따릅니다. 이러한 불확실성은 프로젝트가 진행됨에 따라 줄어들고 당사의 기술, 환경, 성능 및 고객과 사용자의 요구 사항에 대해 더 많이 알려지게 됩니다.

우리는 일정의 버퍼를 사용하여 이러한 불확실성이나 위험을 완화합니다. 이 버퍼는 개발이 시작되기 전에 결정할 수 없는 미지수와 추정 오차의 한계를 설명합니다.

일반적으로 기능 및 일정의 두 가지 버퍼 유형이 있습니다. 고정된 배송 날짜에 대해 고정 가격을 정의하는 경우가 많기 때문에 기능 버퍼를 사용하는 것이 좋습니다.

이 접근 방식은 신뢰할 수 있는 위험 완화 전략을 제공하고 고객이 프로젝트가 완료되었을 때 결과로 기대할 수 있는 것에 대한 확신을 줍니다.

기능 버퍼

기능 버퍼를 사용하여 주어진 기능 세트를 제공하지만 이상적으로는 추가 기능 세트를 완료할 것으로 예측하고 있습니다. 이것은 최소한 고객이 실행 가능한 제품을 출시하는 데 필요하다고 생각하는 최소한의 기능 세트를 반영해야 하지만 모든 다양한 내부 및 외부 영향이 허용하는 경우 시간 프레임 내에 더 많은 기능이 제공될 수 있습니다.

따라서 고객은 최대 100개의 스토리 포인트를 추가하는 제품 백로그에서 가장 우선 순위가 높은 기능이 가장 중요하다고 결정할 수 있습니다. 그런 다음 최대 30개의 스토리 포인트를 추가하는 추가 기능을 고려할 수 있습니다. 따라서 팀은 주어진 고정 가격 계약의 예정된 완료 날짜가 끝날 때까지 최소 100개의 스토리 포인트를 완료하여 130개의 스토리 포인트를 제공하는 것을 기반으로 계획할 것입니다.

닫는 몇 가지 생각

애자일은 완전히 파악하고 채택하기가 매우 어려운 개념일 수 있습니다. 가격, 범위 및 기간과 같은 민감한 주제를 관리할 때도 마찬가지입니다. 불행히도 나는 까다로운 고객이 모든 것을 미리 해결하기를 원하고 모든 것이 풀리기 시작하면 공급업체를 비난하기를 열망한다는 것을 직접 압니다. 마찬가지로, 나는 발을 디디고 무반응이 되어 고객 요구에 응답하지 않는 공급업체를 알고 있습니다. Agile 경로를 선택하는 것은 기본적으로 신뢰, 좋은 관계 및 뛰어난 커뮤니케이션을 기반으로 합니다. 이는 관련된 모든 사람의 평등한 이익, 만족 및 성공을 위해 건강한 프로젝트를 유지하기 위해 양 당사자가 보유하는 가치여야 합니다. 협력과 협상에 대해 열린 마음과 건설적인 태도를 유지하는 것이 관계가 악화되는 것을 피하는 가장 좋은 방법입니다.

저는 Agile의 적응력을 수용하고 명령 및 제어 태도를 포기하는 것이 어렵다는 것을 알게 된 클라이언트와 함께 일해 왔습니다. 모르는 팀에 대한 모든 믿음과 신뢰를 놓기가 어렵습니다. 종종 클라이언트는 전달될 항목의 사양으로 모든 요구 사항을 미리 생성하기를 원할 수 있습니다. 이것은 그들에게 프로젝트의 범위가 잘 정의되어 있다는 확신을 줍니다. 그러나 궁극적으로 이것은 성공적인 접근 방식으로 구체화되지 않습니다. 계약의 범위와 비현실적인 요구에 얽매이면 문제가 매우 빠르게 발생합니다.

우리는 전통적인 방법으로 이 접근 방식을 취할 때 범위가 변경되고 미지의 것이 밝혀지거나 고객이 원한다고 생각했던 것이 더 이상 사실이 아니거나 목표를 벗어났다는 것을 알고 있습니다. 가격 책정, 계획 및 범위에 대한 적응형 접근 방식을 사용하면 고객이 시장에서 필요로 하는 것과 정확히 일치하는 제품을 진정으로 식별할 수 있습니다. 이를 통해 공급업체는 대응력, 상상력 및 효율성도 높일 수 있습니다. 계약 협상을 통해 고객과 공급업체 간의 협업을 활용하는 것이 중요합니다.

공급업체는 정직해야 하고 고객은 처음부터 달성할 수 있는 것에 대해 현실적이어야 합니다. 비현실적인 목표를 약속하고 비용을 증가시키는 공급업체는 초기 계약을 체결할 수 있지만 곧 불만을 품은 고객으로부터 호의를 잃게 됩니다. 너무 자주, 관계는 당사자 간의 신뢰 또는 확신 부족으로 인해 깨집니다. 신뢰는 처음부터 구축되어야 하고 프로젝트가 진행되는 동안 유지되어야 합니다. 공급업체는 유연해야 하고 변화하는 요구 사항에 협조해야 합니다. 고객은 항상 더 많은 것을 원합니다. 사업을 하는 것은 자연스러운 결과입니다. 양측 간에 동등하고 유익한 가치 교환이 있어야 합니다. 고객의 경우 비즈니스 가치를 창출하기를 원합니다. 공급업체의 경우 고객과 오래 지속되는 관계를 형성하여 가치를 창출해야 합니다. Agile Manifesto의 가치와 지침 원칙을 준수하는 것은 강하고 균형 잡힌 긴 관계를 형성하기 위한 건전한 기초입니다.

요약

이것이 Agile 소프트웨어 프로젝트의 가격을 계획, 추정 및 정의하는 데 약간의 통찰력을 주었기를 바랍니다. 위의 모든 접근 방식과 기술은 팀에 대한 신뢰를 구축하고 소프트웨어 제품을 구축하는 데 시간과 시간이 얼마나 걸릴지에 대한 고객의 마음에 확신을 심어주기 위해 설계되었습니다. 그리고 궁극적으로, 진행 결정을 내리는 데 자신감을 갖게 됩니다.

이 지침을 따르면 소프트웨어 제품에 생명을 불어넣는 만족스러운 방법을 찾을 수 있을 것입니다.