기본이 바로 선 나라 » Book

Bookmarks for November 9th through November 17th

정의의소 — Tue, 17 Nov 2009 05:00:49 +0000

These are my links for November 9th through November 17th:

한국 developerWorks : developerWorks Column : 지피지기 –
lovesera.com: ART of VIRTUE :: [팁] 초보자를 위한 가족 여행 계획하기 –
YUZI, in Ma Mind : 박관록씨의 Embedded 개발 vs SI 개발 구분 –
한국 developerWorks : developerWorks Column : 망년회 대신 ‘기(記)년회 –
BarCamp / BarCampSeoul4 – 못가서 넘 아쉽다.
Lim,GeunSik(invain)’s Blog world :: moblin 2.0 정리 –
[알라딘]기업을 죽이고 살리는 리더 간의 갈등 관리 – 성공 조직을 만드는 9단계 실천 전략, Monitor Group 시리즈 1 – 도 아니면 모의 흑백논리로 사람을 재단하는 대신
나름의 사연이 있겠지라는 도량으로 상대를 배려하며
타자의 입장에 서서 타자가 왜 그러한 행동과 판단을 할 수 밖에 없는지 예상하여,
대승적 결론을 이끌어내라는 것.
ForeverSave – Mac 으로 문서 작업시 버전관리까지 포함하여 자동 저장하는 방법 « Peter .WEB2 –
Mac 주소록에서 바로 전화 거는 방법 – eyebeam 소프트폰(SIP) « Peter .WEB2 –
심플하고 강력한 인터넷 가계부 – iCashHouse.co.kr – 복식 가계부.. 백업 기능만 있으면 정말 대단할 듯…

Share and Enjoy:

Bookmarks for November 1st through November 6th

정의의소 — Fri, 06 Nov 2009 04:00:56 +0000

These are my links for November 1st through November 6th:

격물치지 [格物致知] ::변화가 어려울 수 밖에 없는 이유 –
Inuit Blogged : 수원 최고 통닭 – 음… 꼭 가봐야지…
애자일 이야기 : 하향식 변화 도입에 대한 환상 – 상향식 변화를 시도하는 개선자들에게 어떻게 힘을 줄 수 있을까?
iTunes Store 인증 및 인증 해제에 관하여 – iTunes 컴퓨터 인증 해제 방법
:: 지식채널 e Podcast [returns] –
애플 태블릿은 e-Book 및 TV 시장 공략의 첫걸음 | 구루 / Guru –
MobileMe: Syncing calendar subscriptions and CalDAV calendars – 구독하는 캘린더 MobileMe와 동기화 하기. 좀 잘 만들엊 주지.. 이게 뭐니… 구글 캘린더 봐라.. 얼마나 잘 만들었니.. ㅡㅡ;
Windows7 Ultimate K 64bit 설치 가이드 for Macbook402(Early 2008) –
15 Free Guides That Really Teach You USEFUL Stuff –
환영합니다 (설문 1단계) – 설문조사… 흠.. 해 드려야져… ^^
폰 얘기밖에 안하는 블로그 :: 타사간 USIM 이동성 간단 정리 –

Share and Enjoy:

Bookmarks for October 29th through November 1st

정의의소 — Sun, 01 Nov 2009 02:00:17 +0000

These are my links for October 29th through November 1st:

MobileME 와 대안 솔루션 비교/정리 « Peter .WEB2 –
Hard-boiled Wonderland | 아웃룩, 구글 캘린더와 팜, 아이팟 터치 싱크(동기화) 하기 –
paperinz™ 구글 캘린더를 좀더 편리하게 – 알리미 프로그램 GMinder –
눈빛마음의 블랙홀 :: Google Sync와 MAC Address Book 연결하는 방법 – Google과 Mac Sync 하기
Google Sync Services – Mac과 Google Sync하기
lovesera.com: ART of VIRTUE :: [슬라이드] 행복한 개발팀을 만드는 10가지 방법 – 개발자가 주축이 되는 회사가 행복한 회사가 되는 방법을 10가지
김호의 쿨 커뮤니케이션 :: 삼성전자의 지펠 냉장고 리콜은 칭찬받아야 할까? – 고객과의 소통이 얼마나 중요한지… 그 방법이 바뀌어야 한다는 것을… 왜 모를까? 알면서 안 하는거이야? 엉? 엉? 엉?
InfoQ: Agile Project Metrics – 회사에서 애자일을 적용시키기 위해서 가장 필요한 부분… Metrics… 근데 아직 멀었다.
그냥 믿고 하면 안 될까용?
Reading (Agile Coach Squared) – 꼭 참석하고 싶었지만… 상황이 이러니 참석을 못하고… 그냥 책이나 읽어봐야겠다.. 안 읽어본 책이 꽤 되는구나…
IBM – Erich Gamma 와 함께 여는 개발자 세상 세미나 – Erich Gamma 인터뷰 – 한국 – 에릭감타 인터뷰… 협업… 정말 잘 하고 싶다.
Playing For Change | Peace Through Music – 한국에서도 꼭 공연했으면 좋겠다.

Share and Enjoy:

Bookmarks for October 15th from 14:06 to 14:06

정의의소 — Thu, 15 Oct 2009 05:00:08 +0000

These are my links for October 15th from 14:06 to 14:06:

한국 developerWorks : developerWorks Column : 교육과 애자일, Part 2: 변화에 대한 책임 –

Share and Enjoy:

Bookmarks for October 14th through October 15th

정의의소 — Thu, 15 Oct 2009 02:00:44 +0000

These are my links for October 14th through October 15th:

