프로젝트 Xxx에 적용하고 싶은 개발방법

1Copyright © 2009 Xener Systems, Inc. All Rights Reserved.

프로젝트 XXX 에 적용하고 싶은 개발방법

임도형2010/04/21

[email protected]


본 문서의 목적

• 프로젝트 XXX 를 진행할 때 적용할 개발 방법을 제안합니다 .


적용하고자 하는 방법의 목적

• 모두가 행복하기 위하여– 개발자

• 개발 다운 개발– 관리자

• 일정 잘 맞추고 , 개발자 관리 좋고 , 유지보수 좋고

– 회사• 잘 팔리고 , 1 인당 매출액 좋고 , 유지보수 비용

적고– 고객

• 저렴한 가격에 , 성능 / 기능 좋고 , 기능 개선과 버그 픽스 빠르고 .


행복하기 위한 각 관련자의 역할

• 개발자– 최대한 제대로 개발할 수 있도록 노력

• 관리자– 개발자가 제대로 개발할 수 있도록 지원– 회사와의 일정 조율

• 회사– 적절한 일정 제시


실천 항목


실천 항목

• 분석 / 설계 시에 팀원의 참여• 충분한 분석 / 설계• GUI 개발도 설계를 기반으로• 충분한 테스트 케이스• 자동화된 빌드 , 테스트• 가독성을 최상의 품질 요소로• 1 일 빌드 , 자동 테스트 실행• 모든 산출물의 리뷰• scrum 적용

– 진행 상황에 따른 일정 조절 및 개발 범위 조정– 팀원이 선택 가능한 업무 배분– 계획과 회고에 따른 시스템 개선


분석 / 설계 시에 팀원의 참여


잘 팔리는 제품 .

• 품질 속성만 만족하면 잘 팔릴까– 기능 , 성능 , 안정성 , 유지보수성 , 확장성

• 잘 팔릴 만한 제품을 고민하는 것은 누구의 몫 ? 기획자 ?

• 언제나 기획은 불충분하다 . 불충분할 수 밖에 없다 .

• 소프트웨어에 기획자 + 개발자의 구도가 적당할까 ?


가치 창조하기

• 고객이 감동할 수 있는 가치를 찾아내야 한다 . 제품에 불어넣어야 한다 .

• 개발팀에서 해야 한다 .

• ideation 을 통해 구체화 된다 . 상상하고 , 끄집어 내고 , 검토하고 , 정의하고 .

• 프로젝트 관련자 모두가 참여하는 것이 바람직하다 .

• 이러한 ideation 은 분석단계에서 진행되며 , 작업 결과는 보통 요구사항의 형태로 정리된다 .

• 즉 요구사항정의 시에도 팀원 전원의 참여가 필요하다 .


소프트웨어 개발에서의 생각

• 개발에서 생각하는 것은 분석 / 설계에 관련된 것이다 .

• 코딩은 단지 그 결과를 코드로 구현하는 것 뿐이다 .

• 생각을 하게 하지 않는 개발업무는 개발자의 의욕을 꺽는다 . 개발자를 생각하게 하여야 한다 .


분석 / 설계의 구분

• 3 가지로 구분된다 .– 시스템 구조 분석 / 설계– 기반 분석 / 설계– 기능 컴퍼넌트 분석 / 설계


시스템 구조 분석 / 설계

• 각 기능을 제공할 컴퍼넌트의 정의와 컴퍼넌트 간의 관계 정의

• 각 컴퍼넌트들 마다의 기능 요구사항을 정의하고 , 각 컴퍼넌트의 인터페이스까지 정의한다 .

• 기술적인 측면 보다는 시스템 전체적인 흐름을 이해하기 위하여 팀원 모두가 참여하는 것이 바람직하다 .

• 이 단계를 참여하지 못한 개발자는 전체적인 시스템을 이해하기 어렵다 .– 업무의 백업이 어렵다 .– 업무의 선택이 어려워 진다 .– 지엽적인 개발이 될 수 밖에 없다 .


기반 분석 / 설계

