프로젝트에 적합한 생명주기 선정
(1) 똑같은 프로젝트가 하나도 없듯이 생명주기 모델이나 개발방법론도 프로젝트에 적합한 모델을 찾고 조정(Tailoring)을 통해 적용해야 할 것이다. 납기 준수와 결함 제거라는 두 마리 토끼를 동시에 잡아야 하는 프로젝트는 상세설계부터 릴리즈까지의 과정을 우선순위에 따라 2회~3회 반복 개발하여 출시하는 점진적 모델 적용이 유리하다.

요구사항 도출 및 명세화
(2) 요구사항 명세화는 고객이 제시한 사항을 받아쓰기하는 것이 아니라 정 끝으로 원석을 쪼아서 보석을 캐내는 작업이다. 수동적으로 주어지는 것이 아니라 능동적으로 개발해야 하는 것이다. 고객은 절대 원하는 모든 것을 다 말할 수 없다. 프로그램만 개발하는 것이 아니라 고객의 요구사항도 개발해야 한다.

(3) 요구사항을 개발(도출, 분석, 명세화)할 때 갖춰야 할 핵심 역량은 4가지다. 요구개발 방법론, 휴먼 스킬(Human Skill), 요구사항 모델링, 업종/업무 지식이 필요하다.

요구사항의 누락을 막는 법
(4) 모든 사용자 계층이 요구사항을 제시할 수 있도록 유도하고 요구사항을 확정할 때 반드시 Key Man(의사결정자)을 참여시켜라. 또한 응답속도, UI(User Interface)/UX(User eXperience) 등 사용성, 보안, 멀티 플랫폼 지원 등 시스템을 더 잘 만들기 위한 비기능 요구사항을 누락시키지 말아야 한다.

비기능 요구사항 도출
(5) 비기능 요구사항은 시스템이 갖춰야 할 상태, 조건(Condition)에 관한 요구사항이다. 성능, 보안, 신뢰성, 사용성, 효율성, 이식성 등 기능 이외의 품질 특성에 대한 이해를 통해 도출해야 한다.

요구사항 검토 워크숍
(6) 요구사항 검토 워크숍을 공식적인 마일스톤에 포함시키고 요구사항을 충분히 검토한 후 프로젝트 팀과 고객이 함께 서명하도록 한다.

유지보수 요구사항 개발
(7) SR 유형을 세부적으로 구분하고 그 중에서 ‘신규 개발’인 유지보수 요청서에 대해서는 요구사항을 구체적으로 작성하도록 하라. 이를 위해 요구사항을 작성하는 사용자를 대상으로 정기적으로 유지보수 요청서 작성 워크숍을 실시하는 것이 좋다.

(8) 아키텍처 설계 절차 및 적용
아키텍처 설계는 개발 이전에 선행해서 진행해야 한다. 프로젝트 초기 단계부터 고객, 업무 파트, 기술 파트 등 시스템 이해관계자와 긴밀한 소통을 통해 아키텍처 상(象)과 구조를 만들어가야 한다.

(9) 비기능 요구사항을 통해 아키텍처 드라이버를 식별하고 품질 속성 시나리오를 작성한다.

(10) 아키텍처 완성이 아니고 설계를 한 것이기 때문에 평가 단계가 필요하다. 보통 대안(Alternative)을 두 개 이상 준비하여 비교해서 평가한다.

프로그램 명세 설계
(11) 프로그램은 일반적으로 세 가지 경우로 구분할 수 있다. 통상적으로 화면을 토대로 실시간으로 처리가 가능한 온라인 프로그램, 특정 시간에 자동으로 프로그램을 수행하는 배치(Batch) 프로그램, 외부 시스템과의 인터페이스를 위한 프로그램이 그것이다. 세 가지 프로그램은 각각 특징이 있으므로 작성 항목과 작성 방법이 다르다. 프로그램 유형별로 프로그램 명세서 템플릿을 만들어 차별적으로 관리하라.