Visual Understanding Environment – 무료 컨셉맵 툴… 괜찮은 것 같다.
Sync, Play & Send to BlackBerry, PSP, iPod, iPhone with doubleTwist – 아이튠즈의 대항마인가? 향후 법적공방도 재미있을 듯
빛을 담고 세상 넓히기 » Blog Archive » Daum 제주의 ‘캐빈 문화’ 소개 –
REST – 위키백과, 우리 모두의 백과사전 – REST (Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다.
RtcSdk20 < Main < TWiki – Integrating and Extending Rational Team Concert 2.0 (the SDK)
아… 이걸로 만들고 싶은 거 참 많은데…
Artotems iFrame in iWeb – iWeb으로 만든 녀셕을 Wordpress에 넣기 위해서는 iFrame으로 만들어야한다. 야호~
www.iWebFAQ.com – iWeb에 관한 많은 팁을 얻을 수 있다.
[알라딘]4시간 – 4시간이면 충분하지 암.. 그렇고 말고… ㅡㅡ;
함께하는 세상, 하니TV – 김제동 '사람이 사람에게'
"상식이 통하는 세상" 나의 가치관인 "기본을 지키자", "기본이 바로 선 나라"와 일맥상통? 한다. ㅎㅎㅎ
구글 웨이브 단축키 정리 , 한국 구글 웨이브 사용자 리스트 | 구루 / Guru –

Share and Enjoy:

Bookmarks for September 26th through September 30th

정의의소 — Tue, 29 Sep 2009 15:00:16 +0000

These are my links for September 26th through September 30th:

IBM에는 까마귀 둥지가 있다 – "함께 하면 커진다."
함께 하기 위해서는 서로를 위하는 마음, 원활한 커뮤니케이션이 필수적이다.
그 많던 위험 신호, 왜 나만 몰랐지? – “인간은 때때로 진실의 돌부리에 걸려 넘어진다. 하지만 대부분의 사람들은 아무 일도 없었던 듯 허둥지둥 사라져버린다.
코칭, 멘토링을 연습하는 모임 – xper | Google 그룹스 –
페르소나를 사용한 기획을 회사에서 적용해 보신 분께 조언을 구합니다. – xper | Google 그룹스 –
User Experience Design :: [ASK] 간단한 페르소나 만들기 (Making Rapid Persona) –
[알라딘]이너게임 – 배우며 즐겁게 일하는 법 –
[알라딘]성과 향상을 위한 코칭 리더십 – '코칭'은 리더십을 발휘할 수 있는 최고의 수단이며 실제 경영활동과 조직 운영에서 획기적인 성과를 낸다. 동기를 부여하는 의사소통법부터 목표달성률을 높이는 질문법, 성과를 향상시키는 4단계 GROW 프로세스까지 개인, 팀, 조직에서 최상의 결과를 이끌어내는 명쾌하고 실질적인 코칭 기술 22가지를 실었다.
Snow Leopard Native NTFS Read/Write Support – 스노우 레퍼드에서 자체적으로 NTFS볼륨에 읽고 쓰기가 가능해졌다.
한글에 관한 애플과 삼성의 관점 – 부끄럽다.
Extremely Agile – 코드 관리에 관한 재미있는 외국 사례 – 주석에 대한 평가로 코드를 관리하는 예…

Share and Enjoy:

Bookmarks for September 17th through September 25th

정의의소 — Fri, 25 Sep 2009 03:01:26 +0000

These are my links for September 17th through September 25th:

Agile2009 content on InfoQ – 차근 차근 살펴보아야겠다. 다녀오신 분들의 리뷰와 함께…
실천가를 위한 실용주의 프로젝트 관리 7WEEKS – Daum 책 – 개발자에서 관리자로 올라가는 사람들을 위해 쓰여진 책
Project Coin: Final Update List for JDK 7 | Java.net – 코딩에서 멀어져 있는 사이.. JDK가 7까지 갔구나… 으흐흐
ProjectGames/TheKanbanGameEn – やっとむのサイト – 칸반게임을 다운받아서 사용할 수 있다.
The Galaxy: Woo-Gon’s Blog – Xper 정기모임 – Agile 2009 Conference 공유회를 마쳤습니다. – 아흐… 부러움이 더 컸던 공유 모임… 칸반 게임으로 팀에 뭔가 활력소?를 함 줘 봐야겠다. ㅋㅋ
아이엠그라운드 | [column] 한국은 IT강국인가? – 구구절절 올은 말만 하셨다. 역시 기득권 세력들이 지배를 하면 단점이 너무 많다. 작은 장점으로 큰 단점/잘못하는 걸 가려버리지만…
InfoQ: Burndown Analysis for Managing Productivity & Schedules –
시민광장 > 시민토론방 > “역사의 밀물이 들면 진보개혁의 모든 배들이 함께 떠오를 것” –
PredefinedProcessTemplateComparison < Main < TWiki – Eclipse Way, Scrum, OpenUP template 간의 비교
Iphone Paper Dock / Stand on Vimeo – 두꺼운 종이를 어디서 구한담… ㅋㅋ 마분지라도 하나 사러 가야겠다…
맥의 워런티 확인하기 – 워런티가 얼마남았는지 , 언제까지 AppleCare를 사야할 지 궁금하다면 지금 바로 가자. 라잇 나우~
Jazz Community Site – Jazz Team Blog » OSLC and Rational Team Concert –
맥박 회고 – Google 문서도구 – 주기적으로 하는 일 공유하기
Wibiya | Homepage – 블로그에 툴바를 달 수 있다.

Share and Enjoy:

소프트웨어 테스팅 법칙 293가지

정의의소 — Mon, 05 Nov 2007 09:52:15 +0000

팀에 후배가 들어오면 꼭 한 번 읽어 보라고 하는 책 중에 한 권입니다.

이론적인 것을 공부해야한다는 부담담 대신에 가볍게 그리고 테스트가 무엇이고 테스터는 어떻게 해야하는지에 대해서 간략하게 이해할 수 있는 책인 것 같습니다.

아래 제목만 보시고 흥미 있으시면 책을 읽어 보시고 아니면 그정도는 아니다 싶으시면 dejavu_blog에 추가로 요약된 글을 보시면 좋을 것 같습니다.

근데 내 책은 어디갔지? 작년 신입 사원인가? 재작년 신입사원한테 빌려 준 것 같은데… ㅡㅡ;

제1장 테스터의 역할

법칙 1 테스터는 프로젝트의 전조등이다. (가장 좋아하는 말…^^)
법칙 2 임무에 따라 행동이 결정된다.
법칙 3 테스터는 많은 고객들에게 서비스를 제공한다.
법칙 4 고객이 가치 있다고 생각하는 “버그”를 발견하라.
법칙 5 중요한 버그를 신속하게 찾아내라.
법칙 6 프로그래머와 함께 진행하라.법칙 7 모든 것에 의문을 가져라. 그러나 밖으로 크게 드러내지는 마라.
법칙 8 테스터가 실패에 초점을 맞추면 고객은 성공에 초점을 맞출 수 있다.
법칙 9 모든 버그를 찾아낼 수는 없다.
법칙 10 “완전히” 테스트한다는 말을 조심하라.
법칙 11 테스트를 통해서 품질을 보장할 수는 없다.
법칙 12 문지기가 되지는 마라!
법칙 13 테스트에서 “내 업무가 아니야”의 논리를 조심하라.
법칙 14 프로세스 개선 그룹이 되는 것을 조심하라.
법칙 15 테스트를 잘 수행하기 위하여 필요한 항목들을 모든 사람들이 이해할 것이라고 기대하지 마라.

제2장 테스터의 사고방식

법칙 16 테스트는 응용 인식론이다.
법칙 17 인식론을 배우면 테스트를 잘 수행할 수 있다.
법칙 18 테스트는 인지심리학에 바탕을 둔다.
법칙 19 테스트는 당신의 머리 속에 있다.
법칙 20 테스트에는 원하는 결과와 실제 결과의 단순 비교가 아닌 추론이 필요하다.
법칙 21 기술적, 창조적, 비판적, 실질적 사고를 하는 사람이 뛰어난 테스터이다.
법칙 22 블랙박스 테스트는 알지 못함을 기반으로 테스트를 실행하는 방법이다.
법칙 23 테스터는 여행객 이상이다.
법칙 24 모든 테스트는 질문에 대한 대답을 찾는 과정이다.
법칙 25 모든 테스트는 모델을 기반으로 수행된다.
법칙 26 육감은 좋은 출발점이나 결론은 형편없다.
법칙 27 반드시 직접 테스트해보아야 한다.
법칙 28 답사에는 다양한 사고가 필요하다.
법칙 29 판독을 위하여 가정적 귀납법을 이용하라.
법칙 30 제품을 평가할 때 추측과 반박의 논리를 사용하라.
법칙 31 요구조건은 중요한 사람에게 품질과 조건이다.
법칙 32 회의, 추론, 참조를 통해 요구사항을 알아내라.
법칙 33 명시적인 명세서뿐만 아니라 암묵적인 명세서도 사용하라.
법칙 34 “동작한다”는 말은 사실 적절한 수준으로 특정 요구조건을 만족하는 것처럼 보인다라는 의미이다.
법칙 35 결국 우리가 가지는 모든 것은 제품에 대한 인상이다.
법칙 36 ‘테스트’와 ‘테스트하다’를 혼동하지 마라.
법칙 37 복잡한 제품을 테스트할 경우: 시도해보고 그만두기
법칙 38 테스트에 대한 아이디어를 신속하게 떠올리기 위하여 시행착오법을 사용하라.
법칙 39 편향성을 피할 수는 없지만 관리할 수는 있다.
법칙 40 자신이 멍청하다는 사실을 알고 있다면 실제로 멍청한 짓을 잘하지 않는다.
법칙 41 버그를 놓쳤을 때, 버그가 의외의 것이라서 놓쳤는지 아니면 단순히 전략의 자연스러운 결과였는지를 확인하라.
법칙 42 혼란스러움도 테스트 도구이다.
법칙 43 참신한 시각이 오류를 발견한다.
법칙 44 이해하지 못한 채 절차를 따라하지 마라.
법칙 45 테스트 절차를 작성할 때 “1287”을 피하라.
법칙 46 테스트 과정에서 중요한 성과 중 하나는 날로 나아져 가는 영리한 테스터이다.
법칙 47 다시 창안하지 못한다면 테스트를 자유로이 구사할 수 없다.

제3장 테스트 기법

법칙 48 테스트는 테스터, 범위, 잠재적 문제, 행위, 평가에 중점을 두는 기법들로 구분할 수 있다.
법칙 49 누가 테스트를 수행하는가에 중점을 둔 사람 중심 기법
법칙 50 무엇을 테스트하는가에 중점을 두는 범위 기반 기법
법칙 51 왜 테스트를 하는가(테스트에 대한 위험)에 중점을 둔 문제 중심 기법
법칙 52 어떻게 테스트를 수행하는가에 중점을 둔 행위 기반 기법
법칙 53 테스트를 통과했는지의 여부를 어떻게 알 것인가에 중점을 두는 평가 기반 기법
법칙 54 생각하는 방식에 따라 기법이 분류된다.

제4장 버그 보고

법칙 55 버그 보고서의 질이 곧 테스터의 능력을 말해준다.
법칙 56 버그를 보고해야 해당 버그가 고쳐진다.
법칙 57 버그 보고서를 효과적인 세일즈 도구로 만들어라.
법칙 58 버그 보고서는 당신을 대표하는 것이다.
법칙 59 시간을 들여서 버그 보고서의 가치를 높여라.
법칙 60 이해 당사자도 버그를 보고할 수 있다.
법칙 61 다른 사람이 작성한 버그 보고서를 옮겨 적을 때에는 조심하라.
법칙 62 품질 격차도 버그로 보고하라.
법칙 63 몇몇 이해 당사자들은 버그를 보고할 수 없다. 사람이다.
법칙 64 버그가 쟁점이 될 경우, 이 버그 때문에 영향을 받게 될 이해 당사자의 관심을 이끌어내라.
법칙 65 프로그래머의 성능을 모니터하기 위하여 버그 추적 시스템을 절대로 사용하지 마라.
법칙 66 테스터의 성능을 모니터하기 위하여 버그 추적 시스템을 사용하지 마라.
법칙 67 결함은 즉시 보고하라.
법칙 68 명백한 버그가 이미 보고되었을 것이라고 추측하지 마라.
법칙 69 설계 오류를 보고하라.
법칙 70 극단적으로 보이는 버그들이 보안상 잠재적인 취약점이 된다.
법칙 71 드문 경우를 드물게 만들어라.
법칙 72 사소한 버그일지라도 보고해서 고쳐야 할 가치를 가진다.
법칙 73 심각도와 우선순위의 차이를 명확히 이해하라.
법칙 74 실패는 오류의 현상이지, 오류 그 자체는 아니다.
법칙 75 따라하기 테스트를 통해 사소한 오류를 발견하라.
법칙 76 재현 불가능한 오류를 항상 보고하라: 이 오류는 시한폭탄이 될 수 있다.
법칙 77 재현되지 않는 버그도 재현된다.
법칙 78 버그 보고서의 처리 비용을 생각하라.
법칙 79 도구나 환경에 관한 버그는 특별히 취급하라.
법칙 80 프로토타입이나 초기의 개인적인 버전에 대한 버그는 보고하기 전에 물어보라.
법칙 81 버그 보고서를 중복 작성하면서 스스로 문제를 고칠 수도 있다.
법칙 82 모든 버그는 보고되어야 할 가치를 지니고 있다.
법칙 83 요약 부분은 버그 보고서에서 가장 중요한 부분이다.
법칙 84 버그를 과장하지 마라.
법칙 85 문제는 명확하게 보고하되, 해결하려고 하지 마라.
법칙 86 보고서의 어조를 조심하라.
법칙 87 지치거나 까다로운 사람조차도 쉽게 읽을 수 있도록 가독성이 뛰어난 보고서를 작성하라.
법칙 88 보고서 작성 기술을 향상시켜라.
법칙 89 적절한 경우에 시장/기술 지원 데이터를 사용하라.
법칙 90 각자 다른 사람의 버그 보고서를 검토하라.
법칙 91 보고서를 읽게 될 프로그래머를 만나보라.
법칙 92 버그를 프로그래머에게 보여주는 것이 가장 좋은 방법일 수도 있다.
법칙 93 프로그래머가 버그를 고쳤다고 말할 때, 여전히 버그가 있는지를 확인하라.
법칙 94 버그 수정은 바로바로 점검하라.
법칙 95 버그가 제대로 고쳐지지 않았다면 프로그래머와 함께 이야기를 나눠보라.
법칙 96 버그 보고서는 테스트에 의해 마감되어야 한다.
법칙 97 모든 버그를 수정해야 한다고 주장하지 마라.
법칙 98 보류된 버그가 사라지도록 내버려두지 마라.
법칙 99 테스트 관성이 버그 보류의 원인이 되어서는 안 된다.
법칙 100 버그 보류에 대해서는 바로 이의를 제기하라.
법칙 101 싸우기로 했다면 이겨라.

제5장 테스트 자동화

법칙 102 테스트에 드는 비용을 몇 푼 아끼기보다는 개발 프로세스의 속도를 높여라.
법칙 103 동일한 테스트를 반복하기보다는 더 넓은 범위를 테스트하라.
법칙 104 상황에 적절한 자동화 전략을 선택하라.
법칙 105 100% 자동화를 지시하지 마라.
법칙 106 테스트 도구는 전략이 아니다.
법칙 107 뒤죽박죽일 때에는 자동화를 하지 마라.
법칙 108 수동 테스트와 자동 테스트를 동일시하지 마라.
법칙 109 ‘얼마나 자주 실행하는가’라는 기준으로 테스트의 가치를 평가하지 마라.
법칙 110 자동화된 회귀 테스트를 통해 발견할 수 있는 버그의 개수는 적다.
법칙 111 테스트를 자동화할 때에는 발견하지 못하는 버그가 무엇인지를 고려하라.
법칙 112 잘못된 자동화의 문제점은 아무도 알아차리지 못한다는 사실이다.
법칙 113 반복 오류를 잡아라.
법칙 114 테스트 도구도 버그가 있다.
법칙 115 사용자 인터페이스는 변경된다.
법칙 116 호환성, 친밀성, 서비스에 따라 GUI 테스트 도구를 선택하라.
법칙 117 자동화된 회귀 테스트들은 사라진다.
법칙 118 테스트 자동화는 소프트웨어 개발 프로세스이다.
법칙 119 테스트 자동화는 중요한 투자이다.
법칙 120 테스트 자동화 프로젝트에는 프로그래밍, 테스트, 프로젝트 관리에 관한 기술이 필요하다.
법칙 121 파일럿 프로젝트를 통해 실행 가능성을 증명하라.
법칙 122 테스터와 프로그래머에게 자동화된 프로젝트에 대한 특권을 부여하라.
법칙 123 재검토가 용이하도록 자동화된 테스트를 설계하라.
법칙 124 자동화된 테스트를 허술하게 설계하지 마라.
법칙 125 테스트 스크립트에 복잡한 논리를 넣지 마라.
법칙 126 단순히 코드를 반복하지 않기 위하여 테스트 라이브러리를 만들지 마라.
법칙 127 데이터 중심 테스트 자동화는 많은 변종 테스트의 실행을 용이하게 도와준다.
법칙 128 키워드 중심 테스트 자동화는 프로그래머가 아닌 사람이 테스트를 쉽게 생성할 수 있도록 도와준다.
법칙 129 자동화 기법을 사용하여 테스트 입력을 생성하라.
법칙 130 테스트 생성과 테스트 실행을 구분하라.
법칙 131 표준 스크립트 언어를 사용하라.
법칙 132 프로그래밍 인터페이스를 사용하여 테스트를 자동화하라.
법칙 133 유닛 테스트 스위트를 개발하라.
법칙 134 테스트를 이해하지 못하는 사람에게 자동화를 맡기지 마라.
법칙 135 테스트를 존중하지 않는 자동화 담당자는 피하라.
법칙 136 테스트 용이성이 자동화보다 훨씬 더 나은 투자인 경우가 자주 있다.
법칙 137 테스트 용이성이란 가시성과 제어성을 의미한다.
법칙 138 초기에 테스트 자동화를 시작하라.
법칙 139 중앙 집중화된 팀에게 분명한 권한을 부여하라.
법칙 140 바로 효과를 볼 수 있는 것부터 자동화하라.
법칙 141 흔히들 알고 있는 것보다 훨씬 많은 테스트 도구들이 존재한다.

제6장 테스트 문서화

법칙 142 솔루션을 효과적으로 적용하려면 문제를 명확히 이해해야 한다.
법칙 143 테스트 문서 템플릿을 사용하지 마라: 템플릿이 필요하지 않다면 무용지물에 불과하다.
법칙 144 테스트 문서 템플릿을 사용하라: 템플릿은 일관성 있는 의사전달을 촉진시킨다.
법칙 145 IEEE 829 표준안을 사용하여 테스트 문서를 작성하라.
법칙 146 IEEE 829 표준안을 사용하지 마라.
법칙 147 요구조건을 분석한 다음 어떤 제품을 만들지 결정하라: 이 말은 소프트웨어와 마찬가지로 문서화에도 적용된다.
법칙 148 테스트 문서 요구조건을 분석하기 위하여 다음 사항을 물어보라.
법칙 149 핵심적인 문서 요구사항을 세 부분 이하로 한 문장씩 요약하라.

제7장 프로그래머와의 상호관계

법칙 150 프로그래머들의 사고방식을 이해하라.
법칙 151 프로그래머와 신뢰를 쌓아라.
법칙 152 서비스를 제공하라.
법칙 153 성실하고 능력을 갖추어야 존중을 받게 된다.
법칙 154 사람이 아닌 작업에 집중하라.
법칙 155 프로그래머들은 자신의 일에 대해 이야기하는 것을 좋아한다. 궁금한 점이 있으면 직접 물어보라.
법칙 156 프로그래머는 테스트를 도와주고 싶어한다.

제8장 테스트 프로젝트 관리

법칙 157 서비스 문화를 만들어라.
법칙 158 통제 문화를 만들지 마라.
법칙 159 임금님 귀(?)처럼 다양한 의견을 들어라.
법칙 160 개발 프로젝트가 아니라 테스트 서비스를 제공하는 하위 프로젝트를 관리하는 것이다.
법칙 161 모든 프로젝트는 진화한다. 잘 진행된 프로젝트는 진화도 잘한다.
법칙 162 항상 뒤늦은 변경사항이 존재한다.
법칙 163 프로젝트에는 기능, 신뢰성, 시간, 돈 사이의 트레이드오프가 존재한다.
법칙 164 프로젝트 관리자가 프로젝트의 수명주기를 선택하도록 하라.
법칙 165 폭포수 수명주기 모델은 시간에 대한 신뢰성이 부족하다.
법칙 166 진화 수명주기 모델은 시간에 대한 기능이 부족하다.
법칙 167 개발 초기에 프로젝트에 대한 자원을 할당하라.
법칙 168 계약에 따른 개발과 시장에 대한 개발은 다르다.
법칙 169 테스터 용이성 기능을 요구하라.
법칙 170 빌드에 대한 일정을 협의하라.
법칙 171 빌드를 전달하기 전에 프로그래머가 한 일(그리고 하지 않은 일)을 이해하라.
법칙 172 빌드를 준비하라.
법칙 173 때로는 빌드에 대한 테스트를 거부해야 한다.
법칙 174 빌드를 평가하기 위하여 연기 테스트를 사용하라.
법칙 175 때로는 테스트를 멈추고, 개발 주기를 수정한 다음 소프트웨어를 다시 설계하는 것이 올바른 결정이다.
법칙 176 실제로 사용되는 개발 사례에 프로세스를 적용하라.
법칙 177 프로젝트 문서는 재미있는 소설이다: 유용하지만 충분하지는 않다. – Brian Marick
법칙 178 사용하지 않을 항목은 요청하지 마라.
법칙 179 다른 정보 출처도 이용하라.
법칙 180 프로젝트 관리자에게 구성 관리 문제점을 보고하라.
법칙 181 프로그래머는 태풍과 같다.
법칙 182 테스트 계획을 잘 세우면 뒤늦게 변경하기도 쉽다.
법칙 183 인위적인 결과물을 다른 사람에게 전달할 때마다 테스트를 수행해야 한다.
법칙 184 충분히 많은 테스트를 수행했음을 판단하는 공식은 존재하지 않는다.
법칙 185 충분한 테스트란 고객이 좋은 판단을 내릴 수 있도록 충분한 정보를 제공한다는 의미이다.
법칙 186 단순히 테스트를 두 번 수행하기 위한 예산을 책정하지 마라.
법칙 187 작업에 대한 일정 계획을 세울 때 각 작업에 필요한 소요시간을 평가하라.
법칙 188 작업을 담당할 사람이 직접 소요시간을 이야기하도록 하라.
법칙 189 테스터와 다른 개발자 사이의 적절한 비율은 없다.
법칙 190 작업에 실패하였다면 담당 작업을 서로 바꾸거나 사람을 교체하라.
법칙 191 테스터를 기능별로 순환시켜라.
법칙 192 짝을 이뤄 테스트를 하라.
법칙 193 프로젝트에 버그 헌터를 지명하라.
법칙 194 테스트 세션, 특히 답사 방식의 테스트 세션을 계획하라.
법칙 195 테스트를 세션 단위로 수행하라.
법칙 196 테스터의 작업을 방해하는 중단요소를 밝히기 위하여 행동 기록을 사용하라.
법칙 197 정기 상태 보고서는 강력한 도구이다.
법칙 198 부사장이 통계 데이터를 가지는 경우가 가장 위험하다.
법칙 199 버그 개수라는 관점에서 프로젝트의 진척도를 측정하지 않도록 주의하라.
법칙 200 더 많은 독립 기준을 사용할수록 더 많은 것을 알게 된다.
법칙 201 다차원 상태를 보고하기 위하여 균형 잡힌 점수 카드를 사용하라.
법칙 202 주간 상태 보고서는 다음과 같이 작성하라.
법칙 203 프로젝트 상황판은 현재 상태를 알려주는 또다른 유용한 방법이다.
법칙 204 마일스톤(milestone)이 잘 정의되어있다면 마일스톤 보고서가 유용하다.
법칙 205 제품 출시에 찬성한다는 서명을 하지 마라.
법칙 206 만족할 정도로 테스트를 해본 제품에 대해서만 서명하라.
법칙 207 출시 보고서에는 제품에 대한 자신의 의견이 아니라 테스트 작업 결과에 대해 적어야 한다.
법칙 208 최종 출시 보고서에는 수정되지 않은 버그의 목록도 함께 적어두라.
법칙 209 유익한 출시 보고서에는 10가지 단점이 들어있어야 한다.

제9장 테스트 그룹 관리

법칙 210 개성이 사라지면 직장이 무기력해진다.
법칙 211 팀을 경영진처럼 대하라.
법칙 212 팀원들이 작성한 버그 보고서를 읽어라.
법칙 213 경영자의 입장에서 팀을 평가하라.
법칙 214 어떻게 진행되고 있는지 정말 알고싶다면 팀원과 함께 테스트를 수행하라.
법칙 215 여러 개의 프로젝트를 효율적으로 담당하도록 요구하지 마라.
법칙 216 테스트팀의 영역 전문 지식을 만들어라.
법칙 217 테스트 팀원을 관련 기술 전문가로 만들어라.
법칙 218 기술을 적극적으로 개발하라.
법칙 219 기술 지원 기록을 재검토하라.
법칙 220 새로운 테스터가 성공하도록 도와주어라.
법칙 221 새로운 테스터에게는 소프트웨어에 대한 문서를 점검하도록 하라.
법칙 222 새로운 테스터가 제품에 익숙해지도록 긍정적 테스트를 수행하라.
법칙 223 초보 테스터에게는 새로운 버그 보고서를 작성하기 전에 예전 버그 보고서를 수정하도록 하라.
법칙 224 새로운 테스터가 새로운 버그를 테스트하기 전에 예전 버그를 다시 테스트하도록 하라.
법칙 225 초보 테스터에게 거의 종료된 프로젝트를 맡기지 마라.
법칙 226 팀원의 의욕은 중요한 자산이다.
법칙 227 자신을 혹사시키지 마라.
법칙 228 팀원들을 초과 근무로 혹사시키지 마라.
법칙 229 팀원들을 대우해 주어라.
법칙 230 교육 기회를 만들어라.
법칙 231 당신이 내리는 채용 결정은 가장 중요한 판단이다.
법칙 232 채용 기간동안 숨쉴 여유를 제공하는 외주업체를 사용하라.
법칙 233 다른 그룹에서 거절된 사람을 테스트팀에 받아들이지 마라.
법칙 234 그룹에서 해야 하는 업무와 그 업무를 수행하는 데 필요한 기술의 관점에서 계획을 수립하라.
법칙 235 다양한 배경 지식을 가진 사람들로 테스트팀을 구성하라.
법칙 236 기회가 닿은 지원자를 채용하라.
법칙 237 교감에 의해 채용하라.
법칙 238 자신의 업무를 좋아하는 사람을 채용하라.
법칙 239 성실한 사람을 채용하라.
법칙 240 면접시 당신이 왜 그를 테스터로 채용해야 하는지, 테스터에게 그를 채용해야만 하는 고유한 기술을 보여달라고 하라.
법칙 241 면접시 비공식 적성 테스트의 한 방법으로 직장에서 실제로 사용할 기술을 보여달라고 요청하라.
법칙 242 채용시 작업 예제를 요구하라.
법칙 243 마음먹었다면 바로 채용하라.
법칙 244 채용 약속을 서면으로 받아서 잘 보관하라.

제10장 소프트웨어 테스트 분야에서의 경력 관리

법칙 245 진로를 선택하고, 그 방향에 매진하라.
법칙 246 테스터의 연봉이 프로그래머의 연봉보다 많을 수 있다.
법칙 247 진로 변경을 편안하게 느끼고, 다른 직종을 추구하라.
법칙 248 어떤 진로를 택하든지 적극적으로 추구하라.
법칙 249 경력을 소프트웨어 테스팅 이외의 영역까지 확장하라.
법칙 250 현재의 회사를 벗어나는 경력을 확장하라.
법칙 251 컨퍼런스는 이야기를 나누기 위한 것이다.
법칙 252 다른 많은 회사들도 지금 회사와 별반 차이가 없다.
법칙 253 현 직장이 마음에 들지 않는다면 다른 직장을 찾아보아라.
법칙 254 현 직장에서 승부를 걸어야 할(그리고 잃을) 경우에 대비하라.
법칙 255 일하고 싶은 회사의 목록을 작성하여 관리하라.
법칙 256 포트폴리오를 작성하라.
법칙 257 이력서를 세일즈 도구로 사용하라.
법칙 258 내부 추천제도를 이용하라.
법칙 259 급여 데이터를 알아보라.
법칙 260 구직 광고를 보고 지원하는 것이라면, 광고 내용에 대한 답변을 준비하라.
법칙 261 인터뷰 기회를 이용하라.
법칙 262 마음에 드는 회사라면 그 회사에 대한 정보를 습득하라.
법칙 263 직장 인터뷰 중 질문을 하라.
법칙 264 직급을 협상하라.
법칙 265 인사부에 대해 조심하라.
법칙 266 펄(Perl)을 배워라.
법칙 267 자바나 C++를 배워라.
법칙 268 테스트 도구의 데모 버전을 다운로드 받아서 사용해보라.
법칙 269 글 쓰기 능력을 향상시켜라.
법칙 270 대중 앞에서 말하는 기술을 향상시켜라.
법칙 271 자격증을 취득하는 것도 고려하라.
법칙 272 단 2주만에 검은 띠를 딸 수 있다면, 싸움을 피하라.
법칙 273 CSTE 자격증을 취득하라.

제11장 테스트 전략 계획

법칙 274 테스트 전략에 대한 세 가지 기본 질문은 쓰는가?, 얼마나 많이?이다.
법칙 275 가능한 테스트 전략은 매우 많다.
법칙 276 테스트 계획은 실제 테스트 프로세스를 이끌어줄 아이디어의 모음이다.
법칙 277 자신의 상황에 적절한 테스트 계획을 수립하라.
법칙 278 전략, 지원 방안, 그리고 작업 결과물에 대한 결정을 알 수 있는 테스트 계획을 수립하라.
법칙 279 지원 방안과 작업 결과로 인해 전략이 가려지지 않도록 하라.
법칙 280 테스트 사례에 대한 거짓말
법칙 281 테스트 전략은 테스트보다 더 큰 것이다.
법칙 282 테스트 전략은 테스트를 설명한다.
법칙 283 다양한 임시 방법을 적용하라.
법칙 284 강력한 테스트 전략의 원 재료를 만들어라.
법칙 285 프로젝트에 대한 첫 번째 전략은 항상 잘못된 전략이다.
법칙 286 프로젝트의 각 단계마다 스스로에게 “현재 무엇을 테스트할 수 있으며, 어떻게 테스트할 수 있는가?”라는 질문을 던져보라.
법칙 287 프로젝트의 성숙도에 따라 테스트를 진행하라.
법칙 288 테스트 복잡성에 대한 논의를 단순화하기 위하여 테스트 수준을 사용하라.
법칙 289 그레이박스를 테스트하라.
법칙 290 이전 테스트 자료를 다시 사용할 경우 무조건적 신뢰는 위험하다.
법칙 291 두 명의 테스터가 동일한 것을 테스트한다고 해서 중복된 노력을 들이고 있는 것은 아니다.
법칙 292 제품의 위험요소 뿐만 아니라 프로젝트의 요소들에 대한 테스트 전략을 수립하라.
법칙 293 테스트 주기를 테스트 프로세스의 심장박동처럼 취급하라.

팀에 후배가 들어오면 꼭 한 번 읽어 보라고 하는 책 중에 한 권입니다.

아래 제목만 보시고 흥미 있으시면 읽어 보시고 아니면 그정도는 아니다 싶으시면 dejavu_blog에 추가로 요약된 글을 보시면 좋을 것 같습니다.

제1장 테스터의 역할

법칙 1 테스터는 프로젝트의 전조등이다.
법칙 2 임무에 따라 행동이 결정된다.
법칙 3 테스터는 많은 고객들에게 서비스를 제공한다.
법칙 4 고객이 가치 있다고 생각하는 “버그”를 발견하라.
법칙 5 중요한 버그를 신속하게 찾아내라.
법칙 6 프로그래머와 함께 진행하라.법칙 7 모든 것에 의문을 가져라. 그러나 밖으로 크게 드러내지는 마라.
법칙 8 테스터가 실패에 초점을 맞추면 고객은 성공에 초점을 맞출 수 있다.
법칙 9 모든 버그를 찾아낼 수는 없다.
법칙 10 “완전히” 테스트한다는 말을 조심하라.
법칙 11 테스트를 통해서 품질을 보장할 수는 없다.
법칙 12 문지기가 되지는 마라!
법칙 13 테스트에서 “내 업무가 아니야”의 논리를 조심하라.
법칙 14 프로세스 개선 그룹이 되는 것을 조심하라.
법칙 15 테스트를 잘 수행하기 위하여 필요한 항목들을 모든 사람들이 이해할 것이라고 기대하지 마라.

제2장 테스터의 사고방식

제3장 테스트 기법

제4장 버그 보고

제5장 테스트 자동화

제6장 테스트 문서화

제7장 프로그래머와의 상호관계

제8장 테스트 프로젝트 관리

제9장 테스트 그룹 관리

제10장 소프트웨어 테스트 분야에서의 경력 관리

제11장 테스트 전략 계획

Share and Enjoy:

Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

정의의소 — Sun, 07 Oct 2007 14:53:02 +0000

k16wire님께서 소개해 주신 “Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드“를 살펴 보고 오늘 장바구니에 담았습니다. (필요한 책 몇 권을 더 한꺼번에 주문하려고 기다리고 있습니다.)

k16wire님의 말씀처럼 책 목차만 보더라도 개발자나 프로젝트 리더에게 얼마나 필요한 지 알 수 있습니다.

[#M_목차 열기|목차 닫기| 도서목차

머리말
서문
1 서론
1.1 습관적인 탁월함
1.2 실용주의적 관점
1.3 로드맵
1.4 앞으로 나아가기
1.5 이 책을 어떻게 읽어야 하나?

2 도구와 인프라스트럭처
[1]. 모래 상자(Sandbox) 안에서 개발하기
[2]. 자산을 관리하세요
[3]. 빌드를 스트립트화하세요.
[4]. 자동으로 빌드하세요.
[5]. 이슈를 추적하세요.
[6]. 기능을 추적하세요.
[7]. 테스트 장비를 사용하세요.
[8]. 도구를 선택하는 방법
[9]. 실험하지 말아야 할 때

3 실용주의적 프로젝트 기술
[10]. 목록에 따라 일하세요.
[11]. 기술 리더
[12]. 매일 협력하고 의사소통하기
[13]. 코드를 모두 검토하세요
[14]. 코드 변경 통지 보내기
[15]. 모두 통틀어서

4 예광탄 개발
예광탄 개발
프로세스 상의 흔한 문제들
프로세스 정의하기
TBD는 어떻게 작동할까요
시스템 객체를 정의하세요
협동해서 인터페이스 정의하세요
인터페이스 스텁을 작성하세요
계층끼리 대화할 수 있게 만드세요
스텁에 기능적 코드를 채워 넣으세요
리팩토링하고 다듬으세요
간단한 사례
예광탄 개발 방법론 홍보하기
이렇게 시작하세요
이렇게 하고 있다면 제대로 하고 있는 겁니다
경고 신호

5 일반적인 문제와 해결방법
[16]. 도와주세요! 코드를 인수 받았어요.
[17]. 테스트할 수 없는 코드를 테스트하기
[18]. 기능에 문제가 계속 발생합니다.
[19]. 테스트? 우리는 더 이상 테스트를 활용하지 않습니다.
[20]. 하지만 저는 된다구요!
[21]. 코드를 통합할 때 골치 아픕니다.
[22]. 제품을 안정적으로 빌드하지 못합니다.
[23]. 고객이 불만을 표출합니다.
[24]. 불한당 개발자가 있습니다.
[25]. 관리자가 불만스러워 합니다.
[26]. 팀이 협동을 못합니다.
[27]. 핵심적인 부분에 대한 “내부의 지지”를 얻지 못합니다.
[28]. 새로운 실천방법이 도움이 안 됩니다
[29]. 자동화된 테스트가 없습니다.
[30]. 우리는 신참 개발자들이고 이끌어줄 사람이 없습니다.
[31]. “죽음의 행진” 프로젝트에 참여하고 있습니다.
[32]. 피쳐 크리프(Feature Creep) 현상이 일어납니다.
[33]. 프로젝트가 끝날 기미가 안 보입니다.

A 조언 요약
B 소스 코드 관리
C 빌드 스크립트 도구
D 지속적인 통합 시스템 (Continuous Integration System)
E 이슈 추적 소프트웨어
F 개발 방법론
G 테스트 프레임워크
H 추천 도서 목록
H.1 참고 문헌_M#]

“프로젝트에 도움이 되는 거라면 무엇이든 실험해보고 받아들이라”는 저자의 말이 최근의 저의 모습인 것 같습니다. 아직은 윗 분들이 딴지?를 걸지는 않는데… 뭔가 개선되는 것이 보이지 않으면 분명히 제지하겠지요? ㅡ,.ㅡ;

저는 Agile이나 특정 프로세스를 신봉?하거나 선호하는 것은 아닙니다. 현재 처한 모든 상황에 가장? 합리적이고 도움이 되는 것은 무엇인지를 빨리 집어 내어 실천 할 수 있는 프로세스와 환경을 꾸미는 것이 목표이자 꿈? 입니다. 그러한 문화를 만드는 일에도 앞장서고 싶습니다.

아직 공부 중이고 내공이 부족한 관계로 현재 프로젝트에 많은 개선을 이루어 내고 있지는 못하지만, 언젠가는 변화의 첫 걸음 시작했다고 자신있게 이야기 할 날을 기대하면서 내공 증진에 힘써 봅니다.

프로젝트에 도움이 되는 거라면 무엇이든 실험해보고 받아들이라는 자레드와 윌의 유연한 사고 방식은 자칫 교조주의적으로 흐르기 쉬운
특정 프로세스 선호론과는 다릅니다. 무엇이 옳고 그른지보다는 무엇이 실용주의적인지 이 책을 통해 알아보세요.
- 강컴 도서 특징 中

책의 각 섹션을 다 읽고 나면, 잠시 멈추고 5분 정도 투자해서 오늘 하는 일에 각 개념을 적용할 방법을 찾으려 애써보세요.
잊지 마세요. 애써 생각하지 않아도 나오는 가장 쉬운 해답은 ‘그건 할 수 없어’라는 말입니다. 그보단 더 노력하세요! 새
개념을 적용할 방법을 찾지 못했다면, 동료를 붙잡고 물어보세요. 자신의 눈으로 보지 못한다면, 다른 사람의 눈으로 보면 됩니다.
동료의 경험을 활용하는 법을 배우는 것은 어느 분야에서든 장인의 보증수표입니다. -본문 중에서

이것은 훌륭한
생각입니다. 하지만 최고이면서 똑똑한 사람 중에서도 정말 최고인 사람과 직접 만나기는 힘듭니다. 마틴 파울러, 켄트 벡, 그리고
실용주의 프로그래머들과 같은 사람은 우리 대부분에게 시간을 내주지 못합니다. 하지만 그 사람들의 책, 기사, 그리고
프리젠테이션은 그럴 수 있습니다. 그러니 책을 읽으세요. 한 달에 한 권이라면 그렇게 힘들진 않습니다. 하지만 거기서 멈추진
마세요. 새로운 프로그래밍 언어를 배우거나 다른 개발 프로세스를 연구해보세요. 그리고 뭔가를 배우는 중간이나 책을 읽는
와중에도, 새로운 아이디어를 지금 업무에 적용할 방법을 찾아보세요. 새 아이디어를 본업에 적용해보세요. 그렇게 하면 회사를
개선시키는 데 도움이 될 뿐만 아니라 (더 중요한 일인데) 여러분 자신 또한 개선시키게 됩니다. -본문 중에서

주변여
건과 프로세스를 분석하고 비판하면 약점을 찾아낼 수 있습니다. 어쩌면 지금 프로젝트를 개선시키는 데 도움이 될지도 모릅니다.
아니면 다음 프로젝트에서라도요. 어떻게 되든 생각하는 법을 새로 배우게 될 텐데, 여러분이 어디서 일하든 쓸모있을 겁니다.
대부분의 사람은 이런 개념을 결코 배우지 못하고, 훨씬 적은 수의 사람만 잘 해냅니다. -본문 중에서
- 알라딘 책 소개 中

최고이면서 똑똑한 사람 중에서도 정말 최고인 사람과 직접 만나기는 힘듭니다. 마틴 파울러, 켄트 벡, 그리고 실용주의
프로그래머들과 같은 사람은 우리 대부분에게 시간을 내주지 못합니다. 하지만 그 사람들의 책, 기사, 그리고 프리젠테이션은 그럴
수 있습니다. 그러니 책을 읽으세요. 한 달에 한 권이라면 그렇게 힘들진 않습니다. 하지만 거기서 멈추진 마세요. 새로운
프로그래밍 언어를 배우거나 다른 개발 프로세스를 연구해보세요. 그리고 뭔가를 배우는 중간이나 책을 읽는 와중에도, 새로운
아이디어를 지금 업무에 적용할 방법을 찾아보세요. 새 아이디어를 본업에 적용해보세요. 그렇게 하면 회사를 개선시키는 데 도움이
될 뿐만 아니라 (더 중요한 일인데) 여러분 자신 또한 개선시키게 됩니다.
- 저자의 말

Share and Enjoy:

Wikinomics -웹2.0의 경제학

정의의소 — Sun, 16 Sep 2007 15:59:04 +0000

여름 휴가 전에 저희 연구소장님께서 추천해 주신 책입니다.
휴가 때 지만이가 폐렴으로 병원에 입원해서 책을 빨리 읽을 줄 알았는데 오늘에야 다 읽었습니다.
3/2까지 읽은 후에 그 뒤로는 진도가 잘 안 나가더니 하 루에 두어 페에지 읽는 정도였습니다.
그러나 읽고 싶은 책들이 줄을 서고 있기에 오늘 서울 나들이 후에 나머지 부분을 읽었습니다.

책 후기를 적으려고 하니… 헉… 기억이 안 납니다. ㅡㅡ;
머리속에 지우개가 있는 것인지… 아니지요… 책 한 권은 한 달 넘게 읽었으니… 당연한 결과지요.

책 읽을 때는 이런 저런 느낌이 많이 들기도 하였고, 내 생각과 많은 부분이 일치 되어서 가슴이 부르르~ 떨리기도 했는데… 그런데 기억이 안 나다니… 줄 서 있는 다른 책들 때문에 후에 다시 읽기로 하고 도서 판매 사이트에 나와 있는 서평과 리뷰를 직접 타이핑(ㅡㅡ)하면서 정리해 봅니다.(Split Browser를 처음으로 제대로 사용해 봄)

정리하면서 생각난 것
- 회사 내부 프로젝트도 오픈소스처럼 오픈(회사 내부만)해서 개발하면 더 효율적이지 않을까? 물론 그런 문화부터 형성되어야 하겠지만 현재의 문화는 많이 아쉽다. 다만 현재의 개인 평가가 본인의 실적(생산)에 한정되어 있기 때문에 이런 분위기가 안 생기는 것이다.
“오픈소스와 Web2.0의 문화를 팀에 적용할 수 있도록 하나씩 정리해 나가야겠다.”

- 우리 회사는 조금? 더 다양성을 인정하고 조직이나 개발에 있어서 군대의 행진이 아닌 뮤지션의 공연과 같이 즉흥적이고 창조적인 문화(프로세스)가 형성되어야 할 것이다. 최소한 연구 개발 조직에서라도… 먼저…

출처 : 강컴닷컴

소수가 만드는 이코노믹스 시대가 저물고 대중이 만드는 위키노믹스 시대가 오고 있다

이코노믹스 vs 위키노믹스
이코노믹스(Economics) 세계에서는 몇몇 사람, 기업, 국가가 상품을 만들고 정책을 결정하며 고급 지식을 소유하고 외교
관계를 맺고 경제의 패러다임을 형성했다. 그러나 오늘날의 세계를 보라. TV뉴스의 기사거리를 창출하고 인간 유전자의 염기서열을
분석하고 좋아하는 음악을 리믹스하고 컴퓨터 소프트웨어를 설계하고 질병치료제를 개발하고 교과서를 편집하고 화장품을 개발하고 수많은
가치 있는 것들을 만들어내는 주체는 수천 명 아니 수백만 명의 사람들로 구성된 팀이다.
200년 역사의 브리태니커
백과사전의 정보량을 5년 역사의 온라인 백과사전 위키피디아(wikipedia)가 훌쩍 뛰어넘은 사실은 무엇을 의미하는가. 뛰어난
소수가 만드는 이코노믹스의 시대는 가고 보통 사람들의 집단적인 능력과 천재성(collective intelligence)이
세계를 변화시키는 위키노믹스(Wikinomics)의 시대가 왔다는 것을 의미한다.

사공이 많으면 배가 산으로 올라가는 것이 아니라, 목적지까지 더 빠르고 정확하게 갈 수 있다

이
코노믹스 세계의 원리가 소유와 권리였다면 위키노믹스 세계의 대표적인 원리는 개방과 공유이다. 정보와 기술, 계획을 손안에만 꼭꼭
쥐고 누가 알까 조심하다가 예상치 못한 문제가 발생하면 사내 회의실에서 끙끙대며 해결 방법을 고민하던 전통적인 협업은 기업의
성공과 혁신에 도움이 되지 못한다. 성공하는 기업은 세상 사람들 모두를 비즈니스 웹으로 끌어들여 정보와 기술을 공유하고 그들에게
차세대 제품과 서비스를 개발하는 데 주도적인 역할을 맡기는 대규모 협업(mass collaboration)을 도모한다. 이들은
사내 혁신만으로는 극심한 경쟁에서 살아남기 어렵다는 것과 회사 밖에 더 훌륭한 아이디어와 인재, 방법이 있음을 이미 알고 있고
대규모 협업을 통해 성장과 혁신을 지속한다.
P&G, 레고, BMW, GE, 보잉, IBM, 위키피디아,
유튜브, 마이스페이스, 인텔, 아마존, 제록스, 하얏트호텔, 리눅스, BBC, 베스트 바이 등의 글로벌 기업은 새로운 비즈니스
모델로 이미 ‘대규모 협업’을 선택했으며 이를 경쟁력의 원천으로 활용하고 있다. 이와 같은 흐름은 비단 비즈니스 세계에만
국한되지 않는다. 캘리포니아 주 교육부는 ‘캘리포니아 교과서 오픈 소스 프로젝트’를 진행하는데, 이 프로젝트는 10학년 역사
수업에 사용할 세계사 교과서를 만들기 위해 고안된 것으로 선 마이크로시스템즈나 IBM 같은 첨단 기술 기업들과 MIT 등 유수의
대학들이 참여하고 있다.
이들 시장 선도적인 기업과 조직은 새로운 경제 패러다임인 ‘위키노믹스’에 맞게 수평적이고 자체
조직적인 위키 일터(wiki workplace)를 창조하고 있으며 전 세계를 생산 시설의 무대로 본다. 그들에게 사공은 많으면
많을수록 더 좋은 자원이며 경쟁력이다. 인터넷 쇼핑몰 ‘아마존’은 이렇게 말한다. “우리가 개발자들의 손에 더 많은 데이터를
쥐어줄수록, 흥미로운 도구와 페이지 및 프로그램들이 더 많이 만들어지고, 그에 따라 아마존에 돌아오는 수익도 커집니다.”

대규모 협업 모델 7가지
1) 피어 파이오니어(Peer Pioneers) : 운영체제나 온라인 백과사전 등 비트로 구성된 제품을 생산하기 위해 오픈 소스
원리를 적용, 분산되어 있는 수천여 명의 사람들이 자발적인 참여를 통해 자본력이 막강한 대기업보다 훨씬 빠르고 혁신적인
프로젝트를 생산할 수 있다. (사례) IBM, 위키피디아 등
2) 이데아고라(Ideagoras) : 아이디어,
발명품 또는 독특하고 유능한 인재들이 모이는 세계 시장을 활용하여, P&G 같은 기업이 사내 인력의 10배가 넘는 전
세계 유능한 인재 집합을 활용할 수 있게 한다. (사례) 이노센티브, 옛투닷컴, P&G, GE 등
3) 프로슈머(Prosumers) : 위키노믹스 시대의 생산 소비자는 ‘해킹할 권리’를 천부인권으로 부여받는다. 진정한 의미의 ‘고객 중심 혁신’을 가능하게 한다. (사례) 세컨드라이프, 레고 등
4) 새로운 알렉산드리안(New Alexandrians) : 비용을 절감하고 기술의 발전을 가속화할 새로운 협업 모델을 도입한다. (사례) MIT 프로젝트 오픈웻웨어, 인텔 등
5) 참여 플랫폼(Platforms for Participation) : 제품과 기술 인프라를 개방하는 방법을 말한다. (사례) 구글, BBC, 아마존 등
6) 전 세계 생산 시설(Global Plant Floor) : 물리적인 제품을 설계 및 생산하기 위하여, 국가와 조직의 경계를 넘어 인적 자본의 힘을 활용할 수 있다. (사례) 보잉, BMW, 레고 등
7) 위키 일터(Wiki Workplace) : 갖가지 비정통적인 방식으로 조직의 계급구조를 초월하여 혁신을 증대하고 사기를 진작시킨다. (사례) 베스트 바이 등

