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

카테고리

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

최근에 올라온 글

최근에 달린 댓글

새로운 개발팀

이전 개발팀에서 이메일을 이용한 코드리뷰를 시행한 적이 있습니다. (2010/02/26 - [Programming] - 이메일로 코드 리뷰 하기)
혹시나 해서 요즘에도 잘 되고 있나 여쭤보았지만 아직은 형식적인 단계라는 답변을 들었습니다.
이직을 하고 나서 저는 변화된 환경에 적응하기 위해 애자일 프랙티스를 언급하거나 제안하지 않았습니다. 
단지, 이전 업무에 대한 소개를 할 때 개발 프로세스 개선 활동에 대해 짧게 소개만 했습니다. 
(다행히도 입사 4개월 만에 애자일에 관심을 보이시는 관리자 분이 계십니다!^^~~ 이번에 애자일 세미나를 같이 들으러 감~)

프로세스에 녹아든 코드리뷰

경력으로 입사하였기에 빠르게 프로젝트에 투입되었습니다. 현재 개발팀의 소스코드는 svn으로 관리됩니다. (git로 넘어가는 추세..)
그런데 특이했던 점이, 자신의 home directory에 check-out된 소스에서 직접 작업하지 않고 export된 다른 복사본(working source)에서 작업을 하는 것이었습니다. 즉, commit과 update 절차는 다음과 같이 진행되었습니다.
  • commit 절차 : 복사본에서 작업 => svn 소스와 diff를 통한 merge => svn commit
  • update 절차 : svn update => 복사본 소스와 diff를 통한 merge => 복사본에서 검증
즉, 개인 작업물에 대해서 철저하게 분리하는 형태 입니다. 어찌보면 번거로워 보일수 있는 소스관리 프로세스 였습니다.
그런데, 작업이 진행되면 될수록 소스코드가 잘 정리되었으며, 믿음직하고 든든해 졌습니다. 
그것은 merge 과정에서 자신의 코드와 타인의 코드에 대해서 source code inspection이 암시적으로 행해졌기 때문입니다.
복사본에서 작업하기 때문에 개인용 테스트 로그가 svn 소스 트리에 등록되지 않은 것도 한 몫 했습니다.

프로세스(혹은 도구) 개선이 정답?

김창준님이 한국 developerWorks의 dW Column에 기고하신 "소프트웨어 관리자의 개선 우선순위"라는 글을 보면 다음과 같은 재미있는 연구 결과를볼 수 있습니다.

쉽게 말해, 도구 부분에서 상당한 개선을 이뤄내면 비용적으로 세 배 정도 개선을 얻을 수 있다. 이에 비해 관리 부분에서 상당한 개선을 이뤄내면 비용적으로 64배 정도의 개선을 얻을 수 있다는 뜻이다.

관리자들이 선호하는 개선 노력은 어떤 순서일까? 정확히 역순이다. 일단 도구 개선부터 시작한다. 자기 자신(관리)을 바꾸는 것은 맨 나중이다. 그러나 실제 효과로 보면 우선순위는 관리가 맨 처음에 온다


제 경험을 보면 마치 프로세스(혹은 도구) 덕분에 큰 효과를 본것 처럼 보입니다. 하지만 근본적인 원인은 따로 있었습니다.

내 코드가 아닌 우리 팀의 코드

개발과정에서 개발팀의 관리자 분(개발에도 참여하심)과 개발 리더분은 지속적으로 소스코드를 리뷰하고 있었습니다.
라인단위로 의미없거나 논리적이지 못한 코드가 있다면 명확하게 해명을 해야 svn 소스 트리에 남을수 있었습니다.
로직이 불분명하다면 버그가 생길만한 케이스를 분석하거나 테스트 케이스를 만들어서 알려주십니다.
우리에게 누가 문제를 해결했고 누구의 소스에서 버그가 있었다는 것은 중요하지 않았습니다.
중요한건 우리 팀의 코드가 품질이 높아야 한다는 것이지요. (물론 납기일을 만족하면서...)
코드리뷰는 진짜로 해야 효과가 있는 것 같습니다.
Posted by 윤청하
, |
SurfaceView의 역할

