|
|
|
 |
판매가 |
35,000원 → 31,500원  10% |
|
|
마일리지 |
 10% 3,150원 |
|
|
발행일 |
2008-10-08
|
|
ISBN |
8960770590 | 9788960770591
|
|
기타정보 |
번역서 | 416쪽
| Paperback
|
|
|
예상출고일
|
1~2일 이내 (근무일기준) |
|
배송비 |
무료배송
|
| |
|
|
|
|
|
 |
| 컴퓨터공학
|
|
|
| |
|
※ 네이버 체크아웃으로 구매시 비회원으로 구매가
됨으로 강컴 마일리지는 적립 되지 않습니다. |
|
|
|
 |
|
[요 약]
‘애자일 방법론은 대규모 프로젝트, 엔터프라이즈급 환경에는 적합하지 않다’는 잘못된 통념은 이제 사라져야 한다. 대기업이나 대규모 프로젝트에 적용하는 데 필요한 베스트 프랙티스뿐 아니라 조직이 갖춰야 할 인프라와 조직의 문화적인 측면까지 폭넓게 다루며 개발 역량을 높이기 위해 필요한 사항을 구체적으로 제시한다.
[추천사]
다년간 많은 회사들이 대규모 애자일 프로젝트 구현을 시도해 왔다. 하지만 ‘애자일은 소규모 프로젝트에만 효과가 있다’라는 ‘오해’가 애자일을 시작하려는 초보자들에게는 걸림돌로 다가왔으며, 애자일 비평가들에게는 좋은 비평거리가 됐다. 애자일에 대한 연구자료 중 애자일 방법론을 대규모 프로젝트 개발에 적용한 실무서는 지금까지 없었다. 딘 레핑웰의 책 『엔터프라이즈급 애자일 방법론』은 이 격차를 현저히 줄일 수 있을 것이다. 이 책은 아키텍처, 요구사항 개발, 다중 릴리스 계획, 팀 조직 등 대규모 프로젝트에서 빈번하고 중요하게 발생하는 문제에 대해 실무적인 가이드를 제공한다. 레핑웰의 책은 대규모 프로젝트와 조직에서 애자일 개발을 적용하는 데 반드시 필요한 지침서다.
- 짐 하이스미스
/ 애자일 프랙티스와 커터 컨소시엄의 책임자, 『애자일 프로젝트 관리』의 저자
소프트웨어의 신속한 개발과 출하, 시장 변화에 따른 유연성 확보와 제품의 안정성 유지 사이에는 팽팽한 긴장감이 감돈다. 이 책에서 저자 딘 레핑웰은 이들 간의 균형을 어떻게 유지해야 하는지 잘 보여주고 있다. 이 책에 나오는 저자의 관점과 해결책, 그리고 베스트 프랙티스에 대한 설명은 그가 겪은 모든 경험과 성취와 깨달음을 통해 우러난 것이다.
- 그래디 부치 / IBM 펠로우
[소 개]
신속한 시장 출시, 변화하는 고객 요구사항에 대한 유연한 대응, 향상된 품질 확보 등 애자일 개발 활동을 통해 많은 이익을 얻을 수 있다. 지금까지 애자일 활동은 소규모 팀을 대상으로 정의되고 추천됐다. 저자 딘 레핑웰은 드디어 이 책에서 애자일 방법론을 엔터프라이즈급 대규모 개발 프로젝트에 적용하는 방법을 공개한다.
1부에서는 보편적이고 효과적인 애자일 방법론들에 대해 개괄적으로 설명한다. 2부에서는 대규모 프로젝트에 애자일의 7가지 베스트 프랙티스들을 자연스럽게 확장하는 방법을 설명한다. 3부에서는 엔터프라이즈급 프로젝트에 애자일을 적용했을 때, 애자일의 모든 이점을 얻으려면 조직이 반드시 숙지해야 하는 7가지 능력에 대해 설명한다.
[추천의 글]
어떻게 하면 큰 조직에 애자일을 적용할까를 고민하는 사람은 생각보다 그리 많지 않다. 대다수는, 그리고 설사 자신이 큰 조직에 속하더라도 우선은 자신이 속한 소규모 팀이 어떻게 애자일을 도입하고 효과를 낼까 하는 것에 관심이 있다. 하지만 간혹 대규모 적용을 고민하는 사람들이 있다. 조직 내외의 컨설턴트나 기술에 관심 있는 경영진, 정치적 힘을 가진 PM, 혹은 그 사람들 주변의(그리고 종종 그 사람들을 설득해야 하는) 사람들이다.
원래 이런 사람들은 애자일에 별 관심이 없었다. 애자일과 대규모 조직은 그다지 잘 어울리지 않는 그림이었다. 하지만 애자일이 성공 경험을 쌓아가면서, 또 널리 전파되기 시작하면서 대규모 조직에서도 애자일에 관심을 두게 됐다. 여기에서 문제가 생기기 시작했다. 애자일을 어떻게 스케일업하는가. 안타깝게도 애자일을 대규모 프로젝트에 적용한 사례나 베스트 프랙티스가 많지 않았다.
하지만 선구자들에 의해 사례들이 쌓이기 시작했다. 심지어는 애자일의 대규모 적용(예컨대 수천 명 이상의 프로젝트)만 담당하는 컨설턴트까지 생겼고, 이 책처럼 애자일을 대규모 프로젝트에 적용하는 책들이 나오게 됐다.
『엔터프라이즈급 애자일 방법론』 우선 이 책이 우리말로 번역되어 기쁘다. 나에게 “애자일은 대규모 프로젝트/조직에 적용할 수 없어요”라는 비판을 하는 사람의 숫자가 줄어들 것 같다. 또, 어떻게 하면 좋을지 관련 자료를 요청하는 사람에게 권해줄 책이 생겨서 기쁘다. 하지만 미리 경고해 두건대 대규모 적용은 그것이 무엇이건 어렵다. 그러나 처음 시도하는 사람이거나, 아니면 이미 실패를 맛본 사람이거나 간에 이 책을 훑어보면 분명히 한두 가지 이상은 힌트를 얻으리라 생각한다.
1부에서는 애자일에 대한 요약 설명을 한다. 애자일을 잘 모르는 사람에게는 이 책이 간단한 소개서 역할도 할 수 있다는 장점이 있다. 2부와 3부에 걸쳐 총 14가지의 대규모 적용을 위한 실천법들을 소개한다. 사실 2부의 7가지 실천법은 팀 수준의 실천법인데 프로젝트 규모에 큰 상관없이 스케일업해서 적용 가능하다고 한다. 3부가 이 책의 골자라는 생각이 든다.
마지막으로 한마디. 많은 사람은 일명 풀뿌리식이라고 하는 버텀업(bottom-up)을 어떻게 해야 잘할까를 고민하지만, 대규모 적용을 고민하는 사람들은 보통 탑다운(top-down)을 어떻게 해야 잘할까를 고민한다. 남들 입장에서 보기에는 행복한 고민이다. 부사장이 애자일을 지지한다는데 뭐가 걱정이냐 이거다. 하지만 내 경험에서는 피차일반이다. 모두 성공이 간단하지 않다. 내 컨설팅 경험에서 가장 성공적인 경우는 샌드위치식(버텀업과 탑다운 겸비)으로 접근할 때였다. 엔터프라이즈 수준에서는 전략적인 탑다운식 도입과 체계적이고 발 빠른 조율을 하되, 개개인 수준에서는 애자일의 인간성 부분을 강조해서 자발적 참여가 일어나도록 동기 관리에 많은 노력을 기울일 것을 권한다.
이 책을 통해 국내에서 대규모 애자일 성공 사례들이 많아지기를, 그리고 이를 통해 국내 IT 업계가 더 인간적이고 생산적인 곳이 되기를 진심으로 기원한다.
김창준
애자일 컨설팅 대표
http://agile.egloos.com
[이 책의 구성]
1부. 소프트웨어 애자일 방법론 소개
이 책은 세 부분으로 구성된다. 1부는 애자일 방법론에서 가장 많이 쓰이는 XP, 스크럼, 애자일 방식을 적용한 반복적이고 점진적인 방법론인 RUP에 대해 이야기하고, 애자일 역사에 대해 간단히 알아본다. 더불어 애자일 방법론을 지원하는 린 소프트웨어 개발, 동적 시스템 개발방법론(DSDM), 기능 주도 개발방법론 등도 간략히 살펴본다.
2부. 애자일을 확장 적용하는 7가지 팀단위 애자일 활동
2부는 각 장마다 팀 규모에서 적용하는 7개의 애자일 활동을 예로 들어 애자일의 기본 개념에 대해 이야기한다. 각 활동은 직간접적으로 애자일 방법론의 필수 요소를 보여준다. 애자일을 처음 들어본 사람이나 애자일 방법론이 어떻게 구현되는지에 관심이 있는 대규모 조직이라면 2부에 나오는 예제들을 통해 애자일 방법론이 얼마나 간단하게 적용되는지 살펴볼 수 있을 것이다. 더불어 현재 조직 상황에 맞춰 애자일 방법론을 수정하고 적용하는 방법도 배울 수 있다.
3부. 엔터프라이즈 환경에 맞는 애자일 방법론
애자일 방법론을 엔터프라이즈 환경에 적용하려면 좀더 많은 작업이 필요하다. 3부에서는 엔터프라이즈 환경에 맞는 애자일에 대해 설명한다. 3부에서는 조직이 애플리케이션과 시스템 규모에 관계없이 애자일 방법론을 적용하는 데 필요한 능력과 지침, 원칙, 활동들을 보여준다. 여기서 다루는 예제들은 실제로 엔터프라이즈 환경에 직접 애자일 방법론을 적용해본 결과에서 나온 것들로서, 다국적 개발자와 외주 용역 40~50명 정도로 구성되어 이전 기술에 구애받지 않고 완전히 새롭게 시작하는 소규모의 ‘그린 필드’ 프로젝트부터, 하나의 목표 아래 1,000명 정도가 팀을 이뤄 팀원들 간의 조화가 필요한 대규모 조직까지 전반적으로 다룬다. 3부의 원칙 중에는 분명히 생소할 내용도 있을 것이다. 이 중 몇 가지는 애자일을 적용하는 과정에서 각 팀이 수정하고 발전시킨 경험들이다.
이 책이 애자일 방법론을 활용해 소규모 팀에서 효과를 본 것만큼 대규모 조직에도 200퍼센트 향상된 생산성과 품질 제고에 도움이 되었으면 한다. 그리고 생산성과 품질 향상을 통해 대기업들이 좀더 빠른 제품 출시와 개발, ROI 향상, 사용자 만족도 증가를 이룰 수 있기를 바란다. 더불어 애자일 방법론을 통해 무형의 이익도 기대할 수 있다. 팀 스스로 애자일 방법론을 사랑하고 여러 가지 시도로 더욱 강해지며 조직에 맞는 그들만의 방법론을 만들어서 지속적으로 프로세스를 발전시킬 것이다. 그리고 지속적으로 프로세스를 발전시키면서 프로젝트 결과, 사람, 전문성 그리고 업무에 대한 만족도까지 함께 향상될 것이다. ‘새로운 것에 도전하는 기업’은 언제나 가치가 있다.
★ 서문 ★
애자일 프로세스라는 용어에 익숙하지 않은 사람이라면 두려움과 의심을 느끼면서 이 책을 펼쳤을지도 모르겠다. 하지만 그건 여러분 탓이 아니다. 애자일 프로세스를 배우다 보면 질주(스프린트, sprint), 속력(velocity), 스크럼(scrum, 럭비게임의 기본 대형?), 익스트림 프로그래밍(extreme programming, 스노보드로 벼랑 끝에서 점프하는?), 사용자 스토리(user stories), 서사(에픽, epic)와 전설(saga, 소설에 나오는 이야기?), 불가사의한 사회적 의례(weird social rituals), 짝 프로그래밍(pair programming), 사용자 회고(user retrospectives), 허들(huddles), 일일 스탠드업 미팅(이제 서로 껴안아줘야 하나?) 등과 같은 기이한 표현들을 자주 접하게 될 것이다. 또 애자일팀들은 엄청나게 많은 포스트잇과 명함 만한 인덱스카드를 벽에다 마구 붙이면서 무질서하게 일을 하는 것처럼 보이기도 한다. 그리고 이런 행동들은 마치 스콧 애덤스의 만화 딜버트(Dilbert)에나 나오는 이야기처럼 보인다. 그러나 착각하지 않길 바란다. 애자일 소프트웨어 개발 프로세스는 제프리 무어가 말한 것처럼 ‘큰 차이를 극복하는 것(Crossing the Chasm)’이라 할 수 있다. 이제 애자일은 단순히 흥미를 끄는 유행어를 넘어선, 효과적이고 생산적이며 측정 가능한 개발방법론이다. 애자일 개발방법론을 받아들여 성공의 길로 들어서느냐 아니면 그냥 이대로 낙오하느냐는 모두 여러분에게 달렸다.
애자일 개발방법론은 ‘계획적인 개발’ 방법론과는 차이가 있다는 말을 어디선가 들어봤을 것이다. 어떻게 생각하면 애자일 방법론은 매우 무질서하며 그동안 알고 있던 체계적이고 계획적인 소프트웨어 개발방법들과는 많이 다르다고 느꼈을 것이다. 하지만 계획을 세우는 방법이 다를 뿐, 애자일 프로젝트도 매우 주의 깊게 계획된다. 다만 여타 개발방법론에 비해 좀더 자주 정제되고 재계획된다는 점에서 차별된다고 할 수 있다. 애자일 방법론은 7~12명으로 구성된 소규모 팀이 2~9개월 동안 진행하는 단기 프로젝트에는 높은 효율을 보이지만 전 세계에 퍼져 있는 대규모 팀이 진행하는 장기 프로젝트에는 적합하지 않다고 알려졌다. 그렇다고 이 책을 덮을 필요는 없다. 전 세계에서 진행되는 대부분 프로젝트처럼 애자일 프로세스도 그 경계를 넓혀나가면서 생산성이 높은 고품질 소프트웨어를 만들어 가고 있다.
이 책에서 딘 레핑웰이 이야기하고 싶어하는 것은 다음과 같다. 익스트림 프로그래밍(XP), 스크럼(Scrum), 린(Lean), 동적 시스템 개발방법론(DSDM, Dynamic System Development Method), 기능 주도 개발방법론(FDD, Feature Driven Development), 유니파이드 프로세스(Unified Process)와 같은 애자일 프로세스 사이에 발생하는 문제들에 대해 상호 간에 어떤 공통점이 있는지를 먼저 설명한다. 그러고 나서 저자는 이런 장점이 있는 다양한 방법론보다 애자일 접근 방법이 더욱 월등한 이유를 열띤 논조로 이야기하고 있다. 저자는 이 책에서 기존 방법론들과 새로운 애자일 프로세스를 이야기하려는 것이 아니라, 기존 애자일 실례와 새로운 예제를 통해 고수준의 기술과 관리 방법을 설명하고자 한다. 저자는 기존의 베스트 프랙티스에서 볼 수 있었던 내용뿐만 아니라 좀더 큰 애자일 프로젝트 관리에 초점을 맞춰 설명하고 있다. 예를 들어 이제까지는 많이 언급되지 않았던 릴리스 계획법, 대규모로 분산된 팀들을 다루는 법, 프로젝트 사업 목표 수립법, 장기 프로젝트 수행법 등을 다룬다.
저자는 그저 탁상공론을 논하는 학자가 아니며 자신이 주장하는 방법론을 주입시키기 위해 어림짐작으로 이야기하지도 않는다. 저자가 이 책에서 충고하는 내용은 수많은 회사와 다양한 프로젝트(생명의학용 소프트웨어부터 놀이공원과 놀이기구에 필요한 거대한 IT 인프라 애플리케이션까지)에서 직접 겪은 오랜 경험을 바탕으로 하고 있다. 나는 래셔널(Rational) 사와 랠리(Rally) 사에서 저자와 10년 동안 함께 일해왔기 때문에 누구보다도 잘 알고 있다.
이 책에 대한 몇 가지 충고를 덧붙이자면, 이 책을 읽은 후 책의 내용을 그대로 따라 한다고 해서 모든 프로젝트가 곧바로 성공할 거라 기대하면 안 된다. 부동산 업자들이 위치(location)를 중요하게 생각하는 것처럼 새로운 소프트웨어 개발 예를 적용하는 것의 핵심은 컨텍스트(context)라고 말할 수 있다. 여러분이 처한 컨텍스트, 즉 상황을 잘 이해한 다음, 저자가 주장하는 내용과 비교해보고, 프로젝트의 목표와 범위, 크기, 조직 문화 등을 비교해 저자가 추천하는 방법들을 여러분의 조직에 적용하길 바란다. 고려하고 있는 상황은 다양한 요소로 구성되어 있을 것이다. 예를 들어 조직의 도메인(어떤 일을 하는 산업인지), 개발하고자 하는 시스템의 규모, 팀의 경력, 각 팀원의 경험과 교육수준과 학력, 사용하고 있는 기술, 시스템의 엄격도, 심지어는 여러분의 조직과 나라의 문화까지도 포괄한다. 이 책에서 저자는 기업가, 소프트웨어 개발 관리자, 경영진, 방법론자, 컨설턴트 등 다양한 경험을 바탕으로 자신이 정립해둔 가치와 기준, 자신이 처했던 여러 상황을 설명하고 있다. 물론 여러분의 경험은 저자와는 다를 것이다. 책을 읽으면서 조금이라도 의구심이 든다면, 특정 용어와 방법에 연연하지 말고 애자일의 기본 개념을 떠올려보길 바란다.
문서화가 되어 있든, 사람들의 머릿속에만 존재하든 간에 ‘애자일 프로세스’는 프로세스 자체가 기민하거나 민첩하게 변화하는 것이 아니라, 사람이나 팀, 조직 등이 민첩하게 변화하는 것이다. 단순히 애자일 프로세스를 따라만 하기보다는 애자일 자체가 여러분이나 여러분이 속한 조직에 녹아 있어서 ‘애자일’의 속성이 여러분 몸에 깊이 배어들어야 한다. 여러분이 속한 그룹이나 여러분 자체가 애자일화되지 않고 단순히 애자일 프로세스에서 제공하는 몇 가지 방법들만 적용하려고 한다면, 이유를 알지 못한 채 실패할 것이며 어느 책에선가 나쁜 선례로 언급될지도 모른다. 이 차이를 극복하려면 저자나 다른 사람들이 말하는 것을 그대로 따라 하거나 애자일 방법론을 그대로 받아들이는 것을 넘어 그 이상으로 열심히 노력해야 할 것이다. 쉽진 않겠지만 마음가짐이나 태도 자체가 변화해야 한다. 마음가짐이나 태도라는 건 단순히 책을 읽는다거나 교육과정을 통해 수업을 듣는다고 해서 저절로 바뀌는 게 아니다. 애자일 프로세스에서 이익을 얻으려면 여러분과 여러분이 속한 조직이 애자일의 기본 원칙을 받아들여 새로운 시도를 반복, 또 반복해야 한다. 그리고 여러분의 경험을 평가해보고 그 경험을 살려, 새로운 시도를 통해 어떤 것을 얻고 얻지 못했는지를 검토하고 얻어낸 교훈을 다시 적용해 봐야 할 것이다. 거듭 말하지만, 이 책을 읽었다고 해서 애자일 방법론을 모두 배웠다고 생각하지 않길 바란다. 이 책을 통해 생각하고, 느끼고 변화해야만 진정한 애자일이 무엇인지 알게 될 것이다.
만일 여러분이 애자일에 대해 잘 알고 있고, 1970년대 천공카드를 쓸 때부터 애자일 프로세스가 몸에 배어 있는 사람이라면 이 책에서 무엇을 얻을 수 있을까? 답부터 말하자면, 그래도 배울 게 아주 많을 것이다. 개인적으로 이 책을 검토하는 동안 그동안 내가 겪어온 경험과 실례들을 돌이켜볼 수 있었으며 많은 것을 배울 수 있었다. 사실 저자가 말한 모든 의견에 동의하는 건 아니다. 내가 처했던 상황과 경험은 그와는 약간 차이가 있기 때문이다. 하지만 저자와 나는 몇몇 특정 용어와 방법을 제외하고는 전체적으로는 이 책의 모든 내용이나 기본적인 원칙과 전략에 대해서는 서로 동의하고 있다(얼마 전 그에게 들은 바대로 우리는 각자의 의견을 서로 나누며 토론 자체를 즐겼다. 토론을 통해 우리가 지닌 핵심 원칙을 시험해보고 서로 생각을 알아보기도 했다). 이런 관점에서 볼 때, 여러분이 이미 애자일을 많이 경험했더라도 이 책에서 더욱 가치 있는 교훈을 얻고 지식을 한층 강화할 수 있을 거라 믿는다.
자, 이제 충분히 이야기한 것 같다. 이것으로 서문을 마치고 페이지를 넘겨 본론으로 들어가 보자. 책을 읽는 동안 즐겁게 배우면서 ‘애자일’을 몸소 실천하길 바란다.
필립 크루첸
소프트웨어공학 박사
캐나다 밴쿠버의 브리티쉬 컬럼비아대학 소프트웨어공학 교수
★ 저자 서문 ★
소프트웨어 방법론 경력 1단계: 레라와 리퀴짓 사
나는 업무를 통해 소프트웨어 공학과 소프트웨어 개발 관리에 대한 기술을 익히고 발전시켜왔다. 목표는 항상 일정했지만, 소프트웨어 개발 경험은 크게 3단계를 통해 발전한 것 같다. 첫 번째는 다른 업체 수주를 받아 소프트웨어를 개발해주던 레라Rela 사(社)의 CEO로서 출발했다. 레라는 놀이동산의 놀이기구부터 생명의학 장치까지 다양한 분야에 걸쳐 사용되는 소프트웨어 애플리케이션을 개발하는 회사였다. 레라의 소프트웨어는 고객에게 수주해 진행하는 것이었기 때문에, 회사의 목표는 언제나 “고객이 원하는 것을 제대로 만들자(build the right thing)”였다. 회사의 모든 역량은 주어진 문제의 해결책은 무엇인지, 그 해결책을 적용하는 가장 효과적인 방법은 무엇인가를 연구하고 고객에게 설명하는 것에 집중됐다.
그래서 폭포수 방법론(waterfall method)에 기반을 둔 엄격한 방법론을 사용했다. 실제로 몇몇 고객과 식품의약국(FDA) 같은 주요 규제 조직에서는 폭포수 방법론을 원했고, 우린 고객이 원하는 대로 폭포수 방법론을 따랐으며, 필요한 경우 약간의 수정을 가해 적용하기도 했다. 폭포수 방법론을 사용하는 동안 우리가 알아낸 사실은 폭포수 방법론이 과거 프로젝트 중 일부를 기반으로 발전시키고 산출물을 중요시한다는 점이다. 당시 내 주관심사는 요구공학 프로세스(Requirement Engineering Process)에 있었는데, 이는 프로젝트에 큰 영향을 미치는 심각한 문제점을 찾을 수 있으며, 문제의 해결책에 대한 정의가 이뤄지고, 계약의 밑바탕이 되기 때문이었다.
이런 경험을 바탕으로 나는 요구공학 솔루션 프로그램인 리퀴짓프로(RequisitePro)를 만든 리퀴짓(Requisite) 사의 창립자이자 CEO가 될 수 있었다. 리퀴짓 사에서는 요구사항 정의에 필요한 사례와 제품을 개발하고 발전시킬 수 있었으며, 이런 경험 덕분에 소프트웨어 개발 사이클 전반부에 대한 많은 경험을 갖게 됐다. 1997년 리퀴짓은 래셔널 사에 인수되었고, 나는 소프트웨어 개발 프로세스 인생의 두 번째 전기를 맞게 된다.
소프트웨어 방법론 경력 2단계: 래셔널 사
나는 래셔널(Rational) 사의 고위 경영층으로서 UML(Unified Modeling Language)과 RUP(Rational Unified Process) 배포에 조력하고 있었다. 래셔널 사에서 그래디 부치(Grady Booch), 이바 야콥슨(Ivar Jacobson), 제임스 럼바우(James Rumbaugh), 워커 로이스(Walker Royce), 필립 크루첸(Philippe Kruchten)과 같은 당대 석학들과 함께 일할 좋은 기회를 얻을 수 있었다. 그리고 이때 돈 위드릭(Don Widrig)과 함께 Addison-Wesley 출판사에서 『Managing Software Requirements』(2000)라는 책을 집필, 출간했다.
생각할 수 있는 모든 개념은 객체지향(Object Orientation)에 바탕을 뒀는데, 객체지향 사고방식을 통해 개발방법론은 유연성이 높아지고 소프트웨어를 더욱 탄력적으로 작성할 수 있었다. 또 폭포수 모델과는 달리 반복 점진적인 소프트웨어 개발이 가능해졌다. 이렇게 하면 주기마다 객관적으로 평가할 수 있는 소프트웨어를 만들어낼 수 있었고, 이런 방식은 폭포수 모델을 사용할 때보다 좀더 애자일스러웠다. 폭포수 모델을 사용할 때와는 달리, 문서나 디자인 리뷰와 같은 중간 산출물들이 독립적으로 존재할 필요가 없었고 측정, 평가도 가능했다.
래셔널 사는 래셔널 유니파이드 프로세스(RUP)란 이름으로 이 모든 과정들을 집대성해 문서화했다. 그리고 시장에 출시하고 산업체에 적용해 좋은 성공 스토리를 만들었다. 뿐만 아니라 이 프로세스와 래셔널 사의 제품군을 개발에 적용했고, 4개국에 걸쳐 800명의 팀원이 있는 조직에도 적용했다. 매년 두 번씩 유기적으로 연결된 래셔널 제품군을 출시했다. 그 후 래셔널 사는 IBM에 합병됐고 이제는 RUP란 이름으로 IBM의 래셔널 소프트웨어 부서가 판매하고 있으며, 현재 수백, 수천 명의 개발자가 이를 사용하고 있다.
소프트웨어 방법론 경력 3단계: 본격적인 애자일, 랠리 사
래셔널을 떠나서 독립 컨설턴트로서 소프트웨어 각 개발 단계에 대해 조언을 하게 됐다. 사업 전략에 대해 지도를 하고, 몇몇 새로운 벤처 업체에는 소프트웨어 개발방법론을 가르쳤다. 이때 XP나 스크럼 같은 좀더 혁신적이고 가벼운 방법을 적용해 볼 수 있었고 소규모 팀들이 이 방법론을 통해 제품의 생산성과 질을 어떻게 향상시키는지를 두 눈으로 직접 확인할 수 있었다.
얼마 지나지 않아 나는 애자일의 매력에 푹 빠져서 이제는 애자일 방법론을 알지 못하는 팀이나 사업가와 함께 일을 하기 싫을 지경에 이르렀다. 그렇지 않으면 사업에 대한 위험이 너무 컸기 때문이다. 하지만 동시에 애자일 방법론에 대한 한계가 보이기 시작했다. 팀이나 애플리케이션의 규모가 점점 더 커질수록 코드를 만드는 능력은 감소했고, 요구사항을 좀더 명확하게 정의할 필요가 있었으며, 폭주하는 설계방식에 뭔가 변화를 줘야 할 필요성을 느꼈다. 이때를 즈음해 랠리(Rally) 소프트웨어 사에서 소프트웨어 개발방법론자로서 컨설팅을 시작했고, 분산 애자일 기반 솔루션 개발에 많은 조언을 했다. 랠리 사에서는 라이언 마틴즈(Ryan Martens), 켄 슈와버(Ken Schwaber), 짐 하이스미스(Jim Highsmith), 마이크 콘(Mike Cohn), 톰과 메리 포펜딕 부부(Tom and Mary Poppendieck), 제프 서덜랜드(Jeff Sutherland) 같은 애자일 전문가들과 함께 일하면서 많은 영향을 받았다.
엔터프라이즈급 프로젝트에서의 애자일 경험
앞에서 언급한 다양한 직무 경력을 통해, 개인적으로는 많은 기업으로부터 엔터프라이즈급 프로젝트에 애자일 방법론을 도입할 수 있게 해달라는 협조 요청을 받았다. 약간 두려움이 앞서긴 했지만, 몇 년간 각 지역에 산재한 수백 명의 개발자가 대규모 애플리케이션을 개발하는 BMC 소프트웨어에 애자일의 핵심 원리와 내 업무 경험을 적용하는 데 성공했다.
애자일 방법론을 가르치는 동안 기업에 큰 가치를 부여하는 베스트 프랙티스들을 발견할 수 있었다. 하지만 이런 베스트 프랙티스들을 대규모 팀에 적용하는 건 그리 수월한 일이 아니었다. 그래서 엔터프라이즈 조직에 맞는 애자일 방법론을 좀더 연구해 보기로 했다. 하지만 엔터프라이즈급 회사에 맞는 애자일 방법론을 다룬 책들은 찾아보기가 어려웠고 결국 책을 한 권 집필하기로 했다. 이 책을 읽고 배운 내용을 조직에 맞게 적용하고 더 좋은 품질과 생산성을 얻게 되기를 희망한다. 세상에 많은 소프트웨어가 있지만 산업과 경제를 도약시킬 만한 소프트웨어 방법론을 찾기란 쉽지가 않다.
★ 옮긴이의 말 ★
이 책을 읽는 독자라면 이제 애자일이란 용어가 아주 낯설게 느껴지지는 않을 것이다. 서점에 나가도 애자일을 다룬 서적이 이미 많이 나와 있으니 말이다. 내가 처음 애자일이란 용어를 접한 것은 5년 전쯤 익스트림 프로그래밍(XP, Extreme Programming)에 대한 교육을 받을 때였다. 교육을 신청한 이유도 단순히 제목이 참 흥미로웠기 때문이었다. 당시만 해도 ‘애자일=XP’라는 아주 단순한 생각을 하고 있었으며, 처음 ‘애자일’ 이란 용어를 접했을 때에도 매우 낯설어 사전에서 ‘기민한, 민첩한’이란 뜻을 찾아냈지만 정확히 무슨 의미를 뜻하는지 그 느낌이 쉽게 다가오지 않았다.
그 뒤 회사에서 SE 업무를 시작하게 됐고 애자일 방법론의 여러 가지 활동들을 접하게 되면서 몇 가지 베스트 프랙티스들은 지금 하는 현업에 직접 적용해 볼 수도 있겠다는 아이디어가 떠올랐다. 점점 더 애자일 방법론에 대해 알아갈수록 이 방법론은 많은 개발 경험이 있고, 프로세스가 어느 정도 내재화되어 있는 팀에서 충분히 적용 가능하다는 생각이 들었다. 하지만 현실적으로 개발자들에게 가장 매력적으로 다가가는 애자일 방법론의 장점은 개발 도중에 끊임없이 만들어내야 하는, 그리고 도대체 왜 필요한지 동감할 수 없는 ‘문서’가 없다는 점일 것이다. 그래서 ‘애자일 개발 = 애드혹 개발’이라는 오해를 받기도 한다. 이 책 첫머리에 나오는 이야기지만 ‘애자일은 소규모 프로젝트에만 효과가 있다’라는 통념 때문에 애자일 방법론에 대해 약간은 부정적인 시각을 갖고 있었다.
하지만 이 책의 번역 의뢰를 받았을 때 선뜻하겠다고 나선 이유는, 책 제목에서도 알 수 있듯이 애자일 방법론을 엔터프라이즈급 회사에 적용해본다는 새로운 시각, 그리고 애자일 방법론에 대한 기본 이론을 먼저 설명한 후 이를 점차 확장시켜 가면서 고려해야 할 여러 사항을 저자의 경험을 토대로 다양한 사례를 들어가며 상세히 설명하고 있기 때문이었다. 번역을 진행하면서 애자일 방법론에 대해 좀더 체계적으로 알 수 있었고, 현업 적용에 대한 아이디어를 많이 떠올릴 수 있게 됐다.
매번 만족하지는 못하지만, 항상 번역을 하면서 고민하게 되는 것은 어떻게 하면 저자가 말하고자 하는 바를 왜곡 없이 100% 독자들에게 전달할 수 있을까였다. 그래서 가능한 용어는 이미 출간된 여러 책을 참조해 독자들이 무리 없이 읽을 수 있게 하고 전체적으로 저자의 의도를 최대한 살리도록 노력했다.
수많은 애자일 방법론에 대한 책이 출간됐지만, 엔터프라이즈급 대규모 프로젝트에 확장 적용하는 애자일 기법과 사례를 충실히 그리고 생생하게 익힐 수 있는 이 책이 애자일 방법론 확장에 좀더 기여할 수 있게 되길 바란다.
|
 |
