긍정적 사고, 음식의 절제, 규칙적인 운동

소프트웨어 개발의 모든 것(김익환,전규현 지음. 페가수스)를 읽고 나서 중요한 몇 구절을 남겨본다.

요구사항의 중요성
소프트웨어 시스템 구축에서 가장 여려운 부분은 무엇을 구축할 것인지를 정확하게
판단하는 것이다. 그러나. 구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이
불가능한 경우가 많다. 그렇다고 해서 요구사항 개발에 소홀해서는 안 된다. 시간이
허락하는 한 최대한 많은 정보를 파악하는 것이 좋다.
 잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 재작업 비용은 일반적으로 전체 개발
비용의 30~50%에 이르는 것으로 알려져 있다. 요구사항 오류로 인한 재작업 비용은 전체 재작업 비용의 70~85%에 이른다. 잘못된 요구사항, 부족한 요구사항은 일정을 지연시키며
많은 추가 비용을 발생시킨다.
 완벽하게 상세한 요구사항이 가장 좋은 요구사항은 아니다.
 요구사항은 이해하기 쉽게 간결함을 추구해야 한다. 간결하지만 충분히 설계, 구현할 수
있어야 한다. 그리고 요구사항 문서는 모든 관련자가 충분히 검토해야 한다.
요구사항 오류는 개발 단계가 지나가면 지나갈수록 그 수정비용이 기하급수로 증가한다.
유지보수 단계에서 비용이 더 드는 것으로 알려져 있다. 충분히 검토하여 오류가 없는
요구사항을 만드는 것이 프로젝트를 성공으로 이끄는데 가장 필요한 핵심이다.


SRS Template
1.Introduction(개요)
2.Overall Description(전체 설명)
3.Environment(환경)
4.External Interface Requirement(외부 인터페이스 요구사항)
5.Performance Requirement(성능 요구사항)
6.Non-Functional Reuirement(기능 이외의 요구사항)
7.Functional Requirement(기능요구사항)

코딩자세 : 소프트웨어를 잘 구현하기 위해서는 코딩을 함에 있어 반드시 지켜야 할 것들이 있다.
* 회사의 코딩표준을 철저히 지켜야 한다.
* 버그가 발견되면 그 즉시 버그를 고쳐라.
* 발견된 버그가 재현이 안 된다고 해서 버그가 사라진 것이 아니다.
* 문제 없이 작동하고 있는 코드를 괜히 정리하려고 하지 마라.
* 문제가 해결될 때까지 이렇게 저렇게 마구 고치지 마라.
* 코딩 작업을 작게 나누어서 코딩, 빌드, 테스트를 자주 반복하라.
* 중요하지 않은 버그는 하나도 없다.

회사의 코딩표준을 지켜야 하는 이유.
* 소스코드의 작성법을 통일하여 개발자들끼리 서로 코드를 더 쉽게 이해할 수 있게 한다.
* 개발자가 바뀌어도 빠른 시간 안에 소스코드를 파악 할 수 있게 한다.
* 흔히 저지르기 쉬운 사소한 실수를 방지하여 제품의 품질을 높인다.

품질관리
 소프트웨어프로젝트에서 품질은 소프트웨어가 얼마나 요구사항을 잘 만족시키고
 있는가의 정도이다. 품질은 전적으로 테스트에만 의존하는 것이 아니다.
 잘 만들어진 프로젝트 계획, 잘 분석된 요구사항, 각 단계의 철저한 리뷰,
체계적인 테스트 등 프로젝트 전 과정에 걸친 일련의 활동들이 모여서
제품의 품질을 보장하게 된다.
 많은 개발자들이 소프트웨어의 품질에 큰 관심을 두지 않는다. 현재 프로젝트를 끝내고
빨리 새로운 프로젝트를 하고 싶어한다. 현재의 문제는 유지보수에서 해결할 수 있을
것으로 생각하기도 한다. 이러한 생각은 제품의 품질을 떨어뜨리고, 제품을 제 때에
출시하지 못하게 만들기도 한다. 품질을 포기하고 제때 출시된 제품은 정시 출시에 대한
의미조차  없다. 고객들은 제품의 품질을 계속 기억할 것이고, 추후 더 나은 제품에 대한 기억이 사라지지 않을 것이다. 일반적으로 소프트웨어의 유지보수에 개발 지용의 2~5배가
지불된다고 알려져 있다. 최초에 낮은 품질로 출시된 제품은 유지보수 비용을 지속적으로 증가시킨다.
 유지보수 비용을 간과하면 장기적으로 제품의 수익성에 심각한 저하를 가져올 수 있다.
