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

카테고리

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

달력

« » 2024.3
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
31

최근에 올라온 글

최근에 달린 댓글

   켄트백의 "익스트림 프로그래밍 2/E"에 다음과 같은 글이 있다.
  •   상황이 어떻건 간에 당신은 언제나 더 나아질 수 있습니다.
       No matter the circumstance you can always improve.
  •   당신은 언제나 자기 자신부터 개선을 시작할 수 있습니다.
      You can always start improving with yourself.
  •   당신은 언제나 오늘부터 개선을 시작할 수 있습니다.
      You can always start improving today.

나는 오늘부터 개발자로써의 나 자신을 개선하기 시작한다. 
(먼저 저에게 확신, 용기 그리고 영감을 주신 변신철님, 박피디님, 이희찬님, 박형근님, 김창준님께 감사드립니다.^----^)

회고 - 왜 실패했을까?

나는 지난 수개월간 TDD를 스스로에게 적응시키기 위해 부단히 노력하였다. (켄트백의 책은 이해가 잘안되서 3번이나 읽었다.ㅠㅠ) 팀내 동기인 이희찬(http://heestory.kr)씨와 함께하였으며, TDD에 적극적으로 동참하고자 하였다. (불행히도 둘다 팀에서 말단급이다ㅠㅠ. 하지만 나는 팀의 말단에서부터도 변화할 수 있다고 생각한다^^)
하지만, 난 아직도 TDD에 적응하지 못하였다. 이유가 무엇일까? 스스로에게 물어보았다.
  • 의도적 수련 시간의 부족 
    안데쉬 에릭손이 주장한 1만 법칙에 따르면 1만 시간 동안 의도적 수련(deliberate practice, 자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련)을 해야 그 분야의 전문가가 될수 있다고 한다. 또한 TDD의 성공사례를 찾아보면 수개월만에 몸에 익숙해졌다는 사례는 찾기힘들다.
    TDD는 기존 개발 방식을 완전히 뒤바꾸어 놓은 개발 방식이다. 즉, 이미 수년간 몸에 익은 습관을 버리기 매우 힘들다. 변화할만 할때 변화한다. 난 아직 의도적 수련을 더 많이 해야 한다!
  • 테스트 케이스 작성의 어려움
    나는 팀에서 독립적으로 개발 가능한 라이브러리(영상 코덱)을 개발할때 TDD를 적용하려고 했다. 
    하지만, 쉽지않았다. 영상 코덱은 결과물이 영상이기 때문에 자동적으로 옳고 그름을 판단하기 어려웠다.
    어떤 알고리즘은 특성상 최적해(optimal value)를 찾기 보다는 제일 괜찮은 해(best effort)를 찾는 경우도 있는데 정답을 판단하기 어려웠으며, 수학 공식이 있는 부분은 손으로 계산하기 귀찮았다.ㅠㅠ

그럼에도 불구하고 왜 꼭 TDD를 해야 하는가?

  • 선배들의 아픔을 똑같이 경험하고 싶지 않다. 
    기 개발된 다른 코덱들은 테스트 케이스가 전혀 없었으며, 지금도 가끔 상용싸이트에서 장애를 일으키고 있다. 장애가 나면 담당 개발자는 무지하게 골치아파진다.
  • 기존(legacy) 코드는 테스트하기 어렵다.
    내가 작성중인 코드도 어렵다.ㅠㅠ
  • 지속적인 검증이 필요하다.
    영상 코덱은 리눅스 버전으로 기능 개발이 완료된 후 리눅스에서의 최적화 작업(알고리즘 및 어셈블리 최적화)과 DSP 보드 상에서의 최적화 작업(메모리 및 어셈블리 최적화)을 하게 된다. 따라서 자동화된 유닛 테스트가 있다면 해당 작업들이 매우(x백만개) 수월하게 작업할 수 있게 된다.
원래 목표는 자동화된 단위테스트(unit test) 케이스를 누적시키는 것이다. 회사내 수석 개발자 분에게 TDD를 언급하면 항상 이점을 지적하시면서 화이트 박스 테스팅을 하라고 강조(TDD는 말고)하신다.
하지만 TDD의 이점은 자동화된 테스트 케이스의 누적에만 있지 않다. 기존(legacy) 코드를 위해 테스트 케이스를 만들어보려고 시도해본 이는 알것이다. 테스트에 적합하게 작성되어 있지 않은 코드는 당연히 테스트 하기 어렵다. 불행히도 거의 대부분의 기존 코드는 테스트에 적합하게 작성되어 있지 않다. 재미있는 사실은 테스트에 적합하게 작성된 코드는 매우 명확하고 깔끔해 진다는 것이다.
또한 TDD는 점진적인 리팩토링을 하도록 유도한다. 즉, 기존 코드도 점진적인 리팩토링을 통해 거듭날 수 있다. (이는 TDD와 무관할 수도 있다.)

그럼 바로 지금부터 무엇을 할 것인가?

  • 기존 코드는 큰 기능 단위부터 자동화된 테스트를 만들어 본다.
    결과물이 영상이기 때문에 완전히 일치하는지 검사하는 것 보다는 유사성 테스트를 통해 자동적으로 판별하고 유사성이 크게 떨어질 경우 눈으로 확인하는 절치를 스크립트로 작성한다.
  • 신규 개발 코드는 어떤 일이 있어도 TDD로 작성한다.
  • 추가 개발 코드는 테스트 케이스 추가 및 테스트 가능한 인터페이스로의 리팩토링, 이 두가지 작업을 적절하게 조합하여 테스트 케이스를 어느정도 만든뒤 작업한다.
이렇게 꾸준히 작업하면 테스트 커버리지는 자연적으로 상승할 것이다.
나는 XP 정신으로 바로 오늘부터 시작하였다!^^ 뽐뿌 백만개 받았다~ (금요일이라 그런가ㅡㅡ^)
오늘 신규 개발된 코드는 모두 TDD로 작성되었으며, 빠른 테스트를 위해 스크립트도 작성하였다.


앞으로 TDD를 잘하기 위해 필요한 자료들을 정리해서 올려보도록 하겠습니다~ 감사합니다.


'Agile Experience' 카테고리의 다른 글

xper 11월 정기모임 회고  (12) 2009.12.01
우리 팀에 스크럼을 적용했어요 - 마무리  (12) 2009.10.28
xper 10월 정기모임 회고  (10) 2009.10.24
Posted by 윤청하
, |
2009/10/12 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 1편
2009/10/13 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 2편
2009/10/19 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 3편
2009/10/28 - [Agile Experience] - 우리 팀에 스크럼을 적용했어요 - 마무리

1편에서 빼먹은 내용

이 글은 수개월에 걸쳐 스크럼을 개발팀에 적용한 경험을 바탕으로 작성되었다.
개발팀은 7명의 개발자로 이루어져 있으며, 팀의 주된 업무는 통신용 서버 시스템 및 플래폼 개발이다.
실패든 성공이든 각자의 경험을 공유함으로써 한국의 개발자들도 인간적인 삶을 살수 있다는 믿음으로 이 글을 작성한다.

스프린트 회고

스크럼에서 스프린트 사이에 스프린트 회고 및 스프린트 계획 회의는 반드시 해야 할 일들이다.
초기의 스프린트 회고는 스프린트 동안 스크럼을 적용하면서 각자 느낀점을 나누는 정도였다.
데모를 하자는 의견을 냈으나, 다수의 분들이 데모의 필요성을 느끼지 못하여 적용하지 못했다.
몇번의 스프린트가 진행되고 나서 우리는 스프린트 데모의 필요성을 느꼈다.
우리는 스프린트 계획 회의에서 각 스프린트 백로그를 어떻게 데모 할 것인지 결정하였다.
결과적으로 우리는 스프린트 회고를 하면서 자연스럽게 스프린트 백로그 별로 데모를 진행하게 되었다.
말로만 주고받던 회고에서는 없었던 날카로운 피드백을 눈으로 보이는 데모를 진행하면서 주고받게 되었다.
우리는 점점 오픈되고 있었고 우리의 제품은 점점 발전하고 있었다. 조금씩 조금씩..

스프린트 계획 회의

우리의 스프린트 계획 회의는 한번에 끝나는 일이 없었으며, 지연되기 일쑤였다.
회의를 지연시키는 원인중 하나는 스프린트 백로그의 예상 시간을 결정하는 일(추정)이었다.
나는 다음의 책에서 소개하는 플래닝 포커를 적용해 보기로 하였다.
불확실성과 화해하는 프로젝트 추정과 계획 
(규모추정, 우선순위, 일정배치)
Agile Estimating and Planning
마이크 콘 지음 (이병준 역, 인사이트)

재미있게도 위의 책을 주문 하였더니 인사이트에서 플래닝 포커를 할수 있는 매우 이쁜 카드를 보내주셨다.

불확실성과 화해하는 프로젝트 추정과 계획 책을 주문하고 받은 선물

플래닝 포커는 우리가 스프린트 계획 회의를 재미있고 빠르게 진행 할 수 있도록 실질적인 도움을 주었다.
특정 사람(특히 경력이 많은)의 의견이 99% 적용되던 이전과는 달리 우리는 해당 백로그에 대한 여러가지 관점을 통해 매우 의미있는 예상시간(추정치)를 만들 수 있었다.

회의를 지연시키는 다른 원인은 스크럼 마스터를 중심으로 스프린트 백로그를 하나씩 검토해 나가는 방식이었다
우리는 스프린트 백로그를 순차적으로 하나씩 검토하고 정리하는 방식이 회의에 참가하는 리소스(팀원들)를 크게 낭비하는 것임을 깨달았다. 이는 마치 나와 관계 없는 회의에 참가하는 것과 같았다.
우리는 고민 끝에 스토리 카드와 포스트잇을 사용하기로 하였다. 절차는 다음과 같다.
  1. 스프린트 계획 회의 전에 스크럼 마스터는 스토리 카드를 출력해 온다.
  2. 회의실 벽에 스토리 카드를 분산시켜서 붙여놓는다.
  3. 스크럼 마스터는 계획 회의 시작을 알리고 팀원들은 모두 일어난다.
  4. 팀원들은 각자 관련있는 스토리 카드에 앞에 서서 추정치를 의논하고 예상되는 테스크들을 포스트잇에 적어 붙인다.
  5. 모든 스토리 카드가 추정될 때 까지 계속 한다.

스토리 카드와 포스트잇의 내용은 아래와 같다.
  • 스토리 카드에는 스프린트 백로그 번호와 내용이 간략하게 적혀있다.
  • 스토리 카드에는 스프린트 백로그의 추정치 및 데모방법을 적을 수 있는 공간이 있다.
  • 포스트잇에는 테스크 내용, 추정치 및 테스트 방법들을 적을 수 있다.
  • 스토리 카드의 추정치는 일 단위로 하였으며 테스크의 추정치는 시간 단위로 하였다.

우리의 방법은 대성공이었다. 
2~3시간의 스프린트 계획 회의에서 끝내지 못한 내용들을 단, 30분 만에 끝낼 수 있었다.

아날로그로의 귀환

이제 우리의 스프린트 계획 회의의 결과물은 스토리 카드와 테스크들을 적은 포스트잇이다.
따라서 우리에게 디지털로 저장하는 것은 매우 귀찮은 일이 되었다. 
히스토리를 남기길 원하셨던 팀장님 마져 손을 드셨다. 
사실 히스토리를 남기는 게 좋다ㅠㅠ 단지, 우리는 귀찮아서 안할뿐이다.
그래서 우리는 기존에 사용하던 화이트보드보다 더 큰 사이즈를 주문하여 다음과 같이 사용하고 있다.

스프린트 백로그 화이트보드

자세히~

포스트잇을 사용하게 되니, 각 테스크를 3단계(준비, 진행중, 완료)로 구분하여 관리할 수 있었다.
데일리 미팅 시간이 좀 더 역동적으로 변하였으며, 팀 영역에 들어오는 어느 누구도 현재 팀에서 진행중인 작업 내용을 꽤 자세히 확인할 수 있게 되었다.
포스트잇을 하나씩 완료영역으로 옮겨 붙이면서 쾌감을 느끼기도 했지만, 진행이 잘안될 때에는 큰 스트레스로 작용하기도 하였다. 
日新又日新 : 우리는 스크럼이 우리가 서로 커뮤니케이션 하기 편한 형태로 점점 진화하고 있다는 것을 느낄 수 있었다.

다음 편은 내가 느낀 우리팀과 스크럼의 한계에 대해 작성해보고자 한다. 
피드백 좀 부탁드려요~~~~~^----------------------^
Posted by 윤청하
, |

어느날 아침에 한 영업실의 실장님과 간단한 대화를 나누었다. 그때 실장님은 귀에 거슬리는 말씀을 하셨다.
맨날 구조 바꾸고 갈아 엎는다고만 하지 말고 생각 좀 해서 개발해봐! 버그만 심지 말고..
이전에(애자일 마인드를 갖기 전) 이 말씀을 들었다면 매우 부정적으로 "니가 개발을 알아?" 라고 마음속으로 콧방귀를 꼈을 것이다. 하지만 오늘 나는 개발자로써 반성문을 써보고 무엇이 문제인지 밝혀보고자 한다.

영업부서와 개발부서와의 미팅에서 개발자들이 시간적으로나 기능적으로 불합리한 요구사항에 대처하는 핑계중에 하나는 아마 다음과 같을 것이다.
현재 우리 구조에는 적용하기 어렵습니다. 적용하더라도 시간이 걸릴것 같으며, 추후에는 전체적으로 뒤집어 엎어야 합니다.
실제로 내가 다니고 있는 회사의 모습만 봐도 구조 및 설계 개선 등의 이유로 전체 시스템 소스코드를 뒤집어 엎는 경우(전역 리팩토링)가 매우 많다. 우리팀도 작년부터 이전 플래폼을 개선한다는 이유로 2.0이라는 이름을 달고 1년이 넘게 팀의 리소스 중 많은 부분을 플래폼 구조 개선 작업에 투입하였다.

문제는 이러한 작업의 결과가 비지니스적인 가치로 창출되는 경우는 매우 드물다는 것이다. 오히려 새로운 소스코드에 대한 검증 및 안정화 작업으로 인한 업무 오버헤드가 더 증가할 수 있다. 물론 추후 생길수 있는 요구사항을 손쉽게 적용할 수 있을 수도 있다. 그러나 이것은 XP를 인용해보자면 쓸데없는 짓이다. "사용자 스토리"라는 책을 보면 스토리(요구사항)는 투자되는 리소스 대비 비지니스적인 가치가 높은 것의 우선순위를 높게 책정하도록 권장하고 있다. 지금 현재 다른 업무가 거의 없지 않은 이상 전체를 뒤집어 엎는 스토리의 우선순위는 높아질 수 없는것이 자명하다.

그렇다면, 무엇이 문제일까? 개발을 잘 못한 개발자들만의 잘못일까? 이와 같은 일이 벌어지는 이유를 내 경험을 통해 정리해 보겠다. (현재 재직중인 회사만의 현상일 수 있으나, 한국의 개발회사는 크게 차이 없을 것으로 생각된다.)
  1. 개발자마다 "개발완료"의 의미가 다르다.
    어떤 개발자는 코딩 및 컴파일 완료를 개발 완료라고 생각한다.
    어떤 개발자는 기능 테스트(화이트 박스 테스트) 완료를 개발 완료라고 생각한다.
    어떤 개발자는 리팩토링까지 완료해야 개발 완료라고 생각한다.
    불행히도 많은 경우에 두번째의 경우를 개발 완료라고 생각한다.
  2. 개발 기간이 너무 촉박하다.
    영업부서에서 전달하는 요구사항 대비 주어지는 개발 기간이 매우 적은 경우가 많다.
    이럴 경우 핵심적인 기능(비지니스적인 가치가 높은)을 선별적으로 개발해야 하나, 대부분의 협의는 모든 기능 구현으로 종결된다.
    즉, 개발자는 기능 구현에만 집착하게 되며, 리팩토링은 신경쓸 수 없게 된다.
  3. 과도한 업무로 보상 심리가 강해진다.
    개발양은 많고 개발 기간이 촉박해지면, 잦은 야근, 밤샘 작업 및 주말 작업은 일상생활이 된다.
    이로 인해, 프로젝트가 일단락 되어 여유 시간이 생기더라도 보상 심리로 인해 리팩토링 작업은 미뤄지게 된다.
  4. 리팩토링에 대한 교육이 없다.
    리팩토링 뿐만이 아니겠지만, 리팩토링을 강조하고 무엇을, 어떻게 해야하지는 알려주지 않는다.
  5. 깨진 자동차 유리 
    "실용주의 프로그래머"라는 책에 소개된 깨진 자동차 유리 실험처럼, 지속적인 리팩토링이 이루어지지 않은 코드의 중복성은 기하 급수적으로 증가하게 된다.

이유를 적다보니 개발자의 책임이 큰것을 알 수 있었다ㅠㅠ. 
물론 영업부서의 유연하지 못한 요구사항도 큰 문제이다.

나의 결론은 간단하다. 목표는 전체적으로 뒤집어 엎어야 하는 경우를 줄이는 것이다. 
다음과 같은 원칙을 가지고 개발한다면 어느정도 도움이 될 것이다.
  • 항상 중복을 제거한다. [리팩토링]
  • 코딩 전에 테스트를 작성한다. [TDD , 어렵다면 어떻게 테스트를 할지 미리 결정해야 한다.]
  • 설계와 구현은 동시에 진행한다. [XP, 점진적인 설계]
  • 코드 공유 및 리뷰를 수행한다. [XP, Pair Programming]

하지만, 시간이 촉박한 프로젝트의 경우에 해답을 찾기란 쉽지 않다.
결국은 영업 부서와 개발 부서가 한팀이 되어 긴밀한 협업을 하는 것이 중요한 관건이다.
협업이 원활이 이루어 진다면 영업 부서는 비지니스 적인 가치를 극대화 할수 있으며, 개발팀은 핵심 기능에 집중하여 더욱 신뢰성 높일 수 있을 것이다. 고객과의 협업까지 이루어 진다면 금상첨화가 아닐수 없다.
영업 부서와의 협업 방법으로 사용자 스토리스크럼을 추천한다.^^

사용자 스토리와 스크럼에 대한 내용은 다음 책을 참고하면 좋다.
사용자 스토리
고객 중심의 요구사항 기법
마이크 콘, 심우곤 역
인사이트
스크럼과 XP
애자일 최전선에서 일군 성공 무용담
헨릭 크닉버그
인사이트
Posted by 윤청하
, |