소프트웨어 엔지니어링에서 예측 가능성이 속도보다 중요한 이유

기술 세계에서는 속도가 개발 팀의 생산성을 측정하는 기준이 되는 경우가 많습니다. Velocity는 Agile 소프트웨어 개발 에서 팀이 특정 기간 동안 완료할 수 있는 작업량을 측정하는 데 사용되는 평가로, 일반적으로 각 반복에서 완료된 스토리 포인트 또는 사용자 스토리로 표시됩니다. 즉, 팀이 코드를 작성하고 기능을 추진하는 속도에 관한 것입니다. 그러나 속도는 훌륭하지만 균형이 맞지 않으면 결과가 좋지 않고 뒤에서 혼란이 생길 수 있습니다.

서로 수반되어 진행 상황을 추적하는 훌륭한 시스템을 구성하는 다른 측정 방법이 많이 있지만 속도는 여전히 가장 널리 사용되는 측정 중 하나이므로 가장 잘못 적용되는 측정 중 하나입니다.

속도의 매력… 그리고 그 위험

속도가 중심이 되는 경우가 많습니다. 팀은 새로운 기능을 얼마나 빨리 구현하거나 최신 시장 변화에 적응할 수 있는지에 대해 자부심을 느낍니다. 속도에 대한 이러한 추진력은 경쟁사에 뒤처지지 않고 사용자의 참여를 유지하며 지속적으로 혁신하려는 욕구를 나타냅니다. 사고 과정은 간단합니다. 더 빠르게 움직일수록 더 많은 것을 달성하고 이해관계자에게 더 많은 가치를 제공할 수 있습니다.

이제 분석해 보겠습니다. 최고 속도로 나아가는 것은 때때로 훨씬 더 중요한 것, 즉 번아웃을 줄이거나 전혀 없이 일관성 있게 작업할 수 있는 능력을 놓치는 것을 의미할 수 있습니다. 초고층 건물을 초고속으로 건설하지만 기반이 불안정하다고 상상해 보세요. 시간이 지남에 따라 엄청난 기술 혼란이 쌓일 수 있습니다. 이는 나중에 문제가 될 빠른 수정 솔루션에 대한 숨겨진 비용입니다. 물론, 빛처럼 빠른 배송은 매력이 있지만 나중에 가져올 수 있는 골칫거리에 대해 생각해 볼 가치가 있습니다.

예측 가능성: 강력한 도구

측정으로서의 예측 가능성은 팀이나 시스템이 주어진 기간 동안 결과를 제공하는 일관성과 신뢰성을 의미합니다. 팀은 속도를 확대하는 대신 예측 가능성을 높이는 데 초점을 맞춰야 합니다.

여기에는 몇 가지 이유가 있습니다.

• 이해관계자들과 명확한 기대치를 설정합니다.

  한 달에 100포인트, 다음 두 달에는 단 10포인트 등 다양한 결과를 제공하는 팀은 이해관계자들에게 롤러코스터가 될 수 있습니다. 불안정한 결과로 인해 이해관계자들은 다음에 무엇을 기대할지 확신할 수 없는 딜레마에 빠지게 됩니다. 대신, 예를 들어 매달 40점을 지속적으로 제공하는 팀이 MVP가 됩니다. 즉, 그들은 게임에서 신뢰할 수 있는 플레이어가 됩니다. 이것이 바로 비즈니스 영역이 진정으로 원하는 것입니다. 바로 예측 가능성입니다 .

• 오류가 적을수록 게임 시간이 길어집니다.

  예측 불가능성이 때때로 눈부신 빛을 발할 수도 있지만, 장기적으로 진정한 승리를 거두는 것은 예측 가능성의 꾸준함입니다. 문제는 예측 가능성에 대한 로드맵이 보편적이지 않다는 것입니다. 확실히 각 팀에는 고유한 여정이 있습니다. 하지만 최고의 성과를 내는 사람들에게는 패턴이 있습니다.

  
  

  성숙한 애자일 관행은 성과를 예측할 수 있는 팀 사이의 공통 스레드입니다. 스크럼, 칸반 또는 방법론의 혼합에 몰두하든 이들 팀은 핵심에 맞는 리듬을 고정하여 구조화된 작업과 창의적 자유를 위한 공간을 허용했습니다. 반면에, 모든 스프린트나 반복을 이전 것보다 더 빛나게 만들기 위해 향상하려는 끊임없는 추진력이 있습니다.

  
  

  구체적인 예를 생각해 봅시다. Atlassian의 Jira는 단순한 버그 및 문제 추적기로 시작했지만 광범위한 산업에 서비스를 제공하는 세계에서 가장 인기 있는 프로젝트 관리 도구 중 하나로 성장했습니다. 물론 회사의 상승에 역할을 한 수많은 다양한 요소가 있지만 예측 가능성은 가장 중요한 요소 중 하나입니다. 일관된 반복(일관되고 정기적인 업데이트 출시)의 역사, 피드백 루프, 확장 가능한 생태계 및 투명한 로드맵을 통해 Jira는 전 세계적으로 많은 조직에서 입지를 확보했습니다.

균형: 속도와 예측 가능성

이 글에서 나의 최우선 목표는 예측 가능성이 속도보다 중요한 이유를 보여주는 것이지만, 나의 임무는 항상 이 둘 사이의 적절한 균형이 모범 사례라는 점을 언급하는 것입니다. 가장 공정한 측정 방법을 선택할 때 예측 가능성은 의심할 여지 없이 가장 긴 게임을 약속하는 것입니다. 그러나 다면적인 평가 시스템을 구축할 수 있는 능력이 있다면 두 가지(또는 그 이상) 측정값을 교정하는 방법을 찾는 것이 가장 좋은 방법입니다.

최적의 중간 지점을 찾으려면 하이브리드 접근 방식이 필요합니다. 이는 단순히 차이를 나누는 것이 아니라 두 요소를 개발 수명주기에 통합하는 것을 의미합니다. 예를 들어, 반복 개발은 특정 스프린트 동안 폭발적인 속도를 제공할 수 있으며, 예측 가능성과 개선이 우선되는 기간이 뒤따릅니다. 속도와 일관성의 가치를 인식한 팀은 특정 프로젝트 및 단계에 대한 접근 방식을 맞춤화하고 각 장점을 활용하여 적시에 신뢰할 수 있는 제품을 생산할 수 있습니다.

결론적으로, 소프트웨어 영역이 끝없는 부담처럼 느껴져서는 안 된다는 점을 명심하는 것은 어렵지만 정말 중요합니다. 이미 복잡한 엔지니어링 작업이 문제가 있고 때로는 얕은 측정 기준으로 인해 복잡해지면 작업의 진정한 본질이 모호해지고 종종 불필요한 긴장이 고조됩니다. 기술 팀의 책임자라면 성공을 측정하고 직원을 안내하는 방법을 숙고하는 것이 중요합니다. 가장 좋은 방법은 평가하려는 동료 개발자에게 질문하고 계속 확인하는 것입니다.