Android Application에서 View의 내용은 GDI Thread를 통해 Surface에 그려지게 됩니다.
만약 View에 동영상 또는 카메라 프리뷰와 같이 그려지는 양이 매우 많거나 빠른 화면 변화를 원한다면 SurfaceView를 사용해야 합니다. SurfaceView의 내용은 GDI Thread를 통해서 Surface에 그려지지 않고 다른 Thread를 통해서 그려지기 때문입니다.
SurfaceView는 아래 그림과 같이 Window의 아래쪽에 위치하며, Window를 뚫어서(punched) 자신이 보여지게끔 합니다.
단, 해당 Window 위에 다른 View가 있는 경우 블렌딩(blended)이 되어 보여지게 됩니다.

동영상 재생과 SurfaceView

아래 그림은 동영상이 재생되는 SurfaceView를 묘사한 것입니다.

동영상 재생을 담당하는 PVPlayer (Packet Video Player)에서 SurfaceView에 연결된 Surface에 동영상을 그립니다.
그려진 Surface와 다른 내용(ex. GUI)을 담고 있는 View의 Surface들을 모두 합쳐서(composition) 하나의 화면으로 FrameBuffer에 쓰는 역활을 하는 것이 SurfaceFlinger service입니다. SurfaceFlinger service는 연산량이 많기 때문에 독립적인 process로 존재합니다. 동영상의 화면이 크고 그 위에 블랜딩 되어야 하는 GUI가 많은 경우 오버레이를 위한 하드웨어 가속기를 사용하기도 합니다.
Posted by 윤청하
, |
3월 11일 늦은 8시에 강남 토즈에서 xper 주체로 Rebecca Wirfs-Brock 방한 기념 번개 모임이 있었습니다.
급하게 마련된 번개 모임에도 불구하고 30여명에 가까운 분들이 참석해주신 멋진 자리였습니다.
김창준님이 질문 및 답변에 대한 통역을 해주셨는데, 시간 관계상 필요에 의한 나름 인터렉티브한 통역을 하였습니다.
나름 열심히 정리했는데, 정리한 종이가 어디갔는지 안보이네요;; 좌절OTL
그래서 인상 깊었던것 두가지만 가지고 개인적인 소감을 정리해보겠습니다.

패턴과 프랑켄슈타인

사실 이 말은 김창준님이 크리스토퍼 알렉산더를 소개할때 짧게 언급하신 내용입니다.
패턴의 창시자라 불리우는 크리스토퍼 알렉산더가 최근 패턴을 관통할 수 있는 새로운 내용을 정리했다고 합니다.
이유인 즉슨, 패턴의 한계 때문이었습니다. 즉, 패턴을 중심으로 설계를 하다보니 프랑켄슈타인을 만들게 되었다는 것이죠.
짧게 지나친 내용이지만 개인적으로 프랑켄슈타인이란 비유가 인상깊었습니다. 
저는 패턴에 대해 많이 학습하지 못했지만, 패턴에서 커뮤니케이션 도구(어떠한 행동, 구조 등에 대해서 적절한 이름을 붙여놓은 것) 이상의 그 무언가를 발견하지는 못했었습니다.
즉, 패턴은 도구일 뿐 목적이 될 수 없다는 것을 같이 공감한것 같아서 기분이 좋았습니다.

크리스토퍼 알렉산더

