Hacker News 의견

• 개인적인 경험으로는 스토리 포인트의 숫자는 중요하지 않았지만, 팀이 작업의 복잡성을 평가하는 과정은 매우 유용했음

  • 스토리 포인트를 작업 시간 예측에 사용하는 것은 신뢰할 수 없는 지표였음
  • 팀과 도메인의 변화, 개발 외 작업의 가변성 등 여러 이유로 인해 스토리 포인트를 피하려고 함
  • 스토리 포인트를 사용하는 팀에서는 이를 작업 이해를 공유하는 도구로 사용했음

• Scrum 가이드에서 "Commitment"가 "Forecast"로 변경된 것은 2011년이 아님

  • 2010년과 2011년 가이드를 확인한 결과, "Commitment"라는 단어는 2011년 이전 버전에 없었음
  • "Forecast"는 2020년 가이드에서 "Estimate"를 대체했음

• 작업 패키지를 원자 단위로 분해하고 큐 길이를 측정하는 것은 다른 차원의 문제임

  • 작업 패키지를 팀과 함께 정제하면서 스토리 포인트를 사용할 수 있음
  • 모든 작업을 1 스토리 포인트로 분해하는 것은 비효율적이었음
  • 큐 길이와 가변성의 영향을 연결하는 것은 흥미로운 개념임

• 워터폴 방식과 시간 단위로 추정하는 것이 잘 작동하는 경우도 있음

  • 소규모 전문 서비스 팀에서 고객 요구사항을 문서화하고 팀과 논의한 후 시간 범위로 추정함
  • 고객이 승인하면 상세 설계, 개발, QA, 릴리스 과정을 거침
  • 20년 동안 프로세스가 변하지 않았고, 생산성이 높은 팀으로 평가받음

• 스토리 포인트는 시간 단위가 아닌 상대적 복잡성과 불확실성을 나타냄

  • 큰 숫자로 스토리를 측정할 수 있어야 함
  • 일부 팀에서는 7 이상의 포인트를 주지 않음
  • 다른 곳에서는 21, 30, 50 포인트를 주기도 했음

• 스토리 포인트는 대략적인 시간 단위였음

  • 스토리 포인트를 명확한 시간 단위로 맞추는 것은 오해의 소지가 있음
  • 개발자가 작업에 얼마나 시간을 쓸지 예측하는 것이 중요함
  • 큐 분석이 도움이 되려면 각 작업의 예상 시간을 알아야 함

• Scrum을 처음 사용할 때 Rally를 사용했음

  • 스토리 포인트, 예상 시간, 실제 시간을 모두 추적했음
  • Jira로 전환 후 시간 추적이 없어졌음
  • 예상 시간이 정확해지면서 팀의 작업 균형을 맞추기 쉬워졌음

• 스토리 포인트는 작업 복잡성을 논의할 때 유용하지만, 속도를 측정하는 데는 부적합했음

  • 새로운 엔지니어로서 많은 스토리 포인트를 처리했지만, 관리진이 이를 조정하려 했음
  • 복잡한 작업을 적절히 평가하기 어려웠음

• 소프트웨어 개발 프로젝트를 신뢰할 수 있게 추정하는 것은 어려움

  • 팀과 함께 작업을 작은 단위로 나누고 시간 범위를 추정하는 것이 중요함
  • 프로젝트가 진행됨에 따라 기능 목록과 새로운 추정 범위를 보고하는 것이 중요함

• 시간 단위로 추정하는 것이 더 나은 방법임

  • 스토리 포인트는 결국 시간 단위로 변환됨
  • Scrum의 복잡한 절차를 피하고 작업을 완료하는 것이 더 효율적임