(12) 모든 프로그램에 대하여 명세서를 작성할 필요는 없다. 그러나 중요한 요구사항과 관련된 프로그램 명세서는 필수적으로 작성한다.

동료검토의 현실적 접근
(13) 인스펙션이 잘 진행이 되지 않는 가장 큰 이유는 사전 검토가 이루어지지 않기 때문이다. 모여서 개별 검토하는 것을 원칙으로 하고 참여 인원에 맞게 검토 산출물과 검토 산출물을 작성할 때 중요하게 참고한 문서, 즉 원 소스 산출물을 함께 출력하여 제공하라.

(14) 동료검토는 결함을 발견하고 공유하는 자리이지 이슈를 토론하는 자리가 아니다. 결함에 대한 판단, 즉 이슈 논의는 별도의 시간을 마련하여 진행하는 것이 좋다.

2인 1조 프로그래밍
(15) 새로운 인력을 충원하여 프로젝트 환경에 신속하게 적응할 필요가 있거나 신기술을 도입하여 관련 개발자가 부족한 경우에 적용한다.

테스트를 먼저 생각하는 개발
(16) 단위 테스트 케이스를 작성한 후에 프로그래밍을 진행하라. 적어도 무엇을 테스트할 것인가를 미리 스케치하고 프로그래밍에 진입하라.

소스코드 클린업(Cleanup)
(17) 일주일의 후반부에 소스코드 통합 작업, 코드리뷰를 실시한 후에 리팩토링을 실시하라.

(18) 월 1회 클리닝 데이(Cleaning Day)를 실시하여 소스코드를 정비하는 시간을 정기적으로 갖는다.

위험기반의 테스트 전략 수립
(19) 기본적으로 프로젝트는 제한된 자원으로 진행을 하기 때문에 위험 기반의 테스팅을 수행해야 한다. 가장 중요한 것, 실패 가능성이 높은 것, 즉 위험 요소를 파악하여 중점적으로 테스트한다.

(20) 중요한 개별 기능이나 비기능에 대해서는 별도로 테스트 전략을 수립한다.

명세기반 테스트 기법 활용
(21) 동등분할, 경계값 분석, 결정 테이블 등 명세기반 테스트 기법에 대한 이해와 복합적인 활용을 통해 보다 적은 테스트 케이스로 많은 결함을 발견하라.

테스트 시나리오 작성법
(22) 통합 테스트나 시스템 테스트를 수행할 때는 시나리오를 작성하고 이에 기반하여 테스트를 수행한다. 통합 테스트는 연계 절차, 시스템 테스트는 구체적인 상황과 조건을 고려하여 시나리오를 작성한다.

테스트 케이스 작성법
(23) 테스트 케이스는 테스트를 위한 테스트 데이터 세트(Test Data Set)를 명문화하는 것이다. 테스트 데이터를 준비할 수 있는 수준의 구체적인 데이터를 기술한다.

(24) 테스트 케이스에 대한 동료검토는 두 번 실시하는 것이 좋다. 테스트 케이스를 처음 작성한 후에 1차 검토를 수행하여 테스트 케이스의 완성도를 높이고, 테스트를 실행한 후에 2차 검토를 실시하여 누락된 테스트 케이스를 추가하고 불필요한 테스트 케이스를 제거한다.

저비용 고효율 테스트 가이드
(25) 두 가지 테스트를 수행하라. 화이트 박스(White Box) 테스트와 블랙 박스(Black Box) 테스트를 병행하여, 즉 그레이 박스(Gray Box) 테스트를 실시하라.

(26) 체계적인 테스트 기법에 경험 기반 테스트(특히 탐색적 테스팅)를 보완하거나 또는 상황에 따라 반대로 접근한다.