이번에 처음 들은 이름입니다. 패턴의 창시자이자 그것의 한계를 지적하신 분입니다. 
그리고 Nature of Order 라는 새로운 것을 또 만드셨습니다. 패턴을 관통하는 것이라고 하셨는데 아직 이해 불가합니다ㅠㅠ
모임 시간에 언급된 내용들에 대한 정리는 김창준님이 깔끔하게 해주셔서 패스합니다.ㅋㅋ (모임 후기 링크)
두가지 내용이 언급되었었습니다. alternative repetition 과 level of scale 이었습니다.
불행히도 전 정확한 정의를 모릅니다. (이제 슬슬 Nature of Order 책을 사 봐야겠다는 생각이 드네요.) 
따라서 개인적인 소감만 쓰겠습니다^^

Alternative Repetition

저는 alternative repetition을 "조금씩 다른 형태를 지속적으로 반복하는 것"이라고 이해했습니다.
즉, 아키텍쳐를 설계시 추상화 설계와 구현 설계를 지속적으로 반복해야 좋은 결과물을 얻을 수 있을 것 같습니다.
전문가일 수록 반복 주기가 짧고 반복의 깊음와 얕음이 지속적으로 변할 겁니다.
사실 이 부분이 설계에서 가장 어려운 부분이 아닐까 싶네요. 
어디까지 구체적으로 해야 하는지 어느 정도 수준으로 추상화가 되어야 하는지.. 정말 어려운 선택인것 같습니다.
또한 정답이 없기 때문에 검증하기는 더더욱 어려운 것 같습니다.
레베카가 한국에 온 이유가 L모 전자 설계 교육때문에 왔다고 하는데, 설계에 대한 구체적인 교육이었다고 합니다.
정말 부러웠습니다. 전문가를 옆에 두고 실습을 하면서 맞는지 틀리는지 물어볼 수 있으니까요..^^

스크럼의 스프린트나 업무를 위한 학습을 하는 것도 비슷한 맥락에서 생각해 볼수 있지 않을까요?^^ 
Nature of Order같은 책은 정독하는데 시간도 오래걸릴 뿐만 아니라 실무에서 바로 적용하기도 어렵습니다.
반대로 안드로이드 프로그래밍같은 책은 읽는데 시간도 별로 안걸리고 실무에서 바로 적용할 수 있습니다.
학습을 하는 태도가 한쪽으로 치우친다면 초보자라 할 수 있겠습니다. 
분야를 막론하고 지속적으로 반복해야 전문가가 될 수 있을겁니다. (전 아직 초보ㅋㅋ)

골고루 먹자

결론이 좀 쌩뚱 맞습니다. 이해해 주시길 바랍니다^^;;
xper 모임을 많이 나오지는 않았지만 항상 보고 듣고 있었습니다. 이젠 좀더 구체적인 부분에서 학습을 공유하고 싶어졌습니다.
그래서 이번 주 부터 시작하기로 했습니다. 목표는 안드로이드 정복!ㅋㅋ (오래 준비했습니다~)
당연히 xper 모임도 충실히 참석할 겁니다^^

전 친구랑 한잔하러 끝나고 바로가서 못찍었습니다;;

레베카 옆에 앉아서 졸면서 적고 있는 청하^^

사진 찍어주신 최승준님께 감사드립니다^^
Posted by 윤청하
, |
cooperation vs. collaboration

오늘 회사에서 신규 입사자에 대한 연구소장님 간담회가 있었습니다. 신규 입사자들을 모아놓고 1시간 30분 가량 강연을 하셨습니다.
강연중 cooperation과 collaboration의 구분을 명확히 하셨고 우리는 collaboration을 잘 해야 한다고 강조하셨습니다.
사실 cooperation과 collaboration은 사전적인 의미는 대충 비슷합니다.
피자 vs 파전

