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

카테고리

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

최근에 올라온 글

최근에 달린 댓글

오늘 가산에 있는 LG전자 MC연구소에서 Agile Gathering이라는 제목으로 세미나가 있었습니다. 
여차저차 허락을 받고 점심도 안먹고 가산으로 넘어갔습니다. 

리더쉽은 자신이 선택하는 것

첫번째 시간은 애자일 컨설팅의 김창준 대표님이 애자일 적용(혹은 반대)를 위한 조직에서의 리더쉽에 대한 내용으로 워크샾을 진행하셨습니다. 워크샾은 시뮬레이션 형태로 진행되었습니다. 참석자들중 몇분은 관찰자의 역할을 맡고 나머지는 한 회사의 구성원(사장,이사,팀장,사원)이 되어 시장(market)의 요구사항에 맞는 시제품을 개발하는 것이었습니다. 처음에는 어색했지만 나중에는 완전히 몰입해서 정말 제품을 만들어야 한다는 중압감이 생겼습니다+_+! 
약 1시간 넘게 시뮬레이션을 진행한뒤에 피쉬보울 방법으로 회고를 진행하였습니다. 그중에서 가장 인상에 남았던 것은 김대표님이 말씀해주신 매니저와 리더의 다른점, 리더쉽의 본질, 리더쉽의 4가지 유형이었습니다.
매니저는 조직에서 정할 수 있지만 리더는 정해줄 수 없다. 리더는 지휘 여하를 막론(경영진에서 신입사원에 이르기까지)하고 누구나 될 수 있다. 단지 우리는 리더가 되는 것(혹은 리더쉽을 발휘하는 것)을 선택하는 것이다. 단지 안할뿐..
리더쉽은 모든 사람이 창의적으로 문제해결에 기여할 수 있게 환경을 개선하는 것이다. 이에는 4개지 유형이 있다.
motivation leadership, organization leadership, innovation-idea leadership, jig leadership...
애자일에 관심있다고 하는 사람들이 모여서 회사 제품 개발 시뮬레이션을 해도 잘 안되기는 마찬가지였습니다.
중요한건 자신이 현재 상황에서 리더쉽을 발휘할 것인지 아닌지를 선택하는 것입니다.
(다들 가만히 있는데 먼저 나서서 행동을 취하는 것도 리더쉽 입니다. (jig leadership))

짝프로그래밍, 잘하면 고효율~ 못하면 가문의 역적

두번째 시간은 LG CNS의 채수원 과장님이 짝프로그래밍에 대해서 발표해주셨습니다. driver-navigator 라는 패턴을 이용하여 짝프로그래밍 도입하는 것에 대해서 말씀해 주셨습니다. 물론 짝프로그래밍의 장단점, 사례도 말씀해 주셨습니다.
개인적으로 짝프로그래밍을 좋아하지만 사용가능한 분야 혹은 짝이 한정되어있다고 생각합니다. 
정말 필요한 경우에, 고효율이 예상되는 경우에만 사용하는 것이 바람직하다고 생각합니다.

스크럼 vs 칸반

세번째 시간은 LG전자의 MC연구소에 계시는 분이(이름이 기억..안..나..요;;..ㅠㅠ) 스크럼과 칸반에 대해서 아주 이해하기 쉽게 설명해 주셨습니다. 칸반은 아주 심플하게 다음의 3가지를 만족하면 됩니다.
  • Visual Card : 비쥬얼은 필수!
  • Limit Work-In-Progress : 한 스텝에서 동시에 진행될 수 있는 백로그를 제한
  • Measure Lead-time : 지속적으로 리드타임을 측정하여 최소가 될수 있도록 함
특히 칸반은 수시로 인터럽트(QA, 유지보수등)가 발생하는 개발팀에서 유용하게 사용되어 어질수 있다고 생각했습니다. 
즉, 스크럼과 칸반을 개발팀의 업무 특성에 따라 적절히 조합해서 사용한다면 좋을 것 같습니다.

회고

회고에 참석하지 못했습니다.ㅠㅠ 반성중.. 
김창준님이 진행하신 시뮬레이션에 대해서 좀더 자세한 설명이 있었으면 했습니다. (왜 손을 잡는지, 감옥의 역할은 무엇인지 등..)
색다른 경험이었고 즐거웠습니다. 근데 뭘 했다고 이렇게 졸립죠...ㅠㅠ;;
Posted by 윤청하
, |
새로운 개발팀

이전 개발팀에서 이메일을 이용한 코드리뷰를 시행한 적이 있습니다. (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 윤청하
, |