그럼에도 불구하고 소프트웨어 개발 시에 유지보수에 대해 신경을 쓰지 못하는 경우로
다음과 같은 것들이 있다.

* 당장 프로젝트가 발등에 떨어진 불이라서 유지보수에 대해서는 신경 쓸 겨를이 없다.
* 유지보수는 다른 개발팀이 맡을 것이므로 신경 쓰지 않는다.
* 경험이 별로 없어서 유지보수에 많은 비용이 드는지 몰랐다.
* 유지보수에 비용이 얼마나 드는지 정확하게 따져본 적이 없다.

제품의 품질을 유지보수 기간으로 넘길 것이 아니고, 지금 바로 품질에 대해서 신경을 쓰는 것이 경제적으로 더 바람직하다.

리스크 관리
리스크 계획 중 개발자가 퇴사할 징후가 보일때 다음과 같은 대응책을 마련할 수있다.
* 개발자가 퇴사하지 않도록 노력한다.
* 개발자가 퇴사하더라도 보충할 개발자를 미리 사내에서 물색해 놓는다.
* 사내에서 보충할 개발자를 찾지 못하면, 외부 채용 활동의 준비 단계를 해 놓는다.
   즉, 채용공지를 하고 이력서를 분석하여 채용자 후보를 미리 물색해 놓는다.
* 해당 개발자이 모듈을 다른 개발자와 많은 부분 공유하도록 계획한다.
* 아예 해당 개발자를 프로젝트에서 제외하고 진행한다.

동기 유발 요인 : 프로젝트에서 개발자의 동기를 유발하는 요인에는 다음과 같은 것들이 있다.
* 목표설정, 성취감, 성장가능성, 개인생활의 보장, 포상.

프로젝트 팀이 하는 작업 리스트
* SRS 작성 및 검토
* 소프트웨어 아키텍처 설계 논의
* 소프트웨어 컴포넌트와 인터페이스 논의
* 소프트웨어 설계 리뷰
* 소스코드 리뷰
* 결함 추척 및 해결
* 중요 이슈 논의
* 유지보수

성공하는 팀의 특징
* 훌륭한 기술리더가 있다.
* 도전적이고 실천가능한 목표와 비전을 공유하고 있다.
* 실력 있고 헌신적인 팀원들로 구성되어 있다.
* 팀원들간에 서로 신뢰한다.
* 팀원들간에 의사소통이 원활하다.
* 팀이 적절한 권한과 자율성이 있다.
* 팀워크를 유지하기에 알맞은 팀이다.

실패하는 팀
* 비전이 공유되어 있지 않다.
* 팀원들간에 서로 신뢰하지 않는다.
* 팀원들 간 의사소통이 원활하지 않다.
* 문제 팀원 방치.
 
필자의 경험에 의하면 프로젝트를 망치는 길은 지뢰밭과 같이 많아도
성공하기 위한 비법은 없다. 기본에 충실하고 기초와 문화가
각각 개발자들 몸에 배어서 앞에서 언급된 여러 활동들이 종합적으로
자연스럽게 이루어 질 때 소프트웨어 프로젝트 성공이 좀더 가까워 질 것이다.

개발자들은 가장 먼저
* SRS를 작성해야 한다고 생각하고,
* SRS를 작성하면서 모든 관련자와 철저히 리뷰를 하고,
* 프로젝트 관리자는 개발자들과 함께 1,2일 단위의 상세 일정을 작성하고,
* 테스트팀은 SRS를 보고 테스트 Suite를 만들기 시작하고,
* 개발 리더들은 화이트보드나 종이를 펼쳐놓고 아키텍처에 대해 토론을 하며,
* 구현 시 모든 소스코드는 당연히 리뷰를 하고,
* 개발자는 매일 스스로 일정을 업데이트하고,
* 소스코드 작성은 일일빌드가 깨지지 않으면서 이루어지며,
* 소스코드관리시스템과 버그관리시스템을 효과적으로 사용하며,
* 알파, 베타 단계 별로 모든 프로젝트 관련자들이 유기적으로 움직이며,
* 일정에 맞춰 완성도 있는 품질의 제품을 출시한다.

위와 같은 활동들이 당연하다고 생각되고 몸에 배어야 한다.
이러한 것들을 규칙만으로 통제를 해서는 달성하기 어렵고 한꺼번에 모두 다 습득하기도 어렵다.
하나씩 익혀서 몸에 배었을 때 소프트웨어 프로젝트를 성공하는 원리가 보이기 시작하고,
좋은 제품을 만들 수 있을 것이다.