Page Comparison

이슈에 첨부 파일 추가

첨부 파일은 텍스트가 제공할 수 없는 이슈에 컨텍스트를 제공합니다.

이슈에 첨부 파일을 추가하려면:

1. 이슈를 엽니다.

2. 파일을 이슈에 드래그&드롭 합니다.

또는 다음을 수행할 수 있습니다.

1. 이슈를 엽니다.

2. 아래쪽으로 스크롤하여 첨부 파일 섹션으로 이동한 후 +를 클릭합니다.

3. 파일 업로드를 클릭하거나 파일을 미디어 선택기에 드래그&드롭 합니다.

 이슈에 대한 첨부 파일 삭제

첨부파일이 더 이상 필요하지 않으면 이슈에서 제거하여 잡음을 줄일 수 있습니다. 자신이 추가한 첨부 파일만 삭제할 수 있습니다.

첨부 파일을 삭제하려면:

1. 이슈를 엽니다.

2. 삭제할 첨부 파일을 찾아 마우스를 올리십시오.

3. 삭제를 클릭합니다.

이슈에서 첨부 파일 다운로드

첨부 파일은 설명 필드 및 활동 섹션에서 개별적으로 이슈 보기에 표시됩니다. 첨부 파일 섹션에도 함께 표시되며, 여기서 이슈에 대한 모든 첨부 파일을 찾을 수 있습니다.

이슈에서 첨부 파일을 다운로드하려면:

1. 이슈를 엽니다.

2. 다운로드할 첨부 파일을 찾아 마우스를 올리십시오.

3. 다운로드를 클릭합니다.

첨부 파일 패널의 모든 첨부 파일 다운로드

이슈의 첨부파일 섹션에 있는 모든 첨부파일을 한 번에 다운로드하여 검토할 수 있습니다.

이슈에 대한 모든 첨부 파일을 다운로드하려면:

1. 이슈를 엽니다.

2. 첨부파일 섹션을 찾아 ···를 선택합니다.

3. 모두 다운로드를 클릭합니다. 오른쪽 번호는 장치에 다운로드할 첨부 파일 수를 표시합니다.

이것은 첨부파일 섹션의 모든 첨부파일을 다운로드하지만 이슈 필드 및 주석을 포함하지는 않습니다.

이슈를 추정

시작하기 전에

백로그의 스토리를 예측하면 백로그의 특정 부분을 전달하는 데 걸리는 시간이 얼마나 되는지 예측할 수 있습니다. 이 토론은 Jira Software의주요 경로로 구현한 모범 사례를 나타냅니다. 팀에 적합하지 않다고 생각되면 이 방법을 사용하지 않도록 선택할 수 있습니다.

이슈 추정

스프린트가 시작되기 전에 이슈에 대한 추정치를 입력해야 합니다.

추정치를 입력하려면:

1. 스크럼 프로젝트의 백로그로 이동합니다.

2. 이슈를 선택하고 스토리 포인트 또는 원래 추정치 필드에 (설정한 추정 통계량에 따라) 견적을 입력합니다.

Image Modified

1. 선택한 이슈: 오른쪽에 있는 세부 정보를 보려면 이슈를 선택합니다.

2. 추정 필드: 추정 통계에 따라 스토리 포인트 또는 시간 추정치를 입력합니다.

시간 기록 및 나머지 추정치 조정

스프린트 중에 이슈에 대해 작업할 때 시간을 기록하고 필요한 경우 남은 시간 예상을 조정할 수 있습니다. 기록 시간은 Jira에서 보고하는 데 사용할 수 있는 귀중한 정보를 제공합니다.

1. 스크럼 보드의 활성 스프린트로 이동합니다.

2. 이슈를 선택하고 > 로그 작업(또는 시간 추적)필드를 클릭합니다.

3. 남은 시간과 시간을 입력한 다음 저장을클릭합니다.

번다운 차트를 사용하는 경우 보드에 대해 남은 추정치와 소요 시간이 활성화되었는지 여부에 따라 하위 작업 동작이 달라질 수 있습니다.

자세한 내용은 번다운 차트를 참조하십시오.

추정에 대한 개념

다음은 Jira Software에서 이슈를 추정할 때 고려해야 할 몇 가지 개념입니다.

추정은 추적과 다릅니다.

스크럼에서는 추정과 추적 사이에 차이가 있습니다. 추정은 일반적으로 1차 백로그 항목(PI, 보통 이야기)에 대해 수행되며, 백로그의 일부가 전달되는 데 얼마나 걸릴 수 있는지 계산하는데 사용됩니다. 추적은 스프린트에 포함된 모든 이야기가 전달될 수 있도록 스프린트의 진행 상황을 모니터링하는 것을 말합니다.

