스크럼에서는 완료정의가 매우 중요하다. 완료정의를 어떻게 정의하는지, 어떻게 받아들이는지에 따라 스크럼이 성공할수도 실패할수도 있다. 그리고 이 완료정의는 거의 ‘품질’과 관련하여 정의된다.

• 기술부채가 낮아졌다
• 단위테스트를 모두 통과한다 (100% pass, 100% covered)
• 컴파일 경고가 0개
• 테스터가 승인했다
• 배포서버에 올려서 자동시험을 마쳤다
• ..

위처럼 품질 수준으로 완료정의를 기술한다.

당연히 이러한 기준을 처음부터 밀고나가는 것은 말이 안된다. 팀의 역량에 따라 점진적으로 확대/강화해나가면 된다. 예를 들어, 경고 0개 만들기도 처음에는 기본 컴파일러 옵션을 지키고, 그 다음에는 –strict_warnings 처럼 모든 경고를 켠 상태로 강화한다든지 할수 있다.

가장 중요한 터치감. “Touch the wonder”라는 카피로 국내 풀터치폰 시장을 선점하려고 했던 LG전자도 그렇고, 햅틱 및 아몰레드로 국내 1위를 하고 있는 삼성전자도 마찬가지다.

최근에 출시된 HTC의 3번째 안드로이드폰 역시 터치감에서는 모자람이 느껴진다. 아이폰을 배제한 다른 제품들과 비교할 때 상대적으로 낫다고 느껴지는 정도.

개인적으로는 터치감을 좌우하는 팩터를 2가지로 꼽는다. 하나는 화면과 터치면의 간극, 다른 하나는 터치를 따라오는 화면의 애니메이션. 하나는 하드웨어적인 문제이고 다른 하나는 소프트웨어적인 문제이다.

이 두가지를 해결해야지 적어도 터치폰 기기만 놓고 봤을 때 가장 중요하다 할 수 있는 터치감을 제공할 수 있을것이다. 이 두 요소는 사용자 피드백에 영향을 주어 정확한 터치를 가능하게 하고 사용자가 조작감을 느낄 수 있게 한다.

앞서 HTC 모델은 화면과 터처면이 1mm이상은 떠 있는 느낌이 들어서 아쉬움이 크다.

최근 출시된 뉴초콜렛은 터치면과 화면이 맞닿아 있는 듯하여 많이 개선되어지만, 여전히 터치드래그(혹은 flick)에서 애니메이션이 다소 늦은감이 있어서 개선이 필요하다고 보인다.

발표가 끝나고 나온 첫 질문 “방금 발표하신 스크럼이 품질하고 무슨 상관이죠?” 였다. 어쨌거나 스크럼이 품질을 직접적으로 언급하고 있는 것은 아니니 충분히 이해가는 질문이다.

“스크럼을 도입하면 품질이 좋아지나요?”

그러고 보면 스크럼이 보장해주는 것은 거의 없는 것이나 다름없다. “스크럼과 XP”에서처럼 대개의 성공적인 스크럼 팀은 XP에서 강조하는 프랙티스들을 접목하고 있거나 자신들만의 방법들을 가지고 있다지만 어디까지나 권고 사항이지 스크럼이 명시적으로 언급하는 활동은 3가지 미팅 밖에는 없다. 그 밖의 것들은 팀이 결정할 사항이다.

스크럼이 잘 굴러가지 않는 경우를 살펴보면 원인이 여러가지 있겠지만 엉망인 코드베이스도 주요 원인 중 하나이다. 계획 세운 것이 틀어지는 첫번째 이유가 바로 ‘디버깅’이기 때문이다. 일단 디버깅이 시작되면 해당 태스크 항목(스프린트 백로그 아이템)은 언제 끝날지 알 수 없다.

현재 진행 중인 스크럼 팀만 보더라도 디버깅 등으로 인해 스프린트 목표 달성에 실패한 첫번째 스프린트를 회고하는 자리에서 ‘1일 1시간 짝프로그래밍’을 하자는 의견이 도출되었다. 두번째 스프린트에서는 Unit test 환경을 설정하고 Test case 를 추가하는 것이 백로그 아이템에 포함되어 있다.

스크럼 실패의 주요 원인은 낮은 품질이고, 성공적인 스크럼 팀들을 보면 고품질의 제품/코드를 위한 프랙티스들을 병행하고 있다는 점을 보면, 스크럼을 도입이 품질 향상을 가져올 것으로 기대할 수 있다.

정리하자면, 스크럼은 팀 자발적인 품질 활동을 촉발하여 내적품질 향상을 꾀하고 결과적으로 제품 품질의 향상을 가져온다.

스크럼 마스터는 팀이 역량을 최고로 발휘할 수 있도록 도와주는 역할이다. 그런면에서 지난 3주간 나는 스크럼 마스터로서의 역할을 충실히 하지 못했다.

완전히 팀에 녹아들지 못했으며, 그들이 애로사항을 이야기할 때 열정적으로 해결해주지도 못했다. 첫번째 스프린트에서 중간에 갑자기 번다운차트가 상승하기 시작했을 때 이에 적절히 반응하도록 도와주지도 못했다. 예비군 훈련, 다른 회의 등으로 인해 팀 룸을 비운 회수도 많았다.

