블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (41)
Agile Experience (22)
My Family (0)
Life Style (7)
Programming (8)
Android (2)
Total
Today
Yesterday

달력

« » 2024.4
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

최근에 올라온 글

최근에 달린 댓글


전의 상실 후의 스프린트

약 2달전부터 7명의 팀원중 4명이 매우 중요하고 긴박하게 준비되는 프로젝트에 투입되었습니다. 엎친데 덮친 격으로 프로젝트 예상 일정이 크게 틀어져서 프로젝트 맴버들은 야간 작업과 주말 작업에 시달려야 했습니다. 프로젝트는 어느정도 마무리되었지만 4명의 팀원들은 사기가 바닥으로 떨어졌습니다. 물론 나머지 3명의 팀원들의 사기도 좋지 못했습니다.
그 후 팀장님께서는 여기서 고삐를 늦추면 다들 마이너스 사기로 돌아설 걱정에 스프린트를 진행하셨습니다. 물론 예상 작업량도 줄였고, 휴가도 넉넉히 할당하였습니다. 그리고 어제 그 스프린트가 종료되었고, 팀내 회고를 진행하였습니다. 이번 스프린트의 결과는 처참했습니다. 제대로 끝난 스토리가 없었죠.ㅠㅠ

비난 없는 회고 : 무엇이 잘못되었을까?
  • 스프린트 준비가 없었다
    다들 사기가 저하된 상태였던지라 스프린트 백로그에 대한 준비가 미흡했습니다. 따라서 초기 예측도 크게 빗나간 스토리가 많았습니다.
  • 얼렁뚱땅 데일리 미팅
    우리는 스프린트 백로그에 대응하는 스토리와 이를 세분하여 데일리 미팅에서 사용하는 테스크로 관리합니다. 준비가 없다보니 테스크는 미리 정의 되지 못했으며, 데일리 미팅에서 테스크를 즉석으로 마련해 내는 진 풍경이 발생했습니다. 따라서 스토리의 남은 예상 시간은 갱신되지 못했으며, 번다운 챠트도 엉망이 되었습니다. 테스크 관리가 제대로 이루어 지지 않아서 협업이 어려웠고 지연되는 스토리가 대거 등장하였습니다.
  • 스토리 및 테스크의 정의 미흡
    스토리와 테스크에는 종료 조건(데모 방법, 리뷰 방법, 테스트 방법 등)이 명시되어야 하는데 대부분 대충 제목만 적는 경우가 많았습니다. 또한 테스크의 크기는 큰 경우가 많았습니다.(1일~3일 단위) 이번 스프린트에서 리뷰도 거의 이루어 지지 않았으며, 데모를 한 스토리는 없었습니다.

다음 스프린트에서 더 잘하려면 무엇을 해야 할까?

우리는 이번 스프린트를 거울 삼아 다음 스프린트에서 어떻게 하면 더 잘할 수 있을지 논의 하였습니다. 팀원들은 각자 다음 스프린트에서 꼭 했음 하는 것과 꼭 하지 말아야 할 것등을 적어서 서로 공유하였습니다. 많은 이야기가 오갔지만 우리는 예상되는 효과가 좋을것 같고 지키기 쉬울 정도로 명확한 규칙을 몇개 선정하였습니다.
  • 스토리의 남은 예상 작업일을 매일 갱신하자
    데일리 미팅에서 스스로 남은 예상 작업일을 갱신하는 작업은 긍정적인 부담감(혹은 책임감)을 제공하는 요소중에 하나입니다. 또한 정확한 번다운 챠트를 그릴수 있게 합니다.  
  • 테스크의 크기는 4시간 단위 이하로 제한한다
    테스크의 크기가 커질 경우 테스크의 정의를 대충 할 수 있다는 경험을 하였습니다. 조금 더 명확한 가이드 라인을 제시함으로써 테스크를 명확하게 나눌수 있으며, 나누어진 테스크는 협업을 쉽게 할수 있게 합니다. 단, 스프린트 미팅에서 잘게 나누어진 테스크를 산출하기 어려우므로, 준비 상태에 있는 테스크의 크기는 제한하지 않되, 테스크를 진행하기 위해서는 위의 제한을 지켜서 테스크를 산출해야 합니다.
  • 테스크에 테스트 방법을 명시하자
    테스크의 종료조건 중 테스트 방법을 명시함으로써 미리 테스트 환경을 고려하여 테스크를 진행할 수 있게 합니다. 우리팀의 업무 특성상 타 팀과의 연동이슈가 많습니다. 따라서 테스트 환경을 미리 고려하지 않는다면 테스크가 종료되더라도 정확하게 테스트되지 않을 수 있었습니다.
  • 스프린트 사이에 2일간 종료 및 준비기간을 갖자
    그동안 스프린트 사이에 여유가 없어서 데모, 회고, 준비등을 잘 할 수 없었습니다. 스프린트 종료후 하루는 데모 및 회고를 함으로써 스프린트 종료를 명확히 하고, 다음 하루는 다음 스프린트를 위한 스프린트 백로그 공유 및 테스크 산출을 함으로써 스프린트 진행에 착오가 없도록 할 것입니다.