추적은 종종 스토리를 작업으로 세분화하여 스프린트 계획 중에 시간당 추정치를 적용하고, 스프린트 동안 남은 시간을 번다운에서 모니터링하는 방식으로 수행됩니다.

기존 개발 환경에서는 어떻게 추정합니까?

기존 개발 환경에서는 다음과 같은 방식으로 추정이 수행됩니다:

1. 팀은 ‘맨-아워’로 항목을 추정하며 이러한 추정치는 정확하다고 가정합니다.

2. 팀은 프로젝트의 백로그에 대한 총 인력 수를 계산합니다.

3. 총 인력 수를 팀원 수, 그리고 일주일 동안의 업무시간으로 나눕니다. 이것이 그 프로젝트의 예상 날짜가 됩니다

이러한 추정치는 다음과 같은 사항을 고려하지 않기 때문에 부정확한 경우가 많습니다:

• 팀의 자연 추정 특성 – 의미, 과대 평가 및 과소 평가는 고려되지 않습니다.

• 항목에 할당된 작업 시간 동안 예기치 않은 중단

• 시간이 지남에 따라 팀 구성원의 성과

추정치가 부정확해지면 팀은 추정치를 정확하게 '강제'하는데 시간과 노력을 기울입니다. 이것은 불가능하지는 않더라도, 업무시간 접근법을 어렵게 만듭니다.

스크럼 세계에서의 추정은 모두 속도에 관한 것입니다.

스크럼 세계에서는 팀들이 추정 정확도를 얻으려고 노력하지 않습니다. 대신 '신속한' 달성을 목표로 합니다.

속도는 팀이 스프린트에서 스프린트까지 완료하는 경향이 있는 추정 단위 수를 측정한 것입니다. 처음 몇 번의 스프린트를 치른 후 대부분의 팀들은 상당히 일관된 속도를 달성할 것입니다. 백로그에서 PBI에 대한 속도와 추정치로 무장한 팀은 백로그의 일부가 완료되기까지 얼마나 걸릴지 더 정확하게 예측할 수 있습니다.

중요한 것은 스프린트에서 스프린트까지 합리적으로 예측할 수 있게되는 한 추정 단위는 중요하지 않다는 것입니다. 예를 들어, 팀은 '이상적인 시간' 추정치를 사용할 수 있지만, 이러한 시간이 경과된 시간과 어떤 관계를 가질 필요는 없고 기대하지도 않습니다. 팀이 각 스프린트에서 120h의 '맨아워' 용량을 가지고 있지만 속도가 60h인 경우, 60h 속도를 사용하여 백로그의 일부가 완료되는데 걸리는 스프린트 수를 추정할 수 있기 때문에 경과된 시간만큼 차이가 없습니다.

많은 사람들이 '나머지 60시간'이 어디로 갔는지 궁금해하기 시작하는데, 이는 팀 생산성에 문제가 있음을 암시합니다. 그러나 그것은 일반적으로 아무 상관이 없습니다: 팀의 추정치는 팀의 자연적인 행동(과잉 및 과소평가 등)과 조직적인 오버헤드 등을 고려하여, 얼마나 어려운 항목이 될 것인가에 대한 그들의 관점을 나타낼 뿐입니다. 속도는 계획 관점에서 중요한 모든 것입니다.

단위는 시간과 관련이 없기 때문에, 대부분의 팀들은 현재 스토리 포인트를 추정 단위로 선택합니다. 스토리 포인트는 다른 스토리를 기준으로 한 스토리의 복잡성을 측정하는 임의의 숫자입니다. 실제로 스토리 포인트는 시간과의 정신적 고리를 분명히 깨뜨릴 수 있습니다.

부정확한 추정치는 일관적으로 부정확하면 좋습니다.

팀의 속도가 안정적으로 유지되려면 각 백로그 항목을 동일한 수준의 정확도로 추정해야 합니다. 뻔한 것을 반복할 위험을 무릅쓰고, 속도의 목표는 특별히 잘 이해되지 않은 스토리의 뒷줄기를 볼 수 있고, 그것을 완성하는 데 얼마나 많은 스프린트가 필요할지 이해할 수 있는 것입니다. 이를 위해서는 백로그의 모든 추정치에 대해 비슷한 수준의 불확실성이 필요합니다.

