Dreamjr.ORG

특정 클래스(이해 K class)를 사용하기 위한 Adapter interface를 만드는 작업을
같은 회사의 그레이스(저희 회사는 닉네임으로 부릅니다.) 와 짝 프로그래밍으로 수행하였습니다.

스톱워치를 옆에 놓고 10분 단위로 키보드를 바꾸어 가면서
한 사람이 코딩하고, 옆의 사람은 잔소리ㅎㅎ 를 하는 형식이었습니다.

만들어야 하는 interface의 과제는
K class의 메소드를 사용한 바이너리를 에뮬레이터에서 실행시키는 것도 필요한데,
K class의 메소드를 사용한 바이너리를 Dev phone에서 실행시키면 죽어버린다는 것입니다.
바이너리는 에뮬레이터, Dev phone에서 둘 다 실행시킬 수 있어야 하구요.
해서 상황에 따라 K class를 격리(?)시킬 수 있는 구조를 만들어야 한다는 것이 가장 중요한 핵심이었습니다.

짝 프로그래밍 전에는
'격리시키는 구조를 만들어야 한다',
'exception class도 K class의 일부이기 때문에 exception class를 재정의 해야 하나?'
라는 막연한 생각밖에는 없었습니다.

짝 프로그래밍을 진행하면서
우선, 그레이스의 제안으로 인터페이스 하나에서 클래스 2개를 상속받고
하나의 클래스에서만 K class를 사용하자는 생각이 나와서 실행에 옮겼습니다.

그리고, 뭔가 확실한 상황을 알기 위해서 테스트를 진행하였습니다.
둘이서 작업하는 것이라서 테스트 하는 상황을 끊임없이 말로 상대에게 알려 주면서 진행하니 20분 만에 정리가 되더군요
그 결과 'K class를 import/선언만 하고 사용하지 않는 경우에는 Dev phone에서 실행시킬 수 있다' 는 사실을 알게 되었습니다.

클래스, 메소드 naming 도 비교적 원할하게 이루어졌습니다.
한 사람은 생각만 하고 있는데, 다른 사람은 naver 영어사전을 뒤져보는 등의 스킬을 발휘할 수 있었구요

Exception 관련된 내용도
'K class를 사용하지 않기 위하여
별도의 Exception class들을 정의하고, 이 Exception class에 errorCode를 설정하여
사용자가 errorCode에 맞게 handling을 하도록 하자.' 라고 정리가 되었습니다.

약 1시간 30분 정도 이와 같이 진행되었습니다.
이제 전체 클래스의 구조는 완성되었고,
각자 작업을 나누어서 하기만 하면 되는 상황이 되었습니다.

약 3시간 후에 완성된 작업 코드를 보니,
(당연하게도) 두 명이 각자 한 작업의 코드 형식이 거의 똑같았습니다.
마치 한 사람이 짠 것처럼...

이상이 어제 진행되었던 짝 프로그래밍의 시나리오(?) 입니다.

제가 생각하는
어제 했던 짝프로그래밍의 의의(?)는 다음과 같습니다.

- 위의 작업을 혼자서만 진행하였다면,
  두 사람이 사용한 시간(1시간 30분 * 2 = 3시간)을 훌쩍 넘겨 4시간 이상 걸렸을 것이라는 생각이 들었습니다.
  상대방의 생각으로부터 영감을 얻고, 내가 머릿속으로만 생각하고 있는 것을 말로 풀어내는 과정 속에서
  해야 할 것들의 우선순위가 드러나고, 일이 지속적으로 진행이 되더군요.

  게다가, 두 사람이 하나의 모듈에 대한 완벽한 이해도(자기 자신이 직접 만들었으므로)를 가지게 되었습니다.
  이것은 추후에 비상 사태(둘 중 한명이 없다던지, 수정해야 할 양이 많다던지)가 발생하였을 경우에
  상당한 시간 절약 효과로 나타날 수 있습니다.
 