저는 cooperation과 collaboration을 피자와 파전에 비유해볼까 합니다.
cooperation은 피자와 비슷합니다. 큰 원형 조각을 미리 정확하게 조각내어 놓습니다. 크기를 동일하게 하려고 해보지만 크기가 제각각입니다. 그리고 보통 시키기 전에 먹을 인원 및 개인의 취향을 고려하여 미리 모두 주문합니다. 그리고 각자 할당된 조각 만큼을 먹습니다
collaboration은 파전과 비슷합니다. 일단 시켜봅니다. 그리고 각자 알아서 먹고 싶은 만큼 조각내서 먹습니다. 젓가락으로 잘 안떼어질때는 서로 도와주기도 합니다. 먹다가 맛있으면 더 시켜서 먹습니다.
팀에서 공동작업을 할때 어떻게 하십니까? 
일만 나눠놓고 서로 독립적으로 작업하십니까? 전체 작업을 시시각각 때에 맞춰 공동작업 하십니까?
cooperation을 하십니까? 아니면 collaboration을 하십니까?
전 경험이 짧지만 제가 경험했던 리더 분들은 대부분 cooperation을 주로 사용하셨습니다. 관리하기 편하기 때문이죠. 
그리고 동료분들도 독립적인 작업을 좋아하셨습니다. 일하기 편하기 때문이죠.
하지만 고객을 만족시키는 소프트웨어 개발을 위해서는 collaboration을 통한 짧은 주기의 피드백은 반드시 필요합니다.

짝 프로그래밍과 협업

XP에서 제안하는 베스트 프랙티스 중에 하나인 짝 프로그래밍은 cooperation과 collaboration의 밸런스를 맞춰주는것 같습니다.
십여명의 팀원이 모두 collaboration을 한다면 결정 시간 지연, 배가 산으로 가는 현상 등등의 부작용이 있을수 있습니다.
cooperation을 하되 그 단위를 짝(pair, 2명)으로 함으로써 collaboration이 가질 수 있는 장점을 높일 수 있습니다.
2명이서 진행하는 collaboration은 오버헤드가 적고 신속한 피드백으로 좋은 품질의 코드를 유지할 수 있습니다.
그래서 저는 짝 프로그래밍을 강추합니다.^^
Posted by 윤청하
, |
2006년 1월 31일, 대학원을 졸업하고 IT벤처기업에 입사하였습니다. 
그리고 2010년 3월 2일, 처음으로 이직했습니다. 

황상철님의 질문(나는 왜 이 회사를 다니고 있는가?)을 보고 문득...
"그럼 나는 왜 이 회사로 왔는가?"에 대한 제 자신의 답변이 궁금했습니다. 
그런데 막상 고민해 보니 어렵네요^^

제 목표는 수석 소프트웨어 엔지니어 입니다. 그리고 재밌게 일하고 싶습니다.
먼저 수석 소프트웨어 엔지니어가 되기 위해서는 다양한 경험을 해봐야 한다고 생각합니다.
그리고 재밌게 일하기 위해서는 아주 잘해야 합니다. 누구나 인정할 정도로...

전 다양한 경험을 하기 위해서 다른 원하는 분야로 변경하면서 이직했습니다. (직종은 동일합니다.)
감사하게도 조금 다른 분야의 경력이지만 인정해 주셔서 이동할 수 있었습니다.
그리고 좀 더 큰 프로젝트와 치열한 환경에서 인정받을 정도로 잘하고 싶어서 이직했습니다.

제가 연봉에 대한 욕심을 버린것은 1년여전이었습니다. 연봉을 버리니 다른 것들이 보이더군요.
그때부터 팀 개발 효율을 높이기 위해 그리고 제 자신을 개선시키기 위해 이것 저것 노력했던것 같습니다.

현재 이직한 회사에서도 욕심을 버리고 진정한 소프트웨어 엔지니어가 되기 위해 노력할 것입니다.
앞으로 지켜봐 주세요^^ 그리고 제가 이상한 길로 가면 강력한 지도 편달 부탁드립니다!

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

리액션 부탁드립니다.  (8) 2010.02.24
당신의 꿈은 무엇인가요?  (2) 2010.01.13
개발자와 다이어트  (6) 2009.12.26
Posted by 윤청하
, |
저희 회사에서 제품의 품질을 높이기 위해 지난 1년간 코드리뷰를 전사적으로 진행했습니다.
하지만 리포트 형식만 던져주고 어떠한 교육이나 코칭이 없는 상태에서 진행되다 보니 업무에 부담만 되었습니다.
소스코드 출력해서 수정된 부분 체크하고 이전 버전도 체크하고..등등..ㅠㅠ