여기에는 팀들이 각 항목을 한 번 추정해야 한다는 직관에 반하는 암시가 있는데, 이는 팀이 원래 견적이 잘못되었다고 느끼게 하는 항목에 대한 새로운 정보를 발견하더라도 해당 견적을 변경해서는 안 된다는 것입니다. 만약 팀이 계속해서 추정치를 갱신한다면, 이러한 '새로운 정보의 발견'은 정기적으로 일어날 것입니다. 이로 인해 백로그의 정확도가 높아질 것이라 생각하겠지만 대부분은 그렇지 않습니다. 이는 높은 정확도 추정치의 더 큰 비율을 가진 스프린트가 높은 정확도 추정치의 낮은 비율에 비해 다른 수의 단위를 완료하기 때문에 속도를 오염시킬 것입니다. 결과적으로, 속도는 그것의 주된 목적, 즉 팀이 백로그에서 잘 이해되지 않는 일련의 스토리를 완성하는데 걸리는 스프린트 수를 추정하기 위해 사용될 수 없게 됩니다. 따라서 팀의 속도가 현실적으로 미래에 앞서 잘 이해되지 않은 작업의 특정 수를 완료하는 능력을 나타낼 수 있도록 첫 번째 추정을 사용하는 것이 중요합니다.

팀이 틀렸다는 것을 깨닫게 되면 어떨까요?

다음 시나리오를 고려하십시오:

• 이슈 X의 원래 추정치는 5일입니다.

• 다음 스프린트를 계획하기 전에 팀은 원래 추정치가 너무 낙관적이며 실제로 이슈가 15일이 걸린다는 것을 깨닫습니다.

일부 사람들은 원래 추정치를 사용하는 것이 스프린트의 성공을 위태롭게 할 것이라고 주장할 것입니다. 왜냐하면 팀은 실제로 15일 동안 해야 할 작업을 5일 동안 해야 할 것이기 때문이죠.

그러나 부정확한 추정치인 5일이 고립된 사건은 아닐 것으로 보입니다. 사실, 추정치는 항상 틀릴 겁니다. 이것은 스프린트가 시작된 후에 종종 발견됩니다. 팀이 전체 백로그에서 같은 방법으로 추정하는 한, 이것은 시간이 지남에 따라 저절로 해결될 것입니다. 예를 들어, 만약 항상 과소평가하는 경우 4명의 팀원이 있는 10일간의 스프린트를 실행 할 때, 그들은 단지 20일의 추정 단위를 약속할 수 있습니다. 만약 그들이 안정된 속도를 확립했다면, 이것은 아무런 효과도 없게 됩니다. 계획적인 관점에서, 우리는 여전히 다가오는 스프린트에서 우리가 얼마나 많은 일을 할 것인지를 신뢰성 있게 예측할 수 있습니다.

스프린트 의지를 깨뜨리지 않습니까?

팀이 스프린트를 시작하려고 할 때, 그들은 속도를 현실적으로 완료할 수 있는 백로그 항목의 표시로 사용할 수 있습니다. 이 속도는 과거에 성공적으로 완료한 항목 수를 기준으로 합니다. 그러나 어떤 사람들은 원래 추정치에 이미 수행 된 작업에 대한 정보 또는 특정 작업 항목이 얼마나 어려운지에 대한 정보를 포함하지 않을 때 이것이 어떻게 옳을 수 있는지 의문을 제기 할 수 있습니다.

예를 들어 다음 시나리오를 고려하십시오:

• 이슈의 원래 추정치는 10일입니다.

• 팀은 현재 스프린트에서 이 이슈를 5일 동안 작업합니다.

• 팀은 프로젝트의 다른 곳에서 나쁜 버그를 발견하고, 그들은 현재 스프린트에서 버그를 해결하는 것이 계획대로 이슈 X를 완료하는 것보다 훨씬 더 중요하다고 결정합니다.

• 스프린트가 끝나고 이슈가 백로그로 돌아갑니다.

다음 스프린트에서 팀은 이 이슈에 대한 추정치를 5일로 업데이트하고 이를 사용하여 스프린트에 포함할지 여부를 결정하도록 유혹을 받게 될 것입니다. 만약 그들이 이 이슈의 원래 추정치인 10일을 사용한다면 다음 스프린트에 충분한 작업을 포함하지 않을 수 있다는 의미입니다. 그러나 이전에 작업이 완료되지 않은 이유는 계획되지 않은 작업 때문이며, 아마도 다음 스프린트에서도 이런 일이 다시는 일어나지 않을 것이라고 가정하는 것은 비현실적입니다. 따라서, 10일 추정치는 확실성이 없는 경우 사용할 수 있는 현실적인 숫자입니다. 결과적으로, 발생할 수 있는 계획되지 않은 작업의 비용은 결국 원래 견적서에 설명됩니다. 다음 스프린트에 대한 작업이 충분하지 않은 것으로 판명되더라도 팀은 더 많은 작업을 스프린트로 끌어들여 이를 수정합니다.