목차
1장 위키노믹스(Wikinomics)
컴퓨터만 있으면 무엇이든 자유롭게 만들어내고 다양한 주체간의 협업이 일상생활의 운영 방식이 되는 세계, 우리는 이것을 ‘위키노믹스’라고 부른다. 그것은 협업과 참여를 특징으로 하는 새로운 시대의 은유이다.

2장 거센 폭풍우(The Perfect Storm)
산 업화 시대의 낡은 함선은 세계화의 격렬한 물살 아래로 침몰할 것이며, 네트워크로 연결된 융통성 있는 구조를 만들어 외부 아이디어와 에너지를 끌어 모으는 기업은 생존에 필요한 활력을 얻을 것이다. 또한 이러한 변화를 예상하고 혁신을 주도하는 회사는 세계화의 거센 폭풍우를 뚫고 성공적으로 나아갈 것이다.

3장 피어 파이오니어(The Peer Pioneers)
‘ 동등계층peer’는 흔히 P2P(peer to peer)라고 하는 대규모 참여 네트워크 시스템에서, 대등한 입장으로 자료를 공유하는 주체를 말한다. 리눅스와 위키피디아처럼, 이들 동등계층의 천재성과 지성을 바탕으로 놀라운 생산력을 보여주는 개척자를 ‘피어 파이오니어’라고 부른다.