- 짝 프로그래밍 때에는, 옆 사람이 지켜보고 있으므로
  혼자서 일할 때 보다 집중도가 두 배 이상이 됩니다.
  짝 프로그래밍은 빡셉니다. 지치더군요 ㅎㅎㅎ

- 짝 프로그래밍 때에는
  키보드를 안 잡은 사람이 마구 딴지, 수다를 떨어 주어야 도움이 많이 됩니다. (어제는 그랬습니다 ㅎㅎ)

- 무엇보다도 가장 인상 깊었던 것은...
  짝 프로그래밍이 여유있는 상황이 아닌 급한(Extreme한) 상황에서 진행되었다는 것입니다.
 
  짝 프로그래밍이 시작된 시간이 오후 4시, 종료되더라도 6시에 가까운 시간,
  그 이후에 약 3시간 정도의 작업량...
  다소 마음이 급한 상황이었습니다.

  그 상황에서 짝 프로그래밍은 위와 같은 성과를 보여 주었습니다.

  애자일 방법론에서 제시하는 여러 practice들(Scrum, TDD, 짝 프로그래밍 등...)은
  널럴한 상황에서 여유있고 재미있자고 적용하는 것이 아닌,
  급하고 빡센 상황을 대비하고, 헤쳐 나오기 위해서 위해서 시작되었습니다.

  저 개인적으로는 이러한 방법들이 급하고 빡센 상황에서 개발 기간을 단축하는 데
  일조할 것이라는 확신이 있습니다.

한줄로 요약하면
"짝 프로그래밍은 재미있고 유익했다" 입니다. ^^

저희 회사(데이사이드)가 역삼동 성당 바로 옆으로 이사왔습니다.
근무 환경도 좋아지고 공간도 많이 넓어져서
스프린트 현황판도 다음과 같은 위용을 가질 수 있게 되었습니다.


<사진. 스프린트 현황판의 위용>

12월 4일 오후에 스프린트 종료 데모가 있었고
12월 7일 오전에 1층 까페에서 스프린트 회고 시간을 가짐으로써
2nd 스프린트가 종료하였습니다.

저는 출산 휴가로 인해 절반 정도 자리를 비웠습니다.
다녀와 보니 많은 것들이 달라져 있었습니다. *_* 다른 분들이 고생이 많으셨을 듯 ^^;

이번 스프린트의 가장 큰 성과는
'가시적인 결과물' 입니다.
완벽하진 않지만 기능을 제대로 하는 프로그램이 탄생하였고, 스프린트 종료 회의시간에 데모를 할 수 있는 수준까지 되었습니다.

스프린트 회고 내용은 다음과 같습니다.

<좋았던 것>

- SDK 관련하여 많은 생각을 할 수 있었음

- TDD가 손에 익었다. 설계에도 많은 도움이

- 이사 후, 공기/의자 등 작업환경이 개선되어 능률이 좋아졌다.

<나빴던 것>

- UI 작업은 XML 작업이 많아서, 마치 코더가 된 것 같다.

- TDD 때문에 예상한 작업 시간보다 다소 길어진 면도 있음

- UI는 XML 기반이라서 TDD 적용이 힘들다

- UI 작업시, 참고할 문서나 자료를 찾기 힘들어서 내가 확 그려버리고 싶을 때도 있다.

- 이사의 여파가 며칠 갔다. 이사에 사용되는 시간을 하루로 예상했는데 그보다 더 많이 사용하였음

- 문제가 해결되지 않아서 삽질을 조금 했는데, 알고보니 무선랜 문제

  à 문제점을 잘 파악하는게 중요할 듯

<재미있었던 것>

- 어플이 실제로 보이기 시작한다.

<제안 사항>

- 회고 내용도 위키에 정리하자

- TDD를 위한 pair programming

- class간의 dependency를 낮추자

à 최대한 짜잘짜잘하게 나누면 좋음. 설령 나중에 합치더라도 이렇게 해 두면 편함

- API 문서를 시간 날 때마다 읽자