(27) 개발자가 자신이 개발한 프로그램을 테스트하는 것은 객관성이 떨어진다. 별도로 테스트 조직을 구성하여 수행하거나 그럴 수 없는 환경이라면 적어도 개발자 이외의 분석/설계 담당자나 품질 담당자가 수행한다. 또는 개발자 상호간에 중요도가 높은 프로그램을 중심으로 교차 테스트를 수행한다.

테스트 자동화
(28) 자동화 효과가 크고 반드시 도구를 사용해야 하는 시스템 테스트 영역의 도구를 먼저 도입한다. 그 중에서도 특히 성능 테스트나 보안 테스트 도구를 도입한다. 이와 병행하여 요구사항을 등록하고 테스트 케이스를 요구사항과 연결하여 관리하고 테스트 결과를 관리할 수 있는 시스템을 구축한다.

자주, 정기적으로 코드를 통합하기
(29) 규모가 크고 복잡한 프로젝트는 빅뱅 통합보다 지속적인 통합(Continuous Integration)을 하라.

(30) 일 단위로 통합 빌드(Daily Build)를 수행하라. 주 단위로 통합 테스트를 수행하라. 월 단위로 고객 테스트를 진행하라.

대가 산정(Estimation) 현실화 및 검증
(31) 현실적인 최선의 산정 방법은 제안 시점에 과거 유사 사업의 산정 결과를 활용하여 산정을 정확하게 하는 것이다. 만약 산정 자료가 축적되어 있지 않다면 해당 사업을 수행한 전문가들의 의견을 모아 정확도를 높인다.

(32) 프로젝트의 실제 수행 결과를 측정해야 한다. 제안 시점뿐만 아니라 프로젝트가 종료된 후에도 산정할 필요가 있으며 초과근무 실적도 고려해야 한다.

프로젝트 착수 워크숍(Kick Off Workshop)
(33) 프로젝트 초기에 프로젝트의 비전 수립과 팀의 단합을 위한 실질적인 활동을 수행하라. 수행 팀을 대상으로 내부 착수 워크숍을 실시하여 프로젝트 목표와 개인 목표 수립, 위험 식별 및 대응방안 수립, 교훈 도출, 프로젝트 규칙 협의 등을 진행하라.

사용자 참여를 이끌어내는 법
(34) 프로젝트 초기에 고객의 협조를 구해야 할 사항과 고객이 프로젝트 기간에 공식적으로 해야 할 일을 구체적으로 명시하고 설명한다. 초기에 고객의 역할과 책임을 구체적으로 합의해야 이후에 프로젝트를 진행하면서 고객을 참여시킬 수 있는 근거가 된다.

개발자 채용과 경력개발
(35) 개발자를 채용할 때 그들의 경험, 기술, 태도를 경험 기반 인터뷰와 직접 작성한 코드 인터뷰를 통해 확인하라.

(36) 현장학습을 통해 현장에서의 지식과 기술의 노하우를 축적, 공유, 활용함으로써 개인의 성장과 조직의 역량을 강화하라.

품질에 대한 인식 전환
(37) 이제 니즈(Needs)와 원츠(Wants) 둘 다 공략해야 하는 시대가 되었다. 고객의 요구사항(니즈와 원츠)을 제대로 담아라. 이것을 만족시켜야 품질을 만족시키는 것이다.

통찰력을 제공하는 품질활동
(38) 품질 활동은 객관성과 통찰력을 제공해야 의미가 있다. 객관성이란 사실을 기반으로 보편적인 잣대와 기준으로 공정성을 보장하는 것이다. 또한 문제에 대해 의사소통을 하고 해결에 대한 실마리와 통찰력을 제공해야 품질 활동의 부가가치가 높아진다. 품질 인력은 기본적으로 문제 해결 능력을 갖춰야 한다.

프로젝트 초기의 위험과 결함관리
(39) 성공하는 프로젝트는 시작부터 일의 진행을 예측하고 미리 대비한다. 위험을 식별하고 완화하는 활동을 수행하며 동료검토(Verification)를 적극적으로 실시하여 결함을 조기에 발견한다. 처음부터 일을 제대로 하는 것이 가장 비용이 적게 드는 방법이다.