4장 이데아고라(Ideagoras)
이데아고라는 생각, 아이디어를 말하는 Idea와 고대 그리스의 시민 집회장을 의미하는 Agora를 합성한 말로 지식과 지혜, 기술 등을 사고 팔 수 있는 시장을 말한다. 기업은 독특하고 유능한 인재를 찾아내 새로운 제품과 서비스를 기존의 방식보다 더 빠르고 효율적으로 발견하고 개발하기 위해 이데아고라를 활용할 수 있다.

5장 프로슈머(The Prosumers)
영리한 기업은 고객을 비즈니스 웹으로 끌어들여 차세대 제품과 서비스를 개발하는 데 주도적인 역할을 맡길 것이다. 그러자면 비즈니스 모델을 조정하거나 사용자와 보다 효과적으로 협업하기 위해서 내부 프로세스를 쇄신해야 할지도 모른다. 그러나 기업에 대한 고객의 충성도를 유지할 수 있다는 측면에서 보면 이것은 적은 대가이다.

6장 새로운 알렉산드리안(The New Alexandrians)
고 대 알렉산드리아 도서관은 모든 민족의 책과 역사서, 위대한 문헌, 희곡 작품, 당대의 수학 및 과학 논문을 수집하여 건물 하나에 보관하려는 의도에서 만들어졌다. 즉 세상의 모든 지식을 집대성한 곳이었다. 이 시대 새로운 알렉산드리아 도서관은 웹을 통해 탄생하고 있으며 전 우주적인 도서관으로 자리 잡을 것이다.

