Scrum 방법론(애자일) 도입기

 

 

개인적으로 찾아보며 정리한 내용이고 주관적인 생각이 들어있어
오류 사항이나 더 좋은 피드백은 언제나 환영합니다..!

 

 

 

이야기하기에 앞서

 

애자일(agile)이란?

 

애자일이란 소프트웨어 개발 방식의 하나로, 변화하는 요구사항에 유연하게 대응하기 위해 짧은 개발 주기로 제품을 출시하고, 지속적으로 개선하는 소프트웨어 개발 방법론임

 

출처 : 코드스테이츠

 

=> "너무 체계적인 개발론" 과 "너무 계획이 없는 개발론" 둘 사이의 균형을 잡자는 의도로 나온 개발방법론임

주요 특징으로는 
 

• Iterative Development : 기능을 한 번에 다 만드는 것이 아니라, 최소 기능부터 배포하고 지속적으로 개선
  
  
• Customer Collaboration : 개발팀과 고객 간의 긴밀한 협업
  
  
• Flexibility : 요구사항이 변경되더라도 빠르게 반영 가능
  
  
• Continuous Feedback : 매 반복 주기마다 리뷰하고 개선

 

출처 : https://adjh54.tistory.com/147

 

대표적인 애자일 프레임워크로는 Scrum, Kanban 등이 있음

차이점은 위 표에서 확인할 수 있는데

 

스크럼은 초기 MVP(최소 기능 제품)를 빠르게 개발한 후 큰 기능 단위로 추가하는 방식이고
칸반은 작은 기능 단위를 지속적으로 추가하는 방식으로 긴급한 기능 요청이나 유지보수가 많다면 좋은 선택임

 

 

출처 : https://medium.com/hgmin/agile-principles-%EC%95%A0%EC%9E%90%EC%9D%BC-12%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-d3f386bd9839

 

 

그럼 애자일 방식 말고 어떤 개발 방법론이 있을까?

 

Waterfall 방식

 

애자일 등장 전까지 모든 분야 산업에서 보편적으로 워터폴(Waterfall) 개발 방법론을 활용했다는데

 

'요구사항 분석 -> 디자인 -> 개발 -> 검수 -> 배포' 와 같은 방식으로 초기 요구사항이 명확하고 관리가 용이하다는 장점이 있으나, 프로젝트가 끝난 후 제품이 완성됐을 때 결과물이 고객의 기대에 미치지 못할 수 있는 단점이 있음

 

Waterfall의 단점을 봤을 때 애자일 개발 방식은 계획과 개발, 출시와 같은 개발 주기가 작고 여러번 반복되며, 개발 환경에 맞게 요구사항이 추가되거나 변경되고, 결과적으로 고객에게 좀 더 빨리 결과물을 내놓고 고객의 피드백에 민첩하게 반응하게 되는 장점이 있음

 

 

스크럼(Scrum)이란?

 

스크럼이란 애자일 소프트웨어 개발 방법론 중 하나로 '프로젝트를 진행하는 데 있어서 유연성과 적응성'을 강조하는 방법론임

 

• 스크럼은 작은 팀으로 구성되어 각 팀원이 적극적으로 참여하여 프로젝트를 진행하는 방식을 취함
  
  
• 개발 주기를 일정 기간으로 나누어 각 주기마다 일정한 목표를 설정하고 그 목표를 달성하도록 팀원들이 협력하여 일하는 방식을 취함
  
  
• 문제가 발생하면 팀원들끼리 '빠르게 의사소통'하여 '문제를 해결' 하는 것이 스크럼의 핵심

 

스크럼을 사용하면 좋은 이유

 

• 투명성 : 모든 팀원이 작업 진행 상황과 이슈에 대해 인식할 수 있음
  
  
• 적응성 : 팀은 계속해서 변화하는 상황에 대응할 수 있음
  
  
• 생산성 : 스크럼은 팀의 생산성을 높이는 데 도움이 됨
  
  
• 고객 만족도 : 스크럼은 고객 요구사항을 반영하며, 고객 만족도를 높이는 데 도움이 됨
• 지속적인 개선 : 스크럼은 지속적인 개선을 통해 프로젝트의 품질을 높이는 데 도움이 됨

 