• 일반적인 시스템에서 필요로 하는 기능을 제공한다 .– 예 : 컴퍼넌트 로딩 , 로그 , 통신 방법

• 성능에 많은 영향을 끼친다 .

• 기술적인 난이도가 있다 .

• 타 컴퍼넌트의 개발에 기반이 되며 , 선행되어야 한다 .

• 보통 Application Server, framework 이 대신하기도 한다 .

• 모든 팀원이 참여하기 곤란하다 .


기능 컴퍼넌트 분석 / 설계

• 구조 설계에서 정의한 각 컴퍼넌트 자체를 구현하기 위한 것 .

• 특정 업무 담당자가 진행한다 .

• 구현할 기능과 타 컴퍼넌트와의 인터페이스는 구조 설계에서 정의되어 있다 .


실 적용 사례

• 6 개월 일정의 프로젝트에서 3 개월을 분석 / 설계로 진행했으며 , 코딩 , 테스트 , 패키징에 각각 1 개월씩이 소요됨 .

• 코딩 1 개월 때는 고민할 사항 없이 깔끔하게 진행되었고 , 이후 테스트 , 패키징에서도 문제가 발생하지 않았다 .

• 설계된 사항이 크게 변경되는 것이 없었으며 , 이러한 이유로 프로젝트 완료와 유시보수 시에도 문서가 살아있었다 .

• 버그픽스는 설계와 관계없는 것이고 , 기능 추가는 설계서에 추가하면 되고 .


충분한 분석 / 설계


분석 / 설계와 코딩

• 개발의 실체는 고민이다 .

• 고민 과정이 분석 / 설계이고 , 코딩은 그 구현일 뿐이다 .

• 코딩 시에 고민하게 되면 삽질이 필수적이다 .

• 코딩 시에는 고민을 하지 않아야 한다 . 최대한 지양하여야 한다 .

• 어차피 고민해야 하는 것을 분석 / 설계에서 마무리하고 코딩으로 들어가야 한다 .

• 모든 분석 / 설계는 리뷰를 통해 구현 전에 검토하는 것을 원칙으로 한다 .


GUI 개발도 설계를 기반으로


GUI 개발의 특징

• GUI 에 대한 평가가 제품 전체에 대한 평가로 적용되기도 한다 .

• 까다로운 사용자 편의성을 제공해야 한다 .

• 또한 디자인적인 요소도 포함되어야 하기에 단순 개발역량만으로는 안된다 .

• 그러나 개발 과정 자체는 단순 노가다에 가깝다 .– 개발 자동화도 어렵다 .– 테스트 자동화도 어렵다 .

• 무척 중요하지만 어렵고도 지치게 한다 .


GUI 의 분석과 설계

• 가장 문서화하기 힘든 부분이다 .

• 더불어 가장 삽질을 많이 하는 부분이다 . 또한 삽질의 크기가 큰 부분이다 . 그렇기 때문에 설계가 더더욱 중요하다 .

• 설계된 결과의 형태는 중요하지 않다 . 종이에 그리건 , 툴로 그리건 .

• 중요한 것은 설계가 되어야 하고 , 검토 후에 구현되어야 한다는 것이다 .


설계의 의미

• 개발중의 고민이 설계이다 .

• 코딩하기 전에 고민을 충분히 하지 않으면 , 코딩 중에 뒤엎기가 발생한다 .

• GUI 개발도 코딩이며 , 역시 충분히 고민해 놓지 않으면 뒤엎기가 발생한다 .

• GUI 특징으로 인해 설계는 그림으로 그려져야 하고 , 이는 다른 부분의 설계보다 손이 많이 간다 .

• 하지만 그렇더라도 설계가 충분히 되어야 한다 . 설계를 뒤엎는 것이 코드를 뒤엎는 것보다 낳다 .

• 설계된 결과는 상상할 필요 없이 눈으로 확인되어야 한다 .


GUI 설계 참여자

• GUI 는 단지 view 가 아니다 . 시스템 전체의 기능을 눈으로 보여준다 .