위험관리 십계명
(40) 위험과 문제는 동일한 속성을 갖고 있다. 위험은 향후 발생할 문제이며 문제는 위험이 현실화된 것이다. 위험관리는 미래에 발생할 문제를 예측하여 미리 대비를 하는 것이다. 사고나 질병을 대비하기 위해 보험을 가입하는 것처럼 위험관리는 성숙한 경제적 활동이다. 프로젝트 초기에 위험을 최소 10개(위험 Top 10)를 도출하라.

요구사항 변경에 대한 우리의 자세
(41) 요구사항은 프로젝트 기간 내내 끊임없이 변화한다. 변경은 필수 불가결하기 때문에 프로젝트 시작 전에 변경에 대한 대응 방법을 강구한다.

(42) 프로젝트 초기에 요구사항 변경 절차와 변경 처리에 대한 고객의 의무를 공지한다.

요구사항 양방향 추적
(43) 요구사항과 산출물간의 형식적인 연결에 치중하기 보다는 고객 입장에서 요구사항이 구현되고 있음을 확인할 수 있는 항목 위주로 추적을 관리하라.

(44) 기능 요구사항과 비기능 요구사항은 다르게 추적이 되어야 한다. 기능 요구사항은 프로세스, 화면, 단위/통합 테스트 등과 밀접한 관련이 있는 반면 비기능 요구사항은 아키텍처, 개발 표준, 시스템 테스트 등과 관련이 있다.

목표에 부합하는 측정
(45) 비즈니스 목표 달성에 부합하는 소수 지표를 선정하여 효과를 본 후에 다른 지표로 확산하는 전략을 취하라. 해당 지표에 이해관계가 있는 조직이나 담당자를 지표 오너로 지정하고 지표에 책임을 갖고 지표 측정 결과를 수집하도록 독려한다. 지표 관련 데이터를 사람이 수동으로 등록하지 않고 일상적인 업무를 시스템에서 처리하면 자동으로 데이터가 수집될 수 있도록 체계를 구축하여 운영하라.

변화와 협업을 주도하는 형상관리
(46) 소프트웨어 개발은 변화가 필수적으로 발생하고 또한 팀에 의해 개발되기 때문에 형상관리 메커니즘이 필수적이다. 상황에 맞는 형상관리 시스템(중앙집중형, 분산형 등)을 구축하여 사용한다.

효과적, 효율적 프로세스 개선
(47) 좋은 프로세스는 효과성(Effectiveness)과 효율성(Efficiency)을 갖추고 있다. 효과성은 고객의 요구에 얼마나 적합한지를 보는 것이다. 효율성은 얼마나 경제적으로 아웃풋을 만들어 낼 수 있는가를 따진다. 효율성의 가치는 효과성이 입증된 다음에야 존재 가치가 있다. 고객이 원하지 않는 물건을 빠르고 값싸고 튼튼하게 만들어 보았자 아무런 가치를 가지지 못하기 때문이다. 프로세스에 고객의 요구를 담아라.

(48) 모든 행위를 다 모니터링하기보다는 고객 만족에 직접적인 관련이 있는 행위를 선별하고 측정 지표를 모니터링하고 부족한 점을 개선하는 것이 경제적이며 올바른 방법이다.

일의 시작
(49) 생각하는 것이야 말로 일의 시작이다. 일을 수행하는 방법(How)도 중요하지만 일의 목적(Why)과 목표(What)에 대해 생각해야 한다. 일의 목적과 방향을 먼저 생각하는 습관이 쌓여야 내공이 깊어지고 원하는 결과를 만들어 낸다.

