한 4년 반쯤 전에 지금 몸담고 있는 프로젝트 팀 초기때 사서 읽었던 책을 다시 펼쳤다.

여러 애자일 개발 방법론 중

일본에서 처음 시작된 스크럼을 중심으로 다루며,

전반적인 애자일 개발 방법론에 대해 서술하고 있다.

총 3부로 구성이 되어있고,

1부에서는 주로 애자일/스크럼이 무엇인지, 실천법에 대해 나와있고,

2부/3부는 실제 사례, 관련자들 인터뷰를 다루고 있다.

(우리회사 다니시는 분이 번역했고, 인터뷰에서도 다른 분 출연하신다..)

애자일 실천법으로 소개된

사용자 스토리/플래닝 포커/일일 스크럼/회고/태스크 칸반/소멸 차트/짝 프로그래밍/리팩토링/지속적인 통합 등등은

현재 팀에서 시도 해보았거나, 지속하고 있는 프랙티스들이어서 익숙했다.

해당 프랙티스들을 책에서 소개 한대로 완벽하게 운용하고 있지는 않지만,

(사용자 스토리를 적는 방식이라던지, 플래닝 포커라던지, 페어 프로그래밍이라던지..)

책도 관련 프랙티스들의 효과가 과장되어있는듯 한 느낌은 없지 않아 있다.

사실 시도하고 빠르게 실패하고 시도하고 실패하면서 점진적인 질적 향상이 애자일의 철학이므로

어쨌든 그 철학에 맞게 잘 하고 있는것 같다는 생각은 든다.

또한 책에서 강하게 강조 하고 있는 부분인,

제품소유자 (고객 or 기획자)와 개발자간의 막힘없는 소통/빠른 결과물 보여주기는

공감이 많이 되는 부분이며, 실무에서도 의식적으로 노력했던 부분이다.

경험상 요구사항에 대해 이야기 할때도,

당사자에게 그 요구사항이 필요하게된 배경 설명 같은거를 자세히 듣는다거나

하나라도 더 캐묻고 하는게 굉장히 중요한것 같다.

백날 컴퓨터만 들여다보고 사람이랑 얘기 안하면서

누군가 던져주는 부족한 정보를 토대로 개발하면

“원한건 이게 아닌데요?” or “그 기능 안쓰는데요?”

의 결과가 되돌아오는 경우가 많으므로..

어쨌든 SI가 아닌

서비스를 본인들이 직접 개발하고 운영한다면,

퀄리티 좋은 결과물을 적기에 똭 내놓기

위해서는 이것보다 좋은 방법은 없다고 생각한다.

물론 SI쪽은.. 폭포수 모델이 나을수 있다라고 한다..(..탈출해라!)

그럼 이만.