애자일 방법론 스크럼 - 특징, 적용, 칸반&스크럼, 의견

스크럼은 애자일 방법론의 하위 방법론 중에 하나입니다.

소프트웨어 개발을 작은 단위의 개발 주기인 스프린트를 통해 제품을 지속적으로 개발하고 변화에 대응합니다. 

 

스크럼은 가장 어려운 방법론 같은 느낌입니다. 책이나 강의를 들어도 원론적인 이야기들 뿐이니, 실제 조직에서의 활용은 말처럼 쉽지만은 않습니다. 

[목차]

• 특징
• 적용 방법
• 칸반,스크럼
• 의견

특징

• 자기조직화된 팀 
  • 스크럼은 팀원들이 자율적으로 업무를 할당하고 조율하며 실행할 수 있는 환경을 지향합니다. 
  • 팀은 스스로 문제를 해결하고 업무를 진행합니다. 
• 반복적인 개발 주기 ( 스프린트 ) 
  • 스크럼은 짧은 개발 주기인 스프린트를 갖추고, 각 스프린트는 고객 가치를 전달할 수 있는 완전한 제품 기능을 제공합니다.
• 역할 ( 스크럼 마스터, 제품 책임자, 팀 멤버 ) 
  • 스크럼에는 특정한 역할인 스크럼 마스터, 제품 책임자, 팀 멤버의 역할과 책임이 명확히 정의되어 있습니다.
• 스크럼 이벤트 ( 스프린트 계획 회의, 스프린트 리뷰 등 )  
  • 스크럼은 스프린트 계획 회의, 데일리 스탠드업, 스프린트 리뷰 등 다양한 이벤트를 통해 팀의 협업과 제품의 진행 상황을 관리합니다. 

적용 방법

1. 스크럼 팀 구성
   • 스크럼 마스터 선정 : 스크럼 마스터는 팀의 스크럼 프로세스를 이끄는 역할을 합니다. 
   • 제품 책임자 식별 : 제품 책임자는 제품의 비전과 요구사항을 정의하고, 팀과 함께 제품을 개발하는 데 필요한 우선순위를 결정합니다. 
   • 스크럼 팀 구성 : 개발 팀은 스크럼을 수행할 준비가 된 다양한 역량과 전문성을 가진 구성원으로 이뤄져야 합니다. 
2. 제품 백로그 관리 
   • 제품 백로그 관리 : 제품 책임자와 팀은 제품에 대한 요구사항과 기능을 문서화하고 우선순위를 정하며 이를 제품 백로그로 관리합니다. 
   • 백록 상세화 : 백로그 아이템은 자세한 설명과 팀이 이해할 수 있는 정도로 세부화되어야 합니다.
3. 스프린트 계획 
   • 스프린트 목표 설정 : 제품 백로그에서 가장 중요하거나 긴급한 항목들을 선택하여 해당 스프린트의 목표를 설정합니다. 
   • 작업 아이템 선정 : 팀은 선택된 목표에 도달하기 위해 수행할 작업을 결정하고 그에 따른 계획을 수립합니다. 
4. 스프린트 실행
   • 데일리 스탠드업 ( 일일 회의 ) : 매일 짧게 15분 이내로 진행되는 회의에서 팀은 자신의 작업 상황, 어려움, 협력이 필요한 부분 등을 공유합니다. 
   • 작업 진행 및 추적 : 각 팀원들은 계획된 작업을 수행하고, 스프린트 진행 상황을 스크럼 보드나 다른 시각화 도구를 통해 추적합니다. 
5. 스프린트 검토 및 회고 
   • 스프린트 리뷰 : 스프린트가 끝나면 완성된 작업물 ( 동작되는 소프트웨어 )을 검토하고, 제품이나 기능에 대한 피드백을 수렴합니다. 
   • 스프린트 회고 : 팀은 스프린트에서 배운 점과 개선할 점을 공유하고, 다음 스프린트에 적용할 수 있는 방법을 찾습니다. 

칸반 vs 스크럼

• 칸반과 스크럼의 기본 원리 비교 
  • 칸반 : 지속적인 흐름을 중시 
  • 스크럼 : 일정한 주기의 스프린트를 중시 
• 업무 관리 방법 
  • 칸반 : 작업 흐름을 시각화하여 관리 
  • 스크럼 : 스프린트를 통해 제품을 개발하는 것을 강조 
• 장점 
  • 칸반 : 유연성과 시각적 투명성 제공
  • 스크럼 : 명확한 역할과 스케줄을 제공하여 예측 가능성을 높임

의견

다른 방법론 보다 좀 길게 작성했습니다. 

그 이유는 현재 최고의 인기 방법론이기 때문입니다. 

제가 아는 개발회사들 중에 애자일을 따르지 않는 회사는 없습니다. 

하지만, 제대로 운영되는지는 잘 모르겠습니다. 

다른 방법론들은 팀장 같은 리더가 잘 이끌면, 구성원들은 무슨 방법론을 따르는지 인지하지 못한 상태에서도 개발 업무가 잘 되기도 합니다. 

하지만 애자일 방법론 중 스크럼만큼은 그게 잘 안됩니다. 

스크럼을 적용하는 방법들 중에 기술적인 부분들은 참고할 곳이 많으니 그런 내용은 기술하지 않겠습니다. 

 

제가 적용해 보면서 가장 어렵고 힘들었던 부분은 다름 아닌 구성원들을 스크럼, 스프린트에 적응시키는 것이었습니다. 

데일리 미팅 같은 경우는 이미 운영하는 조직도 많이 있으니, 진행하는데 크게 무리는 없습니다. 

스프린트를 시작하면 여러 이벤트( 편하게 회의라고 합니다. )를 진행할 때 구성원들은 본인이 하고 있는 작업을 명확하게 이야기하고 다른 사람의 작업 이야기를 경청해야 합니다. 

특히, 스프린트 리뷰 때는 스프린트에서 잘 못 된 점 그리고, 개선할 점이 무엇인지 의견을 말해야 합니다. 

하지만 이런 기본적인 것들을 말하는 것에서부터 익숙해지지가 않습니다.

본인의 의견을 논리 있게 말한다는 것 더욱이 짧게 요약한다는 것은 참으로 어렵고 어색하고 익숙해지지 않습니다.

 

그래서, 스크럼 팀은 작게 운영해야 합니다. 그렇게 운영하면서 다른 조직에게 보여줘야 합니다. 

그래야 조금씩 변화가 생깁니다. 물론 좋은 성과는 당연히 있어야 됩니다. 

스크럼의 전체 흐름만 따르려고 노력하고, 디테일한 부분들은 천천히 개선하시는 것을 추천드립니다. 

 

회사 차원에서의 지원도 빼놓을 수 없습니다.  스프린트가 온전히 운영되려면 배려가 필요합니다. 

레거시 시스템 운영 업무를 조금 덜어 준다던지, 사내 기준 설계 문서의 수준을 조금 적게 적용해 주는 것 같은 것들을 말합니다. 

 

당부의 말씀 ) 스크럼을 적용하다 보면 유독 힘들어하는 구성원이 반드시 생깁니다. 이런 분들께는 많은 배려가 필요합니다.  

적응될 때까지는 마스터(리더)분들이 그분들에게 적당한 질문을 먼저 해서 말하는 게 자연스러워질 때까지 기다려 주십시오.