- 코드 리뷰

à 회의실 생기면 하자. 우선 필요한 내용을 위키에 정리해 둘 것. 좋은 분위기에서 진행
    코드 리뷰 중, 기술적인 내용이 비교적 적은 UI, TDD 관련 내용에는 Amy를 참석시키자.

- 추정이 많이 틀렸는데, 걸릴 시간을 솔직하게 말하자

à 추정이 틀리더라도, 하루 단위로 tight하게 잡으면 오히려 일할 때 늘어지지도 않고 좋을 수도…작업 시간이 늘어나면 그때 그때 이야기 하면 좋을 것 같다.

  집중도 70%를 감안하여 추정하자.

  번다운 차트에도 70%를 명시할까?

- 다음 회고 회의때는 Amy를 참석시키자.

<다음 Sprint 때 적용할 제안 사항 Top 2>

- 재 추정시 집중도(70%)를 감안하여 추정하자.

- 다음 sprint 때에는, TDD pair programming을 개인당 최소 1회 진행하자.

그 동안 이런 저런 일로 바빠서(아빠가 되는 일로 ㅎㅎ)
두 번째 스프린트 회의 관련된 글이 많이 늦었습니다.

11월 19일, 스프린트 회의를 시작으로
두 번째 스프린트가 시작되었습니다.

지난 번 스프린트 회고 때 나왔던 의견인 "Backlog를 추정할 때 추정치를 각자 제시하고, 추정치가 서로 다른 경우에는 이유를 논의한 후에 개개인이 추정한 추정치의 평균값으로 정하자" 를 수행하기 위하여, 추정 카드를 사용하였습니다.


<사진 1. 추정카드>

추정 시에 다음과 같이 각자가 카드를 들어 의견을 제시한 후,
추정치가 비슷하면 평균을 내어 결정하고
추정치가 다르면, 추정치를 크게 정한 사람과 적게 정한 사람이 각자의 입장을 밝힌 후 결정하는 식으로 진행되었습니다.


<사진 2. 추정치를 제시하는 중>

이와 같은 과정을 거쳐 두 번째 스프린트가 시작되었습니다.

약간의 미숙함과 기대감으로 시작하였던 첫 번째 Sprint가 드디어 종료되었습니다.

11월 18일, 첫 번째 스프린트 회고 미팅을 가졌습니다.
회의실에서 백로그/번다운차트 회고 및 각자 결과물을 데모하는 시간을 가졌고,
커피숍으로 자리를 옮겨서 Sprint 전체에 대한 회고를 자유로운 분위기에서 진행하였습니다.

PMIS(Plus, Minus, Interesting, Suggestion) 회고를 하였고,
제안 사항 중에 3가지를 투표로 선정하여 다음 Sprint에 반영하도록 하였습니다.

회고에서 인상깊었던 것 하나는
누가 시켜서 하는 압박이 아닌, 상황판과 동료들이 주는 무언의 압박(?) 관련한 내용이었습니다.

저의 경우에, Scrum 방법론을 사용하고 있지 않았다면
출산이 임박한 상황이고, 프로젝트 초반이므로
슬슬 일하고 어느 정도 농땡이를 피우다가 출산 휴가를 갔을 가능성도 꽤 있었을 것 같습니다.
그러나 상황판이 지켜보고 있었기 때문에 ㅎㅎ 그렇게 할 수 없었습니다.
대신, 약간의 성취감을 얻을 수 있었지요.

이런 것이 Scrum의 장점 중 하나인 것 같습니다. 자발적인 압박감!

회고 결과는 다음과 같습니다.
<좋았던 것>

-       상황판이 지켜보고 있다.
à 일을 하도록 만든다.

-       시간을 추정하고, 분배하는 것 자체는 좋았음

-       스프린트 종료 시, “무언가 했다” 는 느낌
à 수행한 내용을 구체적으로 볼 수 있었다.

-       일을 몰아서 하지 않고 꾸준히 할 수 있었다.

