Dreamjr.ORG

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


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

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 개발 방법론 적용이 시작되었습니다.
기대 반, 두려움 반입니다.

제가 다니고 있는 데이사이드(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에 열심히 참여하는 것이 제 역할이겠지요.

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

Dayside 라는 회사에 들어가서 윈도우 모바일 개발자로 일을 한 지 한 달이 조금 넘었습니다.

그동안에 다녔던 회사에서 초기 컨셉으로 잡았던 '처음에는 조용히 있기' 를 탈피하여,
'처음부터 할 말은 하기' 컨셉으로 약 40일 간을 일했습니다.

이 컨셉의 좋은 점은...

1. 덜 쌓인다 - 하고 싶은 말을 그때 그때 하기 때문에 그리 많은 스트레스를 받을 일이 없지요. 물론 이야기를 할 때에는 아무 이야기나 막 던지면 안 되겠고,  '비폭력 대화' 와 같은 방법을 사용하여 잘 하는 것이 중요하겠지요.

2. 새로운 시도를 많이 할 수 있다 - 해 보고 싶은, 시도해 보고 싶은 방법들을 많이 이야기 하였습니다. 말을 했으니 하게 되고, 하다 보니 더 많은 것들을 해 보고 싶은 생각이 드는...선순환 구조에 빠져들 것 같네요.

그럼 한 달간, 일반 개발자가 하는 일 말고 어떤 특별한 일들을 하였을까요?

- 오후 미팅 제안
Dayside에서는 Scrum에서 이야기하는 아침 미팅을 이미 하고 있었습니다. 회의 시간이 다소 길고 본래의 취지와는 약간 어긋나 있기는 했지만 일단 하고 있었습니다. 그리고 퇴근 시간 전에 정리회의를 하더군요.
  문제는 퇴근 시간 전까지 상황 공유가 제대로 되어 있지 않다 보니 퇴근 시간 직전에 상황이 급박하다는 것을 알게 되어서 갑자기 야근을 한다던지, 8시까지 일을 하다가 늦게 저녁을 먹으러 가는 상황이 가끔 발생하더군요.
  중간에 한 번쯤 한 일/할 일을 공유하면 이러한 문제를 덜 수 있을 것 같아서 건의하였고, 현재는 오후 2시쯤에 중간 회의를 통해 상황 공유를 하고 있습니다.

- 할 일/한 일 메일 공유
  한 달간 느꼈던 제일 큰 어려움은, 일을 하고 있는 동안에 우선 순위가 높은 다른 일이 치고 들어오는 것이었습니다.
  오늘은 A, B, C를 해야지...라고 생각하고 있는데, A를 시작한지 20분이 지나서 한창 몰두하고 있는데 'D가 더 중요하니 D를 먼저 처리해 달라'는 요청이 들어와서 하던 A를 접고 D를 하게 되는 상황이지요. 이런 상황을 피할 수는 없겠지만, 최소한으로 줄인다면 뇌가 context switching 되는 낭비를 줄여서 생산성을 높일 수 있을 것입니다.
  이런 상황을 막기 위해서, 아침에 회의때 이야기한 한 일/할 일을 메일로 팀장에게 보냈습니다. 팀장도 보낸 일 목록을 근거로 하여 아침 회의 / 오후 회의때 우선순위를 조정해 주고 새로 해야할 일을 미리 말 해 주었습니다. 일이 긴급하게 치고 들어오는 횟수가 많이 줄어들었고 그만큼 집중력을 향상시킬 수 있었습니다.

- Mantis 설치 및 활용
  처음에 팀에 들어왔을 때, 이슈트래커가 없었습니다. 팀장님의 지시로 mantis를 설치하였습니다.
  업무 상황 공유를 위하여, mantis의 '이슈 감시자' 기능을 최대한 활용해 보았습니다. 제가 해야 할 이슈가 생기면 '이슈 감시자' 에 무조건 팀장님을 넣었습니다. 이렇게 되면 이슈 관련 코멘트를 달 때마다 그 내용이 팀장님에게 메일로 날아가므로, 현재 어떤 일이 진행되어 가고 있다는 내용을 알 수 있게 되어 팀 관리가 수월해지겠지요.

- SVN branch/tag 기능 습득 및 공유
  버전 관리 시, 특정 release 버젼을 따로 보관해 두는 기능 / 각자 다른 기능을 개발할 때 저장소를 부분적으로 따로 가져가는 기능을 팀에서 필요로 하였습니다. 전자는 tag로, 후자는 branch로 처리하면 된다는 것을 알고, 팀에 공유하였습니다. http://dreamjr.springnote.com/pages/3963331에 정리해 두었습니다.

- 페르소나를 이용한 기획 회의 제안
  P-Camp&대안언어축제 2008 에서 PyO에게 배웠던 페르소나를 이용한 기획법을 활용해 보자는 제안을 하였고, 채택되었습니다.
  페르소나를 이용한 기획 회의는 특정 인물의 페르소나(ex) 17세, 여고생, 키는 165cm, 약간 통통함, 미래에 대한 고민 많음, 남자친구 있음... 이런 식으로 가상의 특정 인물을 만들고 특성을 부여하는 것)를 만들고, 그 페르소나가 원하는 것이 무엇인지를 생각하며 기획을 하는 방법입니다.
  8월 14일(금)에 하게 될 것 같습니다.

  그 외에 CppUnitLite를 설치하고 테스트 해 본 것도 있지만, 아직 공개하지 않아서 회사에 아무 영향을 끼치지 못하였기 때문에 제외합니다.

  다음 포스트에서는 더 알차고 많은 내용을 추가할 수 있기를 바라면서, 하고 싶은 말을 하는 생활은 죽 계속됩니다.