스크럼은 어떻게 진행해야할까?

 

우선 스크럼 방법론이 실제 필드에서 어떤식으로 이용되는지를 알아보기 위해 스크럼 방법론의 best practice들을 찾아보았음

 

기본적인 용어들부터 살펴보면

• 스프린트(Sprint) : 스크럼에서 사용되는 일정 기간 (보통 1~4주)을 의미
  
  
• 스프린트 백로그(Sprint Backlog) : 해당 스프린트에서 완료해야 할 작업을 우선순위에 따라 정리한 목록을 의미
  
  
• 제품 백로드(Product Backlog) : 제품의 모든 요구사항을 우선순위에 따라 정리할 목록을 의미
  
  
• 스크럼 이벤트(Scrum events) : 스크럼 프로세스에서 일어나는 이벤트
  
  
  • 스프린트 계획 회의(Sprint Planning Meeting) : 스프린트를 진행하기 전, 해당 스프린트에서 완료해야 할 작업을 선정하는 회의를 의미
    
    
  • 데일리 스크럼 회의(Daily Scrum Meeting) : 매일 진행되는 짧은 회의로, 진행 상황과 문제를 공유하는 회의를 의미
    
    
  • 스프린트 리뷰 미팅(Sprint Review Meeting) : 해당 스프린트에서 개발한 제품의 작동 여부를 검증하는 회의를 의미
    
    
  • 스프린트 회고 미팅(Sprint Retrospective Meeting) : 해당 스프린트에서 진행한 프로세스와 문제점을 검토하고 개선점을 도출하는 회의를 의미

 

스크럼 팀의 역할을 살펴보면 크게

 

출처 : https://www.visual-paradigm.com/scrum/what-is-scrum-team/

 

• 제품 책임자(Product Owner) : 제품 개발 프로젝트에서 고객 또는 사용자와의 의사소통을 중개하고 제품의 우선순위를 결정하는 역할을 수행
  
  
• 스크럼 마스터(Scrum Master) : 스크럼 프로세스를 이해하고, 팀이 스크럼을 잘 수행하도록 도와주는 역할을 수행
  
  
• 개발팀(Development Team) : 제품 개발을 위해 스스로 조직되는 팀이며, 제품 책임자와 스크럼 마스터의 지도를 받는 역할을 수행

 

로 나눌 수 있음

 

---

 

Scrum의 수행과정을 살펴보면

1. 스크럼의 시작은 '스프린트 계획 회의'를 통해서 스프린트(보통 2~4주) 기간을 정함
(팀의 크기나 업무의 복잡도 및 일정에 따라 적절한 스프린트 주기를 찾는 '여러번의 시도' 가 필요함)

=> Sprint Planning

2. 회의에서 제품 개발을 위해 개발 해야 하는 '목표'를 지정하며 목표를 달성하기 위해 스크럼 마스터는 개발팀과 협의를 통해 '백로그'를 작성

=> Sprint Backlog

3. 도출된 백로그를 기반으로 개발팀 내에서 각각 백로그에 대한 역할을 지정

=> Daily Scrum

4. 스프린트를 진행하면서 매일 스탠딩업 미팅(Stand-up Meeting)을 통해 간략한 미팅을 진행

=> Sprint Execution

5. n차의 스프린트 기간이 종료가 되면 스프린트 리뷰 미팅을 통해 리뷰를 진행
(리뷰 기간에는 제품의 작동여부를 검증하며 제품의 책임자와 사용자가 검토하고 승인함)

=> Sprint Review

6. 제품 개발이 종료될 때까지 스프린트는 진행되며 이러한 과정을 반복하며 제품을 완성해나감

=> Sprint Retrospective

 

우리 프로젝트에 맞는 개발론은 무엇일까?

 