-       강제로 한다는 느낌이 적었다.

-       하록님이 작성한 ‘SVN 설정 30분 완성’ 위키 페이지는 도움이 많이 되었다.

<나빴던 것>

-       시간 분배, 시간 지키기가 생각대로 잘 되지 않았다.
à 시간이 지나면 좀 나아지겠지…

-       오전 Scrum 회의 때 상황판 앞에서 자기가 할 일을 assign 할 때에 서먹하다
à 뭘 가져다 해야 할지…

-       백로그 하나의 추정치가 15일인 것이 있었는데, 좀 길었던 것 같다.
à 최대 10일 정도로 세분화해야 하지 않을까?

-       기존 방법에서는 각자 기능을 맡아서 하기 때문에, 각 기능에 능숙해졌는데
Scrum에서도 이렇게 각 기능에 능숙해지는 것이 가능할까…?

-       서로 미루게 되는 일이 있지 않을까?
à 지켜보고 있으므로 미루기 쉽지 않다…

<재미있었던 것>

-       스스로 압박되는듯한 분위기
à 오전 Scrum 회의 때, 다들 무언가를 하고 있는데, 나도 뭔가를 해야 하겠다는 생각…

-       기존 개발 방식으로 돌아가자는 압박이 있을 때,
번다운 차트 등의 현황판을 제시하면서 ‘이러이러하게 진행되어 가고 있다’ 고 설명할 수 있음

-       ‘시켜서 일 한다’는 느낌이 적어 스트레스가 덜하다.

<제안 사항>

-       위키에서 세부적으로 필요한 내용이 있으면 페이지가 만들어져 있지 않더라도 대괄호([[ ]])로 묶어 놓자.
누군가가 페이지를 생성할 것이다.

-       위키를 많이 씁시다.

-       Backlog 추정치는 최대 10일로

-       Backlog를 추정할 때 추정치를 각자 제시하고,
추정치가 서로 다른 경우에는 이유를 논의한 후에 개개인이 추정한 추정치의 평균값으로 정하자.

-       Task에 본인의 이름/수행한 시간을 적어 두자

-       하나의 Backlog를 완료한 경우에, 관련 이슈를 적어 두자.

-       아침회의 때 부드럽게 말하자.

-       아침회의 때, 해야 할 일을 자발적으로 선택하자.

-       추정치를 지켰거나, 더 일찍 한 경우에 박수를 쳐 주자

-       Backlog를 추정할 때, 한 명은 Tight 한 추정치를 제시하여서
추정치에 균형을 맞추도록 하자.

<다음 Sprint 때 적용할 제안 사항 Top 3>

-       Backlog를 추정할 때 추정치를 각자 제시하고,
추정치가 서로 다른 경우에는 이유를 논의한 후에 개개인이 추정한 추정치의 평균값으로 정하자

-       하나의 Backlog를 완료한 경우에, 관련 이슈를 적어 두자

-       아침회의 때, 해야 할 일을 자발적으로 선택하자.

11월 3일에, 드디어 역사적인 첫 번째 스프린트 미팅을 가졌습니다.






















Backlog 목록입니다.

인터넷에서 찾은 Scrum Backlog용 엑셀 파일을 사용하였습니다. Backlog 관리하기에도 좋고, Backlog를 index card로 자동으로 변환해 주는 상당히 편한 툴인데, 다른 글에서 소개하도록 하겠습니다.

몇몇 Backlog를 추가하고, 덩치가 큰 Backlog는 나누는 작업을 수행하였습니다.

Backlog 제품관리자는 Dayside 솔루션팀에 얼마 전에 입사한 QA분(이하 Amy)이 맡아 주셨습니다.























의욕적으로 Scrum을 추진하고 계신 간지 PL 하록님의 카리스마! ㅎㅎ






















완성된 Scrum dashboard의 위용.

Task 한 칸에는 현재 Sprint에서 진행중인 Index card가 들어갑니다. 위에 있는 것일수록 우선순위가 높은 것이지요.

