2015년 12월 31일 목요일

2015년을 회고하며



포스트 모템과 회고는 뭐가 다르냐?


회고는 아래와 같은것이 다릅니다.
  • 실행가능한 개선안이 있어야한다. 
  • 실행되었는지 수치적으로 측정할수 있어야한다.


오늘 2015 회고를 해보았습니다.



작년과 마찬가지로 1월1일 아침 7시 회사에 출근했습니다.

아침에 졸려서 차한잔하려고 스타벅스를 갔습니다.

꽁짜로  하나 주네요. 선착순 10명이라더군요. ㅎㅎ~

덕분에  1월 1일 아침에는 스타벅스 이벤트로 커피를 증정한다는 사실도 알게 되었습니다.




남들이 자고 일하지 않을때 회사에 나와서 1년의 목표를 적어보는것이 이제는 즐거운 일인것 같습니다.


작년에 대한 회고를 보면 목표 대비 약 66% 완료했습니다.
작년에는 주로 작업한게 생상성 향상에 대한 것들이었습니다.

생산성 향상은 장기적인 투자의 결과 이기 때문에 Project에주어진시간에 생상성까지 올리는것은 어렵습니다.

시간이 부족하다보니 일요일 마다 아침에 나와서 20%의 추가 시간을 만들었습니다.

매일 야근하면서 주말까지 나온다는게 쉬운건 아닙니다.

열심히 하는자는 즐기는 자를 이길수 없다고 했습니다.  즐거우면 가능합니다.

구글처럼 20% 추가 시간주기 힘드니까 남들 잘때 하면 됩니다.


Scrum

애자일의 Scrum 미팅 을 계속 하다보니 팀의 퀄리티가 정말 좋아졌습니다.
개인적으로 Scrum자동화툴을 쓰는것은 별로 추천하지 않습니다.
그냥 포스트잇이 더 좋더군요.
사람은 글자체의 차이점등을 각인하기 때문에 나중에 보았을때 훨씬더 기억이 잘됩니다.

게다가 포스트잇에는 그림도 그릴수 있습니다.!!

프로젝트 초반에 작전회의 1주일정도 하고나면 그 다음부터는 프로젝트가 알아서 굴러갑니다.
별로 터치하지 않아도 팀원들이 스스로 하게됩니다.
중요한것은 Plan이 아니고 Planning(계획하기)이더군요.
팀원들의 머리속에 Why?를 심어주면 알아서 굴러갑니다.
절대로 What만 시키면 안됩니다.
바로 Why?를 심어주는 방법이 Scrum입니다.
우리팀의 퀄리티는 업계에서도 높은수준이라 생각합니다.

Scrum 의 Scrum

잠깐 Scrum의 Scrum(전사적 Scrum)을 해본적도 있습니다.
하다가 너무 힘들어서 중단했습니다.
이게 올해에 아쉬운 점입니다.
전사적인 린(Lean)을 적용하려면 Scrum의 Scrum이 필수라고 보는데요.
막상 하니 너무 많은 문제들을 feedback받아서 업무가 마비될 지경입니다.

너무 팀장수가 많아서 그런것 같기도하구요.
Scrum의 Scrum에는 작전회의라는것이 없어서 그런것 같기도합니다.

올해는 일단 팀장수를 줄여서 다시 시도해 볼까합니다.











2015년 12월 16일 수요일

2015년 4분기 읽은 책들

open stack 을 다루는 기술

오픈스택을 다루는 기술
다른회사 CTO이신 뉴타임 건담님의 블로그에서 이런책이 있다는것을 알고 한번 읽어보았다.
처음부분은 자세한 설명이 있어서 개념잡기에 좋았지만
아쉬운점은 너무 설치에 대해서만 나와있어서, 뒤로가면서 좀 지루했다.
어짜피 오픈 스택이 Infra이기때문에 그런것 같기도 하다
아마존웹서비스를 대신쓸수 있는것 같습니다.

the art of unix programming

The Art of Unix Programming
와우. 감동적인 전설적인 unix 개발자들의 현명한 노하우를 들을수 있어서 좋았다.
어떤면에서보면 저자들의 내공은 실용주의 프로그래머 (책) 보다 한수 위로 보인다.
객체 지향 설계보다도 Data Driven 개발 방식이 왜? 뛰어난지 알수 있었다.
실용주의 프로그래머 에서는 Do not repeat your self 였다면
이 책에서는  SPOT (Single Point Of True) 를 강조한다.
현대적으로 치면 Specification 에 의한 개발이나 행위 개발 정도에 해당하는것 같다.

visualize this