우선 학부생인 필자는 자연스럽게 모든 프로젝트를 Waterfall 개발론으로 진행하고 있었음

이게 잘못되었다는게 아니라 개발 방법론의 존재 여부조차 몰랐던 것임😭

현재 애자일(스크럼 개발론)을 도입한 프로젝트는 소규모의 인원으로 진행하는 가계부 어플리케이션임

=> 기존에 사용하던 가계부 어플들의 사소하지만 조금은 불편한 부분들과 가계부를 작성하는 귀찮음을 이기기 쉽지 않다는 한계점을 극복하여 '경제적인 측면에서 여러 긍정적인 영향을 불러일으키자' 라는 생각으로 재학중인 대학교 동기 2명과 후배 1명 총 4명이서 진행하게 되었음

 

애자일(스크럼 개발론)을 생각한 이유는 크게 3가지임

 

1. 운영 단계에서 개발을 통해 버전을 업그레이드 하는 방식으로 진행하고 싶다는 점

 

 

2. 팀원 모두 바쁜 스케줄을 소화하고 있음 (+ 개발할 수 있는 마감 기한이 정해져있음)

1번과 2번의 사유를 토대로 생각해보았을 때 우선 체계적으로 계획을 세우고 개발을 시작할 시간적인 여유가 부족함
계획을 꼼꼼하게 세우지 않겠다는 의미가 아니라

 

다른 가계부 어플리케이션과 차별성을 둘 여러 서비스들을 모두 초기에 계획하고 개발을 완료하여 출시할 시간적인 여유가 부족하다는 뜻 (하반기 부터는 취업해야하는 인원도 있기에)

=> 조금 더 중요 기능들(MVP)에 초점을 맞추고 단계적으로 빠르게 중요 기능들을 붙이며 업그레이드 시켜나가자

 

 

3. 내가 곧 사용자이자 개발자임 (언제든 수정사항이 생길 수 있음 -> 초기계획을 확정지어놓고 개발을 진행할 수 없음)

 

 

결국 이 가계부 관련 어플리케이션을 개발하기로 결심하게 된 계기는 다른 가계부 어플리케이션에서 느낀 사소한 불편함과 한계점 때문임

 

직접 작성하는 가계부부터 통장을 연결하여 사용하는 가계부까지 여러 어플을 실제로 사용해보며
현재도 종종 느껴지는 아쉬운 부분들이 있음

 

그렇기에 개발을 하며 언제든 불편함과 한계점을 느낀 부분에 대해 사용자의 입장에서 스스로 수정사항을 발생시킬 수 있고
이 수정사항은 현재 이용중인 가계부 어플리케이션을 사용하던중 언제든 갑작스레 생길 수 있기에 

 

내가 개발자인 입장에서는 '팀은 계속해서 변화하는 상황에 대응할 수 있다' 라는 적응성과

내가 사용자인 입장에서는 '스크럼은 고객 요구사항을 반영하며, 고객 만족도를 높이는 데 도움이 된다' 라는 고객 만족성

 

에 있어서 Scrum 개발론을 선택하게 되었고

중요 기능들을 추가하며 어느정도 MVP들이 완성되었다면 위에서 다뤘던 Kanban 방식으로 작은 기능 단위를 지속적으로 추가하며 사용자(이 어플리케이션의 개발자 + 실제 이 어플리케이션을 이용할 사용자)의 피드백을 즉각 반영하는 방식으로 진행해야할 것 같음

일단 결론은 시작은 Scrum 개발론으로 진행하고 추후 기능 업데이트는 Kanban으로 전환

 

아니 어쩌피 운영 단계에서 버전 업그레이드하는 방식으로 진행해보고 싶은거면 칸반쓰면 되지않나?

우선 팀 전체가 같은 목표를 향해 달려야 하므로 Scrum을 사용해서 정해진 기간동안 주요 기능(출시 가능한 단위로)을 완성하는데 집중하는 것이 더 좋다고 생각했음

=> 밑에서 다루겠지만 Daily Scrum이 불가능하므로 상호간 피드백 루프가 필요함