나는 다음과 같은 엑셀 파일을 만들어서 개발할 때 사용한다.









날짜와 작업명을 기록한 후, 시간을 추정하여 '시간 추정치' 란에 기록하고
작업을 시작함과 동시에 스톱워치를 Start 한 후에
작업 종료와 동시에 Stop 버튼을 누르고, 해당 시간을 '실제 시간' 란에 기록하면
추정 오차 및 추정 오차율이 자동 계산되어 나온다.

작업 항목 옆의 란은 '비고' 란인데, 여기에는 작업 진행 중에 있었던 일 들을 간단한 회고 형식으로 한 문장 정도로 적는다. 적을 필요가 없으면 안 적기도 한다.

주로 20~40분 정도 되는 항목 2/3개 정도를 추정한 후 작업을 진행하고,
작업을 완료하면 다시 추정하여 개발을 진행한다.

컨디션이 안 좋을 때에는 30분 정도의 항목을
10분 내외의 항목 3개 정도로 쪼개서 진행하면
목표를 하나씩 달성하고 있다는 성취감 / 뭔가 하고 있다는 만족감 등의 기분을 느낄 수 있어서 슬럼프를 탈출하는 데 도움을 준다.
(대개의 슬럼프는 나태함, 또는 촉박한 일정때문에 마음이 급해져서 일이 손에 잡히지 않는 상태...이 둘 중 하나가 아닐까 생각한다)

추정 시간을 많이 over하고 있으면,
그것은 풀리지 않는 문제를 놓고 미로에 빠져버린 경우이므로
이럴 때에는 빨리 생각의 스파게티 속에서 벗어나서,
기존 항목을 새로운 항목 2~3개 정도로 나눈 후에 다시 작업해야 한다.

그런데, 이렇게 빠져나오기가 쉽지 않다. 이럴 때에는 강제로라도 잠시 바람을 쐬고 온 후에 생각을 정리해야만 한다. 페이스를 유지하는 것이 생산성을 높게 가져갈 수 있는 비결 중 하나라고 생각한다.

간편하면서도 쓸만한 개발 관리 툴이다.