Visualize This 비주얼라이즈 디스
각종 시각화 도구 R( 언어) 등에 대해서 알게 되었다.
Python에서는 beautiful soup로 처리하는것 같다.
하여간 데이터 시각 화에 대해서 끝내주는 책이다.
근데 구글 스프레드 시트에 깔끔하게 visualize를 사용할수 있게 친절하게 되어있는것 같다. (대단한 구글임)




가장 빨리만나는 docker

가장 빨리 만나는 도커 Docker
국내 저자의 책인데 상당히 퀄리티가 좋다.
내용도 좋고 예제들도 잘 되어있다.

가장 빨리만나는 go 

가장 빨리 만나는 Go 언어
이것도 위와 동일한 저자의 책인데 정말로 퀄리티가 좋다.
언어 책중에서 아주 깔끔한 편에 속한다.
예제들도 너무너무 좋고, Go라는 언어를 배우기에는 최고의 책으로 보인다.
인터넷 보고 Go를 전혀 이해하지 못하고 있었는데, 이책을 보니 쏙쏙 이해가된다.
Go 언어는 정말 야리꾸리한 언어같다.
Go라는 게 초스피드 경량형 C 언어 같은 건데 프로그래밍 하기는 정말 불편한,
최고의 성능을 지향하는 언어이다.
코드 읽기가 정말 짜증이 나더라.

데드라인 

데드라인
관리자 뿐 아니라 프로젝트를 리딩하려면 필수적으로 읽어야 할 책으로 보입니다.
바로 구현을 하기보다는 인터페이스의 명세를 정제하는데 시간을 투자하는것이
남는 것이다... 라는 것이 가장 마음에 와닷습니다.
시간이 없다고 바로 대충 구현하기보다는, 조금이라도 명세에 투자하는것이 중요합니다.
우리나라는 명세를 써서 인도 등에 외주주는것에 약합니다.
개발자들이 글쓰기를 잘 못하기 때문이기도 한데요.
앞으로는 명세에 좀더 힘을 기울여야 겠습니다.



마케팅 전쟁

마케팅 전쟁
마케팅 책중에 최고의 서적이라 뽑힐만 하다.
포지셔닝이 사람의 두뇌에 어떻게 진입할지에 대해서 논했다면
마케팅 전쟁은 어떤게 다른회사와 싸울지에 대해서 논의하고있다.
책의 결론은
마케팅이란 전략과 타이밍이 모든것을 좌우한다.
뭐 남들보다 조금더 잘하기보다는 남들보다 최초가 되라는거다. 그것도 적절한 타이밍에.
예를들면 매운 가그린이 나왔다면, 달콤한 가그린을 만든회사는 자신만의 포지션을 가져갈수 있다... 이런 내용이다.

GPU Pro

GPU Pro

역자가 자동번역기로 돌린듯 번역되어서 상당히 읽기가 버겁습니다.
인터넷에서 목차를 뒤져봐야 하는 수고를 해야했습니다.
영어를 옆에 친절하게 써두면 더 좋을텐데, 어떤뜻인지 찾으려고 책 전체를 뒤지는게 한두번이 아니여서 보면서 GPU Pro 원서를 살까 고민되네요.
그래도 내용은 좋은편에 속하구요.
Graphic쪽보다는 요즘 대세인 GPGPU쪽만 읽어보았습니다.
Clipmap 쪽이 재미있네요.. 요즘 나오는 구글 맵 지도같은게 번개같이 빠른이유가
이런 알고리즘을 쓰기 때문이겠지요?

오픈소스 소프트웨어 성능 최적화 보고서

오픈소스 소프트웨어 성능 최적화 보고서
내용은 참 좋더군요. 읽기도 편했습니다.
특히 구글-크롬 등을 개발하면서 어떤식으로 최적화 했는지를 보았는데
역시 구글이더군요...
각종 오픈소스들을 보면서, 정말 잘만든다는생각이들고
나도 진작에 오픈소스를 해볼껄 하는 생각이 들었습니다.
하지만 역시 번역에 부담이 있어서 읽기 불편한 부분이 있기는 합니다.
그냥 업계에서 많이 쓰는 언어를 적용해주면 더 좋겠습니다. 
아마도 역자가 업계종사자가 아니고, 전문 번역가라서 이런 문제가 있는것 같습니다.
좀 개선 되었으면 합니다. 

올해읽은 책

올해는 달랑 45권 밖에 못읽었네요.
100권 채우는게 목표입니다.
기술 서적을 포함하면 한달에 4권읽는게 한계이더군요.
무지하게 빠르게 핵심만 읽어야 100권이 가능할것 같습니다.