Ferrari !!!!!
이름만 들어도 남성들의 가슴을 설레게 하는 그 이름 입니다.
설레다 못해 가슴이 미어지죠. ^^;
(가끔 운전하며 지나가다 강남에 가면 '부릉부릉~' 해대는 전 이 Ferrari를 볼때 혹시 스치고라도 지나갈까 바짝 긴장합니다. 아주.. 찌질하죠 - -;)
이번 XP2007 에 Ferrari 에서도 가장 최고의 기술력을 발휘하는 F1 팀에서 Opening Keynote 를 담당했습니다.
F1 경주에서 잘 모르시는 분들을 위해 그림을 첨부합니다.
이렇게 생겨먹은 차들이 300km/h 를 넘는 속도로 미친듯이 트랙을 질주합니다.
F1 팀은 이 차를 제어하는 소프트웨어를 만듭니다.
이 분들이 왜 XP2007 에 참가했는지 의아했습니다.
서두를 떼는 수석 엔지니어의 말이
"우리는 XP를 하지 않는다. 사실 난 XP가 뭔지 알지도 못한다"
라고 말했기 때문입니다.
그러나 세션이 시작되고 곧 알 수 있었습니다.
그들이 Crystal Clear 한 프로젝트를 수행하기 위해 그들만의 방법을 구축했는데, 그 방법이 매우 XP 와 유사합니다.
일단 그들이 설명한 프로젝트 상황에 대해 잠깐 얘기해보겠습니다.
1. 우리 프로젝트의 전체 개발자는 20명이다 (--;)
2. 우리는 100개 이상의 여러종류의 언어로 만들어진 레거시 시스템이 있다.
3. 이들 레거시 시스템은 각기 다른 프레임웍을 사용한다.
4. 매주 레이싱이 있으며, 레이싱은 각기 다른 국가들에서 열리기 때문에 이때마다 우리는 환경에 따라 변경하는 다른 프로그램 및 부품을 만들어야 한다.
5. 우리는 전 세계 수십개의 지사가 있다(분산되어 있는 조직이라는 것을 말하기 위함입니다.)
이들은 그들의 목표가 명확하기 때문에 다른 회사들보다 훨씬 일하기 편하다 라고 했습니다.
우리 회사도 목표가 있지요. '2010년까지 매출 4조' 우리같은 경우에는 2010년에 매출 4조를 달성하면 목표를 상향조정하거나 또다른 목표를 만들어야 하지만 F1 팀은 항상 변하지 않는 같은 목표를 위해 일합니다. 그것은
'F1 레이스 참피온 쉽 우승' 입니다
이 팀은 궁극적으로 자동차를 생산하는 팀입니다.
하지만 우리가 몸담고 있는 IT 와 굉장히 비슷하더군요. 그들이 말한 IT 측면입니다.
1. 예상하지 못한 flow
2. tight deadline
3. work related events
4. 24/7 availability
이들이 자동차를 개발하는 방식 입니다.
1. 개념적인 디자인을 합니다(Conceptual Design)
2. 실제 논리적 물리적 디자인을 합니다(Design)
3. 실제 자동차를 만듭니다.
4. 테스트 합니다.
5. 레이스를 합니다.
6. 우리가 만든 자동차는 역사가 됩니다. (이 말 참.. 맘에 듭니다. 스스로의 작업에 충분히 자부심을 가질 수 있을 것 같습니다. 많이 우승하면 할 수록 '호랑이는 가죽을 남기고 사람은 이름을 남긴다'는 말을 피부로 느낄 수 있게 되겠죠
수백번의 실패를 거쳐 그들은 F1 car 를 위한 프로세스를 만들었고 이를 위해 그들이 사용하는 방법입니다.
1. Iteration #1 basics
- 과거에 프로젝트를 실패하게 만든 원인을 규명하기 위해 20명의 팀원이 참여하는 투표를 실시하고 서로의 의견을 교환하는 프로세스를 만들었다.
- 또한 고객과의 커뮤니케이션을 단일화 하는 것이 매우 필요했는데, 고객이 시도때도 없이 interrupt 를 걸어 제대로 일할 시간이 매우 부족했기 때문이다. 이를 위해 우리는 driver 라는 역할을 만들었다. 문제가 발생하면 이 driver 가 대표로 문제를 확인하고 fix 할 책임을 진다. 이 driver 는 특정 프로젝트의 특정 일을 맡지 않으며, driver 고유의 역할을 수행한다. 다른말로 우린 warrior(해결사 정도라고 하면 될 것 같습니다) 라고 한다. 이 방법을 도입할 때는 20명중 2명의 driver 를 두고 시작했지만 이젠 1명의 driver 도 충분하다는 것을 알게됐다. 현재 1명의 driver 가 프로젝트 내에 존재하며 일정 기간이 되면 이 role 을 프로젝트 내 적절한 사람에게 넘긴다.
- 우리는 wiki 를 사용한다. 그리고 wiki 에 driver의 전체 역할 및 하루하루 벌어지는 일을 정리하고 정보를 공유한다. 이 wiki 가 프로젝트의 열쇠 역할을 한다.
- 우리는 CI(Continuous Integration)을 사용한다. 우리 시스템은 한번 클릭하면 100개 이상의 레거시 시스템과 새로 만든 시스템이 같이 통합된다. 이의 효율성을 위해 한가지 조사를 해봤는데. 빌드를 너무 자주 수행하면, 문제가 생길때마다 수정하는 시간이 늘어나고 요구사항이 밀려들며, 빌드 주기를 너무 길게 가져가면 요구사항은 적게 나와도 통합할 때 엄청난 고통이 발생했다. 결론적으로 3~4일 정도의 빌드주기를 가져간다. 주로 nightly build 를 사용한다.
- 우리는 manufacturing 단계에서 official 한 버젼이 나오면 3개 이상의 약간씩 변경을 가한 beta 버젼을 가지고 테스트 한다. 그리고 이중 한 개를 선택한다
- 두명씩 한 pair 가 되어 작업하다가 우리는 보다 나은 커뮤니케이션을 위해 한프로젝트를 수행하는 한 pair 와 또다른 프로젝트를 수행하는 pair 를 같이 일하게 만들었다. 다시말하면 4명이 2개의 프로젝트를 수행하는 셈이다. 두 가지 planing game 을 실시하고 half for one half on other PJT 방식으로 역할을 변경하며 작업한다.
- 우리는 스토리 카드를 사용한다. 또한 스토리 보드를 사용하는데 now, next, warehouse 로 카테고라이징을 하여 프로젝트 전체를 모니터링한다.
세션의 내용이 정말 흥미 진진했습니다.
일단 먼저 든 생각은 CI, wiki, pair programming, story card, planing game 이들 개념 모두가 Agile method 와 매우 유사하다는 것이고 그들이 현재까지 가장 안정된 개발 방법이라고 믿고 있다는 것입니다.
개인적으로 이 머리긴 수석 엔지니어가 얼마나 받을지 굉장히 궁금했습니다. 정말 물어보고 싶었는데... ^^;
이름만 들어도 남성들의 가슴을 설레게 하는 그 이름 입니다.
설레다 못해 가슴이 미어지죠. ^^;
(가끔 운전하며 지나가다 강남에 가면 '부릉부릉~' 해대는 전 이 Ferrari를 볼때 혹시 스치고라도 지나갈까 바짝 긴장합니다. 아주.. 찌질하죠 - -;)
F1 경주에서 잘 모르시는 분들을 위해 그림을 첨부합니다.
이렇게 생겨먹은 차들이 300km/h 를 넘는 속도로 미친듯이 트랙을 질주합니다.
F1 팀은 이 차를 제어하는 소프트웨어를 만듭니다.
이 분들이 왜 XP2007 에 참가했는지 의아했습니다.
서두를 떼는 수석 엔지니어의 말이
"우리는 XP를 하지 않는다. 사실 난 XP가 뭔지 알지도 못한다"
라고 말했기 때문입니다.
그들이 Crystal Clear 한 프로젝트를 수행하기 위해 그들만의 방법을 구축했는데, 그 방법이 매우 XP 와 유사합니다.
일단 그들이 설명한 프로젝트 상황에 대해 잠깐 얘기해보겠습니다.
1. 우리 프로젝트의 전체 개발자는 20명이다 (--;)
2. 우리는 100개 이상의 여러종류의 언어로 만들어진 레거시 시스템이 있다.
3. 이들 레거시 시스템은 각기 다른 프레임웍을 사용한다.
4. 매주 레이싱이 있으며, 레이싱은 각기 다른 국가들에서 열리기 때문에 이때마다 우리는 환경에 따라 변경하는 다른 프로그램 및 부품을 만들어야 한다.
5. 우리는 전 세계 수십개의 지사가 있다(분산되어 있는 조직이라는 것을 말하기 위함입니다.)
이들은 그들의 목표가 명확하기 때문에 다른 회사들보다 훨씬 일하기 편하다 라고 했습니다.
우리 회사도 목표가 있지요. '2010년까지 매출 4조' 우리같은 경우에는 2010년에 매출 4조를 달성하면 목표를 상향조정하거나 또다른 목표를 만들어야 하지만 F1 팀은 항상 변하지 않는 같은 목표를 위해 일합니다. 그것은
'F1 레이스 참피온 쉽 우승' 입니다
이 팀은 궁극적으로 자동차를 생산하는 팀입니다.
하지만 우리가 몸담고 있는 IT 와 굉장히 비슷하더군요. 그들이 말한 IT 측면입니다.
1. 예상하지 못한 flow
2. tight deadline
3. work related events
4. 24/7 availability
이들이 자동차를 개발하는 방식 입니다.
1. 개념적인 디자인을 합니다(Conceptual Design)
2. 실제 논리적 물리적 디자인을 합니다(Design)
3. 실제 자동차를 만듭니다.
4. 테스트 합니다.
5. 레이스를 합니다.
6. 우리가 만든 자동차는 역사가 됩니다. (이 말 참.. 맘에 듭니다. 스스로의 작업에 충분히 자부심을 가질 수 있을 것 같습니다. 많이 우승하면 할 수록 '호랑이는 가죽을 남기고 사람은 이름을 남긴다'는 말을 피부로 느낄 수 있게 되겠죠
수백번의 실패를 거쳐 그들은 F1 car 를 위한 프로세스를 만들었고 이를 위해 그들이 사용하는 방법입니다.
1. Iteration #1 basics
- 과거에 프로젝트를 실패하게 만든 원인을 규명하기 위해 20명의 팀원이 참여하는 투표를 실시하고 서로의 의견을 교환하는 프로세스를 만들었다.
- 또한 고객과의 커뮤니케이션을 단일화 하는 것이 매우 필요했는데, 고객이 시도때도 없이 interrupt 를 걸어 제대로 일할 시간이 매우 부족했기 때문이다. 이를 위해 우리는 driver 라는 역할을 만들었다. 문제가 발생하면 이 driver 가 대표로 문제를 확인하고 fix 할 책임을 진다. 이 driver 는 특정 프로젝트의 특정 일을 맡지 않으며, driver 고유의 역할을 수행한다. 다른말로 우린 warrior(해결사 정도라고 하면 될 것 같습니다) 라고 한다. 이 방법을 도입할 때는 20명중 2명의 driver 를 두고 시작했지만 이젠 1명의 driver 도 충분하다는 것을 알게됐다. 현재 1명의 driver 가 프로젝트 내에 존재하며 일정 기간이 되면 이 role 을 프로젝트 내 적절한 사람에게 넘긴다.
- 우리는 wiki 를 사용한다. 그리고 wiki 에 driver의 전체 역할 및 하루하루 벌어지는 일을 정리하고 정보를 공유한다. 이 wiki 가 프로젝트의 열쇠 역할을 한다.
- 우리는 CI(Continuous Integration)을 사용한다. 우리 시스템은 한번 클릭하면 100개 이상의 레거시 시스템과 새로 만든 시스템이 같이 통합된다. 이의 효율성을 위해 한가지 조사를 해봤는데. 빌드를 너무 자주 수행하면, 문제가 생길때마다 수정하는 시간이 늘어나고 요구사항이 밀려들며, 빌드 주기를 너무 길게 가져가면 요구사항은 적게 나와도 통합할 때 엄청난 고통이 발생했다. 결론적으로 3~4일 정도의 빌드주기를 가져간다. 주로 nightly build 를 사용한다.
- 우리는 manufacturing 단계에서 official 한 버젼이 나오면 3개 이상의 약간씩 변경을 가한 beta 버젼을 가지고 테스트 한다. 그리고 이중 한 개를 선택한다
- 두명씩 한 pair 가 되어 작업하다가 우리는 보다 나은 커뮤니케이션을 위해 한프로젝트를 수행하는 한 pair 와 또다른 프로젝트를 수행하는 pair 를 같이 일하게 만들었다. 다시말하면 4명이 2개의 프로젝트를 수행하는 셈이다. 두 가지 planing game 을 실시하고 half for one half on other PJT 방식으로 역할을 변경하며 작업한다.
- 우리는 스토리 카드를 사용한다. 또한 스토리 보드를 사용하는데 now, next, warehouse 로 카테고라이징을 하여 프로젝트 전체를 모니터링한다.
세션의 내용이 정말 흥미 진진했습니다.
일단 먼저 든 생각은 CI, wiki, pair programming, story card, planing game 이들 개념 모두가 Agile method 와 매우 유사하다는 것이고 그들이 현재까지 가장 안정된 개발 방법이라고 믿고 있다는 것입니다.
개인적으로 이 머리긴 수석 엔지니어가 얼마나 받을지 굉장히 궁금했습니다. 정말 물어보고 싶었는데... ^^;
덧글