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

3,062 views

Published on

소프트웨어 개발 프로젝트 XXX에 적용하고 싶은 개발 방법을 기술. 행복하게 개발하기가 목적.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,062
On SlideShare
0
From Embeds
0
Number of Embeds
144
Actions
Shares
0
Downloads
50
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

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

  1. 1. 프로젝트 XXX에 적용하고 싶은 개발방법<br />임도형<br />2010/04/21<br />dh-rim@hanmail.net<br />
  2. 2. 본 문서의 목적<br />프로젝트 XXX를 진행할 때 적용할 개발 방법을 제안합니다.<br />
  3. 3. 적용하고자 하는 방법의 목적<br />모두가 행복하기 위하여<br />개발자<br />개발 다운 개발<br />관리자<br />일정 잘 맞추고, 개발자 관리 좋고, 유지보수 좋고<br />회사<br />잘 팔리고, 1인당 매출액 좋고, 유지보수 비용 적고<br />고객<br />저렴한 가격에, 성능/기능 좋고, 기능 개선과 버그 픽스 빠르고.<br />
  4. 4. 행복하기 위한 각 관련자의 역할<br />개발자<br />최대한 제대로 개발할 수 있도록 노력<br />관리자<br />개발자가 제대로 개발할 수 있도록 지원<br />회사와의 일정 조율<br />회사<br />적절한 일정 제시<br />
  5. 5. 실천 항목<br />
  6. 6. 실천 항목<br />분석/설계 시에 팀원의 참여<br />충분한 분석/설계<br />GUI 개발도 설계를 기반으로<br />충분한 테스트 케이스<br />자동화된 빌드, 테스트<br />가독성을 최상의 품질 요소로<br />1일 빌드, 자동 테스트 실행<br />모든 산출물의 리뷰<br />scrum 적용<br />진행 상황에 따른 일정 조절 및 개발 범위 조정<br />팀원이 선택 가능한 업무 배분<br />계획과 회고에 따른 시스템 개선<br />
  7. 7. 분석/설계 시에 팀원의 참여<br />
  8. 8. 잘 팔리는 제품.<br />품질 속성만 만족하면 잘 팔릴까<br />기능, 성능, 안정성, 유지보수성, 확장성<br />잘 팔릴 만한 제품을 고민하는 것은 누구의 몫? 기획자?<br />언제나 기획은 불충분하다. 불충분할 수 밖에 없다.<br />소프트웨어에 기획자+개발자의 구도가 적당할까?<br />
  9. 9. 가치 창조하기<br />고객이 감동할 수 있는 가치를 찾아내야 한다. 제품에 불어넣어야 한다.<br />개발팀에서 해야 한다.<br />ideation을 통해 구체화 된다. 상상하고, 끄집어 내고, 검토하고, 정의하고.<br />프로젝트 관련자 모두가 참여하는 것이 바람직하다.<br />이러한 ideation은 분석단계에서 진행되며, 작업 결과는 보통 요구사항의 형태로 정리된다.<br />즉 요구사항정의 시에도 팀원 전원의 참여가 필요하다.<br />
  10. 10. 소프트웨어 개발에서의 생각<br />개발에서 생각하는 것은 분석/설계에 관련된 것이다.<br />코딩은 단지 그 결과를 코드로 구현하는 것 뿐이다.<br />생각을 하게 하지 않는 개발업무는 개발자의 의욕을 꺽는다. 개발자를 생각하게 하여야 한다.<br />
  11. 11. 분석/설계의 구분<br />3가지로 구분된다.<br />시스템 구조 분석/설계<br />기반 분석/설계<br />기능 컴퍼넌트 분석/설계<br />
  12. 12. 시스템 구조 분석/설계<br />각 기능을 제공할 컴퍼넌트의 정의와 컴퍼넌트 간의 관계 정의<br />각 컴퍼넌트들마다의 기능 요구사항을 정의하고, 각 컴퍼넌트의 인터페이스까지 정의한다.<br />기술적인 측면 보다는 시스템 전체적인 흐름을 이해하기 위하여 팀원 모두가 참여하는 것이 바람직하다.<br />이 단계를 참여하지 못한 개발자는 전체적인 시스템을 이해하기 어렵다.<br />업무의 백업이 어렵다.<br />업무의 선택이 어려워 진다.<br />지엽적인 개발이 될 수 밖에 없다.<br />
  13. 13. 기반 분석/설계<br />일반적인 시스템에서 필요로 하는 기능을 제공한다.<br />예 : 컴퍼넌트 로딩, 로그, 통신 방법<br />성능에 많은 영향을 끼친다.<br />기술적인 난이도가 있다.<br />타 컴퍼넌트의 개발에 기반이 되며, 선행되어야 한다.<br />보통 Application Server, framework이 대신하기도 한다.<br />모든 팀원이 참여하기 곤란하다.<br />
  14. 14. 기능 컴퍼넌트 분석/설계<br />구조 설계에서 정의한 각 컴퍼넌트 자체를 구현하기 위한 것.<br />특정 업무 담당자가 진행한다.<br />구현할 기능과 타 컴퍼넌트와의 인터페이스는 구조 설계에서 정의되어 있다.<br />
  15. 15. 실 적용 사례<br />6개월 일정의 프로젝트에서 3개월을 분석/설계로 진행했으며, 코딩, 테스트, 패키징에 각각 1개월씩이 소요됨.<br />코딩 1개월 때는 고민할 사항 없이 깔끔하게 진행되었고, 이후 테스트,패키징에서도 문제가 발생하지 않았다.<br />설계된 사항이 크게 변경되는 것이 없었으며, 이러한 이유로 프로젝트 완료와 유시보수 시에도 문서가 살아있었다.<br />버그픽스는 설계와 관계없는 것이고, 기능 추가는 설계서에 추가하면 되고.<br />
  16. 16. 충분한 분석/설계<br />
  17. 17. 분석/설계와 코딩<br />개발의 실체는 고민이다.<br />고민 과정이 분석/설계이고, 코딩은 그 구현일 뿐이다.<br />코딩 시에 고민하게 되면 삽질이 필수적이다.<br />코딩 시에는 고민을 하지 않아야 한다. 최대한 지양하여야 한다.<br />어차피 고민해야 하는 것을 분석/설계에서 마무리하고 코딩으로 들어가야 한다.<br />모든 분석/설계는 리뷰를 통해 구현 전에 검토하는 것을 원칙으로 한다.<br />
  18. 18. GUI개발도 설계를 기반으로<br />
  19. 19. GUI 개발의 특징<br />GUI에 대한 평가가 제품 전체에 대한 평가로 적용되기도 한다.<br />까다로운 사용자 편의성을 제공해야 한다.<br />또한 디자인적인 요소도 포함되어야 하기에 단순 개발역량만으로는 안된다.<br />그러나 개발 과정 자체는 단순 노가다에 가깝다.<br />개발 자동화도 어렵다.<br />테스트 자동화도 어렵다.<br />무척 중요하지만 어렵고도 지치게 한다.<br />
  20. 20. GUI의 분석과 설계<br />가장 문서화하기 힘든 부분이다.<br />더불어 가장 삽질을 많이 하는 부분이다. 또한 삽질의 크기가 큰 부분이다. 그렇기 때문에 설계가 더더욱 중요하다.<br />설계된 결과의 형태는 중요하지 않다. 종이에 그리건, 툴로 그리건.<br />중요한 것은 설계가 되어야 하고, 검토 후에 구현되어야 한다는 것이다.<br />
  21. 21. 설계의 의미<br />개발중의 고민이 설계이다.<br />코딩하기 전에 고민을 충분히 하지 않으면, 코딩 중에 뒤엎기가 발생한다.<br />GUI 개발도 코딩이며, 역시 충분히 고민해 놓지 않으면 뒤엎기가 발생한다.<br />GUI 특징으로 인해 설계는 그림으로 그려져야 하고, 이는 다른 부분의 설계보다 손이 많이 간다.<br />하지만 그렇더라도 설계가 충분히 되어야 한다. 설계를 뒤엎는 것이 코드를 뒤엎는 것보다 낳다.<br />설계된 결과는 상상할 필요 없이 눈으로 확인되어야 한다.<br />
  22. 22. GUI 설계 참여자<br />GUI는 단지 view가 아니다. 시스템 전체의 기능을 눈으로 보여준다.<br />GUI 개발자도 시스템 전체를 이해해야하고, 타 부분 개발자도 GUI를 파악하고 있어야 한다.<br />전체 시스템의 이해를 포기하는 순간, 생각을 배제하는 개발자 즉 코더임을 자청하는 것이다.<br />GUI의 이해를 포기하는 순간, 전체 시스템 파악을 포기하는 것이다.<br />
  23. 23. 테스트 케이스<br />
  24. 24. why must 테스트 케이스<br />영향도 분석은 실제적으로 불가능하다. 대충하기도 무척 어렵다.<br />특정 부분을 변경 했을 때 기존의 것이 모두 제대로 동작하는지를 확인하는 유일한 방법은 충분한 테스트 케이스 뿐이다. 요걸 회귀테스트라 한다.<br />수정에 의한 감추어진 버그는, 테스트 케이스가 없다면 몇 달 뒤에 고객이 찾아 줄 것이다.<br />방금 수정한 것에 의한 버그를 테스트 케이스가 잡아준 경우와, 몇 달 뒤에 고객이 발견하여 등록된 경우 둘 사이의 버그 픽스의 공수, 난이도는 비교가 안된다.<br />
  25. 25. 어느 정도 양의 테스트 케이스<br />최소한 본 코드의 양과 동일한 라인 수의.<br />최소한 작업한 본 코드의 메소드 수와 동일한 개수의 테스트 케이스 개수.<br />최소한 본 코드의 사용예를 볼 수 있는.<br />컴퍼넌트 단위의 테스트 케이스는 충분히 꼼꼼하게.<br />시스템 단위의 테스트 케이스는 QA팀에서도 활용할 수 있게. 혹은 QA팀에서 실행하는 테스트 항목 수 정도로. 혹은 QA팀에서 테스트 케이스를 직접 작성할 수 있도록.<br />
  26. 26. 자동 실행<br />모든 테스트 케이스는 한방에 실행 될 수 있어야 한다.<br />사람 손으로 일일이 실행하는 테스트 케이스는 제대로 활용되지 못한다. GUI 테스트는 그래서 더 어렵고 허술하다.<br />GUI와 같이 자동실행하기 어렵더라도, 최선의 방법을 찾아내야 한다.<br />
  27. 27. 테스트 케이스와 생산성<br />테스트 케이스 작성 역시 공수가 필요하다.<br />임도형이 파악하는 구현 시의 공수 증가는 1.5배정도.<br />임도형이 파악하는 유지보수 시의 공수 이득은 10배 정도.<br />개발 비용과 유지보수 비용을 1:2로 했을 때<br />비적용 공수 : 3 ( = 1+2 )<br />적용 공수 : 1.7 ( = 1*1.5 + 2*0.1 )<br />테스트 케이스 작성을 먼저 할 경우 해당 로직의사용예를 먼저 구현해 보는 효과가 있어서, 삽질을 많이 방지하게 한다.<br />구현 시의 공수는 유지보수 시에 발견될 버그를 구현 시에 픽스하는 것으로 생각할 수 있다.<br />
  28. 28. 테스트 케이스와 유지보수<br />타인이 개발한 부분을 파악할 때, 살펴 보기 가장 좋은 부분은 테스트 케이스이다.<br />컴퍼넌트 기반의 코드는 그 진입점을 찾기도 어렵다.<br />테스트 케이스 자체가 코드의 사용 예가 된다.<br />테스트 케이스 코드에는 대상 코드가 사용되는 입력값과출력값의 예도 있다.<br />새로운 기능을 추가하거나 버그를 수정하기 위해서는 로직을 전부 파악하고 목적에 맞는 샘플을 작성해야 한다. 기존에 테스트 케이스가 있으면, 이를 참조하기 넘 좋다.<br />
  29. 29. 테스트 케이스와 리팩토링<br />리팩토링은 기능은 그대로 유지한 채 내부의 구조를 개선하는 것이다.<br />시스템이 커질 수록 리팩토링의 필요성은 절대적이다.<br />테스트 케이스가 없이는 리팩토링은 불가능하다. 기존의 기능이 그대로인 것을 어떻게 보장하는가.<br />클래스의 이름 변경, 엔티티의 이름 변경과 같은 사소한 리팩토링 조차도 테스트 케이스 없이는 많은 손이 가고 힘들다.<br />테스트 케이스 없이는 구조 변경이나 뒤엎기는 큰 비용을 감수해야 한다.<br />
  30. 30. 그 외 효용<br />만약 어떤 컴퍼넌트가 테스트 케이스를 작성하기 어려운 경우라면, 시스템의 구조가 적절하지 않은 것이다.<br />테스트 케이스 작성이 용이하도록 하다보면 시스템의 구조가 좋아진다. 컴퍼넌트 간의 종속성이 줄어든다.<br />
  31. 31. 실 적용 사례<br />약 30개의 컴퍼넌트, 400개의 클래스로 이루어진 시스템에 약 2000개의 테스트 케이스가 있었다.<br />각 컴퍼넌트는 개별적으로 테스트 가능하였다.<br />릴리즈 이후 1년 간 최대 미 처리 버그수가 5개를 넘지 않았다. 유지 보수에 들어간 공수가 미미. 별도의 유지보수 인력 배정 불필요.<br />유지 보수 시에 어느 부분을 수정 후에 어느 테스트 케이스에서 실패하면 안도감이 느껴진다. 무엇을 선택할 것인가?<br />modify & pray<br />cover & improve<br />고의적으로 삽입된 버그의 검출률이80% 이상이 되도록 유지되었다.<br />
  32. 32. 가독성<br />
  33. 33. 가독성과 유지보수성<br />가장 좋은 코드는 읽기 쉬운 코드이다.<br />유지보수?<br />기능을 추가하거나 버그를 픽스하는 것.<br />주석을 읽어야 하거나, 문서를 읽어야 하거나, 로직을 파악하기 힘들면 유지보수가 힘들어 진다.<br />읽기 어려운 코드라면 주석을 잘 달거나, 문서를 잘 만들거나 별도의 노력을 해야 한다. 하지만 잘 안 된다. 이건 경험적 진리이다.<br />가독성이 떨어지면, 적지 않은 경우, 다시 개발한다.<br />
  34. 34. 가독성과 성능<br />일반적으로 가독성이 좋은 코드는 실행 시에 오버로드를 요구한다. (예: 별도로 뽑은 메소드, 인터페이스 사용)<br />성능 문제는 튜닝으로 처리해야 한다.<br />튜닝은 비정규화 작업이다. 정형화된 코드를 비정형화 하는 것은 쉽지만, 비정형화된 것을 정형화하는 것은 무척이나 어렵다.<br />전체 시스템의 성능에서 특정 부위가 좌우하는 비중을 가늠하는 것은 거의 정확하지 못하다.<br />가독성 없는 코드를 정리하는 것은 무척이나 어렵지만, 가독성 좋은 코드를 성능 튜닝하는 것은 할만하다.<br />
  35. 35. 가독성과 생산성<br />가독성 향상으로 인한 개발 시의 생산성 저하는 미미하다.<br />타이핑 시간이 생산성에 영향을 주지 않는다.<br />그보다는 유지보수성이 좋아지기 때문에 전체적인 생산성은 좋아진다.<br />
  36. 36. 가독성을 위한 실천 항목<br />단어의 축약 엄금.<br />축약은 가독성의 상극이다.<br />클래스명, 메소드명,변수명을 확실하게.<br />이름 짓기가 어렵다면 개념이 불확실한 것이다. 설계가 부족한 것이다.<br />주석 지양.<br />코드 자체로 이해가 되도록 한다. 주석은 이런 코드가 될 수 밖에 없는 사항을 설명하거나, 입출력의 예를 명시할 때만 사용한다.<br />하나의 블록은 50 line이 넘지 안게<br />indent는 3개까지만<br />
  37. 37. 자동화된 빌드/테스트<br />
  38. 38. 자동화<br />머리로 생각하는 개발에 집중하게 하자.<br />반복되는 것, 기계적인 업무의 것들을 자동화 하자.<br />빌드 자동화<br />빌드 스크립트.<br />daily build<br />테스트 자동화<br />모든 테스트는 사람이 손이 아닌 한방에 가능하게.<br />자동화를 위한 툴이나 환경을 위한 개발이 필요할 수도 있다. 이런 것도 개발이며, 업무에 포함된다.<br />
  39. 39. 일일 빌드<br />보통 CI(Continuous Integration)이라고도 한다.<br />프로젝트 내내 빌드되고 테스트 성공하는 것을 보장한다.<br />이것이 없이는 빌드성공하고 테스트 성공하는 것에 대한 강제성이 없어진다.<br />빌드가 안되거나 테스트가 실패한 코드는 타 팀원의 업무를 진행하지 못하게 한다.<br />목숨처럼 지켜야 하는 것.<br />
  40. 40. 리뷰<br />
  41. 41. 리뷰 방법<br />모든 업무 결과를 리뷰한다.<br />정규적 혹은 비정규적으로 진행한다. 대신 2주 이상을 넘기면 안된다.<br />하나의 업무에 대한 리뷰 시간은 30분 정도로 하고, 최대 1시간을 넘지 않는다.<br />프로세스 상에 언급된 산출물의 경우 리뷰 자체를 업무로 진행한다.<br />
  42. 42. 코드 리뷰 대상<br />리뷰 대상은 문서, 테스트 케이스, 본 코드이다.<br />문서<br />외부와의 인터페이스<br />그렇게 로직을 구성한 이유<br />이외의 모든 고민이 담겨 있어야 한다.<br />테스트 케이스<br />중점 리뷰 사항<br />테스트 케이스 양의 적절함<br />테스트 케이스 안의 코드 샘플의 적절함<br />본 코드<br />일반적인 가독성<br />상식적인 품질<br />
  43. 43. SCRUM 적용<br />
  44. 44. 스트럼의 개요<br />한달 정도의 주기로 개발을 진행<br />각 주기별로 계획, 실천, 회고를 반복.<br />각 주기별로 구현할 개발 항목을 선정<br />개발자가 개발할 항목을 선택<br />매일 마다 진행 사항을 공유<br />자세한 사항은 별도로 소개<br />
  45. 45. 효과<br />일정 예측이 용이해 진다.<br />일정 조정이 용이해 진다.<br />팀원이 원하는 업무를 선택할 수 있다.<br />팀 개발 환경 자체의 개선이 가능하다.<br />업무 백업이 자연스럽게 된다.<br />
  46. 46. SCRUM 효과 - 일정 예측이 용이해 진다.<br />스토리 포인트를 사용하여 각 업무별 크기를 결정한다.<br />스토리 포인트<br />관련자들이 모두 모여 크기를 투표한다.<br />최대치와 최소치를 제시한 자가 생각을 설명한다.<br />만장일치 될 때까지 반복한다.<br />소수가 어렴풋이 산정한 일정보다는 정확하다.<br />산정된 업무의 크기와 실제 진행된 크기를 가지고 팀의 개발 속도를 구할 수 있다.<br />첫 번 째 주기 이후에는 이 개발 속도를 가지고 진행할 수 있는 업무 범위를 비교적 정확하게 추정할 수 있다.<br />
  47. 47. SCRUM 효과 - 일정 조정이 용이해 진다.<br />돌발성 업무가 발생한 경우 초과되는 스토리 포인트만큼의 업무를 우선순위에 따라 배제한다.<br />이미 빡박한 일정에서 끼어드는 돌발성 업무에 합리적으로 대처할 수 있다.<br />관리자에게 중요한 것은 어느 시점에서 특정 업무의 완료 여부를 예측할 수 있는 지이다.<br />
  48. 48. SCRUM 효과 - 팀원이 원하는 업무를 선택할 수 있다.<br />업무를 팀장의 결정에 의한 할당이 아닌, 나열된 업무 중에 개발자가 선택하게 한다.<br />이러한 점은 개발자 동기 부여에 크게 영향을 끼친다.<br />
  49. 49. SCRUM 효과 - 팀 개발 자체의 개선이 가능하다.<br />계획, 실행, 회고의 과정을 통하여 보다 합리적이고, 효율적이고, 참여할 수 있는 시스템으로 개선할 수 있다.<br />소프트웨어 개발의 가장 중요한 요소는 개발자이다.<br />개발자의 동기 부여가 프로젝트 성공을 결정한다.<br />
  50. 50. SCRUM 효과 - 업무 백업이 자연스럽게 된다.<br />특정 분야의 업무는 특정 개발자가 담당하는 것이 아니라, 희망자가 선택하게 되어 자연스럽게 업무의 백업이 이루어진다.<br />팀 전체의 업무를 알게 된다.<br />기술적 기반이 다른 경우가 아니라면 자연스럽게 업무를 순환할 수 있다.<br />
  51. 51. 위험성<br />
  52. 52. 위험성 항목들<br />지체되는 일정<br />팀원의 무관심<br />미검증 기술<br />
  53. 53. 위험성 – 지체되는 일정<br />분석과 설계에 팀원 모두가 참여할 경우 진행이 늦어진다.<br />방안<br />분석/설계 단계의 기간을 충분히 갖는 것이지 전체 프로젝트가 지연되는 것이 아니다.<br />더욱이 유지보수가 쉬워진다.<br />
  54. 54. 위험성 - 팀원의 무관심<br />팀원이 무관심할 경우 일반적인 개발방법보다 프로젝트 진행이 위험할 수 있다.<br />방안<br />능동적으로 개선할 수 있는 것으로 의욕을 고취하여야 한다.<br />
  55. 55. 위험성 – 미검증 기술<br />구현 단계에서 미검증된 기술의 문제로 인해 프로젝트가 위험하게 될 수 있다.<br />방안<br />분석/설계 기간 중에 검증하거나 대안을 찾는다.<br />
  56. 56. 실천 항목 요약<br />
  57. 57. 요약된 실천 항목<br />분석/설계에 중점<br />자동화<br />테스트 케이스<br />리뷰<br />SCRUM<br />
  58. 58. 상상<br />
  59. 59. 구현 시의 개발자의 모습<br />아침에 출근하여 daily build가 잘못된 것이 있는지 확인한다. 있으면 이를 최우선으로 처리한다.<br />standup 미팅에 참석하여 팀의 진행 사항을 파악한다. 고민되고 있다는 타인의 문제에 대해서 도움을 주어야 겠다고 언급. 나의 진행 상황은 별 특이사항이 없어서 패스한다.<br />새로운 컴퍼넌트 구현의 업무를 선택한다.<br />구현할 컴퍼넌트에 대한 정의를 시스템 설계서에서 확인한다.<br />어떻게 구현할 지를 이리 저리 고민하고, 그 결과를 문서로 작성한다.<br />그 문서를 리뷰 받는다.<br />정의된 인터페이스를 구현한 껍데기 컴퍼넌트를코딩한다.<br />이를 사용한 테스트 케이스를 작성한다.<br />껍데기 컴퍼넌트의로직을 완성하고, 테스트 케이스가 성공함을 확인한다.<br />전체 테스트 케이스가 동작함을 확인한다.<br />커밋하고 로그를 남긴다.<br />
  60. 60. 유지보수 시의 개발자 모습<br />아침에 출근하여 daily build의 결과를 확인한다.<br />standup 미팅에서 버그를 업무로 선택한다.<br />대상 버전의 소스를 다운로드한다.<br />버그를 재현하는 테스트 케이스를 작성한다.<br />작성한 테스트 케이스가 성공하도록 본 코드를 수정한다.<br />기존 모든 테스트 케이스가 성공하는 것을 확인한다.<br />본 코드와 테스트 케이스를 커밋하고 버그 트랙킹 시스템에 메시지를 남긴다.<br />
  61. 61. 기타<br />
  62. 62. 개발 환경 안 for Java<br />Eclipse for IDE<br />JUnit for test framework<br />maven for build tool<br />SVN for SCM<br />TRAC for issue tracking system<br />Hudson for daily build & auto test<br />SpingNote for documentation share<br /><<TODO : ? >> for flex test framework<br />JBoss for WAS<br />
  63. 63. 고민되다 언급하지 않은 실천 항목<br />야근 금지<br />자기 계발 의무<br />일정 버퍼링<br />
  64. 64. Special Thanks!<br />Are There Any Other Questions? <br />

×