• GUI 개발자도 시스템 전체를 이해해야하고 , 타 부분 개발자도 GUI 를 파악하고 있어야 한다 .

• 전체 시스템의 이해를 포기하는 순간 , 생각을 배제하는 개발자 즉 코더임을 자청하는 것이다 .

• GUI 의 이해를 포기하는 순간 , 전체 시스템 파악을 포기하는 것이다 .


테스트 케이스


why must 테스트 케이스

• 영향도 분석은 실제적으로 불가능하다 . 대충하기도 무척 어렵다 .

• 특정 부분을 변경 했을 때 기존의 것이 모두 제대로 동작하는지를 확인하는 유일한 방법은 충분한 테스트 케이스 뿐이다 . 요걸 회귀테스트라 한다 .

• 수정에 의한 감추어진 버그는 , 테스트 케이스가 없다면 몇 달 뒤에 고객이 찾아 줄 것이다 .

• 방금 수정한 것에 의한 버그를 테스트 케이스가 잡아준 경우와 , 몇 달 뒤에 고객이 발견하여 등록된 경우 둘 사이의 버그 픽스의 공수 , 난이도는 비교가 안된다 .


어느 정도 양의 테스트 케이스

• 최소한 본 코드의 양과 동일한 라인 수의 .

• 최소한 작업한 본 코드의 메소드 수와 동일한 개수의 테스트 케이스 개수 .

• 최소한 본 코드의 사용예를 볼 수 있는 .

• 컴퍼넌트 단위의 테스트 케이스는 충분히 꼼꼼하게 .

• 시스템 단위의 테스트 케이스는 QA 팀에서도 활용할 수 있게 . 혹은 QA 팀에서 실행하는 테스트 항목 수 정도로 . 혹은 QA 팀에서 테스트 케이스를 직접 작성할 수 있도록 .


자동 실행

• 모든 테스트 케이스는 한방에 실행 될 수 있어야 한다 .

• 사람 손으로 일일이 실행하는 테스트 케이스는 제대로 활용되지 못한다 . GUI 테스트는 그래서 더 어렵고 허술하다 .

• GUI 와 같이 자동실행하기 어렵더라도 , 최선의 방법을 찾아내야 한다 .


테스트 케이스와 생산성

• 테스트 케이스 작성 역시 공수가 필요하다 .

• 임도형이 파악하는 구현 시의 공수 증가는 1.5 배 정도 .

• 임도형이 파악하는 유지보수 시의 공수 이득은 10 배 정도 .

• 개발 비용과 유지보수 비용을 1:2 로 했을 때– 비적용 공수 : 3 ( = 1+2 )– 적용 공수 : 1.7 ( = 1*1.5 + 2*0.1 )

• 테스트 케이스 작성을 먼저 할 경우 해당 로직의 사용예를 먼저 구현해 보는 효과가 있어서 , 삽질을 많이 방지하게 한다 .

• 구현 시의 공수는 유지보수 시에 발견될 버그를 구현 시에 픽스하는 것으로 생각할 수 있다 .


테스트 케이스와 유지보수

• 타인이 개발한 부분을 파악할 때 , 살펴 보기 가장 좋은 부분은 테스트 케이스이다 .

• 컴퍼넌트 기반의 코드는 그 진입점을 찾기도 어렵다 .

• 테스트 케이스 자체가 코드의 사용 예가 된다 .

• 테스트 케이스 코드에는 대상 코드가 사용되는 입력값과 출력값의 예도 있다 .

• 새로운 기능을 추가하거나 버그를 수정하기 위해서는 로직을 전부 파악하고 목적에 맞는 샘플을 작성해야 한다 . 기존에 테스트 케이스가 있으면 , 이를 참조하기 넘 좋다 .


테스트 케이스와 리팩토링

• 리팩토링은 기능은 그대로 유지한 채 내부의 구조를 개선하는 것이다 .

• 시스템이 커질 수록 리팩토링의 필요성은 절대적이다 .

• 테스트 케이스가 없이는 리팩토링은 불가능하다 . 기존의 기능이 그대로인 것을 어떻게 보장하는가 .

