ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 애자일 스크럼은 생각보다 어렵다
    2015. 12. 3. 0 comments

    개발팀에서 이제는 전통적인 waterfall 방식을 사용하는 경우는 많지 않을 것 같다. 스크럼은 애자일 개발 프로세스 중 하나를 말한다. 개인이 아닌 팀으로 활동하게 된다면 대부분 애자일 프로세스를 알거나 취하고 있을 것이다. 임기 응변식의 대응이 아닌, 체계적이고 변화에 대응하기 위해 팀에서 약 1년 반동안 스크럼을 반영하고 활용해가면서 느꼈던 여러가지를 글로 남긴다.



    무엇이 좋은가?

    첫째, 스프린트 계획 회의를 통해서 팀 전체가 정량의 업무를 정하고 논의할 수 있다.


    둘째, 매일 스크럼(Daily scrum) 회의를 통해서 팀원간 업무 진행을 잘 알 수 있고 필요한 사항들을 공식적으로 요청할 수 있다. 


    셋째, 개발자 본인이 능동적으로 할당받은 업무에 대해서 세부 할 일들을 계획하고 실행할 수 있다.

    특별한 경우가 아니라면 개발자 본인에게 자유롭게 세부 업무와 업무 순서를 계획할 수 있도록 한다. 


    넷째, 스프린트 리뷰를 통해서 각자가 "완료"한 일을 공유하고 논의함으로써 산출물의 품질을 높일 수 있다.





    무엇이 아쉬운가?

    첫째, 스크럼은 긴급 요청 업무에 대해서 매우 취약하다.

    스프린트 주기를 2주 단위로 운영하였다. 그 기간 동안 실시간으로 급하게 들어오는 요청을 누가 처리하느냐가 관건이다. 긴급 업무를 동료에게 할당하면 되지만 반복되면 결국 스프린트 계획을 재조정하는 사태가 발생하기 때문이다. 처음에는 어쩔수 없이 스크럼 마스터(팀장)가 혼자서 긴급 요청 업무를 처리했다. 하지만 팀원 관리를 병행 하면서 긴급 업무들을 소화해내기는 어려운 일이었다. 긴급 업무 처리가 점차적으로 지연되었었지만 스크럼 마스터의 야근은 계속 반복되었기에 스크럼은 긴급 요청 업무에 매우 취약하다라는걸 깨닫게 되었다.

     

    이를 대처하기 위해서 우리는 스프린트 기간에 실시간 긴급 업무를 진행하는 사람을 결정했다. 스프린트 주기로 돌아가면서 1명을 지정 하였고, 스크럼 마스터과 함께 긴급 업무 처리가 가능해졌다. 하지만 곧 부작용들이 나타나기 시작했다. 예를 들어 약 한달이상의 시간이 소요되는 주요 개발 업무들을 맡게 된 팀원들은 생산성과 효율을 위해 긴급 업무를 진행하지 못하게 된다. 스프린트 주기인 2주가 넘어가게 되면 다른 개발자에게 업무를 양도하는 방안을 냈지만 대부분의 팀 동료들은 이 의견에 반대했다. 자신이 시작한 업무에 대해서 다른 사람이 마무리 짓는 것은 옳지 않다고 판단했기 때문이다. 이런 패턴은 업무를 빨리 끝내게 하기 위해서 경험이 많은 개발자가 계속 주요 업무를 맡게 되는 경향이 생긴다. 


    약 반년간의 업무 소요 시간을 확인해본 결과,  대부분의 업무가 한달 이상은 넘지 않는다는걸 알게 되었다. 긴급 업무 처리 담당은 1달은 진행하도록 규칙을 변경했다. 

    지금은 이 변화가 효과적인지 지켜보고 있는 중이다. 



    둘째, 추정은 너무나도 어렵고  일정 재조정을 자주 하게 된다.

    팀 동료들이 모두 5년 이상의 개발 경험과 자신있는 언어를 자유자재로 구사하는 풍부한 경험을 갖고 있는 사람들로 구성되어 있지 않다. 1년안에 동료가 떠나기도 하고 새롭게 맞이하는 동료들도 종종 나타난다. 그렇기 때문에 팀에서 다루는 다양한 모듈들을 모든 팀원이 모두 자세하게 알지 못한다. 이러한 상황이 반복되고 있기 때문에, 팀원은 스프린트 계획시 본인이 세운 업무 추정은 틀릴 가능성이 높다. 

    우리는 해야할 일에 대한 추정이 달라질 것을 고려해서 스프린트 계획 회의를 진행하는 날 오후 시간에는(스프린트 계획은 매주 월요일 오전에 회의를 진행한다) 계획한 일들을 검토해서 세부 항목과 좀 더 자세한 추정을 하는 시간을 갖는 규칙을 만들었다. 하지만 반나절만에 추정의 정확도를 높일 수 있는 동료들은 생각보다 많지 않고 그 일 자체도 매우 어렵고 고된 일이다. 2주간 해야할 일의 개수가 5개 이상이라고 가정해보자. 하루만에 검토한 모든 일들이 계획한 날짜 안에 딱 완료될 가능성이 높을 것인가? 아니 높지 않을 것이다. 결국 추정의 오차범위가 커진다. 



    셋째, 각자가 기간안에 해결해내야 하는 일 때문에 팀 동료를 도와주기 어렵다. 

    우리는 "매일 스크럼 회의에서 동료의 어려움을 발견하면 도와주기"라는 규칙을 정했다. 하지만 동료를 도와주고 나면 본인이 야근할 가능성도 높아진다는 것을 깨닫게 되었다. 이유를 곰곰이 생각해보면 첫째 내용, 긴급 요청 업무 때문이라는 것을 알게 된다. 팀 동료를 도와주는 것 또한 긴급 요청 업무로 볼 수 있기 때문이다.  각자가 스프린트 기간내 일의 "완료"를 위해 업무를 진행하고 있기 때문에 "적극적으로" 도와주기가 어렵다. 또한 도움을 요청할 때 누구에게 도움을 요청해야 할지 난감한 경우도 있다. 




    생각을 정리하자면

    일부 사람들은 스크럼은 이제 안정적으로 자리잡힌 프로세스라고 말하기도 한다. 하지만 애자일 스크럼은 생각보다 어렵다. 

    스크럼을 운영하고자 한다면, 본인이 작성한 글을 참고해서 꾸준히 개선해야할 사항들이 있다는 것을 알았으면 좋겠다.




    반응형

    댓글 0

Designed by Tistory.