정리

어떤 방법을 사용하던 지속적으로 신경쓰고 개선하지 않으면, 습관화 또는 형식화 되기 쉽습니다. 우리 팀은 스크럼이라는 도화지에 우리 나름의 방법을 하나씩 그리고 있습니다.
Posted by 윤청하
, |
팀장 뒷담화와 커뮤니케이션 만족도

회사 동료들과 수다를 즐길때 쉽게 등장하는 주제가 바로 팀장 뒷담화입니다. 특히 술안주로 제격이죠.
얼마전 xper 모임에서 한 팀장님께서 발표하실 때 팀원들에게 '커뮤니케이션 만족도'라는 보상을 주기 위해 고민한다고 하셨습니다. 그런데 말단 팀원의 입장으로써 생각하면 할수록 이 '커뮤니케이션 만족도'라는게 얼마나 중요한건지 새삼 느끼고 있습니다. 그 이유는 팀장 뒷담화를 통해 알수 있죠.
우리 팀장님은 위에서 나오는 얘기들을 도통 해주질 않아.. 나 그 얘기(연봉 동결) 오늘 첨들었어..
우리 팀장님은 우리랑 밥도 같이 잘 안먹어..
우리 팀장님은 구현할 기능만 설명해 주고 그 기능이 나온 과정은 설명해주질 않아.. 왜 그 기능이 필요한지 모르겠어.. 그래도 구현은 해야지..
내가 구현하는 블럭이 누구와 메시지를 주고 받는 지는 모르겠지만 하라는 데로 하고는 있어.. 물어보고 싶은데 다들 바빠보이고ㅠㅠ
뒷담화의 대부분은 커뮤니케이션에서 오는 불만족이었습니다.(여기에 제 불만은 하나도 없습니다ㅋㅋ) 알고 싶은 것은 많은데 알기 어렵다는 것이죠. 그렇다고 팀장님께 따질수 도 없죠. 말단 팀원으로써 방법은 하나 밖에 없습니다.

당신은 묻기만 하면 된다

예전에 읽은 책이 생각났습니다. 랜디 포시 교수님의 마지막 강의!
가끔씩, 당신은 그저 물어보기만 하면 된다. 나는 묻는 것에 꽤 숙달된 사람이었다. 나는 용기를 내어 컴퓨터학 분야의 세계적인 권위자 프레드 브룩스 주니어에게 연락을 했던 일을 자랑스럽게 생각한다.
....
그때 나는 이십대 후반이었고, 꼭 한번 그를 만나고 싶었다. 그래서 나는 그에게 이메일로 이렇게 물었다. "만약에 제가 버지니아에서 노스캐롤라이나까지 운전을 해서 가면, 삼십 분 정도 제게 시간을 내어지실 수 있습니까?"
그는 답했다. "만약 자네가 운전해서 여기까지 내려오겠다면, 내가 삼십분 이상의 시간이라도 내겠네." 그는 나에게 한시간 반을 할애 했고 그날 이후 내 인생의 멘토가 되었다. 수년이 지나고 그는 노스캐롤라이나대학에서 강연해줄 것을 부탁하며 나를 초대했다. 그리고 그 여행은 내 인생에서 가장 중요한 순간으로 나를 이끌었다. 그때 재이를 만난 것이다.
때때로 당신은 그저 물어보기만 하면 되고 그것이 당신이 일생 동안 품어왔던 꿈을 이루는 길로 이끌 수도 있다. 요즘의 나는 "그냥 질문하기"에 이전보다 훨씬 능숙해졌다. 살날이 얼마 남지 않았기 때문이다. 다들 아는 것처럼 검사 겨로가를 받는데 며칠씩 걸리는 경우가 종종있다. 지금에 와서는 검사 결과를 초조하게 기다리는 것으로 남은 시간을 써버리고 싶지 않다. 그래서 나는 항상 묻는다. "어떻게 하면 최대한 빨리 결과를 알 수 있을까요?" 그들은 보통 이렇게 대답한다. "아, 잘하면 한 시간 안에  준비해드릴 수도 있겠군요." "잘됐군요. 물어보기를 잘했어요!" 내가 말했다.
궁금한 것이 있다면 질문하라. 그저 묻기만 하면 된다. 당신이 기대 하는 것보다 자주 당신이 듣게 될 대답은, "물론이죠."가 될 것이다.
팀장의 리더쉽도 중요하지만 그 팀장을 따르는 팀원들도 중요하다. 커뮤니케이션이란 양방향이다. 팀장님 혼자서 만족을 주기에는 무리가 있지 않을까?^^ 일단 물어보자!

'Life Style' 카테고리의 다른 글

개발자와 다이어트  (6) 2009.12.26
책은 깊이 읽어야 한다. 그리고 기록해야 한다.  (8) 2009.12.23
Carpe Diem  (6) 2009.11.11
Posted by 윤청하
, |
새로운 업무를 받음

