💡 아래의 내용은 순전히 본인 시점에서 본인의 솔직한 감상일 뿐 팀의 의견은 아님을 강력히 강조합니다. 또한 팀 전체에 대한 평가가 아닌 글쓴이 본인에 대한 본인의 평가임을 밝힙니다.

팀의 최우선 목표

• 짧은 기간 내에 기술 연습 및 기술 습득에 집중하기 위해 기획 과정 없이 클론 코딩 프로젝트를 진행

• 애자일 방법론 중 스크럼 방식을 채택

• 프로젝트 시작 전부터 충분한 커뮤니케이션을 통해 확장성을 갖춘 유연한 볼륨의 프로젝트 목표를 설정

현실

• 클론코딩도 기획에 많은 시간을 투자했어야만 했다. 빠른 코딩을 위한 엉성한 기획은 시간이 지날수록 드러나는 구조적 문제점과 엉성한 타임테이블 작성을 불러올 뿐이었다.

• 꼼꼼한 구조 설계 없이 프로젝트를 시작하였음으로 스프린트를 위한 Trello또한 엉성했고, 제대로 관리되지 않았다. 스프린트는 적어도 나에겐 티타임을 곁들인 조깅이 되어버렸고, 스크럼또한 반쪽짜리였다.

• 반대로 유연한 볼륨의 프로젝트 목표 설정 및 이행은 나름 잘 이루어졌다고 생각한다.
  우리의 작업량은 다른 팀에 비해 특별히 부족하거나 많지도 않았고, 팀원간의 스트레스도 크게 없다시피 했다.
  모두가 본인이 할 만큼의 작업량을 잘 이행하였고 다들 나름 만족했다고 생각한다.

왜 우리는 애자일한 워크 플로우를 가져야 하는가?

단순히 트랜디하고 요즘 스타트업이나 유니콘에서 많이 채택하는 방법론이라서 애자일 방식을 사용한다는 것은 분명 좋지 못한 접근일 것이다.

애자일에 방식을 사용하기 전, 나는 스스로에게 다음과 같은 질문을 던져보아야했다.

• 왜 하필 애자일이고 왜 하필 스크럼인지,
• 해당 방식으로 팀이 얻을 수 있는 이점은 무엇인지,
• 해당 방식을 사용하기 위해서, 개개인은 어떠한 생각과 마음가짐을 가지고 있어야 하는지

지금 부터 위 부분들에 대해 느꼈던 나의 생각을 하나씩 풀어보고자 한다.

왜 스크럼인가? 🔥

일단 스크럼의 커다란 6가지 특징에 대해 살펴보자.

• 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
• 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
• 날마다 15분 정도 회의를 가져라.
• 항상 팀 단위로 생각하라.
• 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.
  위키피디아

스크럼 방식의 가장 큰 이점은 어쨌거나 저쨌거나 빠른 시간안에 실제 동작할 수 있는 결과를 제공하는 것 일것이다.

결국 우리도 많은걸 포기했지만, 그래도 최소한 프로젝트의 핵심 플로우는 진행시킬 수 있는 결과물을 만들었다.
(물론 개인적으로 추가 기능 구햔이나 리팩토링, 에러 핸들링, 디자인 다듬기 등 손볼게 엄청날테지만...)

스크럼말고 다른 효율적인 방식은 없었을까?

위 의견은 합리적이지만, 한편으로는 이상적인 생각이었다.

첫번째로 적어도 나는 프로젝트 시작하기 전, 과제 진도 따라가기도 조금 벅찼다.
만약 괜찮아 보이는 방법을 찾았어도, 스스로 충분히 이해하고, 팀원들에게도 이해시키고, 효율적인 워크 플로우를 확립할 시간적, 심적 그 어떤 여유도 없었다.

(시도조차 안한 놈이 뭘 그리 당당하게 못하는 이유를 말하냐고 하면 할말없지만)

그럼 스크럼 방식은 효과적이었나?

개인적인 생각이지만 어떤 효율적인 방법론이든, 워크플로우든 무엇이든, 팀원들 간의 해당 방식에 대한 충분한 이해와, 확실한 동의 없이는 다 무용지물이라고 생각한다.

스크럼의 커다란 6가지 특징을 지켰다고해도
과연 지키기만 한 것인지, 해당 특징이 효율적으로 팀에 도움이 되었는지는 완전의 별개의 문제라고 생각한다.

회의를 진행해도 해당 회의가 괜한 코스트 낭비였는지, 필수적인 가치를 지녔는지는 회의의 퀄리티에 따라 달려있는거지 15분 간의 회의 자체에 달려있는건 아니다.

그래서 결론적으로 스크럼 방식이 프로젝트에 도움이 되었는가?

역시 스크럼이다라고 할 순 없었지만, 물리적인 환경, 불협화음 없이 서로 존중하고 수평적인 팀원들의 마음가짐, 볼륨은 적었지만 효율적이었던 의사소통 등이 갖춰진 시점에서 우리는 강제적으로 스크럼 방식을 체험했다고도 볼 수 있다.

그리고 나 스스로에게는 완벽히 만족하진 못하지만, 이번 프로젝트의 결과에서 팀적인 불만은 전혀 없었다.

결론적으로 스크럼 방식은 어느정도 도움이 되었다고 할 수 있다.

그럼 앞으로도 스크럼 방식의 워크 플로우를 고집하고 싶은가?

물론 위 질문은 내가 앞으로 속하게될 팀에 따른 변수가 가장 크게 작용하겠지만,
개인적인 심정으로는 나는 아직 이 질문에 대답할 자세가 되어있지 않다는 것이다.

나는 아직 전통적이라 칭하는 워터폴 모델이나, 나선형 모델에 대한 기본적인 지식도, 경험도 없다. 또한 다른 애자일 방법론들에 대한 경험이나 지식도 없다.
최소한 해당 방법론들에 대해 조사와 이해가 끝난 후 해당 질문을 다시 스스로에게 던져야 한다고 생각한다.

스크럼을 대하는 개인의 태도💡

프로젝트가 끝나고 많은 생각을 하게되었다.

단순히 코딩이 아닌 TEAM과의 협업이라는 측면에 대해
많은 노력을 기울였던 다른 팀들을 보자면, 참 궁금했다.

그분들은 어떠한 태도로 팀 프로젝트에 임하셨는지, 그래서 만족은 하는지,
팀 협업에 투자한 코스트들은 제 값을 하였는지, 개인과 팀 수준에서 스크럼이라는 방식에 대해서 어떠한 태도를 지녔는지 등 말이다.

나는 스크럼에서 단순히 프로젝트의 효율성만을 생각하였고, 그마저도 열정적으로 수행하려 노력하지 않았다. 그때문인지 중간에 워크플로우가 흔들린 경험이 너무나 많았고, 해당 경험들은 큰 코스트의 손실로 이어졌다. 덕분에 리팩토링을 통한 깔끔한 코드, 애초 기대했던 성과
그 무엇도 만족스럽지 못했고, 막판에는 쫒기듯 기능구현하기에 바빴다. 즉 전혀 체계적이지 못했다.

당장 내일 시작 할 2차 프로젝트에서는 어떤 환경을 마주하게 될지,
나는 어떤 환경을 만들어나갈 것인지, 벌써부터 기대가 앞선다.

적어도 이번에는 스크럼 방법론에 대해 개인적이든, 팀적이든 좀 더 깊은 접근을 해보고자 한다.

2주 후의 후기에는 어떤 말을 쓰게될지, 스스로에게 어떤 질문을 던질지 기대가되는 밤이다.