몇달전에 박형근님 블로그(코드리뷰, 좀 쉬운 방법은 없을까?)에서 공짜로 책을 준다는 글을 읽고 바로 신청했습니다.
지금도 공짜로 보내주고 있네요^^

책을 읽어보니 이메일로 코드리뷰를 하는 방법이 소개되어 있었습니다. 그래서 가장 간단한 형태로 적용해보기로 했습니다
그 형태는 체크아웃된 소스코드를 작업하고 체크인할 때 수정내용을 입력하도록 하고 이전 버전과의 차이점을 이쁘게!!! 팀원 전체에게 이메일로 보내는 것이었습니다. 이렇게 하면
  1. 팀원들이 쉽게 볼수 있기 때문에 코드 정리에 더 신경쓰게 된다.
  2. 어떤 내용을 수정했는지 히스토리가 명확하게 남을 수 있다. (모두가 보고 있음..ㅋㅋ)
살짝 이 정도의 장점이 생기는것 같습니다.
물론 반발을 최소화 하기 위해 저 방법을 안써도 체크인 할 수 있도록 했습니다. 
하지만 요즘은 팀장님이 리뷰할 수 있게 체크인 해달라고 요구하십니다.ㅋㅋ 팀장님은 상시 리뷰어로써의 역활을 하고 계시죠..
굉장히 단순한 형태이긴 하지만 그 효과는 괜찮은것 같습니다.

저희 코드리뷰 이메일은 다음과 같이 vim에서 보는 것과 동일한 형태로 보내집니다.
  • vim에서 C syntax highlight에 diff highlight를 추가하였습니다.
  • vim에서 :runtime! syntax/2html.vim 을 실행하면 highlight 된 형태를 html 포멧으로 저장해줍니다.
Posted by 윤청하
, |
최근에 신입 개발자 분이 들어오셨습니다.
팀에서 데일리 미팅을 진행하고 스프린트 회고/계획 회의를 진행합니다.
모르는 내용이 나오면 옆에 사람 붙잡고 물어봅니다.
열정이 있어보이셔서 제가 슬쩍 책을 한권 건냈습니다. (패턴 그리고 객체지향적 코딩의 법칙)
신입에게는 살짝 어려울수 있는 내용이지만 쉽게 이야기 형식으로 풀어 쓴 내용이라 읽는데에는 문제가 없을거라 생각되었습니다.
일주일 내에 읽기로 약속했습니다. (브라보~) 
그리고 하루만에 리액션을 주셨습니다. (데일리 미팅에서 살짝 귓속말로..ㅋㅋ)
"책 너무 재미있게 읽고 있습니다. 제가 잘못하고 있었다는게 느껴지네요.."
이분과 같이 일하면 즐거울거라 예상됩니다.

비교하면 안되지만..ㅠㅠ 2년전에 들어오신 신입분은 제가 책을 건내면..
"전 잘 모르는데.."
그 뒤로도 리액션이 없었습니다.
스터디를 제안해도, Pair Programming을 제안해도 해본적 없고, 잘 모른다고 빼기만 하십니다.
리액션 부탁도 해보고 얘기도 많이 시도해봤지만, 솔직히 같이 일하기 어렵습니다.
술도 안드셔서 술한잔 하자고도 못합니다.ㅠㅠ

리액션이 없으면, 상대방이 뭘 원하는지, 어떤 생각을 하시는지 공유하기 너무 어렵습니다.
강호동 만큼은 아니더라도 살짝~ 리액션 부탁드릴게요~ㅠㅠ

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

