XP, 희한하게 나아지는 방법론

안녕하세요. yeTi입니다.

오늘은 XP 를 읽고 느낀점들을 공유해보려고 합니다.

계기

XP(eXtreme Programming) 를 처음 접한건 2009년 대학생 시절 소프트웨어 공학 강의를 들으며 잠결에 본 XP 라는 구문이었습니다.

이후 안영회 대표님의 브런치 의 XP 넘어서기 연재를 보며 개발과는 연관성이 없는 행동들이 개발을 잘 되게 해준다는 것을 느끼고 회사에 도서 신청을 하여 읽어보게 됐습니다.

아기 발걸음

XP에서 제시하는 작은 실천이 변화의 시작이라는 의미에 아기 발걸음 을 먼저 실행해본 후에 책을 읽게 됐는데요.

처음에 미심쩍었던 소통, 함께 앉기, 나부터 잘하기 와 같은 것들을 해보며, 원활하지 않았던 파트내 정보의 교류가 시간이 지날수록 원활해진다는 것을 체감했습니다.

개발 프로세스의 가치 (feat. 방법론)

XP 는 단순한 가치를 전제로 합니다.

상호 존중하는 구성원간 제품의 성공을 위해 최선을 다한다.

즉, 형식보다 구성원들이 가진 뜻의 일치성이 가장 중요하다는 것입니다.

가령, 폭포수 모델(마르미3), 스크럼 을 접할때 수행해야하는 산출물이나 형식으로부터 의무적인 느낌을 받을 때가 있고 우리 개발 프로세스가 원활하지 않다고 느낄때 형식을 완전히 습득하지 못했기 때문이라는 생각을 하는 경우가 있습니다.

XP 에서는 필요하다면 불필요하다고 생각하는 문서도 만들 수 있고, 회의를 길게 할 수도 있고, 일정이 촉박할 수도 있고, 설계를 변경할 수도 있다고 합니다.

목표는 상호 존중하며 제품을 원활히 만드는 것 입니다.

저는 개발 프로세스가 가지는 가치 또한 이와 같다고 생각합니다.

개발 프로세스를 만들어가는 이유는 개인의 욕망보다 제품을 잘 만들기 위한거 아닐까요?

실천 방법

XP 가 제시하는 다양한 실천 방법중에 몇 가지만 언급하면 함께 앉기, 전체 팀, 페어 프로그래밍, 스토리, 주기, 여유, 10분 빌드, TDD, 점진적 설계 입니다.

빠르고 정확한 의사결정

함께 앉기, 전체 팀 은 빠르고 정확한 의사결정을 위한 방법입니다.

물리적 거리가 가깝다는 것은 정보의 공유가 쉽게 되는 환경을 만드는것이고 의사 결정이 필요할 때 빠르게 논의할 수 있는 효율성을 제공합니다.

그리고 다양한 사람들이 모인다는 것은 의사 결정에 필요한 많은 요소들은 한 자리에서 고민하며 유기적인 고려를 통하여 판단 및 결정할 수 있는 환경입니다.

빠른 시도

스토리, 주기 는 빠른 시도에 따른 빠른 피드백을 받기 위한 방법입니다.

스토리 단위로 개발을 시작하면 설계부터 테스트까지 작은 단위로 빠른 릴리즈가 가능합니다.
단위가 작다보니 의사 결정도 빠르게 진행할 수 있습니다.

추가적으로 릴리즈 주기를 짧게 가져감으로 인해서 실 사용자에 대한 피드백을 빠르게 받아 다음 의사 결정에 중요한 자료로 사용할 수 있습니다.

만일 개발 방향이 잘못되어 방향을 전환하더라고 작은 단위의 빠른 릴리즈는 위험 부담을 줄여주는 효과가 있습니다.

품질 보장

페어 프로그래밍, 여유, 10분 빌드, TDD 는 제품의 품질을 높이기 위한 활동입니다.

함께 생각하면 고려하는 관점을 다르게 볼 수 있어 오류 발생 가능성을 낮춰주고, 개인적인 요령을 피울 수 없습니다.

테스트 코드를 작성하는 것은 설계의 품질을 높이고 동일한 문제를 다른 관점으로 볼 수 있어 오류 발생 가능성을 줄여줍니다.

테스트 코드의 양은 10분내에 빌드가 끝나는 수준으로 관리하면 적정 수준의 테스트 케이스를 가져가면서 개발자가 여유를 가질 수 있는 시간를 줄 수 있습니다.

점진적 설계 (비용 최소화)

설계는 제품의 가치와 비용 을 최소화 할 수 있을 때 할 수 있는 부분만 해나가는 것이 좋습니다.

간혹 개발자나 Manager가 과거 경험을 기반으로 기획자가 되고자하는 분들이 있습니다.

서비스는 과거 경험을 기반으로 찍어내는 산물이 아닙니다.

동일해 보이는 서비스더라도 지닌 가치가 다르다면 설계 중요도는 다릅니다.