같은 예에서, 이것이 해당 스프린트에서 유일한 이슈였고 다음 번에 유일한 이슈가 될 것인지 고려하십시오. 두 번째 스프린트에서 이슈가 완료되고 나머지 추정치를 사용하는 경우 속도는 (0d+5d)/2=2.5d가 됩니다. 그러나 팀은 향후 스프린트보다 더 많은 작업을 완료할 수 있습니다. 원래 추정치를 사용하는 경우 속도(0d+10d)/2=5d가 됩니다. 원래 추정치를 사용하면 계획되지 않은 작업이 불가능할 가능성이 있기 때문에 팀이 모든 스프린트에서 10d를 투입할 수 없다는 사실을 설명합니다. 또한 모든 스프린트에서 계획되지 않은 작업이 일어나지 않을 것이라는 사실을 현실적으로 설명합니다.

하위 작업을 추정하고 속도와 커밋을 위해 롤업하는 것은 어떨까요?

많은 팀이 스프린트가 시작되기 직전에 스토리를 하위 작업으로 분할하여 스토리를 추적에 사용할 수 있습니다. 이것은 스프린트 (그리고 잠재적으로 속도를 위해)에서 어떤 이슈를 커밋 할 것인지 결정하는 방법으로 하위 작업에 대한 추정의 합계를 사용할 가능성을 높입니다.

위에서 설명한 것처럼 추적은 실제로 추정 및 속도와는 별개의 프로세스입니다. 하위 작업에 적용된 추정치는 원래 스토리에 적용된 추정치보다 정확도가 더 높습니다. 속도를 위해 그것들을 사용하면 도가 높은 정확도와 낮은 정확도 추정치를 둘 다 갖게 되고, 낮은 정확도 추정치만을 가지고 있는 백로그에서 더 자세히 살펴볼 수 없게됩니다.

또한 백 로그의 맨 위에있는 항목만 작업으로 분류되었을 가능성이 있습니다. 속도에 대한 작업 추정치를 사용한다는 것은 속도 값이 작업으로 분할된 마지막 스토리까지 백 로그를 완료하는데 걸리는 시간만 예측할 수 있음을 의미합니다.

마지막으로, 속도 값과 달리 계획되지 않은 작업 및 중단의 오버헤드를 고려하지 않기 때문에 하위 작업 롤업을 사용하여 스프린트 약속을 결정하는 것은 위험합니다.

스토리 포인트 활용 - 팀에 적합한 스토리 포인트 활용

점점 더 많은 업계 리더들이 시간 추정에서 벗어나 스토리 포인트 접근 방식을 사용하고 있습니다. 스프린트에서 답변해야 할 주요 질문은 다음과 같습니다:

• 이 스프린트를 완료하기 위해 현실적으로 얼마나 많은 작업을 할 수 있습니까?

• 백 로그의 이 부분이 전달되는 데 얼마나 걸립니까?

원래 추정치를 기반으로 한 스토리 포인트 접근 방식은 팀이 몇 시간  안에 추정을 요청했을 때 느끼는 '정확성'에 대한 불안감 없이 이러한 질문에 대한 답을 제공 할 수 있습니다.

Jira Software 팀 자체는 이 기사에 설명 된 접근 방식을 사용하며, 우리가 몇 달 전에 작업 계획을 세우는 데 사용하는 신뢰할 수 있는 속도를 확립했습니다. 심지어 그 몇 달 동안 새로운 작업을 접했을 때에도 말이죠. 이 방법은 때때로 직관적이지 않지만 강력하고 빠르며 간단하기 때문에 권장됩니다.

즉, 애자일의 핵심 교훈 중 하나는 자신에게 적합한 방법을 찾는 것입니다. 따라서 Jira Software는 스프린트 약속, 추정 시간 및 하위 작업 시간에 대한 나머지 추정치의 사용을 포함하여 위에서 설명한 대안을 지원합니다.

이슈 플래그 지정

이슈에 플래그를 지정하여 그것이 중요하다는 것을 나타낼 수 있습니다. 스크럼 백로그, 스크럼 보드의 활성 스프린트, 칸반 백로그(활성화된 경우), 칸반 보드(활성화된 경우)에 플래그(flag) 아이콘이 우선 순위 아이콘을 대체하여 빨간색으로 표시됩니다.