7장 참여 플랫폼(Platforms for Participation)
아 마존이 모든 독점 도구와 데이터를 철저히 보호하고 싶어했을 거라고 생각하는 사람이 있을지도 모른다. 하지만 실제로는 정반대이다. “우리가 개발자들의 손에 더 많은 데이터를 쥐어줄수록, 흥미로운 도구와 사이트 및 프로그램들이 더 많이 만들어지고, 그에 따라 아마존에 돌아오는 수익도 커집니다.”

8장 전 세계 생산 시설(The Global Plant Floor)
산업의 종류와 관계없이, 새로운 황금률이 떠오르고 있다. 그것은 바로 고객이 가장 가치 있게 여기는 분야에서 최고가 되기 위해 노력하고, 그 이외 모든 것에 대해서는 파트너십을 맺는 것이다.

9장 위키 일터(The Wiki Workplace)
과 거의 일터는 완전하게 짜여진 군악에 맞춰 틀에 박힌 자세로 행진하는 군대의 모습에 비유할 수 있다. 하지만 미래의 일터는 뮤지션들이 조(調)와 멜로디, 박자만 미리 정한 상태에서 즉흥적이고 창조적으로 연주하는 재즈 앙상블과 비슷할 것이다.

10장 협업 지성(Collaborative Minds)
오늘날 성공하는 기업은 개방적이고 유연한 경계를 가지고 있다. 그들의 경쟁 원칙은 회사의 벽을 넘어 외부 지식과 자원 및 인재를 활용하는 것이다. 그들은 혁신의 중심이며, 독특하고 유능한 인재들을 끌어들이는 자석이다.

Share and Enjoy:

No related posts.

기본이 바로 선 나라 » Book

Bookmarks for November 9th through November 17th

Related posts

Bookmarks for November 1st through November 6th

Related posts

Bookmarks for October 29th through November 1st

Related posts

Bookmarks for October 15th from 14:06 to 14:06

Related posts

Bookmarks for October 14th through October 15th

Related posts

Bookmarks for September 26th through September 30th

Related posts

Bookmarks for September 17th through September 25th

Related posts

소프트웨어 테스팅 법칙 293가지

Related posts

Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

Related posts

Wikinomics -웹2.0의 경제학

Related posts