속도(소프트웨어 개발)
Velocity (software development) | 이 글은 검증을 위해 인용구가 추가로 필요하다.– · · 책· · (2018년 5월)(이 템플릿 과 시기 |
| 다음에 대한 시리즈 일부 |
| 소프트웨어 개발 |
|---|
Velocity는 수행된 작업에 대한 메트릭으로, 신속한 변화를 위한 소프트웨어 개발에 자주 사용된다.[1]
속도 측정은 때때로 속도 추적이라고 불린다.[citation needed]속도 측정계는 스프린트 계획과 팀 성과 측정에 사용된다.
원리
속도 이면의 주요 아이디어는 팀이 이전에 유사한 작업이 얼마나 빨리 완료되었는지에 따라 주어진 시간 내에 얼마나 많은 작업을 완료할 수 있는지 추정할 수 있도록 돕는 것이다.[2]속도는 상대적인 척도다.즉, 원시 숫자는 별 의미가 없다. 중요한 것은 추세다.[3]
용어.
속도 추적에는 다음 용어를 사용한다.
- 작업 단위
- 팀이 속도를 측정하기 위해 선택한 단위.이것은 엔지니어 시간, 엔지니어 일수 또는 PBI(Product Backlog Items)와 같은 실제 단위가 될 수 있다.[4]소프트웨어 개발 프로세스의 각 작업은 선택한 단위로 평가되어야 한다.
- 간격
- 간격은 속도가 측정되는 소프트웨어 개발 프로세스의 각 반복 시간이다.간격의 길이는 팀에 의해 결정된다.가장 흔히 간격은 일주일이지만 한 달 정도 길 수 있다.
비판
속도의 한 가지 문제는 그것이 계획 정확성을 가지고 수행된 일을 공란시킨다는 것이다.다시 말해, 팀은 일을 좀 더 보수적으로 추정함으로써 속도를 부풀릴 수 있다.한 팀이 2시간 걸리거나 2점짜리 대신 4시간 걸리거나 4점짜리라고 하면 속도가 더 좋아 보일 것이다(때로는 포인트 인플레이션이라고도 한다).[5][1]
속도의 두 번째 문제는 사용자 목표 또는 우선순위와의 조정, 품질을 고려하지 않는다는 것이다.좋은 설계, 리팩터링, 코딩 표준, 기술 부채를 소홀히 함으로써 속도를 높일 수 있다.가능한 한 빨리 피쳐를 완성하면 품질에 상관없이 속도가 빨라진다.마찬가지로 속도에는 해당 작업의 이익에 관계없이 수행된 작업이 포함된다.예를 들어, 아무도 원하지 않거나 필요로 하는 기능을 구축하는 것은 여전히 "완료된 작업"으로 간주되며 사용 편의성과 같은 사용자 목표에서 벗어나는 작업 단위를 완성하는 것은 원하는 방향과 반대되는 움직임이다.[citation needed]
속도의 세 번째 문제점은 그것이 종종 효율이나 팀 성과의 척도로 오용된다는 것이다.속도는 수행된 작업의 측정 기준이지 효율성이 아니다.야근이나 팀원 충원 등으로 속도를 높일 수 있는데, 둘 중 어느 것도 반드시 효율이나 성과를 높이지는 않는다.[citation needed]
참조
- ^ a b Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process, Addison-Wesley, ISBN 978-0-13-704329-3
- ^ Glossary of scrum terms: Velocity, archived from the original on 2010-11-29, retrieved 2010-09-24
- ^ Agile 101: Agile Software Development Velocity, VersionOne.com, archived from the original on 2010-10-02, retrieved 2010-09-23
- ^ Measures of size, agilesoftwaredevelopment.com, archived from the original on 2010-10-26, retrieved 2010-09-24
- ^ "point inflation". innolution.com. Retrieved 2019-06-06.