얼마전 오래된 시스템(legacy system)에 새로운 플랫폼의 부가(extension) 모듈을 이식하라는 업무를 할당 받았습니다. 쉽게 생각하면 새로운 플랫폼은 유연성을 크게 가질수 있도록 작성되었으니 쉽게 이식 될 수 있다고 오해 할 수 있습니다. 저는 먼저 오래된 시스템과 새로운 플랫폼의 의존성을 확인하였습니다. 오래된 시스템의 일부 코드를 수정(modification)하는 것은 일단 허용하기로 하였습니다. 하지만 새로운 플랫폼의 부가 모듈을 바로(쉽고 빠르게 수정없이) 이식하기에는 문제가 있었습니다. 

무엇이 문제였을까

새로운 플랫폼의 부가 모듈은 하위 모듈(base library)에 의존성(dependency)을 가지고 있었습니다. 일반적으로 계층 기반(layer based)으로 모듈을 작성할 때 하위 계층에서 상위 계층을 직접 참조하는 것은 원칙적으로 불허 하지만, 그 반대의 경우는 허 하는 경우가 많습니다. 간단히 생각해보면 이는 크게 문제가 되지 않을 수 있지만, 상위 모듈이 하위 모듈에 의존하기 때문에 상위 모듈의 유연성, 재사용성은 매우 떨어지게 됩니다.

해결 방법

이와 같은 상황을 해결하는 방법은 다음과 같습니다.
  1. 오래된 시스템에 하위 계층까지 모두 이식한다.
  2. 새로운 플랫폼의 부가모듈을 컴파일 옵션으로 시스템에 따라 다른 하위 레이어를 사용하도록 수정한다.
  3. 새로운 플랫폼의 부가모듈을 복사하여 오래된 시스템에 맞도록 수정한다.
  4. 새로운 플랫품의 부가모듈이 가지는 하위 계층에 대한 의존성을 제거한다.

의존성을 역전시키자

위의 문제에서 하위 계층에 대한 의존성을 제거하는 것(해결방법 4)을 객체지향 디자인에서는 의존성 역전 원칙(The Dependency Inversion Principal)이라고 합니다.
High level modules should not depend upon low level modules. Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.
이 원칙은 상위모듈은 하위 모듈의 추상 클래스(또는 인터페이스)에만 의존함으로써 구체적인 구현에 대한 의존성은 갖지 않도록 하는 것입니다. 
위의 상황에서 의존성 문제가 되는 하위 모듈 중의 하나는 타이머입니다. 만약에 해결방법 1로 해결한다면 다음과 같은 그림처럼 작업이 이루어질 것입니다. 즉, 오래된 시스템에도 TimerB가 존재하지만, TimerA까지 이식함으로써 부가 모듈을 이식 가능하게 합니다. 이는 타이머 기능의 중복을 만들게 됩니다. 때에 따라서 TimerA의 의존성 때문에 다른 모듈들이 줄줄이 딸려가는 일이 생길수도 있습니다.
해결방법 2로 하게 되면 모듈의 구현 복잡도는 증가하게 될 것이며, 해결방법 3은 새로운 소스코드 브랜치가 생기게 되어 관리에 대한 부담이 증가하게 됩니다.
마지막으로 해결방법 4로 이 문제를 해결하면 다음과 같은 그림처럼 작업이 이루어 질 것입니다.
즉, 부가모듈은 ITimer라는 인터페이스에만 의존하게 되고 새로운 플랫폼과 오래된 시스템은 각각 해당 인터페이스를 Adapter Pattern을 이용하여 TimerA, TimerB로 구현하면 됩니다. 결과적으로 부가 모듈만 깔끔하게 이식할 수 있습니다.
저는 이 문제를 해결방법 4를 이용하여 해결했습니다. 제가 정의한 추상클래스는 다음과 같습니다.
IMpTimerListener는 타이머의 이벤트를 받기 위한 추상클래스이며, IMpTimer는 타이머 등록 및 해제를 위한 추상클래스입니다.

회고(retrospective)

사실, 이 업무를 진행하면서 모든 의존성을 위와 같은 방법으로 해결하지는 못했습니다. 기존 구현에 따라 해결방법 2를 사용한 경우도 있었습니다. (Define으로 구현되어 있어서 불가피 했음) 하지만 이러한 리팩토링을 통해 위의 부가모듈의 의존성은 상당히 사라지게 되었고 재사용성은 크게 증가하게 되었습니다. (추후 재사용 요구사항이 예상되는 모듈이었습니다.) 모든 모듈에 대해서 재사용성에 포커스를 두는 것은 over-engineering의 가능성이 있습니다. 하지만 이와 같이 재사용 이슈가 예상되는 모듈에 대해서는 의존성을 철저히 관리함으로써 추후 유지보수 업무를 줄일 수 있을 것입니다.^^ 감사합니다.

Posted by 윤청하
, |