세상을 놀라게 하자!

저는 작년 말에 Boardman이라는 앱을 앱스토어에 올렸습니다. 이 앱은 화이트보드 사진을 찍어주는 앱입니다. 그냥 사진을 찍는 거면 카메라 앱이 있는데 왜 만드나 하실 겁니다. 바로 아래 그림과 같은 효과를 내주는 앱이지요. 이 앱을 만들게 된 동기는 이렇습니다. 보통 그림을 그려서 설명하고 설계하는 software engineer는 화이트보드를 끼고 살지요, 저 역시 그랬습니다. 그런데 문제는 이것이 기록으로 남아서 정리가 되질 않기 때문이었습니다. 당시 제가 일하던 직장에 전자칠판이 몇개 있긴 했지만 이것이 늘 제가 쓸 수는 없는 상황이었거든요. 그러다가 camera calibration으로 유명한 Zhengyu Zhang의 논문을 발견했습니다. 한번 짜보자 싶어서 가볍게 python script..

우리는 늘 고객이 우리의 개발에 참여해야 한다라고 말합니다. 그러나 실제 우리는 어떻게 그들을 참여 시키고 있습니까? 단순히 매주 한번씩 고객과 만나는 것인가요? 아니면 제품 출시 직전에 테스트를 통해 고객과 만나나요? 최근 The lean startup으로 유명한 Eric Rise는 Nordstrom이란 Team이 벌인 Flash build라는 개발 방식에 대해 글을 올렸습니다. 이들의 실험은 지금 무언가 마땅한 제품을 기획을 해내지 못하고 있는 회사나 조직이 반드시 해보기를 권하는 일입니다. 먼저 이들의 프로젝트는 ‘1주일간 선글라스 가게에서 사용할 앱 만들기'입니다. 이게 어떻게 가능할까요? 한번 생각해보세요, 여러분이라면 어떻게 할지. 이들의 방법은 이랬습니다. '우리 모두 선글라스 가게로 가자’..

Joseph Yoder 소개 우리나라에서는 정말 만나기 힘든 ‘Architect’이신 Joseph Yoder가 한국에 다른 일정으로 오셨습니다. 이분의 주무기는 Refactoring과 Adaptive Object Model, Design Pattern입니다. http://www.joeyoder.com/ 에 자세한 이야기가 나와 있습니다만 다양한 형태의 PLoP Conference를 주관하시고 있고 소프트웨어 아키텍쳐, 설계, 구현과 같은 다양한 소프트웨어 개발에 대한 훈련, 멘토링과 컨설팅을 하고 계십니다. The Big ball of mud 특별히 이번에 진행된 Conference에서는 TDD와 Refactoring에 대한 이야기를 했습니다. 왜 소프트웨어는 가면 갈수록 점점 엉터리 코드로 엉망이 되어..

서로 다른 욕구 대부분의 경우 개발자들은 사람과 상호 작용을 다루는 일에 서투릅니다. 경영진은 사람과 친숙치 않은 사람과 일을 함께 하는데 서툽니다. 개발자들은 경영진이 쉽게 일을 생각한다 느끼고 경영진은 개발자들이 일을 성실하게 하지 않는다고 느낍니다. 그런데 정말 그것이 사실일까요? 왜 경영진은 개발팀이 보기에 촉박한 일정을 제시할까요? 경영진의 ‘욕구’를 생각해봅시다. 일반적인 경영에서는 제품의 출시로 매출이 나오면 성공이라 생각하지요. 그래서 빠르게 개발이 되어서 시장의 반응을 알고 싶어합니다. 또는 개발 기간 = 임금 비용이기 때문입니다. 즉 경영진에게 가치가 있는 일이란 가능한 적은 비용은 적게 들이고 빨리 시장에 물건을 내놓아 매출을 만드는 것입니다. 그리고 의외로 많은 시간을 고민고민해서 ..

5월 XPer정모를 다녀왔습니다. XPer는 XP 프로그래밍 방법론에 관심을 가지고 있는 사람들의 모임이고 처음 XP를 국내에 소개하신 김창준님이 주관하시는 모임입니다. 어느 모임에서 했던 회고의 내용. 이번 정모에 Gerald Weinberg가 하고 있다는 PSL( Problem Solving Leadership )에 창준님이 다녀오시고 이에 대한 소개를 했습니다. 그리고 실제 이를 해보았지요. 저희가 해 본것은 회사를 하나 설립하는 것을 모의실험 한 것이었습니다. 이에 대해서는 이 글을 좀 참조하심 도움이 되실 지 모르겠습니다. (과거 PSL에서도 이런 식으로 진행 되었나 봅니다.) 끝나고 딱 보는데 우선 소설 '파리대왕' 이 생각났습니다. 아무리 멀쩡한 사람이라도 극한 환경속에 둘 때 그 사람의 진..