나 역시도 아직은 갈길이 먼 스크럼 마스터이다.

- 너무 긴것도 문제고
- 예외가 너무 많은 것도 문제고
- 일관되지 않은 것도 문제고
- 설명이 부족하거나 모호한 것도 문제고..

특히, 일관되지 않은 시나리오, 예외가 많은 시나리오는 코드를 지저분하게 하고, 논의하느라 시간을 낭비하게 하고, 결정적으로 결함을 유발한다.

… 코드 리팩터링을 하다보면 그렇게 짜도록 만들어진 시나리오 문서부터 바로잡아야 한다는 생각이 든다.

처음에는 블로그 포스트 몇개로 시작하더니 차차 살이 붙어간다. Gambit Scheme 을 이용하고 있으며 현재 OpenGL 과 Touch event를 연결하는 FFI까지 작성하여 공유하고 있다.

때마침 이 글을 발견하게 된것은 나 역시 Scheme을 C개발 환경에 붙여넣는 시도를 해보는 중이었기 때문이다.

난 TinyScheme 을 이용해서 조금씩 기능을 붙여보고 있었다. TinyScheme은 정말 작게 구현된 Scheme interpreter 이다. 최소한으로 빌드하면 .c 하나만 있으면 된다. FFI 연결도 쉬운 편이다. (GIMP 가 TinyScheme 을 이용하여 스크립팅을 지원한다고 한다)

일단 TinyScheme 붙여보는 작업을 좀더 진행해보고 Gambit을 살펴봐야겠다.

스크럼 입문 v1.1 한글판 PDF

- 측정하지 않으면 개선할 수 없다 라는 말이 더 널리 쓰이긴 하지만, 암튼 나처럼 개발을 지원하는 입장에서 보자면 ‘지표, 측정’ 등이 늘상 따라다닌다.

측정하면 부작용을 낳게 되고, 측정하지 않으면 현상을 파악하기 어렵고.. (특히 보고하기가 어렵다.. ) 해결하기 쉽지 않은 문제다.

박피디 님도 지적하듯이 측정은 목적에 상관없이 측정한다라는 사실만으로 부작용이 생긴다. 아플때 병원에서 우리몸 구석구석에 각종 계측기를 달아서 몸 상태를 파악할 때는 우리 심장이 ‘어, 나를 측정하고 있잖아?..’ 라고 하진 않지만.. 사람은 누군가 내가 하는 일에 숫자를 매기기 시작하면 (그래서 그것을 인지하고 나면) 어떤 식으로든 반응하게 마련이다.

단순 현황파악이 아닌 피측정자의 반응(대응)을 기대하는 측정도 있지만, 원하는 반응을 이끌어내기 어렵다.  이 부분도 박피디님 말처럼 사람이 워낙에 똑똑해서 측정 시스템을 쉽게 엿먹일 수 있기 때문이다.

개선을 위한 측정이 되었건 변화를 유도하기 위한 측정이 되었건 일단 측정의 결과가 피측정자들에게 전달되는 순간부터 역기능은 발생하는 셈이다.

그렇다면 이렇게 생각해볼 수 있을까?

개선을 위한 현상 파악이 목적이라면 1회성 측정만이 유효하며 반복하면 안된다. (소위 모니터링은 적절치 않다)  그리고 피측정자가 어떤식으로든 측정 사실 자체를 모르는 상태에서만 측정이 이뤄져야 한다.   .. 라고.

최근에 ‘복잡도’를 측정하여 주간단위로 각 팀에 리포팅을 시작했다가 부작용이 우려되어 곧 그만두었다. 복잡도가 어차피 코드품질의 전체를 반영하지 못하는데도 숫자에만 매달리는 현상이 슬슬 벌어질 조짐이 보였기 때문이다.  복잡도 모니터링/리포팅을 계속했다면 이름고치기 같은 멋진 리팩터링은 복잡도 수치에 전혀 영향을 못주기 때문에 오히려 측정하기 전보다 더 안하게 됐을지도 모른다.

어떻게든 ‘측정’  이 필요한 나같은 입장에서는 다양한 측면을 드러내는 지표를 꾸준히 모색하고 그것으로 해당 측면을 파악하고 나면 슥 다음으로 넘어가는식으로 역기능이 유발되지 않도록 부지런해져야 할 것이다.

오랜 기간 상벌에 단련된 조직 문화에 위키가 쉽게 정착될 지는 알수없다. 수평적 커뮤니케이션과 공동 저작을 통한 협업 모델이 아직은 불편할 수 밖에. 거기다 보안이란 잣대를 들이대면 내놓고 이야기하기도 어렵다.

우려되는 점들이 있다고는 하지만 작은 변화들이 모이고 쌓여서 큰 변화를 가져오길 희망하면서, 이번에 오픈한 위키가 좀더 활성화되고 효과적으로 사용될 수 있는데 일조하고 싶다.

바쁘다고 힘들다고 외면하거나 소극적이어서는 우리 정치와 우리 미래는 더 어두울 수 밖에 없다는 당연한 진실을 새삼 깨닫는다.

늘 깨어있어야 한다.