|
 |
1부 소프트웨어 애자일 방법론 ● 35
01장 애자일 방법론 소개 ● 39
소프트웨어 경쟁에서 앞서 나아가기 ● 39
소프트웨어 개발방법론 발전 ● 40
애자일 방법론으로 들어가기 ● 40
엔터프라이즈급 애자일 ● 41
애자일 방법론을 바라보는 시선 ● 43
애자일 선언문 ● 43
애자일 도입 경향 ● 46
비즈니스에서 애자일 소프트웨어의 장점 ● 46
생산성 향상 ● 47
품질 향상 ● 48
팀의 사기와 업무 만족도 향상 ● 48
제품 출시 앞당기기 ● 48
익스트림 프로그래밍, 스크럼, RUP ● 49
익스트림 프로그래밍 ● 49
스크럼 ● 50
RUP ● 51
정리 ● 52
02장 폭포수 모델이 적합하지 않은 이유 ● 53
폭포수 모델의 문제점 ● 55
폭포수 모델에 기반한 가정 ● 56
가정1: 요구사항을 잘 이해하고, 제대로 정의하려면 시간을 투자해야만 한다 ● 57
가정2: 변경사항은 많지 않을 것이고 수용 가능할 것이다 ● 58
가정3: 시스템 통합은 순조로울 것이다 ● 59
가정4: 일정에 맞게 완료할 수 있다 ● 59
결론 ● 63
애자일 방법론을 통한 제대로 된 작업의 시작 ● 64
03장 XP의 핵심 요소 ● 67
XP란? ● 67
XP의 논쟁거리 ● 68
XP의 무엇이 그토록 익스트림한 요소일까? ● 69
XP의 기본 원리 ● 70
XP의 가치와 원칙, 활동 ● 72
XP의 5가지 핵심 가치 ● 72
기본 원리 ● 73
XP의 12가지 주요 활동 ● 74
짝 프로그래밍에 대한 메모 ● 78
XP 프로세스 모델 ● 79
방법론의 적용성 ● 80
더 읽을거리 ● 81
04장 스크럼의 핵심 요소 ● 83
스크럼의 정의 ● 83
스크럼에서의 역할 ● 84
스크럼의 철학적 뿌리 ● 85
스크럼의 가치와 원리, 활동 ● 86
스크럼의 핵심 활동 ● 87
스크럼의 기본 원리: 경험적 프로세스 제어 ● 88
스크럼의 프로세스 모델 ● 90
스크럼과 조직의 변화 ● 92
스크럼 방법론의 응용 ● 92
더 읽을거리 ● 93
05장 RUP의 핵심 요소 ● 95
RUP란? ● 95
RUP의 주요 특성 ● 96
RUP의 뿌리 ● 97
RUP의 원리와 실제 ● 98
반복: RUP의 기본 개념 ● 100
아키텍처 기반과 유스케이스 중심 ● 101
RUP의 프로세스 모델 ● 102
시간 축 ● 102
분야 축 ● 103
RUP 반복의 종류 ● 104
애자일 RUP 변형판 ● 106
오픈 유니파이드 프로세스(`OpenUP) ● 106
애자일 유니파이드 프로세스 ● 107
방법론의 적용성 ● 107
더 읽을거리 ● 108
06장 린 소프트웨어, DSDM, FDD ● 109
린 소프트웨어 개발 ● 109
린 소프트웨어 개발의 더 읽을거리 ● 111
동적 시스템 개발방법론 ● 112
배경 ● 113
기본 원리 ● 113
DSDM의 핵심 활동 ● 115
DSDM 상세 정보 ● 117
기능 주도 개발 ● 117
FDD의 베스트 프랙티스 ● 118
07장 애자일의 핵심 요소 ● 123
애자일로 무엇을 바꾸려고 하는가? ● 123
성공의 새로운 척도 ● 124
관리 문화의 차이 ● 125
요구사항, 아키텍처, 설계에 대한 접근법의 차이 ● 126
수정된 코드와 구현 활동 ● 126
테스트와 품질보증 활동에 대한 변화 ● 127
계획과 스케줄 작성의 새로운 방법 ● 128
가장 큰 변화: 개발 범위 대 일정 - 일정의 승리 ● 129
애자일의 심장: 짧은 타임박스 내에서 동작하는 코드 만들기 ● 130 1. 타임박스 내에서 일하기 ● 131
2. 작은 덩어리로 개발하기 ● 132
정리 ● 134
08장 애자일 확장에의 도전 ● 135
애자일 방법론이 직면하는 장벽 ● 136
소규모 팀 ● 136
고객의 밀접한 참여 ● 137
한 공간에서 일하기 ● 137
서서히 드러나는 아키텍처 ● 138
요구사항 분석과 문서화된 명세의 부족 ● 138
업무 문화와 물리적 업무 환경 ● 138
엔터프라이즈의 장애물 ● 139
프로세스와 프로젝트 관리 조직 ● 139
형식화된 기존 정책과 절차 ● 140
기업 문화 ● 140
고정된 일정과 고정된 기능의 강요 ● 141
개발팀과 사용자/고객 대변팀과의 마찰 ● 141
제품 라인2이 아닌 분야별로 조직된 구성원 ● 142
여기저기 흩어진 조직 ● 142
정리 ● 143
2부 애자일을 확장 적용하는 7가지 팀단위 애자일 활동 ● 145
09장 정의/빌드/테스트 컴포넌트팀 ● 151
정의/빌드/테스트 컴포넌트팀의 의미? ● 152
단순한 스토리의 생명주기 ● 152
기능 사일로의 제거 ● 154
애자일 컴포넌트팀의 역할과 책임 ● 156
자체적으로 조직, 관리되는 정의/빌드/테스트팀 ● 160
적합한 인재를 보유하고 있는 팀(버스) ● 161
관리하지 않고 이끌어가면 되는 팀 ● 162
미션을 이해하고 있는 팀 ● 163
끊임없이 대화하고 협업하는 팀 ● 163
자신의 결과에 책임을 지는 팀 ● 164
지리적으로 떨어진 팀 ● 165
10장 두 단계 계획과 추적 ● 167
일반화된 애자일 프레임워크 ● 168
반복이란? ● 169
반복의 구조 ● 169
릴리스란? ● 170
릴리스의 해부 ● 171
릴리스 계획하기 ● 171
요구사항을 릴리스에 분배하기 ● 171
전반적인 릴리스 계획 ● 172
정리: 두 단계 계획 ● 172
11장 반복 숙달하기 ● 175
애자일의 심장, 반복 ● 175
2주? 반복의 표준 주기? ● 175
반복의 계획과 실행 ● 177
반복 작업 계획하기 ● 178
반복 계획 회의 준비 ● 179
참가자 ● 179
반복 계획 회의 ● 180
결과: 반복 계획 ● 181
반복 계획 지침 ● 181
분산된 팀의 반복 계획 ● 182
반복 수행 ● 183
책임 수반 ● 184
개발 ● 184
스토리 출하 ● 185
스토리 완료 선언 ● 185
반복 수용 ● 185
반복의 추적과 조정 ● 186
일일 스탠드업 미팅을 통한 추적 ● 187
일일 스탠드업 미팅 지침 ● 187
반복의 진행 상태 추적 ● 188
번다운 차트로 추적하기 ● 189
반복 리듬 달력 ● 189
12장 짧고 빈번한 주기의 릴리스 ● 193
짧은 릴리스 주기의 장점 ● 193
릴리스의 정의와 스케줄 ● 195
일정 주도형 릴리스 ● 196
가장 단순한 모델: 고정된 주기의 릴리스 일정 ● 196
기능 셋 추정 ● 198
릴리스 계획 ● 199
참여자 ● 200
준비하기 ● 200
릴리스 계획 프로세스 ● 201
결과: 릴리스 계획 ● 202
릴리스 계획에 대한 추가 지침 ● 203
릴리스 추적 ● 203
릴리스 현황 리뷰 준비 ● 204
릴리스 현황 리뷰 미팅 ● 204
결과물/문서화 ● 205
릴리스 로드맵 ● 205
미리 살펴보는 애자일 확대 적용: 대규모 조직에서의 릴리스 계획과 추적 ● 206
대규모 조직에 적용 가능한 애자일 만들기 ● 206
복수 팀에 대한 릴리스 계획 ● 210
릴리스 추적 ● 211
13장 동시 테스트 ● 213
애자일 테스트 개요 ● 213
시작부터 테스트 가능한 시스템 만들기 ● 214
애자일 테스트 원칙 ● 214
단위 테스트 ● 216
반복 안에서의 단위 테스트 ● 217
단위 테스트와 테스트 주도 개발 ● 218
인수 테스트 ● 219
자동화된 인수 테스트 예제: FIT 접근 방식 ● 219
컴포넌트 테스트 ● 221
시스템 테스트와 성능 테스트 ● 222
정리: 애자일 테스트 전략에 대한 요약 ● 223
반복과 릴리스 테스트 패턴 ● 223
14장 지속적인 통합 ● 227
지속적인 통합이란? ● 227
불연속적 통합: 마이크로코즘에서의 문제점 ● 228
지속적인 통합 ● 229
지속적인 통합으로 향하는 3단계 ● 230
소스코드 통합 ● 231
자동화된 빌드 관리 ● 232
자동화된 빌드 검증 테스트 ● 233
지속적인 통합의 성공이란? ● 235
15장 정기적인 반성과 적응 ● 237
반복 회고 ● 238
반복 회고의 형식 ● 238
정량적 분석 ● 238
정성적 분석 ● 241
해야 할 일 ● 241
릴리스 회고 ● 242
정량적 분석 ● 242
정성적 분석 ● 244
릴리스 회고를 통해 조직 장애물 드러내기 ● 244
3부 엔터프라이즈 환경에 맞는 애자일 방법론 ● 247
16장 계획된 아키텍처 ● 253
소프트웨어 아키텍처란? ● 254
애자일과 아키텍처 ● 256
익스트림 프로그래밍: 아키텍처는 서서히 드러난다 ● 256
스크럼 ● 257
기능 주도 개발방법론 ● 258
RUP: 아키텍처 중심 ● 259
리팩토링과 시스템 규모 ● 261
무엇을 만드는가? ● 261
엔터프라이즈급 시스템에 대한 애자일 아키텍처 접근 ● 262
컴포넌트 기반 시스템: 아키텍처를 따르는 조직 ● 263
아키텍처 런웨이 만들기 ● 264
변경되기 쉽고 임시적인 아키텍처의 특성 ● 267
아키텍처 런웨이 확장 ● 268
제품 백로그를 활용한 리팩토링 ● 269
아키텍처 런웨이의 확장: 반복과의 동기화 ● 269
아키텍처 런웨이 확장: 린, 풀 기반 접근 방식 ● 271
17장 린 요구공학: 비전, 로드맵, 적시 정교화 ● 273
개요: 요구사항 피라미드 ● 274
이해관계자의 요구 ● 275
솔루션 기능 ● 275
소프트웨어 요구사항 ● 275
기존 요구사항 접근법 ● 276
애자일의 요구사항은 어떤 점이 다른가? ● 278
XP에서의 요구사항 ● 278
스크럼, 제품 책임자, 제품 백로그 ● 280
RUP에서의 요구사항 ● 282
대규모 시스템에 대한 애자일 요구사항 접근법: 비전, 로드맵, 적시 정교화 ● 283
1. 비전 ● 284
2. 로드맵 ● 287
3. 적시 정교화 ● 289
사용자 스토리로 정교화 ● 291
유스케이스로 정교화 ● 294
인수 테스트 케이스로 정교화 ● 296
정리 ● 296
18장 대규모 시스템과 애자일 릴리스 기차 ● 297
애자일 컴포넌트 릴리스 일정 ● 298
애자일 기차에서 얻을 수 있는 교훈 ● 301
애자일 릴리스 기차의 원칙 ● 302
애자일 릴리스 기차 ● 303
기차는 동기화돼야 한다 ● 303
비전, 주제, 유스케이스에 의해 동작하는 기차 ● 304
기차가 궤도를 이탈하지 않고 일정을 준수하도록 유지하기 ● 305
진행 측정과 속도 ● 305
시스템 수준 패턴 관찰하기 ● 306
상호 의존성 관리하기 ● 307
릴리스 기차 회고 ● 308
19장 분산 개발의 관리 ● 309
애자일 확장 시 모든 개발은 분산 개발이다 ● 309
[사례 연구 1] 핑 아이덴티티 사: 흩어져 있는 정의/빌드/테스트 컴포넌트팀 ● 311
핑 아이덴티티 사의 배경 ● 311
교훈 ● 314
[사례 연구 2] BMC 소프트웨어 : 분산도가 높은 대규모 엔터프라이즈에서의 애자일 ● 315
배경 지식 ● 315
IMD에서의 애자일 전환 ● 316
결과 ● 316
파일럿에서 프로그램으로: 엔터프라이즈급 애자일 도입 ● 317
교훈: 큰 조직 간에 걸친 애자일 활동 확장 ● 319
다음 단계: 애자일 성공 첫해, 그 후 ● 321
의사소통의 강화 ● 323
직접 교류 지원 ● 323
의사소통 도구 ● 324
엔터프라이즈 애자일을 위한 도구 ● 326
소스코드 관리 ● 329
네트워크 인프라 ● 329
초기 반복에서 인프라의 구현 ● 330
정리 ● 331
20장 고객과 조직에 미치는 영향 ● 333
애자일 도입을 통해 영업과 마케팅에 돌아가는 이익 ● 334
제품 마케팅/제품 관리에 대한 효과 ● 336
짧고 빈번한 주기의 릴리스 ● 337
짧고 빈번한 주기의 릴리스에 대한 도전 ● 338
애자일 릴리스 프로세스 최적화하기 ● 339
릴리스 선택사항 1: 애자일 무시하기 ● 340
릴리스 선택사항 2: 애자일 따라가기 ● 341
릴리스 선택사항 3: 외부 릴리스로부터 개발 릴리스를 분리해 최적화하기 ● 342
영업과 마케팅 관리자가 제기하는 애자일에 관한 오해 ● 347
21장 조직 변화 ● 351
개요 ● 351
왜 애자일은 조직적인 변화가 있어야 하는가? ● 352
1. 경험적 프로세스 채택과 계획 기반 프로세스 채택 비교 ● 353
2. 스크럼 정신: 장애물을 제거하고, 팀은 맡은 바 임무를 다할 것이다 ● 354
ba: 스크럼의 핵심 ● 355
3. 방임: 덜 예측 가능하지만 더 좋은 결과물 ● 356
스크럼과 애자일 준비하기 ● 358
소프트웨어 프로세스와 조직 모두 ‘스크럼 짜기’ ● 359
경영진은 조직 변화를 위한 스크럼 마스터 ● 359
주의사항: 변화는 많은 노력을 필요로 한다 ● 360
소프트웨어 생산성에 대한 장애 요소 제거하기 ● 361
경영진을 위한 애자일 모델 ● 363
애자일 적용의 지원 ● 365
어떤 것을 권고할지 연습하기: 경영진 활동으로서의 애자일 ● 366
대규모 조직에서 스크럼/애자일 수행 ● 368
개괄, 평가, 파일럿 준비 ● 369
파일럿 프로젝트 ● 371
조직 내 확장 ● 372
효과 달성 ● 373
측정, 평가, 조정 ● 374
확장, 성공 ● 375
정리 ● 375
22장 비즈니스 성과 측정 ● 377
애자일 평가: 주요 차이점 ● 378
팀 성과 측정 ● 378
애자일 프로젝트 측정 지표 ● 379
애자일 프로세스 측정 지표 ● 379
결과 분석 ● 383
‘프로세스 정책’ 측정 지표와 팀 자체 평가 ● 384
조직 생산성 확대: 균형성과기록표 접근 방법 ● 385
효율성 ● 386
품질 ● 387
가치 조달 ● 388
애질리티 ● 388
확장 단계에서의 애자일 측정 지표 ● 389
1단계: BSC 항목 수치화 ● 389
2단계: 알파벳 점수로 변환 ● 390
3단계: 제품 라인, 비즈니스 부서, 대기업에 대한 결산 ● 391
결론: 애자일 확대 적용 ● 393
참고문헌 ● 397
베타리더 한마디 ● 415
|
|
|
 |
딘 레핑웰
유명한 소프트웨어 개발방법론자이자 저자이며, 소프트웨어팀이 목적을 성취하는 데 도움을 주는 컨설턴트로 일하고 있다. 리퀴짓(Requisite) 사의 창립자이고 리퀴짓프로(RequisitePro)를 만들었으며, 래셔널(Rational) 사의 부회장직을 지내면서 RUP의 상용화를 이끌었다. 최근 5년간 독립적으로 활동하는 한편, 랠리 사에 소속된 컨설턴트이자 방법론자로 일하며 자신의 경험을 바탕으로 다국적 기업으로서 전 세계에 분산되어 있는 대규모 조직에 애자일 방법론을 적용하는 데 힘썼다. 이 책은 저자의 다양한 경험에서 우러나온 이야기를 담았다. 레핑웰은 『Managing Software Requirements, Second Edition: A Use Case Approach』(Addison-Wesley, 2003)의 저자이기도 하다.
[옮긴이]
제갈호준
아이오와 주립대 컴퓨터 사이언스 박사과정에 재학 중이다. 삼성전자 가전연구소 S/W Lab에서 임베디드 시스템 소프트웨어 개발을 했으며, 벤처기업에서 애플리케이션 개발을 하고 삼성 멤버십에서 활동한 경험도 있다.
이주형
현재 카이스트 소프트웨어 대학원 과정에 있으며, 삼성전자 가전사업부 SE 파트에서 선임연구원으로 재직 중이다. 주요 관심분야는 소프트웨어 테스팅, 요구공학이다.
김택구
서강대 컴퓨터학과 졸업 후 3년간 LG전자 MC 사업본부에서 소프트웨어 엔지니어로 근무했으며, 지금은 ICU-CMU의 MSE(Master of Software Engineering) 과정에 재학 중이다. 관심분야는 소프트웨어 아키텍처와 소프트웨어 프로세스다.
|
|
|
|
|
|
|
|
|
|
|
|
|
Home > 
POD(Printed On Demand)