서론 최근 연구결과에 의하면 실제 진행되는 정보기술 프로젝트들의 32%만이 성공( 2009 Standish group CHAOS 2009 report ) 한다고 합니다. 그럼 어떻게 32%는 이룩할 수 있었을까요? 어떤 공통된 완벽한 답은 없습니다. 각자의 길을 잘 수행한것일뿐입니다. 실제 일반적인 관리자 육성 교육 몇번 받았다고 해서 그런 사람들이 진행하는 프로젝트가 성공하지도 않습니다. 그 자리에 서 있는 사람에 따라 달라진다는 거지요. 그럼 뭐가 달라서 어떤 관리자들은 성공하고 어떤 이들은 실패할까요?이를 위해 두가지를 생각해야 합니다. 첫번째는 기술관리자가 생각하는 성공의 정의이고 두번째는 구성원들의 성향입니다. 첫번째, 기술관리자의 성공의 가장 큰성공은 무엇일까요? 자신이 관리하는 프로젝트가 성..

회사에서 회고를 매주 하고 있는데 인수인계를 받았거나 다른 사람의 작업을 받아서 일하는데 어려움이 있단 말이 나왔습니다. 그래서 이를 해결할 방법으로 문서와 comment이야기가 나왔습니다. 문서야 그렇다지만 도데체 주석을 어떻게 써야되는지 사람들이 잘 모르더군요. 그래서 빼든 책이 바로 Code Complete죠. (한국어판) 제발 개발 일 하시겠다는 분들은 읽어주세요... 제발. 주석을 어떻게 달아야 되냐, 한마디로 코드의 의도와 목적이 뭔지 적으라는 것입니다. 아래 코드가 무엇을 의미하는지 어떻게 된 것인지 적어야 나중에 본인 스스로도 헤메지 않을 것입니다. 마지막으로 Code complete에서 소개한 Book paradigm이란 방법론을 소개했습니다. 한마디로 요약하면 '코드를 일종의 특별한 책..

요즘 김창준님의 Agile Coach Squared란 교육을 받고 있습니다. 한마디로 Agile방법론을 코칭하는 사람들을 양성하는 교육입니다. 우선 Agile 방법론, XP방법론을 가르치는 것은 아니고, 그런 방법론들을 도입하는데 도움이 되는 것들을 배우는 것이라고 하는게 정확할 것입니다. 실제 많은 방법론들을 배우기도 하고 실제 코칭을 하면서 부족한 점들을 많이 배웁니다. 소개는 이만큼 하고요 본론으로 가지요. 이 내용도 사실 이번 강의를 통해 배운것입니다. 죽은 이유 미리찾기( Premortem )은 Gary Klein이란 사람의 Harvard Business review 기고글의 내용입니다. 원래 검시(Postmortem)는 죽은 다음에, 즉 프로젝트가 실패한 다음에 하는 것입니다. 하지만 '죽은 ..

최근에 신입 사원부터 코드리뷰를 해보고 있습니다. 역시 하면서 많은 것을 서로 알게 됩니다. 저는 솔직히 이번 리뷰에 참여하고 준비해준 모든 분들에게 고마울 뿐입니다. 사실 무언가 '까발'려지는 현장임에도 정말 성심성의껏 허심탄회하게 받아주고 더 나은 소프트웨어를 만들어 내 주는 우리 동료들, 정말 감사합니다. 벽위의 파리가 되는 경험... 정말 쉽지 않죠. 하지만 좋은 약이 입에 쓴 법이라고 공자께서 말하셨지요. ㅋㅋ 화이링~!! 현재 저희는 코드를 스크린에 쏘면서 같이 보고 , 구조는 칠판에 그리거나 설명을 하는 방식을 택하고 있습니다. 따로 슬라이드를 준비하는 방식은 시간이 많이 걸려서 안쓰고 있습니다. 가장 큰 소득은 '지식의 공유'입니다. 언어적인 것 뿐 아니라 설계의 오류도 잡고 요구사항을 정..

요즘 이슈 트랙킹 툴들을 통해 계속해서 팀내 업무 진척 상황을 보면서 재미있는 것을 알게 되었습니다. 그것은 어떠한 이슈 트랙킹 툴이라도 실제 개발팀의 일들을 100%다 반영하지 못한 다는 것입니다. 초반에는 해야하는 일 모든 일이 안올라가 있는 사람들을 계속 '쪼기'하면서 괴롭혀댔었습니다. 그러나 사람들이 계속해서 할일을 올리기를 회피하는 통에 이게 원인이 뭔가 조사를 해봤습니다. 결론은 이슈 트랙킹에 올라가면 이것은 나에게 결함이 있어 생기는 것이다 라고 생각하는 것이었습니다. 이렇게 된 이유는 과거 총 매니저가 작년 인사고과 평가 자료로 이슈 트랙킹 툴에 있는 자료를 가지고 문제시 한데서 생긴 생각들이었습니다. 사람들은 자신의 할일이라고 생각되는 것들과 문제가 있어 올라오는 것들을 구분하고 싶어한다..