고려할 옵션이 하나 더 있다. /OPT:NOREF 라는 최적화 옵션이다.

링커의 기본 최적화 설정은 따라 참조되지 않는 데이터를 링크할 때 삭제해 버린다. 이렇게되면 Coverage 분석할 때 모두 몇 라인 중에서 몇 라인이 커버되었다라는 분석데이터가 정확하지 않게 된다. 함수 foo() 가 테스트 코드에서 호출되지 않아서 실행파일에 포함되지 않기 때문이다.

/OPT:NOREF 옵션은 참조되지 않는 데이터도 유지하겠다는 옵션이다.

이 옵션을 찾게 된 이유는 새로 테스트를 추가했는데 오히려 Coverage가 낮아진 경우가 있어서였다. Test가 추가되었는데 Coverage가 낮아지다니!.. 하지만 TDD로 개발한 것이 아니다보니  어쩔 수 없는일… 우선은 TAD(Test after development)라도 열심히하고, 다음부턴 TDD 열심히 해야지.

• 어제 Beta 링크가 떴다. 가격이 $22. 살까 하는데 친구추천하면 40% 할인 쿠폰을 준다고 하여 우곤씨를 추천하고 쿠폰받아 $13.2 에 구입했다.
• PDF를 확인하니 두번 초청 교육받은 내용이 거의 전부다. (조금 아깝긴 하지만..) 그리고 아직 160페이지 정도만 Beta로 나온 상태. 완전판은 아마도 300페이지에 이를 것이다.
• 우리 팀에서 번역하기 위해 인사이트 출판사에 문의했으나 인사이트에서도 아직 판권을 확인하지 못한 상태라고 한다.
• 올해 안에 마무리 지어야겠지?

• 배터리가 오래간다 (실수로 와이어리스 켜놓지만 않는다면 걱정할 일 없음)
• 가독성이 좋다
• 눈의 피로가 적다
• TTS (단 리스닝이 딸린다면.. )
• MP3 들으면서 독서 가능하다
• 오디오북도 지원
• 노트북보다 가볍고 아이팟/아이폰보다 화면이 크다
• 약간 더 저렴한 가격에 즉시 받아볼 수 있다 (미국에서 출판되자마자 구입, 다운로드하여 읽을 수 있다)
• 부가 컨텐츠를 넣어서 볼 수 있다 (신문/잡지 등)
• 밑줄/북마크/메모 등을 추가할 수 있다
• 사전이 있어서 바로 찾아볼 수 있다.

google을 검색하면 여기저기서 자료를 구할 수 있는데 한글로 정리된 자료가 부족한 듯 하여 팀내위키에 정리된 것을 pdf로 만들어서 올려본다.

CodeCoverageUsingVisualCpp

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

• 기술부채가 낮아졌다
• 단위테스트를 모두 통과한다 (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을 살펴봐야겠다.