일의 가치 찾기
(50) 일에서 가치를 찾으려면 일에 대한 비전과 철학이 있어야 한다. 내가 하는 일의 고객이 누구인지 명확히 정의해보자. 고객은 내가 하는 일의 수혜자다. 고객을 도울 수 있는 방법을 정의해보고 그 일을 통해 일의 가치를 부여하고 일의 보람을 느껴보자.

일의 우선순위 정하기
(51) 모든 일을 우선순위에 의해 진행하고 관리하라. 중요한 요구사항의 개발, 중요한 요구사항의 테스트 케이스, 중요한 요구사항의 결함 해결 등 ‘중요한’에 초점에 두고 일을 진행하라. 우선순위를 정하는 것은 쉽지만 우선순위대로 일하기는 어렵다. 우선순위는 실천의 문제다. 우선순위를 결정하는 것에는 중요한 일에 집중하고 하찮은 일은 과감히 버릴 수 있는 용기가 필요하다.

(52) 내가 하는 일을 회사나 시장에서 판단하는 일의 중요도와 나의 적성에 따라 4가지 영역으로 구획하고 선택과 집중 전략을 세워라.

PDCA 사이클
(53) PDCA(Plan-Do-Check-Act) 사이클에 따라 어떠한 일이든 계획을 세우고 실행하고, 이에 대한 점검을 통해 개선 활동을 지속적으로 수행하라. 이 중에서 특히 계획(Plan)과 개선(Act) 활동에 신경을 써라. 부실한 계획과 개선 활동의 부재는 주도성을 상실하게 하고 성장을 도모할 수 없다. 계획은 구체적이고 현실적으로 세우고 일이 종료된 후에는 되돌아보고 개선의 기회로 삼아라.

성장을 기록하기
(54) 내가 한 일을 나열하기만 하는 이력서를 관리하지 말고 비즈니스와 직접적인 관련이 있는 일의 성과, 가시적인 고객 만족, 전문성의 증거, 휴먼 네트워크의 4가지 항목으로 비즈니스 성공 이력서를 관리하라.

(55) 오늘 새롭게 배우고 깨달은 것은? 오늘 새롭게 시도한 것은? 오늘 나는 누구를 기쁘게 할 것인가? 이 세 가지 관점에서 일지를 쓰게 되면 효과적으로 일과 관계의 품질을 높일 수 있기 때문에 경력관리에 큰 도움이 될 뿐만 아니라 인생의 축소판인 하루를 잘 보낼 수 있게 된다.

테크니컬 라이팅(Technical Writing)
(56) 글쓰기는 전문가가 갖춰야 할 필수능력이다. 기술 분야에 종사하고 있는 사람들이 써야 하는 글의 대부분은 회사 공문, 회사 내의 보고서, 제안서, 사양서, 제품의 사용설명서 등의 실용적인 글이다. 사용자의 관점에서 논리적으로 명확하게 써라.

5단계 시간관리
(57) 내가 일하는 시간의 절대량보다 능력을 최대한 발휘한 시간이 진정한 의미의 생산성이다. 하루 중에서 업무에 집중한 시간(Flow Time)을 기록해보자. 조각난 시간을 통합해서 연속적인 시간을 만들어야 성과를 낼 수 있다.

(58) 시간 관리의 요체는 불필요한 시간을 제거하는 것이다. 제거 없이 창조는 없다. 쓸데없는 약속시간을 줄이고 나를 위해 투자하는 시간을 만들어 보자.

(59) 매일의 힘을 빌려라. 정해진 시간에, 정해진 분량의 시간을 투입하여 정해진 과제를 매일 수행할 수 있는 시스템을 갖춰라.

창의, 기술과 인문의 만남
(60) 창의는 무에서 유를 창조하는 것이 아니다. 사람들이 원하는 것을 먼저 생각하고 그에 맞는 기술을 개발하고 접목시켜야 한다. 인간의 마음으로 세상을 바라보아야 한다. 인간이 어떤 방향으로 움직이는 지를 예측하는 것이 창의력이다.