Index card 밑에 붙어있는 포스트잇은 각 Index card의 task들입니다. 작업이 진행 되면 이 task들이 TODO / DONE으로 옮겨지게 됩니다.

옆에는 Burndown Chart가 붙어 있고, 그 밑의 Intercept 란에는 예정에 없이 치고 들어오는 일의 목록이 붙게 됩니다. Scrum에서는 하나의 Sprint 진행중에는 새로운 일을 추가할 수 없도록 되어 있지만, 현실은 그러기 쉽지 않으므로 일종의 타협을 두자는 하록님의 의견이셨습니다. 이렇게 되면 나중에 'Intercept 되는 일 때문에 Burndown Chart가 영 진전이 없네요' 라는 변명거리도 될 수 있겠구요 ㅋㅋㅋ

마지막으로, Intercept 칸 밑의 Inventory는 현재 Sprint에서 진행될 예정이지만, 우선순위에서 밀려서 기다리고 있는 Index card가 붙어 있습니다.























제품 백로그 목록판입니다.
아직 할당되지 않은 Backlog Index card들이 붙어 있는 상황판입니다.

Backlog는 엑셀로 관리되지만 엑셀 파일은 보는 사람이 별로 없기 때문에, 이렇게 붙여 놓아서 지나다니는 사람 또는 관리자가 보면서 우선순위를 조정한다거나 문구를 수정할 수 있도록 하자는 하록님의 의견으로 탄생한 아이템입니다.

생각보다 쉽지는 않지만, 일단 Scrum 개발 방법론 적용이 시작되었습니다.
기대 반, 두려움 반입니다.

지난 주에, 역삼동의 와인 바를 찾아갔다.
사장님이 소믈리에셨고, 같이 갔던 분이 그 사장님과 친분이 있으셨던 분이라 와인에 대하여 많은 설명을 들을 수 있었다.

2병의 와인을 마셨는데,
그 중 하나가 Montes classic 이라는 칠레산 와인이었다.

<Montes classic 2007년산, 출처: http://www.monteswines.com/ >

맛이 풍만하고, 끝맛이 진한 타입의 와인이었다.
나중에 또 맛보고 싶어서 기억하려고 하였는데, 기억하기 위하여 나는

'휴대폰을 꺼내어 와인 명을 기록' 하였다.

옆 자리에 앉아 있던 형은

'와인 병의 모양과, 찍혀 있는 천사 캐릭터 이미지를 기억' 하였다.

이처럼 어떤 사실을 기억하는 방법은 여러 가지가 있고,
나는 주로 기록에 의지하는 방법을 사용해 왔던 것 같다.

수업시간에 선생님(or 교수님)이 설명하시는 모든 항목을 노트에 적으려고 했고
이와 같이 필기에 목을 맨 결과...
며칠 지난 후에는 배웠던 내용이 가물가물해 졌지만,
시험기간에는 노트필기의 힘으로 많은 내용을 복습할 수 있었던 것 같다.

그러나, 실생활을 할 때에는 노트에 기록한 내용보다는 머리에 각인된 내용이 필요할 때도 많다.

해서 요즘 몇 가지 실험을 해 보고 있다.

실험 1)
지난 주에, 이대 목동 병원 빈소에 다녀왔다.
버스정류장의 위치를 기억해야 집에 무사히 돌아올 수 있는데...
종전에는 '사진 찍어두기', '무슨무슨 건물 옆의 어디쯤 이라고 메모를 남기거나 기억해 두기'의 방법을 사용하였는데,
이번에는 그냥 버스정류장 주변을 1분 정도 쳐다보며 풍경의 이미지를 '각인' 시켜 보았다. 어떠한 기록도 남기지 않은 채...

돌아올 때 버스 정류장 근처에서 '아! 이곳이었지!' 라는 느낌을 받을 수 있었고, 그 느낌은 아직까지도 살아 있다.