처음으로 이직 했습니다.  (6) 2010.03.11
당신의 꿈은 무엇인가요?  (2) 2010.01.13
개발자와 다이어트  (6) 2009.12.26
Posted by 윤청하
, |
저는 스크럼, 테스트 주도 개발, 짝프로그래밍, XP의 원칙과 가치 등을 처음 접했을 때 큰 영감을 받았던 기억이 있습니다.
이런 것을 팀에 도입한다면 한단계 발전하는 팀이 될 수 있을 거라는 확신이 들었습니다.
고민했던 생각들을 실천하고 주변사람을 선동하는데 익숙한 저는 바로 실행에 옮겼습니다.
우리는 XXX 문제들이 있기 때문에 YYY를 도입해서 해결해야 합니다.
그리고 우리는 YYY를 도입했습니다.

새로운 것을 도입하는 것이 끝은 아니다.
스크럼은 정말 쉬워보였습니다. 그래서 우리는 스크럼을 가장 먼저 도입하기로 하였습니다.
약 1년간의 스크럼을 해보면서 느낀 것은 새로운 프로세스와 방법을 도입하는 것은 단순한 액션에 불과하다는 것이었습니다.
새로운 것이 정착하기 위해서 우리는 기존의 것을 포기해야 했습니다. 
적게는 수년에서 많게는 십수년의 경력동안 유지했던 자신만의 틀을 깨야 했습니다.

  • 매일매일 자신의 일정과 업무 진행 상황을 모든 팀원에게 솔직하게 공개해야 했습니다.
  • 팀장님은 외부와의 업무 상황 및 요구사항의 출처 및 발생 이유에 대해서 모두 공유해야 했습니다.
  • 특정 개발자만 처리할 수 있는 소스코드가 없어져야 했습니다.
  • 우리 팀의 상황을 타 팀(영업, 마케팅, QA 등)에게 여과 없이 공개해야 했습니다.
이 외에도 여러가지가 있습니다. 하나하나의 틀을 팀원 각자가 깨나가야 했습니다. 정말 어려웠습니다.

틀을 깬다는 것은 안해봤던 일을 시도해보고 새로운 틀을 만드는 것이다.
기존의 틀이 개발 생산성에 문제가 된다면 과감하게 깰수 있어야 합니다. 단, 단순한 현상이 아닌 핵심이 되는 원인을 깨야 합니다.
그리고 새로운 틀을 만들 수 있어야 합니다. 그 틀이 멋진 선배들이 만들어 놓은 것이라면 자신에게 맞게 고칠 줄도 알아야 합니다.
새로운 기술, 새로운 방법, 새로운 환경이 매일 차고 넘치기 때문에 소프트웨어 엔지니어라면 항상 틀을 깰수 있어야 합니다.
이미 아는 기술, 써봐던 방법, 경험했던 환경이 아니라고 해서 할 수 없다고 말씀하시는 분은 진정한 소프트웨어 엔지니어가 되기 힘들것입니다.
저는 그 틀을 깨는 경험들을 공유하고 싶습니다.^^ 같이 깨보실래요?ㅋㅋ
Posted by 윤청하
, |
2010/01/06 - [Programming Practice] - 낡은 코드(legacy code)를 어떻게 테스트 하시나요?
2009/10/31 - [Agile Experience] - 다시 시작하는 테스트주도개발(Test Driven Development)

얼마전까지 낡은 시스템을 어떻게 테스트 할지 고민하고 실행에 옮겼었습니다. 그 결과 팀내 시스템 테스트 케이스 작성을 위한 프레임워크가 생겨났고, 팀원들은 그것을 사용하여 시스템 테스트 케이스를 만들기 시작했습니다. 뿌듯!
저희는 그 다음 작업으로 통합 빌드 및 시스템 테스트 자동화를 구축하는 계획을 세웠습니다. 통합 빌드는 이미 사용중에 있었지만 좀 더 이쁘게 리포팅하도록 다듬기로 하였고, 그 결과를 바탕으로 시스템 테스트를 자동으로 돌릴 수 있도록 하였습니다.