실무 적용 경험

지난 4달동안 실무에 적용하며 느낀 부분입니다.

신뢰기반 프로세스를 만달고자 했습니다.

비신뢰기반 프로세스가 기지는 방어적 커뮤니케이션은 개발을 저해하는 큰 요소입니다.

또한 실수도 죄악으로 치부하는 경향이 있기 때문에 숨기는 경향이 생길 수 있고, 이로 인해 잠재적인 위험성은 증가하며 실수 재발을 막는 학습효과를 만들 수 없습니다.

이를 투명한 정보 공개, 실수의 조직적 책임, 유대감 형성 을 통해 커뮤니케이션의 효율을 높여 성장, 추정의 정확성 증가, 이슈의 빠른 대응 을 가능하도록 했습니다.

가치를 기반으로 소통했습니다.

처음에는 파트원들이 의사소통에 힘들어했었습니다. 왜냐하면 의사소통을 시작하면 쿼리로 얘기하길 원했습니다.

처음에는 도메인 레벨, 업무 레벨로 우리가 운영하는 제품의 가치를 공유하기에 힘이 들었으나 한달정도가 흐른 뒤 한분, 두분, ... 대화가 되기 시작했으며

현재 저희 파트는 업무로 대화가 가능한 수준이 돼었고 얘기한 대로 구현했는지는 코드로 확인하도록 노력하고 있습니다.

의사 소통의 방식이 변하면서 설계 수준이 변하기 시작했고 서비스 레이어가 구조화되기 시작했습니다. (시작만 했습니다..)

불편한 회고를 했습니다.

저희 파트는 배포 회고, 이벤트 회고, 문화 회고, 업무 리뷰, 전파 교육 을 수행합니다.

목적은 세가지 입니다. 실수로 성장하고, 능력을 성장하고, 파트원들의 생각을 듣는 것입니다.

처음에는 회고 자리가 실수한 파트원을 조명하여 상처받지 않을까 라는 염려를 했습니다.

하지만 다행이도 모두들 덤덤하게 받아 들여 줬고, 현재는 배포시 이슈률 제로, 이벤트 수행시 이슈률도 줄이고 있는 정도의 성과를 내고 있습니다.

지속적인 성장

위에서 언급한 회고 및 리뷰를 통하여 개발자들이 성장하고 있습니다.

증거는 XP 활동전에는 본인들이 작성한 코드를 설명할 수 없었는데, 요즘은 설명이 가능해 졌습니다.

그러한 설명가능한 영역이 점점 늘어가는 것이 개발자들이 성장하고 있는 증거라고 생각합니다.

유대감을 가지려고 노력했습니다.

앞서 언급한 회고를 통해 파트에 대한 생각, 개발 프로세스에 대한 생각, 업무에 대한 생각 등등 만족감을 높게 유지하고자 했습니다.

그 중 큰 역할을 했던것이 점심시간에 보드게임을 한 것이라고 생각합니다. (제가 제안한것은 아닙니다.) 별거 아닌것 같은 게임으로 생긴 좋은 감정이 업무시에 진실한 의사 소통으로 이어졌을 것으로 생각합니다.

추가적으로 이번 달부터 파트 자체적으로 pair lunch day 를 만들어 한달에 한번 파트원간 1:1 점심을 먹는 시간을 가지기로 했습니다. (시니어 개발자의 사비로 진행합니다..)

이 역시 유대감 증가를 통해 업무 효율을 늘리기 위한 활동입니다.

결론

요즘 꼰대, 사생활 이라는 단어가 업무시 필요한 최소한의 유대감까지 단절시키고 있지 않을까하는 생각이 들어 아쉬운 마음이 있습니다.

그런 의미에서 현 파트에서 유대감의 증가, 커뮤니케이션의 개선이 개발의 효율을 얼마나 증가 시킬 수 있는지에 대해 느낄 수 있었단 것은 앞으로 삶을 살아감에 있어 좋은 기반이 될거 같습니다.

뛰어난 기술자 한명보다 커뮤니케이션이 원활한 팀이 가치가 높다.

※ XP를 읽는 과정에서 책을 다 읽으면 XP팀을 만들어보고 싶다는 생각을 했습니다. 하지만 책을 다 일고 난 후에는 그냥 일 잘하는 백엔드 파트가 됐으면 좋겠다고 생각합니다.

다른 기록

소프트웨어가 가지는 힘
개발의 낭비 막기
QA팀과 품질의 책임
주변에 강요하지 마라
신뢰기반 프로세스에 대한 피드백
설계의 때
점진적 설계의 역반응
결함을 제어하여 신뢰 높이기
TDD는 왜 어렵게 느껴질까?
타이핑의 중요성
계획에 유연성을 부여하기
계획 추정 잘 하기
같이 계획 세우기
처리성능 향상하기
XP 팀에서 기치있는 직원
XP팀이 얼마나 건강한지 측정하는 수치