추후 주요 기능들이 모두 prod 환경에서 동작하고 있다면 유저 피드백 반영 및 유지보수는 Kanban으로 유연하게 추가하며 빠르게 적용할 수 있는 것이 좋다고 생각

 

정석의 Scrum 개발론?

 

위에서 찾아본 결과 정석의 Scrum을 그대로 프로젝트에 적용시키는데는 여러 문제가 있었음
(애자일을 처음 접해보는거라 잘못된 부분이 있다면 언제든 피드백해주시면 큰 도움이 될 것 같습니다!!)

 

 

우선 팀원이 개발자 4명이라는 사실(프론트2/ 백엔드2)은 곧 스크럼 마스터가 없다는 뜻...

그래서 이 부분에 대해서는 조금은 개별적으로 맡은 테스크에 대한 압박이 들어가지 않아 나태(?) 해질 수 있는 우려가 있고
(아무래도 팀원 모두 바쁜 스케줄을 가지고있다보니..)

(각자 개발에 집중하다 보면) 스크럼을 총괄하며 프로젝트의 진행 사항을 파악하고 이끌어줄 누군가가 존재하지 않기에 팀끼리 조금은 더 서로서로 소통을 많이하며 Daily Scrum으로 극복하는 것으로 나아가야할 것 같다고 느낌

그런데 여기 또 큰 문제가 발생하게되는데 바로 Daily Scrum을 진행할 시간이 안된다는 것임
(군복무, 직장, 학기 수업, 동아리, 대외활동, .... 등의 이유)

 

=> 사실 Daily Scrum이 정말 개발속도 측면에서나 목표를 확인하며 업무 진행 상황을 빠르게 파악할 수 있어 효율적일 것이라고 생각했는데 시간상 Weekly Scrum로 바뀌어버림

 

이 부분에 대해서는 Weekly Scrum에서 스프린트 백로그를 작성할 때 주차별로 task를 쪼개고 파트별로 개개인이 Daily Scrum 처럼 해당 Week 동안 매일 진행되는 Done과 Todo를 적어놓고 스스로 체크하며 Weekly Scrum 때 팀원간 공유하도록하는 진행하는 방식이 괜찮을 것 같다고 느낌

 

결국 Daily Scrum에 비해 진행 상황 공유를 Week 단위로 하기에 조금은 널널하여 개개인이 매일 계획한 Todo를 진행하지 못할 수 있지만 Week 단위로 보았을 때는 하나의 Task이기에 개발 완료 여부에 대해서는 몰아서 개발을 하던 계획한 Todo대로 진행하던 차질은 없다고 생각

 

이 후 기존 Scrum 방식대로 스프린트를 실행하며 정해진 스프린트 기간동안 스프린트 백로그에 맞춰 개발, 테스트, 배포 작업을 수행하고

 

스프린트에서 개발한 기능 점검하고 시연(프론트팀과 백엔드팀 모두의 피드백을 받음) + 스프린트 회고 (개선점 논의)
=> 당연히 해당 팀별 코드리뷰는 함께 진행할 예정

 

이제 막 시작하는 프로젝트라 이런 Scrum 방식에서 발생할 수 있는 문제점 및 단점들은 직접 겪어본 후작성해보도록 하겠음!

 

 

참고 자료

 

https://medium.com/dtevangelist/scrum-dfc6523a3604

[Agile] Scrum(스크럼) 이해하기

https://techblog.gccompany.co.kr/%EC%97%AC%EA%B8%B0%EC%96%B4%EB%95%8C%EA%B0%80-%EA%B0%91%EC%9E%90%EA%B8%B0-%EC%95%A0%EC%9E%90%EC%9D%BC-%ED%95%98%EC%9E%90%EA%B3%A0-%ED%96%88%EB%8B%A4-ee06c4bce323

여기어때가 갑자기 ‘애자일’ 하자고 했다

https://adjh54.tistory.com/147

[개발방법론] 스크럼(Scrum) 방법론 이해하기