• 클래스의 이름 변경 , 엔티티의 이름 변경과 같은 사소한 리팩토링 조차도 테스트 케이스 없이는 많은 손이 가고 힘들다 .

• 테스트 케이스 없이는 구조 변경이나 뒤엎기는 큰 비용을 감수해야 한다 .


그 외 효용

• 만약 어떤 컴퍼넌트가 테스트 케이스를 작성하기 어려운 경우라면 , 시스템의 구조가 적절하지 않은 것이다 .

• 테스트 케이스 작성이 용이하도록 하다보면 시스템의 구조가 좋아진다 . 컴퍼넌트 간의 종속성이 줄어든다 .


실 적용 사례

• 약 30 개의 컴퍼넌트 , 400 개의 클래스로 이루어진 시스템에 약 2000 개의 테스트 케이스가 있었다 .

• 각 컴퍼넌트는 개별적으로 테스트 가능하였다 .

• 릴리즈 이후 1년 간 최대 미 처리 버그수가 5 개를 넘지 않았다 . 유지 보수에 들어간 공수가 미미 . 별도의 유지보수 인력 배정 불필요 .

• 유지 보수 시에 어느 부분을 수정 후에 어느 테스트 케이스에서 실패하면 안도감이 느껴진다 . 무엇을 선택할 것인가 ?– modify & pray– cover & improve

• 고의적으로 삽입된 버그의 검출률이 80% 이상이 되도록 유지되었다 .


가독성


가독성과 유지보수성

• 가장 좋은 코드는 읽기 쉬운 코드이다 .

• 유지보수 ?– 기능을 추가하거나 버그를 픽스하는 것 .

• 주석을 읽어야 하거나 , 문서를 읽어야 하거나 , 로직을 파악하기 힘들면 유지보수가 힘들어 진다 .

• 읽기 어려운 코드라면 주석을 잘 달거나 , 문서를 잘 만들거나 별도의 노력을 해야 한다 . 하지만 잘 안 된다 . 이건 경험적 진리이다 .

• 가독성이 떨어지면 , 적지 않은 경우 , 다시 개발한다 .


가독성과 성능

• 일반적으로 가독성이 좋은 코드는 실행 시에 오버로드를 요구한다 . ( 예 : 별도로 뽑은 메소드 , 인터페이스 사용 )

• 성능 문제는 튜닝으로 처리해야 한다 .

• 튜닝은 비정규화 작업이다 . 정형화된 코드를 비정형화 하는 것은 쉽지만 , 비정형화된 것을 정형화하는 것은 무척이나 어렵다 .

• 전체 시스템의 성능에서 특정 부위가 좌우하는 비중을 가늠하는 것은 거의 정확하지 못하다 .

• 가독성 없는 코드를 정리하는 것은 무척이나 어렵지만 , 가독성 좋은 코드를 성능 튜닝하는 것은 할만하다 .


가독성과 생산성

• 가독성 향상으로 인한 개발 시의 생산성 저하는 미미하다 .– 타이핑 시간이 생산성에 영향을 주지 않는다 .

• 그보다는 유지보수성이 좋아지기 때문에 전체적인 생산성은 좋아진다 .


가독성을 위한 실천 항목

• 단어의 축약 엄금 .– 축약은 가독성의 상극이다 .

• 클래스명 , 메소드명 , 변수명을 확실하게 .– 이름 짓기가 어렵다면 개념이 불확실한 것이다 .

설계가 부족한 것이다 .

• 주석 지양 .– 코드 자체로 이해가 되도록 한다 . 주석은 이런

코드가 될 수 밖에 없는 사항을 설명하거나 , 입출력의 예를 명시할 때만 사용한다 .

• 하나의 블록은 50 line 이 넘지 안게

• indent 는 3 개까지만


자동화된 빌드 / 테스트


자동화

• 머리로 생각하는 개발에 집중하게 하자 .

• 반복되는 것 , 기계적인 업무의 것들을 자동화 하자 .