통합 빌드 및 시스템 테스트 자동화 전체 구성

저희는 개발 서버, 테스트 서버, CI 서버(Continuous Integration)를 구성하였습니다. 
그리고 다음과 같은 순서로 간단하게 통합 빌드 및 테스트 자동화를 수행하도록 스크립트를 작성하였습니다.
  1. 시스템 테스트 서버의 시스템들을 모두 다운 시킨다.
  2. CI 서버에 있는 스크립트를 개발 서버로 보낸다.
  3. 개발서버에서 전체 통합 빌드를 수행하고 그 결과를 팀원들의 이메일로 이쁘게 리포팅 한다.
  4. 빌드완료된 바이너리를 시스템 테스트 서버로 인스톨 한다.
  5. 시스템 테스트 서버의 시스템들을 모두 동작 시킨다.
  6. 개발서버에서 시스템 테스트에 사용될 mocker를 빌드한다.
  7. mocker를 CI 서버로 다운로드 한다.
  8. mocker를 이용하여 시스템 테스트를 수행한다.
  9. 테스트 결과를 이메일로 리포팅 한다.

모든 스크립트는 파이썬으로 작성되었으며, 파일 전송은 ncftp, 이메일 전송은 ssmtp, mutt, 주기적 실행은 cron을 사용하였습니다.

다음은 저희가 만든 이메일 리포팅의 예제입니다.
MPP2.0 Daily Build Report (2010/02/03 09:43:44)
[NO] /....../MPP2.0/src/lib/ASMTEST compiling...
[OK] /....../MPP2.0/src/lib/SF compiling...
[OK] /....../MPP2.0/MPbase/src/lib/MpGen compiling...
[OK] /....../MPP2.0/MPbase/src/lib/MpSk compiling...
[OK] /....../MPP2.0/MPbase/src/lib/MPkt compiling...
[OK] /....../MPP2.0/MPbase/src/lib/Pfe compiling...
[OK] /....../MPP2.0/MPbase/src/lib/Hrm compiling...
[NO] /....../MPP2.0/MPbase/src/lib/pfem compiling...
[OK] /....../MPP2.0/MPbase/src/lib/MpUtil compiling...
[OK] /....../MPP2.0/MPbase/src/lib/MpObj compiling...
[OK] /....../MPP2.0/MPbase/src/lib/MpCfg compiling...

Hudson이나 CruiseControl을 사용하여 형상 관리 시스템 및 위키 등과 연동해보는 것이 다음 과제 입니다.^^
노하우가 있으시다면 같이 공유해주시면 감사하겠습니다.
Posted by 윤청하
, |

2010년을 맞이해서 대대적인 조직개편이 이루어 졌고, 저희 팀 자리가 변경되었습니다.
저는 가장 먼저 떠오른 걱정이 War Board를 어디로 옮길까 였습니다. 
불행히도 변경된 자리는 비좁기로 유명한 곳이었습니다.ㅠㅠ
하지만 저희는 꿋꿋히 War Board의 위치를 저희 마음데로 통로로 선정하고 벽에 못까지 박아서 달았습니다.
결과적으로 War Board와 데일리미팅 진행은 완전히 아주 깨끗하게 공개되었습니다. 
이 통로는 개발자분들 뿐만 아니라 영업, 마케팅 등등의 분들도 다니시는 곳입니다.
본의 아니게 스크럼의 핵심 가치를 실행할 수 있었습니다.^^ 아싸~
그리고 저희 팀에서 스크럼을 한지 1년정도 되가는데 자리 이동을 계기로 더욱 견고해지는 것을 느낄 수 있었습니다. (보는 눈이 많아지니..자연스럽게..ㅋㅋ)

매일 아침 10:30에 진행하는 데일리 미팅

통로에 위치하게된 War Board!

우리의 War Board!

번다운 차트 및 돌발성/미지정 업무 관리



Posted by 윤청하
, |