6장. 애자일 교육기획#4
#6-4 확산 계획
#6-4 확산 계획
* 애자일 개발 교육
애자일 개발 교육은 이전의 개발 교육과정과 매우 달랐다.
먼저 Dev들이 페어로 일하기 위해 페어 스테이션(Pair Station)을 함께 만들었다. 페어 스테이션은 페어 프로그래밍에 최적화된 환경을 말한다. 먼저, 노트북을 가운데 두고 USB 커넥터를 이용해 키보드 두 개와 마우스 두 개를 붙였다. 또한 모니터 2대를 공유기에 연결하고 노트북에 연결했다. 이렇게 모든 Dev들은 페어로 늘 같은 화면을 볼 수 있게 세팅했다.
페어 스테이션은 모든 개발자들이 똑같은 환경에서 개발할 수 있게 같은 키보드와 같은 마우스를 세팅했다. 두 자리에 페어로 앉은 개발자들은 늘 같은 화면을 볼 수 있었다. 그리고 이 환경을 모두 동일한 장비로 구성하여 매일매일 페어를 바꾸더라도 환경에 차이를 느끼지 않도록 했다. 업무 시간 중에는 늘 이 페어 스테이션에서 개발하는 것이 원칙이었다.
[페어 스테이션]필자는 이들의 교육방식, 수강생들이 느끼는 것을 보고 여러 가지를 관찰할 수 있었다. 흥미롭게도, 페어 프로그래밍은 명확한 장점과 단점이 있었다.
가장 큰 장점은 모든 팀원이 소스코드에 대한 공동의 오너십을 느끼는 것이었다. 모든 팀원이 페어 프로그래밍으로 일하고 매일 페어를 바꾸니, 나와 다른 개발자들의 업무의 경계가 별로 의미 없었다. 내 코드가 아닌 우리 모두의 코드로 보는 새로운 관점이 만들어졌다. 이렇게 오너십을 갖게 되면서 팀 내 문제가 생기면 너나 할 것 없이 해결하려고 하고 해결할 수도 있었다. 모든 팀원이 소스코드에 대해 알게 되고 이에 따라 협업이 보다 강화되는 느낌이었다.
또 다른 장점은 작성하는 코드의 가독성이 매우 높아진다는 것이었다. 페어를 늘 바꾸는 형태로 개발하다 보니, 늘 주변을 배려하며 코드를 짜게 되었다. 쉽게 읽을 수 있는 코드를 짜는 것이 무엇보다 중요했다. 이 쉽게 읽을 수 있는 코드가 테스트 코드와 엮여 유지보수가 수월한 코드로 유지되고 있었다.
그리고 쉽게 서로의 노하우를 배울 수 있었다. 팀이 개발을 하기 전에는 각자 다른 능력을 가지고 있었다면, 빠른 속도로 각자의 능력치를 팀 전체가 흡수하고 이를 업무에 활용하고 있었다. 새로운 기술이나 툴을 활용하는 것도 매우 빠르게 적응할 수 있었다.
코딩 방법에 대한 의사결정 또한 빨라졌다. 서로 이야기하며 코딩을 짜니, 고민의 시간이 그만큼 줄었다. 코드를 작성하는 개발자가 확신에 차지 않은 상태에서 ‘이렇게 해볼까?’라고 제안하면 다른 한 사람이 ‘이게 더 낫지 않을까?’라고 하며 키보드를 뺐고 빠르게 제안을 고쳐가며 개발할 수 있었다.
반면에, 가장 큰 단점은 모두가 일할 때 매우 힘들어진다는 것이었다. 페어 프로그래밍은 업무 강도를 극대화시켰다. 페어와 토의를 하면서 코딩을 하는 것은 정말 높은 집중력을 요구했다. 심지어 짝을 항시 배려해야 하기 때문에 화장실에 가는 것도 자유롭지 못했다. 모든 일을 협의해서 진행했다. 두 눈이 아닌 네 눈으로 보며 코딩하니, 자연스레 코드의 품질은 올라갔다. 항시 코드 리뷰를 진행하며 소스를 짜는 느낌이었다.
또한, 그리고 Dev들은 테스트 코드 작성에 익숙해지고 있었다.
[테스트 피라미드]이번 교육을 통해 작성한 테스트 코드는 이전과 많이 달랐다. 먼저 늘 성공하는 테스트 케이스를 작성했다. 우선 모든 메서드에 대해 코딩을 하기 전에 유닛 테스트 코드를 먼저 작성했다. 모듈 간 테스트를 해야 할 일이 있으면, 모듈 간 테스트 케이스를 만들기 전에 모킹(Mocking)을 써서 유닛 테스트 코드 위의 모듈 내 테스트를 수행했다. 전 독립적인 모듈의 신뢰도를 높였다. 그 뒤 모듈 간 테스트를 자동화 테스트로 만들었다.
그 위에 한 개의 레이어부터 여러 레이어를 함께 테스트하는 테스트 코드들을 계속 늘려가며 코드를 작성했다. 그리고 테스트 피라미드의 상위로 올라갈수록 케이스 수를 줄였다. 이미 유닛 단에서 많은 테스트 코드를 작성하여 검증하고 있기 때문에 상위로 올라갈수록 아주 중요한 테스트 시나리오만 커버하면 됐다. 예전 같으면 UI 테스트 코드를 메인 흐름과 대안 흐름 그리고 예외 흐름까지 모두 작성했다면 이제는 메인 흐름만 작성했다. 그리고 QA는 행위 주도 개발(Behavior Driven Development) 방식으로 GUI 중심의 인수 테스트 코드를 만들었다. 이 테스트 코드는 BA가 정의한 인수 조건을 만족했다.
수강생들은 실제 코드를 짜기 전에 늘 테스트 코드를 먼저 짜고 개발했다. 명명부터 시작하여 코딩을 할 때도 클린 코드의 원칙을 활용했다. 이 클린 코드로 만든 코드가 정상적으로 동작하는지는 테스트 코드를 통해 대시보드에서 확인할 수 있었다. 대시보드를 통해 지속적으로 소스코드가 통합되고 애플리케이션으로 만들어지는 것을 확인할 수 있었다.
[T사의 리드 개발자 크리스 곤잘레즈와 살림 시드키]이 위에 지속적인 딜리버리가 가능하도록 개발, 스테이징, 프로덕션의 3가지 단계를 통해 배포 파이프라인을 만들었다. 늘 버튼을 한번 클릭하면 다른 단계로 넘어가서 자동화 테스트를 수행할 수 있도록 했다. 이 자동화 테스트 덕분에 우리는 어느 순간에나 프로덕션 환경에서 동작하는 SW를 만들 수 있었고 배포할 수 있었다.
그다음으로 가장 큰 차이는 짝으로 코딩을 하는 것이었다.
* 교육 종료
전체 7주의 과정 중 수강생 모두가 이 프로세스와 기법들에 익숙해지는 데는 3주 정도가 걸렸다. 그 뒤부터는 주어진 환경에서 스스로 위와 같은 방식으로 일할 수 있었다. 4주 정도가 지나자 BA, QA, Dev 모두 해당 프로세스에 익숙해지기 시작했다. 그리고 고객에게 쇼케이스 하면서 만들어가는 애플리케이션의 가치를 이해하기 시작했다. 수강생들의 마인드 셋은 변해가고 있었다. 이렇게 개발하는 방식이 이전보다 더 낫다고 깊이 생각하고 있었다.
[당시 교육장]마지막 회고를 진행하던 날, 회사 내 중요한 스폰서 한 명이 참여하는 가운데 쇼케이스를 했다. 쇼케이스를 흥미롭게 지켜보던 그가 수강생들을 대상으로 다음과 같이 물었다.
"7주간 정말 의미 있는 과정을 진행하신 것 같습니다. 모든 분들이 사고의 전환과 행동의 전환점을 경험하신 것 같아요. 혹시나... 여러분들이 현장에 돌아가셨을 때 계속해서 애자일 방식을 수행할 수 있게 도와드릴 수 있을까요?"
모두가 그 질문의 의미가 무엇인지 알고 있었다. 히지만, 그 질문에 대해 아무도 답을 하지 못했다. ‘이 방법을 과연 현실에서 쓸 수 있느냐?’라는 질문에 모두가 말문이 막혔기 때문이었다. 수강생들은 이 교육을 듣고 현실에서 시도하면서 겪을 좌절에 대해 서로 이야기했다.
그 스폰서십을 가진 이해관계자는 뜻밖에 말을 했다.
“그렇게 좋다면 한번 해보죠. 제게 확산 방안을 가져다주세요”
적어도 수강생들은 이날 매우 기뻤다. 이러한 방식을 실제 현장에서 활용하여 소프트웨어를 개발할 수 있을 것이라 생각했다.
필자는 이 수강생들과 함께 조직대 확산 방안을 함께 만들었다. 짝 코딩을 통해 지식을 전수하며 안정적으로 확장할 수 있는 방안을 만들었다. 비슷한 교육을 확장하는 안을 만들었다.
2개월씩 팀을 두 배로 불려 나가는 안을 만들었다. 8명의 코치가 16명의 교육생을 양성하는 강사를 양성하는 교육(Train the Trainer) 접근 방식이었다.
하지만, 곧 준비한 계획은 회사의 조직개편과 함께, 물거품이 되었다. 두 번째 애자일 전환의 좌절이었다. 그 스폰서는 이 일과 관련 없는 완전히 다른 조직으로 이동되었다.