• 빌드 자동화– 빌드 스크립트 .– daily build

• 테스트 자동화– 모든 테스트는 사람이 손이 아닌 한방에 가능하게 .

• 자동화를 위한 툴이나 환경을 위한 개발이 필요할 수도 있다 . 이런 것도 개발이며 , 업무에 포함된다 .


일일 빌드

• 보통 CI(Continuous Integration) 이라고도 한다 .

• 프로젝트 내내 빌드되고 테스트 성공하는 것을 보장한다 .

• 이것이 없이는 빌드성공하고 테스트 성공하는 것에 대한 강제성이 없어진다 .

• 빌드가 안되거나 테스트가 실패한 코드는 타 팀원의 업무를 진행하지 못하게 한다 .

• 목숨처럼 지켜야 하는 것 .


리뷰


리뷰 방법

• 모든 업무 결과를 리뷰한다 .

• 정규적 혹은 비정규적으로 진행한다 . 대신 2주 이상을 넘기면 안된다 .

• 하나의 업무에 대한 리뷰 시간은 30 분 정도로 하고 , 최대 1 시간을 넘지 않는다 .

• 프로세스 상에 언급된 산출물의 경우 리뷰 자체를 업무로 진행한다 .


코드 리뷰 대상

• 리뷰 대상은 문서 , 테스트 케이스 , 본 코드이다 .

• 문서– 외부와의 인터페이스– 그렇게 로직을 구성한 이유– 이외의 모든 고민이 담겨 있어야 한다 .

• 테스트 케이스– 중점 리뷰 사항– 테스트 케이스 양의 적절함– 테스트 케이스 안의 코드 샘플의 적절함

• 본 코드– 일반적인 가독성– 상식적인 품질


SCRUM 적용


스트럼의 개요

• 한달 정도의 주기로 개발을 진행

• 각 주기별로 계획 , 실천 , 회고를 반복 .

• 각 주기별로 구현할 개발 항목을 선정

• 개발자가 개발할 항목을 선택

• 매일 마다 진행 사항을 공유

• 자세한 사항은 별도로 소개


효과

• 일정 예측이 용이해 진다 .• 일정 조정이 용이해 진다 .• 팀원이 원하는 업무를 선택할 수 있다 .• 팀 개발 환경 자체의 개선이 가능하다 .• 업무 백업이 자연스럽게 된다 .


SCRUM 효과 - 일정 예측이 용이해 진다 .

• 스토리 포인트를 사용하여 각 업무별 크기를 결정한다 .

• 스토리 포인트– 관련자들이 모두 모여 크기를 투표한다 .– 최대치와 최소치를 제시한 자가 생각을 설명한다 .– 만장일치 될 때까지 반복한다 .

• 소수가 어렴풋이 산정한 일정보다는 정확하다 .

• 산정된 업무의 크기와 실제 진행된 크기를 가지고 팀의 개발 속도를 구할 수 있다 .

• 첫 번 째 주기 이후에는 이 개발 속도를 가지고 진행할 수 있는 업무 범위를 비교적 정확하게 추정할 수 있다 .


SCRUM 효과 - 일정 조정이 용이해 진다 .

• 돌발성 업무가 발생한 경우 초과되는 스토리 포인트만큼의 업무를 우선순위에 따라 배제한다 .

• 이미 빡박한 일정에서 끼어드는 돌발성 업무에 합리적으로 대처할 수 있다 .

• 관리자에게 중요한 것은 어느 시점에서 특정 업무의 완료 여부를 예측할 수 있는 지이다 .


SCRUM 효과 - 팀원이 원하는 업무를 선택할 수 있다 .

• 업무를 팀장의 결정에 의한 할당이 아닌 , 나열된 업무 중에 개발자가 선택하게 한다 .

• 이러한 점은 개발자 동기 부여에 크게 영향을 끼친다 .


SCRUM 효과 - 팀 개발 자체의 개선이 가능하다 .

• 계획 , 실행 , 회고의 과정을 통하여 보다 합리적이고 , 효율적이고 , 참여할 수 있는 시스템으로 개선할 수 있다 .

