이상적으로 기능은 다음 기준을 준수해야 합니다.
- 제공해야 합니다 사업적 가치.
- 그것은해야한다 평가할 수 있는 – 개발팀이 구현에 필요한 작업에 대한 추산을 제공할 수 있을 만큼 충분한 정의가 있어야 합니다.
- 그것은해야한다 충분히 작은 반복에 맞춰야 합니다. 따라서 너무 큰 경우 더 세분화해야 합니다.
- 그것은해야한다 테스트 가능 – 고객에게 수용 가능한 기능을 제공하기 위해 어떤 자동 또는 수동 테스트를 통과해야 하는지 이해해야 합니다.
다양한 방법론은 기능을 지칭하는 데 각기 다른 용어를 사용합니다. 어떤 방법론이나 용어를 사용할지는 팀이 결정해야 합니다. 익스트림 프로그래밍(XP)은 기능을 나타내는 데 "사용자 스토리" 또는 "스토리"라는 용어를 사용하고, 스크럼은 기능 목록을 설명하는 데 "제품 백로그"를 사용하며, 기능 중심 개발(FDM)은 "기능"을, DSDM은 "요구사항"을 사용합니다. 마찬가지로, 통합 프로세스(UP)의 다양한 경량 버전, 즉 애자일 UP는 "요구사항" 및/또는 "사용 사례"를 사용하여 점진적으로 제공 가능한 기능을 정의합니다. 궁극적으로 목표는 동일합니다. 즉, 비즈니스 가치를 작은 단위로, 그리고 늦지 않게 정기적으로 제공하는 것입니다.
방법론적 차이점
스크럼 기능을 호출합니다 백로그 항목일반적으로 더 큰 단위이며 "생산 하드웨어 설정"이나 "xyz 옵션 조사"와 같이 기능이 아닌 항목도 포함될 수 있습니다.
XP 기능을 호출합니다 이야기이는 기능을 정의하는 데 특히 유용한 접근 방식에 적합합니다.
DSDM 기능을 호출합니다 요구 사항여기에는 시스템 기능 외에도 더 많은 기능이 포함될 수 있습니다.
애자일 UP 실무자들은 사용합니다 기타 요건 사용 사례 특징을 정의하다.
기능 분석 구조(FBS)
세부적인 계획을 세우는 동안, 민첩한 개발 폭포수 개발 방식에 사용되는 작업 분할 구조(WBS) 대신 기능 분할 구조(FBS) 방식을 선호합니다. 기능 분할 구조는 다음과 같은 몇 가지 이유로 유리합니다.
- 이를 통해 고객과 개발팀이 모두 이해할 수 있는 용어로 소통할 수 있습니다.
- 이를 통해 고객은 비즈니스 가치에 따라 팀의 업무 우선순위를 정할 수 있습니다.
- 이를 통해 실제 생산된 사업 가치에 대한 작업 추적이 가능합니다.
큰 기능부터 시작해서 시간이 지남에 따라 더 작은 기능들로 나누어 진행하는 것도 좋습니다. 이렇게 하면 고객이 실제 설계 및 납품에 필요한 세부 정보가 필요할 때까지 너무 자세한 내용을 파악하지 않아도 됩니다.
초기 기능 목록 작성
출시 전 계획 및 반복 계획팀은 가능한 한 많은 잠재적 기능 목록을 신속하게 작성해야 합니다. 일반적으로 기능 수집을 담당하는 사람은 한 명입니다(예: 제품 관리자, 고객, 프로그램 관리자, 비즈니스 분석가 또는 기타 고객 대리인). 하지만 기능 요청은 여러 출처에서 올 수 있습니다. 사용자, 고객, 영업, 마케팅, RFP, 개발 팀원, 경영진, 경쟁사 및 정부 규정은 모두 기능의 출처가 될 수 있습니다. 팀의 중앙 기능 목록에는 중복 항목, 불가능한 기능 및 지나치게 모호한 요청을 방지하기 위한 몇 가지 제어 기능이 있어야 합니다. 그러나 팀은 새로운 기능을 식별하는 대로 입력하여 우선순위 지정 및 계획 프로세스에 통합할 수 있도록 권장해야 합니다.
초기 기능 목록은 출시 및 첫 번째 반복 작업을 계획하는 데 필요한 대략적인 스케치이자 상위 집합이 될 수 있습니다. 이는 시스템이 여러 번의 출시를 통해 어떤 모습으로 발전할 수 있는지에 대한 현재 잠재력을 나타냅니다. 모든 기능이 정의될 때까지 기다릴 필요는 없습니다. 소프트웨어 제공. 그리고 원래 목록, 원래 설명, 또는 원래 우선순위를 무의미하게 고수할 필요는 없습니다. 애자일 개발의 핵심 중 하나는 이 목록이 (다른 모든 것과 마찬가지로) 반복을 통해 진화한다는 것입니다.
대략적인 기능 목록이 완성되고, 릴리스 계획과 반복 계획이 수립되고, 첫 번째 반복이 완료된 후 몇 가지 중요한 기능이 파악되었다고 가정해 보겠습니다. 이러한 기능은 단순히 진화하는 릴리스 계획과 이후 반복에 포함되어 가능한 한 빨리 배포됩니다. 하지만 그 사이에 시간은 낭비되지 않습니다. 팀은 가능한 한 빨리 가치를 제공하기 시작하고, 프로젝트가 시간이 지남에 따라 새로운 우선순위, 정보, 그리고 비즈니스 역학에 적응할 수 있도록 인프라를 구축합니다.
기능 목록
기능 목록을 작성할 때, 처음에는 각 기능을 짧은 단락(일반적으로 2~4문장)으로 설명합니다. 이 설명은 기능에 대한 개략적인 요약이자, 사전 이해를 위한 자리 표시자이며, 향후 소통의 기반이 됩니다. 이는 나중에 작성될 기사의 헤드라인과 같습니다. 목표는 다른 모든 기능과 비교했을 때 상대적인 크기, 복잡성, 그리고 우선순위를 합리적으로 이해할 수 있을 만큼 충분한 시간을 들여 기능을 설명하는 것입니다. 몇 가지 더 자세한 내용은 나중에 설명하겠습니다. 반복 계획. 하지만 고객과 개발자가 해당 기능을 구현할 만큼 충분히 논의하거나(일부 방법론에서는) 해당 기능을 확정적으로 지정하는 자동화된 수용 테스트를 만드는 반복 작업 중에 해당 기능에 대한 정확하고 구체적인 이해가 드러날 수 있습니다.
도움이 되는 참고 자료
사용자 스토리
적용된 사용자 스토리: 민첩한 소프트웨어 개발을 위해 마이크 콘 지음
웨비나
PI 계획을 실행하는 방법 Digital.ai Agility
구성 기능
하나의 긴 기능 목록을 관리하는 것은 어려울 수 있습니다. 범주, 상위 기능 그룹, 비즈니스 가치 또는 우선순위, 그리고 위험을 명시하여 기능을 구성하는 것이 매우 유용합니다. 이러한 다양한 속성을 기준으로 필터링하고 정렬하면 매우 큰 기능 목록을 관리하기 쉬운 단위로 나눌 수 있습니다.
프로젝트팀 모두가 어떤 기능이 가장 가치 있는지 쉽게 파악할 수 있도록 전체 기능 목록을 단일 연속 순서로 정렬해야 합니다. 프로젝트가 목록에 100개의 기능으로 시작한다면, 그중 50개가 "높은" 우선순위 범주에 속하는 경우가 흔합니다. 기능들을 단일 순차적 순위로 정렬하면 "가장 높은" 우선순위를 가진 기능을 파악하는 데 도움이 되므로, 제공 가치를 극대화하기 위해 먼저 완료해야 합니다.
위험 설명
특정 기능과 관련된 위험에 대해 추가로 고려할 수 있습니다. 일부 기능에는 팀에 새로운 디자인, 아키텍처, 프레임워크 또는 알고리즘이 포함되거나 다른 측면에서 위험한 경우가 있습니다. 이러한 기능이 최고의 비즈니스 가치를 제공하지 않더라도 초기 반복 단계에서 해결할 수 있도록 우선순위를 높이는 것이 합리적입니다. 고위험 기능이 프로젝트 초기에 해결되었지만 어떤 이유로든 실행 불가능하다고 판명되더라도 팀은 여전히 대응하고 해결할 시간이 있습니다. 이를 통해 프로젝트의 전반적인 위험을 최소화할 수 있습니다. 이러한 유형의 문제, 위험 및 종속성을 파악하기 위해 고객과 긴밀히 협력하는 것은 개발 팀의 몫입니다. 기능의 우선순위를 정하는 것은 궁극적으로 고객의 몫이지만, 이 중요한 프로세스는 외부와 단절되어서는 안 됩니다. 최고의 팀은 프로젝트 수명 주기 전반에 걸쳐 가치를 제공하고 위험을 줄이기 위해 협력합니다.
특징 추정
기능을 파악한 후, 고객은 주요 개발 이해관계자와 협력하여 기능 추정치를 정의하는 경우가 많습니다. 기능 추정치는 개발 과정을 주도하는 데 사용되는 예비적인 고수준 추정치입니다. 출시 일정 반복 계획. 추정에 참여하는 이해관계자에는 설계자, 기술 책임자, 개발자, 테스터, 작성자, 관리자 등이 포함될 수 있습니다. 많은 조직에서 그룹이 협력하여 초기 추정치를 신속하게 제공하는 프로세스를 구축하고 있습니다. 이 단계는 기능을 더 세분화해야 하는지 여부를 초기에 결정하는 데 도움이 될 수 있습니다.
처음에 기능을 추정할 때 목표는 합리적인 상위 수준 추정치에 빠르게 수렴하는 것입니다. 기능에 정확히 17.5 아이디어 시간(또는 구미 베어, NUT 또는 사용되는 다른 단위, 아래 참조)이 필요한지 여부에 집중하는 대신, 목표는 훨씬 짧은 시간 안에 합리적으로 근접하는 것입니다. 기능을 구현하는 데 이상적인 2~3일이 걸릴 것이라는 데 동의하는 데 2분이 걸리는 반면, 정확한 17.5 아이디어 시간 추정치를 설정하는 데 30분이 걸린다면, 전자의 접근 방식이 더 선호됩니다. 그룹 내 의견이 다를 때 단일 추정치를 설정하려면 팀은 평균을 구하거나, 합리적인 근사치를 개발하거나, 항상 최상의 시나리오를 사용하거나, 더 복잡한 경우 최상의 경우, 최악의 경우, 예상 추정치를 포함하는 계산을 사용할 수 있습니다. 어떤 경우든 서로 다른 추정치에 대한 논의는 종종 유용한 지식을 제공합니다.
기능을 정의하고 추정하는 이러한 과정은 처음에는 어려워 보일 수 있으며, 팀이 처음 구현할 때는 자신에게 적합한 프로세스에 익숙해지기 위해 여러 차례의 회의가 필요할 수 있습니다. 시간이 지남에 따라 기능을 단일 반복 작업으로 제공할 수 있는 작업 단위로 분해하는 것이 더 쉬워집니다. 팀은 자신이 수행하는 작업에 매우 능숙해지며, 애자일 개발은 팀이 모든 릴리스 및 반복 작업에서 추정을 연습할 수 있도록 합니다.
추정 단위
추정은 본질적으로 부정확하며, 개발자들은 역사적으로 개발 작업을 완료하는 데 필요한 전체 시간에 대한 유용한 추정치를 산출하는 데 어려움을 겪어 왔습니다. 실제 프로그래밍 시간에 대한 추정치는 종종 부정확합니다(특히 실제 수치와 엄격하게 비교하지 않은 경우). 하지만 프로그래밍이 아닌 시간은 훨씬 더 정확하게 파악하기 어렵습니다. 누군가 시내를 차로 이동하는 데 얼마나 걸리는지 묻는다면 어떻게 대답하시겠습니까? 상대적인 측정값을 사용합니다. "러시아워가 아닌 시간대에 날씨가 좋을 때 공사가 없으면 한 시간, 그렇지 않으면 두 시간 정도" 등입니다. 이러한 외부 요인은 통제가 불가능하고 예측하기 어렵습니다. 프로그래머는 코드 개발 외에도 테스트, 문서 작성, 디자인, 회의 및 검토 참여, 이메일 작성 등에 시간을 보냅니다. 프로그래밍 작업과 비교했을 때 프로그래밍이 아닌 작업은 예측하거나 통제하기 어렵습니다. 업계, 조직, 연중 시기, 그리고 조직에 가해지는 외부 압력의 변화에 따라 달라질 수 있습니다.
일부 팀은 프로그래머에게 모든 비프로그래밍 활동을 추정에 포함하도록 요청합니다. 하지만 앞서 언급했듯이 이는 쉬운 일이 아닙니다. 특정 애자일 프로젝트의 경우, 팀이 비프로그래밍 작업에 소요되는 시간을 정확하게 측정하기 훨씬 전부터, 각 기능을 완료하는 데 필요한 상대적인 작업량을 파악하고 그에 따라 계획을 세울 수 있습니다. 그렇기 때문에 애자일 팀은 가장 직접적으로 추정하고 측정할 수 있는 부분, 즉 실제 프로그래밍에 집중하여 추정하는 것이 일반적입니다. 각 기능과 각 기술 작업에 다른 기능 및 기술 작업과 비교하여 얼마나 많은 작업이 필요한지에 집중합니다. 몇 번의 반복을 거쳐 실제 속도가 나타나면서 비프로그래밍 작업에 소요되는 시간을 명확히 알 수 있습니다. 애자일 팀은 이러한 방식으로 프로그래밍에 집중하기 위해 두 가지 주요 추정 단위를 사용합니다.
- 작업 단위
- 이상적인 시간
작업 단위
작업 단위는 실제 시간과 혼동될 수 없는 상대적인 측정 단위입니다. 이러한 단위에는 다음이 있습니다.
- 포인트
- 구미베어스
- 피트-파운드
- NUT(Nebulous Units of Time)
이는 다른 기능(또는 작업)과 비교하여 특정 기능(또는 작업)을 구현하는 데 필요한 상대적인 작업량을 나타냅니다. 팀이 일반적으로 몇 번의 반복을 통해 일정한 속도를 확보한 후에야 이러한 작업 단위를 실제 시간 단위에 매핑하기 시작할 수 있습니다. 속도의 핵심은 바로 팀이 실제 시간 단위당 얼마나 많은 작업을 수행할 수 있는지를 설명하는 것입니다.
팀이나 조직이 추정 단위에 합의하면, 이를 일관되게 구현하고 원래 정의를 고수하기 위해 노력해야 합니다. 특히 프로젝트 초기 단계에서는 모든 구성원이 이러한 단위를 정확한 시간 단위에 매핑하려는 충동을 억제해야 합니다.
이상적인 시간
작업 단위와 마찬가지로, 이상 시간은 프로그래밍 외 시간을 제외합니다. 팀이 추정에 이상 시간을 사용할 때, 다른 기능이나 작업과 비교하여 특정 기능이나 작업을 완료하는 데 필요한 프로그래머 시간만을 명시적으로 지칭하는 것입니다. 다시 말해, 처음 몇 번의 반복 과정에서 추정 이력이 축적되고 실제 속도가 나타나며, 이상 시간을 실제 경과 시간에 매핑할 수 있습니다.
이상적 시간을 사용하는 많은 팀은 최종 작업량이 초기 프로그래머 추정치의 1~2배를 초과하며, 이 수치는 몇 번의 반복을 거치면서 허용 범위 내에서 안정화되는 것을 확인했습니다. 작업별로 비율은 다르지만, 전체 반복 과정에서 팀이 개발한 비율은 상당히 일관되게 유지되는 것으로 나타났습니다. 특정 팀의 경우, 이상적 시간과 실제 시간의 과거 비율을 아는 것은 릴리스 계획에 특히 유용할 수 있습니다. 팀은 필요한 기능을 신속하게 검토하여 200일이라는 대략적인 이상적 시간을 추정할 수 있습니다. 팀의 과거 이상적 시간과 실제 시간의 비율이 약 2.5라면, 팀은 500일이라는 프로젝트 일정을 제출하는 데 상당히 자신감을 가질 수 있습니다. 고정 입찰 시나리오에서는 이러한 추정치가 신뢰할 수 있습니다.
상대 추정
많은 애자일 팀은 특성에 대해 상대 추정을 사용합니다. 다양한 단위 길이에 걸쳐 특성을 추정하는 대신, 몇 가지(3~5개) 상대 추정 범주 또는 버킷을 선택하고 이러한 범주를 기준으로 모든 특성을 추정합니다.
기능 대 작업 계획
계획 초기 단계에서는 속도와 기능별 상대적 작업에 중점을 두지만, 어느 시점에서는 기능을 해당 작업으로 세분화하고 더욱 정확하게 예측해야 합니다. 이는 릴리스 계획과 반복 계획 단계에서 이루어집니다. 일반적으로 기능 예측과 작업 예측은 서로 다른 목적을 갖습니다.
- 기능 추정은 릴리스와 반복 작업 전반에 걸쳐 일정을 조정하는 데 도움이 됩니다.
- 작업 추정은 반복 내에서 리소스 로딩을 촉진하는 데 도움이 됩니다.
각 기능은 서로 다른 용도로 사용되므로, 특정 기능의 추정값이 해당 기능의 작업 추정값 합계와 정확히 일치할 필요는 없습니다. 그러나 여러 기능의 범위에서는 기능 추정값과 해당 기능의 작업 추정값 합계 사이에 적어도 대략적인 상관관계가 있어야 합니다.
자주 묻는 질문
기능의 크기는 얼마입니까?
이는 팀에서 진행하는 개발 작업에 따라 크게 달라질 수 있습니다. 일반적인 경험 법칙은 기능은 반복 작업 내에 완료될 만큼 작으면서도 일정을 정할 만큼 커야 한다는 것입니다. 예를 들어, 10명으로 구성된 팀이 한 달 스프린트를 진행하는 동안 한 시간짜리 기능만 스케줄링하는 것은 바람직하지 않습니다. 스케줄링하고 추적하기에는 항목이 너무 많기 때문입니다. 그렇게 작은 기능 변경 사항이 있는 경우, 스케줄링을 위해 작은 변경 사항들을 하나의 큰 항목으로 그룹화하는 것이 가장 좋습니다. 각 한 시간 분량의 작업은 해당 기능 아래에 작업으로 분류하세요.
버그 수정 기능이 있나요?
그럴 수도 있습니다. 예를 들어 스크럼은 팀이 완료해야 하는 모든 작업을 백로그 목록에 포함해야 한다고 가르칩니다. 버그를 처리하는 일반적인 방법에는 1) 각 버그에 대한 기능 항목을 만드는 것, 2) 각 반복마다 '버그 수정'이라는 기능 항목을 만들고 수정할 버그 목록이나 유형을 자세히 설명하는 것, 3) 버그를 개별적으로 처리하고 버그에 대한 시간을 추적하지 않는 것 등이 있습니다. 팀에서 발생할 것으로 예상되는 버그의 수와 규모는 어떤 방법을 선택할지 결정하는 데 중요한 요소입니다.
왜 특징을 추정해야 하나요?
기능 추정은 릴리스 계획 및 반복 계획에서 순위 지정 및 일정을 결정하는 데 도움이 됩니다. 특정 기간 내에 얼마나 많은 작업을 계획해야 하는지 파악하려면 각 작업의 규모를 추정해야 합니다. 또한 다음을 참조하세요. 민첩한 속도두 기능의 비즈니스 가치가 동일하지만 하나가 다른 하나의 절반 크기인 경우, 팀은 첫 번째 기능에 집중하는 것이 더 효율적이므로 두 번째 기능보다 순위가 높아야 합니다.
작업 추정치가 맞지 않으면 기능 추정치를 업데이트해야 합니까?
아니요, 기능 추정치는 스케줄링을 좌우합니다. 작업 추정치는 리소스 할당을 좌우합니다. 값 사이에 상관관계가 있어야 하지만, 정확하게 일치할 필요는 없습니다.
