스크럼(Scrum) 개발 방법론에 대해서..

최근에 스크럼이란 개발 방법론을 이용하여 프로젝트를 관리하고 개발을 진행하고 있습니다.

이번에 KGC에도 보니 유명하신 분이 이 스크럼에 대해서 강연을 하신 것 같습니다.

저는 그것을 듣지 못했지만 제가 경험했던 내용들에 대해서 간단하게 적고자 합니다.


사실 저도 스크럼에 대한 문서가 있지만 처음부터 끝까지 읽어보지는 않았습니다.

실제 실무를 통하여 대부분을 접하였고 그에 대한 후기를 써보고자 합니다.

자세한 분석이 아닌 후기이기 때문에 간단하게 봐주시길 바랍니다.

여러 가지로 사실과 틀린 내용이 있더라도 지적해주시고 이해해주셨으면 좋겠습니다.


* 장점

1. 시각적으로 작업 사항을 한눈에 파악 할 수 있다.

2. 서로 어떤 것을 작업하는지 잘 알 수 있고 도와 가면서 작업을 분배해 가면서 효율적으로
  일할 수 있다.

3. 일정과 관련하여 처음에 작업을 시작할 때 충분히 작업에 대한 일정 예측이 가능하며
  작업 중간중간 일정 변경이 다소 유연하다.

* 단점

1. 일주일 작업량인데 하루 종일 회의를 회의를 하는 것은 비효율적이라고 생각된다.
   (처음 백로그 만들 때) 우리 같은 경우 팀 전체 회의와 스크럼 회의가 따로 있기 때문에
  회의 시간이 비교적 많이 들었다.
  생각보다 커뮤니케이션 하는데 소모되는 비용이 많지 않나 싶다.

2. 서로 간의 작업 공유가 잘 되어 있어야 한다. 다른 사람이 만든 코드도 알아야 한다.
   다른 사람이 만든 코드를 만들어야 하는데 내가 모른다면 작업 예측 시간보다 더 오래
   걸릴 수도 있고 치명적인 버그를 만들어 낼 수 있다.
    실제 우리 회사의 경우는 클라, 서버 프로그래머 구분 짓지 않고 어떤 작업이 있으면
   그것을 한사람이 다 작업할 수 있도록 멀티플레어가 되어 가는 듯 싶다.

3. 아날로그 방식이기 때문에 어떤 식으로든 진행한 내용을 디지털화 시켜서
    백업을 해둘 필요가 있다.


만약 제가 그리 규모가 크지 않은 프로그램팀을 꾸린다고 가정하겠습니다.

그리고 여러 가지 시스템이 완전히 초기 상태로 처음부터 다 개발을 해야한다고 합니다

그렇다면 저는 개발 방법으로 스크럼을 쓰고 실제 세부적인 작업이나 버그 관리는

멘티스를 통해 하겠습니다. 그리고 위키나 공유 폴더로 기획서나 개발 문서를 공유하는

방식으로 팀의 업무를 진행하지 않을까 생각합니다.

전체적인 일정은 엑셀로 공유를 해야 할 수 있겠네요. 스크럼에 참여하지 않는 사람들은

엑셀로 작업이나 일정관리를 할 수 있게 지원해야 할 것 같습니다.

이렇게 많은 좋은 프로그램과 툴, 여러 가지 시스템이 나와 있기 때문에 아무것도 없는

상태에서 시작하더라도 간단하게 개발 프로세스를 구축 해서 진행을 할 수 있을 것 같습니다.

[‘매스이펙트’로 살펴보는 스크럼 방법론]