• 소프트웨어 개발의 가장 중요한 요소는 개발자이다 .

• 개발자의 동기 부여가 프로젝트 성공을 결정한다 .


SCRUM 효과 - 업무 백업이 자연스럽게 된다 .

• 특정 분야의 업무는 특정 개발자가 담당하는 것이 아니라 , 희망자가 선택하게 되어 자연스럽게 업무의 백업이 이루어진다 .

• 팀 전체의 업무를 알게 된다 .

• 기술적 기반이 다른 경우가 아니라면 자연스럽게 업무를 순환할 수 있다 .


위험성


위험성 항목들

• 지체되는 일정• 팀원의 무관심• 미검증 기술


위험성 – 지체되는 일정

• 분석과 설계에 팀원 모두가 참여할 경우 진행이 늦어진다 .

• 방안– 분석 / 설계 단계의 기간을 충분히 갖는 것이지 전체

프로젝트가 지연되는 것이 아니다 .– 더욱이 유지보수가 쉬워진다 .


위험성 - 팀원의 무관심

• 팀원이 무관심할 경우 일반적인 개발방법보다 프로젝트 진행이 위험할 수 있다 .

• 방안– 능동적으로 개선할 수 있는 것으로 의욕을

고취하여야 한다 .


위험성 – 미검증 기술

• 구현 단계에서 미검증된 기술의 문제로 인해 프로젝트가 위험하게 될 수 있다 .

• 방안– 분석 / 설계 기간 중에 검증하거나 대안을 찾는다 .


실천 항목 요약


요약된 실천 항목

• 분석 / 설계에 중점

• 자동화

• 테스트 케이스

• 리뷰

• SCRUM


상상


구현 시의 개발자의 모습

• 아침에 출근하여 daily build 가 잘못된 것이 있는지 확인한다 . 있으면 이를 최우선으로 처리한다 .

• standup 미팅에 참석하여 팀의 진행 사항을 파악한다 . 고민되고 있다는 타인의 문제에 대해서 도움을 주어야 겠다고 언급 . 나의 진행 상황은 별 특이사항이 없어서 패스한다 .

• 새로운 컴퍼넌트 구현의 업무를 선택한다 .• 구현할 컴퍼넌트에 대한 정의를 시스템 설계서에서 확인한다 .• 어떻게 구현할 지를 이리 저리 고민하고 , 그 결과를 문서로

작성한다 .• 그 문서를 리뷰 받는다 .• 정의된 인터페이스를 구현한 껍데기 컴퍼넌트를 코딩한다 .• 이를 사용한 테스트 케이스를 작성한다 .• 껍데기 컴퍼넌트의 로직을 완성하고 , 테스트 케이스가

성공함을 확인한다 .• 전체 테스트 케이스가 동작함을 확인한다 .• 커밋하고 로그를 남긴다 .


유지보수 시의 개발자 모습

• 아침에 출근하여 daily build 의 결과를 확인한다 .• standup 미팅에서 버그를 업무로 선택한다 .• 대상 버전의 소스를 다운로드한다 .• 버그를 재현하는 테스트 케이스를 작성한다 .• 작성한 테스트 케이스가 성공하도록 본 코드를 수정한

다 .• 기존 모든 테스트 케이스가 성공하는 것을 확인한다 .• 본 코드와 테스트 케이스를 커밋하고 버그 트랙킹

시스템에 메시지를 남긴다 .


기타


개발 환경 안 for Java

• Eclipse for IDE• JUnit for test framework• maven for build tool• SVN for SCM• TRAC for issue tracking system• Hudson for daily build & auto test• SpingNote for documentation share• <<TODO : ? >> for flex test framework• JBoss for WAS


고민되다 언급하지 않은 실천 항목

• 야근 금지• 자기 계발 의무• 일정 버퍼링

Copyright © 2009 Xener Systems, Inc. All Rights Reserved.

Special Thanks!Are There Any Other Questions?

프로젝트 Xxx에 적용하고 싶은 개발방법

Technology