실험 2)
목사님의 설교를 들을 때에,
수첩에 메모를 하지 않고, 하시는 말씀의 이미지를 머리에 넣어 두는 식으로 들어 보았다.
모든 내용을 기억할 수는 없었지만, 몇 가지 중요한 내용은 생생히 남아 있다.

회고)
그 동안 너무 좌뇌만을 사용하여 기억을 하려 했던 것이 아니었을까?
이미지를 통하여 기억하는 방법의 장/단점 : 모든 것을 기억할 수는 없지만, 중요 사실들을 매우 오랜 시간까지 생생히 남길 수 있는 장점이 있다.
길을 찾아갈 때에는 이미지를 통한 방법을 사용하는 것이 좋을듯. '길치'의 오명을 벗을 날이 멀지 않았다!!!
프로그래밍 공부에도 사용해 보면 어떨까?

오늘의 작업로그 기록...
컨디션은 상당히 나른하다.

11:20)
인수인계 작업 중
뽑아낼 작업 목록 작성 완료.
어느 정도 일을 진행하고 있다. 50% 정도?
점심먹기까지 남은 30분 동안 달려보자!

18:20)
열쇠 없어서 1시간 허송세월, 그 후 Windows mobile 코드 인수인계 작업

인수인계를 진행하면서, '내가 코드를 이렇게 짠 부분도 있구나' 라는 생각에 상당히 부끄러웠음...
프로젝트 진행하면서 중간 중간에 코드 리뷰를 하면, 중간 중간에 부끄러워하겠지만 최종 코드 품질에는 도움이 많이 될 것 같다는 생각을 하였음.

Mobile 폰에 들어가는 코드에는 메모리 관리를 더욱 잘 해야겠다는 생각

Scrum 관련 준비작업(물품 사오기 등)을 하였음. 그냥 일보다 이런 준비작업이 더 재미있다.

인수인계 관련 작업을 많이 해서 그런지, 오늘은 한 게 없다는 생각에 조금 허무해지려고 함.
또한, 중간 중간에 이런 저런 이유로 1시간마다의 회고를 소홀히 하여 회고의 효과가 거의 없었다는 점이 아쉬움.

요즘 잠시 슬럼프 기간인 것 같아서
한시간 단위로 알람을 맞춰 두고, 알람이 울릴 때 마다 회고를 한 후에
그 내용을 기록해 보려고 합니다.

오전 10:57)
팀장님이 다소 급해 보이셨음. 뭔가를 빨리 해야 한다는 분위기. 하지만 스트레스 받지 않고 차분하게 진행하려 노력중.
오전에 뻘짓(웹서핑;;)을 하지 않았다는 것에 큰 의미를!
일이 약간 하기 싫어서, 다른 일에 집중하여서 성과를 냈음.

오전 11:59)
이런 저런 일들을 잘 수행하고 있음(개발 외 다른 일들)
다운로드 받으면서 잠시 웹서핑...

오후 2:51)
피곤하기도 하고, 멍 하기도 하여 웹서핑을 주로 하였음
30분쯤 지난 후, 이렇게는 안되겠다는 생각에 유용한 자료를 읽고 있음
읽던거 마저 읽고 난 후, 좀 쉬어야겠음

오후 4:19)
여전히 멍한 상태, 많이 놀았음
마지막 20분 정도는 작업을 열심히 하였음. 이제 슬슬 일하는 감이 생기고 있음

오후 5:29)
개발 관련된 일부 작업을 수행. 비교적 단순한 작업(설정, 테스트, 소스 보기 등)을 수행하였음
또다시 free 한 상태가 되었다. 한시간을 잘 써봐야지.

제가 다니고 있는 데이사이드(www.dayside.com) 에서
PL 역할을 맡으신 개발자(이하 하록)의 제안으로,
다음 개발 프로젝트를 Scrum으로 시작하기로 하였습니다.

제품 담당자를 선정하고, 상황판을 붙이고
sprint 계획 회의로 하나의 sprint를 시작하고
매 sprint 종료 시 회고를 진행하는 등의 전형적인 Scrum을 적용합니다.

나왔던 이야기 중에 기억에 남는 것들을 말해 보자면,

- 1차 sprint는 11월부터 2주만 진행,
일단 업무 기간의 50% 정도의 일만 배정해 두고, 나머지는 급하게 끼어드는 일을 처리하는 시간으로 비워둔다.
- 전 Sprint에서 발생한 버그는, 다음 sprint의 초반부에 야근을 불사하여서라도 처리한다.
- TDD를 적용하도록 한다.
- 아침회의는 현황판 앞에서, 팀장님도 별도로 참석(하시지만 발언권은??)
- 개발 지연시, '언제까지 끝날것이냐' 라는 질문은 금지
--> 현황판에 update하고, 무조건 현황판을 본다
- 회고 : 좋았던 것 / 그저 그랬던 것 / 나쁜 것
          나쁜것 중에 제일 큰 점수 2개는 반드시 개선.
- 회고, Sprint 회의는 모두 참석
  발언권은 팀원만 갖는다.
- sprint 종료시 Lab day를 하루간 갖고, 그 하루는 자기가 하고 싶은 것을 하는 날로 삼으면 좋겠는데...가능할지는 확실치 않음
- 급한 요구 사항이 발생하면 sprint를 취소하고 sprint 계획 회의를 다시 갖는다.

회의가 끝난 후, 간단하게 Userstory를 뽑아 봤는데, 생각보다 쉽진 않더군요.
아직 개발해야 할 내용이 확실히 정해진 것도 아니고, 무엇보다도 말을 만드는 것이 생각보다 어려운 작업이었습니다.
그래도 약 20개 정도의 story를 뽑아 보았습니다.

SI 프로젝트에서 적용하는 agile이라...
회사에서 agile을 적용해 보는 것은 꿈이었는데,
설레기도 하고 약간 걱정이 되기도 합니다.

하록님은
뭐든 해 보고, 안되면 그때 가서 개선하면 된다고 하셔서
많은 용기를 얻었습니다.

참고로 저의 역할은
기존에 적용해 보았던 TDD 방법을 제안하여, 설계에 반영시키는 것입니다.
심심풀이로 만들어 보던 iPhone project에 적용한 TDD를 이번 주 목요일 정도에 회사에서 발표해 보고자 합니다.
그 외에 여러 process에 열심히 참여하는 것이 제 역할이겠지요.

회사 다니는 것이 갑자기 막 즐거워집니다.

<배운 것>
- Android 어플에서, 가로 모드로 시작하는 법
- 새로운 SDK를 탐험할 때에는, API 문서 및 관련 소스를 많이 디벼 보는 것이 좋다는 것

<좋았던 것>
- 산세베리아가 도착하였다.
- 점심시간에 좋은 시간을 가졌다. 뭔가 좋았던 것 같긴 한데 까먹었다;;

<나빴던 것>
- Android 에서, Video의 크기를 resize 하는 법을 알아내지 못했음.
SurfaceHolder 클래스의 setFixedSize 함수를 호출해 보았으나 효과가 없었음.
그룹스 및 기타 게시판에도 관련 질문만 있고 답변은 없음
- 휴식 시간을 많이 갖지 못함
- eclare 가 Android 2.0 이었다 OTL
1.6이 최신버젼이라고 생각하여, Android 버젼명이 아니라고 우기다가 한 방 맞았음 ㅠㅠ 기술 관련된 내용은 내가 항상 맞는 것이 아니므로 신중하게 생각하자!
- eclare에 대해 나온 내용이 별로 없음(SDK도 아직 나오지 않았다)
제조사에만 풀린 듯 한데, 프로젝트의 큰 불확실성 이슈가 될 수도 있겠다.

<시사점>
- Opencore 소스 분석을 위해, SourceInsight 같은 프로그램이 있으면 좋을 듯.
- Opencore를 통채로 빌드해 보면 어떨까? cygwin만 깔면 ㅇㅋ일 듯 한데