프로젝트 에코시스템(개발환경의 효율적 개선)
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

프로젝트 에코시스템(개발환경의 효율적 개선)

on

  • 713 views

아주 오래전에 OKJSP 커뮤니티에서 발표했던 PPT 자료입니다. ...

아주 오래전에 OKJSP 커뮤니티에서 발표했던 PPT 자료입니다.

2008.04.23 [OKJSP세미나-서울] 레거시 코드와 개발환경의 효율적 개선 - http://180.150.228.177/seq/115256
2008.04.26 [OKJSP세미나-부산] 레거시 코드와 개발환경의 효율적 개선 - http://www.okjsp.pe.kr/seq/114988

Statistics

Views

Total Views
713
Views on SlideShare
713
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 이러한 요소가 잘 갖춰진 환경일 때 자연스레 소프트웨어의 품질은 향상 될 것입니다 . 하지만 이러한 환경을 도입하기에 앞서 고려할 것이 있습니다 . 어떤 소프트웨어 제품이건 간에 모든 문제를 해결해 주지 못합니다 . 제가 설명 드릴 내용 또한 마찬가지 일겁니다 .. 개발환경 개선에 앞서 무엇보다도 중요한 것은 팀 구성원 전체가 개발환경 개선의 필요성을 인식하고 다 함께 개발환경을 개선에 동참할 때 좋은 품질을 내는 개발환경을 구축하실 수 있을 겁니다 .
  • 여러분들도 이러 생각을 해보신 경험이 있으실 겁니다 .
  • 이 말은 시간이 흘러 그때를 돌이켜 봤을 때 득보다는 실이 더 크다란 사실을 깨닫게 됨을 의미합니다 .
  • 이 시간관리 메트릭스를 통해 이전에 보여드렸던 나무꾼이 어느 상한에 해당하는지 살펴보도록 하겠습니다
  • 전 불과 얼마 전까지만 해도 긴급성 패러다임에 심취해 일을 해 왔었습니다 . 항상 납기에 쫓겨 계획되지 않은 문제들과 싸우느라 정작 신경 써야 할 중요한 문제는 놓치는 일이 비일비재하였죠 그러다 보니 저의 시간관리 메트릭스는 다음 도표와 같았습니다 . 하지만 근래에 들어서는 좋은 습관 두 가지를 몸에 익혔고 이를 통해 긴급성 패러다임에서 탈출 할 수 있었습니다 . 그 습관은 바로 매일 아침 업무 시작 전에 그 날 하루의 일과를 정리하는 Todo List 작성과 주어진 업무 스케쥴링 시 최대한 여유를 가질 수 있도록 시간안배를 하는 것 입니다 . 이 두 가지를 통해 하루 일과를 계획적으로 수행하고 예측하지 못한 문제에 대해 여유 있게 대처할 수 있었습니다 . ( 클릭 ) 이를 통해 저의 시간관리 메트릭스는 도표 2 와 유사하게 변하였습니다 . 물론 아직까지 2 상한에서 보내는 시간이 적지만 개선하고자 마음 먹었을 때 어떤 부분을 잘 조절하면 되는지 알게 되어 효율적으로 환경을 개선하는데 필요한 힘을 얻게 되었습니다
  • 이 회사는 사이냅소프트라는 개발업체이며 문서필터를 개발을 전문으로 하는 업체로서 개발 체계를 오픈 해둔 우리나라에 몇 안 되는 개발업체입니다 . -- 링크 오픈 개발체계를 보면 VMWARE 를 이용한 다양한 개발환경 관리 , 소스관리 , 소스리뷰 , 프로젝트 관리 , 기술세미나 등 좋은 품질을 위한 실천사항을 잘 준수하고 있습니다 . 더불어 사이냅이 개발체계를 왜 소개하고 있을까에 대한 의문이 생기는데 어차피 문서필터란 제품의 특성상 실무자들이 구매를 결정하는 것이기에 이러한 개발체계 노출은 요즘 많이 소개되는 LCD 모니터 생산공장의 생산라인을 소개하여 제품의 신뢰도를 높이는 마케팅 전략과 유사하다고 생각되어 집니다 . 이러한 노출이 전략적이건 그렇지 않건 간에 상당히 좋은 모습으로 비춰지는 것이 사실입니다 .
  • 소스관리시스템을 적용한 후 개발자가 백업에 신경 쓰지 않아도 된다는 것을 보여드리도록 하겠습니다 . 이 화면은 subversion 클라이언트 툴 중 하나인 Tortoisesvn 을 이용해 소스저장소 로그보기 기능을 수행한 화면입니다 .
  • Winmerge 를 이용해 소스파일 리비전별 차이점을 비교해보았습니다
  • 기존 개발환경이 가지는 문제점 - UNDO 버튼 없는 에디터 ( 개발환경 ) - 동일한 파일 작업 시 작업상태 보장 안됨 ( 서로 다른 개발자가 하나의 파일을 동시에 수정할때 ) 개발자의 실수로 소스가 삭제될 우려가 있는 환경 등등의 많은 단점이 존재하지만 초기 셋팅이 용이함과 사용이 편하다는 점때문에 지금도 사용되고 있는 개발환경입니다 .
  • 이 시스템에 대한 장점에 대해서는 이미 설명했기 때문에 장점은 넘어가도록 하겠습니다 . 단점만 보자면은 소스관리 시스템에 대한 배경지식이 없으신 분들이 처음 이 시스템을 접하게 되면 기존의 공유시스템과는 개념이 많이 달라서 접근하기가 쉽지 않다는 단점이 있습니다 .
  • 네 !! 이것으로 소스관리 시스템에 대해 살펴보았습니다 . 다음으로 넘어가기에 앞서 블리자드사 개발자가 캡쳐한 스타크래프트 2 의 한 장면을 보여드리겠습니다 이 사진을 보고 특이한 점을 발견하셨나요 ?~ 그렇습니다 . 바로 스타크래프트 2 의 소스관리 도구로 subversion 을 이용하고 있습니다 .
  • Posco 에서 월화수목금금금 할 당시에 작업문서들을 정리한 것입니다 . “ 찾기 ”가 너무 힘듦 구글데탑을 통해 찾기 다른 사람과의 이슈 공유되지 않아 커뮤니케이션도 힘듦 만든 사람만이 알아볼 수 있는 이슈 관리 !!
  • 위키에 대해 좀 더 직관적으로 소개해드리기 위해 위지윅 에디터를 보여드리겠습니다 . 이 화면은 스프링노트 프로토타입 시연 동영상입니다 .
  • 위키로 관리할 때 이점은 이슈와 관련된 내용을 한곳에서 모두 볼 수 있다는 점과 빠르게 작성할 수 있고 , 누구나 추가 , 수정 , 삭제 할 수 있는 것이 아닐까 생각됩니다 .
  • 4 단계는 앞으로 이슈관리방법을 발전시켜 나갈 모델입니다 . 예제로 테터툴즈의 이슈추적 시스템을 소개 드리겠습니다 . 화면을 보시면 다음과 같이 ticket 으로 불리는 이슈들이 있고 이슈에 대한 개요와 change history 가 보여집니다 . 그럼 ( 링크 클릭 ) 하여 보도록 하겠습니다 .
  • ( 리딩 ) Mylyn 에 대한 경험이 없어 소개만 잠깐 하고 넘어가도록 하겠습니다
  • 이러한 이슈 관리 시스템도 방치하면 어떻게 되는지 한번 살펴보겠습니다 . PlayXP 는 게임 커뮤니티 사이트이며 이 사이트는 특이하게도 버그 신고나 건의사항을 기존의 게시판형태에서 벗어나 trac 의 이슈를 아무나 등록할 수 있도록 해 실제 사용자들이 직접 이슈를 등록할 수 있게끔 해두었습니다 . ( 링크 클릭 ) 하지만 작년 8 월부터 관리를 하지 않아 trac 에 온갖 스팸이 난무하는 상황에 치닿게 되었습니다 . 이러한 이슈관리 시스템을 오픈 하고도 지속적으로 관리하지 않는다면 어떻게 되는지 경각심 (?) 을 일깨우게 하는 사례로 보입니다 .
  • 시간이력 메뉴는 Trac 을 사용하면서 가장 빈번하게 들여다 메뉴 중 하나입니다 . 시간이력에는 지난밤 누가 코딩을 했는지 , 무엇을 고쳤는지 , 내가 모르는 사이에 어떤 이슈가 발생했는지 등을 쉽게 파악할 수 있습니다 . 하지만 이 기능을 활용하기 주의 하셔야 할 점은 “절대 시간이력을 평가도구로 사용하지 마시라고 말씀 드리고 싶습니다 . 그렇게 되면 사용자들은 이 시스템을 사용하기 꺼려 할 것입니다 .
  • 마일스톤 관리입니다 . 이 부분은 테터툴즈의 구성이 명료하여 테터툴즈의 로드맵을 이용해 예를 들어 보겠습니다 . 이 메뉴는 주로 관리자가 이용하는 메뉴가 될 것입니다 . 관리자의 주 관심사는 현재 진척상황이 어느 정도인지 파악하는 것이기 때문이죠
  • 네 !! 이것으로 이슈관리 시스템에 대해 살펴보았습니다 . 다음으로 넘어가기에 앞서 제 2 의 폴포츠라 불리우는 앤듀류의 노래솜씨를 감상해 보도록 하겠습니다 .
  • 제가 오늘 준비한 세미나는 여기까지 입니다 . 회사에서 지속적인 통합 부분은 현재 적용 초기 단계라 아직 경험이 부족 경험과 내공이 쌓이는 그 때 나머지 부분을 가지고 세미나 하겠습니다
  • 끝으로 질문과 답변을 해 보는 시간을 가지겠습니다 . 강의 내용 중에서 궁금한 점이나 잘 이해하지 못한 부분 등을 질문해 주시기 바랍니다 .
  • 이상으로 발표를 마치도록 하겠습니다 . 끝까지 경청해 주셔서 대단히 감사합니다 .

프로젝트 에코시스템(개발환경의 효율적 개선) Presentation Transcript

  • 1. 프로젝트 에코시스템( 개발환경의 효율적 개선 ) 발표자 : 강대권 ( 프리챌 ) E-mail : ncrash.dk@gmail.com
  • 2. Agenda 1. 좋은 품질을 내는 개발 환경이란 2. 버전관리 시스템 3. 이슈관리 시스템 4. 최종목표는 지속적인 통합
  • 3. 좋은 품질을 내는 개발 환경이란 1. 소스가 건강하고 2. 이슈에 대한 의사소통이 원활 하고 3. 반복적인 작업을 줄여 이슈에 집중할수 있는
  • 4. The Joel Test: 나은 코딩을 위한 12 단계 1. Source Control( 소스 컨트롤 ) 을 사용하십니까 ? 2. 한번에 빌드를 만들어낼 수 있습니까 ? 3. daily build( 일별 빌드 ) 를 만드십니까 ?
  • 5. The Joel Test: 나은 코딩을 위한 12 단계 1. Source Control( 소스 컨트롤 ) 을 사용하십니까 ? 2. 한번에 빌드를 만들어낼 수 있습니까 ? 3. daily build( 일별 빌드 ) 를 만드십니까 ? 4. 버그 데이타베이스를 가지고 있습니까 ? 5. 새로운 코드를 작성하기 전에 버그들을 잡습니까 ? 6. up-to-date( 최신 ) 스케줄을 가지고 있습니까 ? 7. spec( 설계서 ) 를 가지고 있습니까 ? 8. 프로그래머들이 조용한 작업환경을 가지고 있습니까 ? 9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까 ? 10. 한테스터들을 고용하고 있습니까 ? 번에 빌드를 만들어낼 수 있습니까 ? 11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까 ? 12. hallway usability testing( 무작위 사용성 테스팅 ) 을 하십니까 ?
  • 6. < 출처 : 소중한것 먼저하기 V2.0>
  • 7. < 출처 : 소중한것 먼저하기 V2.0>
  • 8. < 출처 : 소중한것 먼저하기 V2.0>
  • 9. < 출처 : 소중한것 먼저하기 V2.0>
  • 10. < 출처 : 소중한것 먼저하기 V2.0>
  • 11. < 출처 : 소중한것 먼저하기 V2.0>
  • 12. < 출처 : 소중한것 먼저하기 V2.0>
  • 13. < 출처 : 소중한것 먼저하기 V2.0>
  • 14. < 출처 : 소중한것 먼저하기 V2.0>
  • 15. 좋은 품질을 유지하는 개발 사례 - 1
  • 16. 좋은 품질을 유지하는 개발 사례 - 2
  • 17. 좋은 품질을 유지하는 개발 사례 - 3
  • 18. 버전 관리 시스템 * 개발 버전과 릴리즈 버전이 섞이지 않고 쉽게 관리 * 소스를 잘못 수정 했더라도 기록이 남고 되돌리기 원활 * 수정 , 추가 , 삭제 등의 기록이 모두 남고 변경 사항을 추적하기 쉬움 * 개발자들이 따로 따로 백업 할 필요 없음
  • 19. 소스관리 시스템 적용 전 소스 관리
  • 20. 소스관리 시스템 적용 후 소스 관리 - 1
  • 21. 소스관리 시스템 적용 후 소스 관리 - 2
  • 22. 소스관리 시스템 적용 전 공유 개발
  • 23. 소스관리 시스템 적용 후 개발
  • 24. 이슈 관리 시스템 * 협업은 함께 코드를 작성하는 것만을 의미하는 것이 아니다 . 누군가와 함께 일하는 모든 것을 의미한다 . 협업이 중요한 이슈로 떠오르는 이유는 협업의 성패가 곧 프로젝트의 성공 여부와도 밀접하게 연관되어 있기 때문이다
  • 25. 이슈관리 방법의 변화 단계 시기 이슈정리방법1 단계 2001~2004 일일 업무에 이슈관리2 단계 2005~2006 작업폴더를 통한 이슈관리3 단계 2007~ 현재 위키를 통한 이슈관리4 단계 To be Ticket 을 통한 이슈관리
  • 26. 1 단계 일일 업무에 이슈관리 “ 샘플이 없어요”
  • 27. 2 단계 작업폴더를 통한 이슈관리
  • 28. WIKI < 출처 : 위키피디아 >
  • 29. WIKI - 위지윅 편집 지원 에디터 소개 < 출처 : 오픈마루 >
  • 30. 3 단계 위키를 통한 이슈관리
  • 31. TICKET < 출처 : 조인시 위키 : 위키를 이용한 업무지원 시스템의 개발 >
  • 32. 4 단계 이슈관리 시스템을 활용한 이슈 관리 < 출처 : http://textcube.org/>
  • 33. 이슈시스템의 확장 - Mylyn* Mylyn 은 태스크 중심 프로그래밍을 통해 개발자들의 정보 오버로드를 줄여주 고 , 개발 효율을 높여주는 이클립스 플러그인 입니다* Mylyn 이 제공하는 Task List 와 Task Repository 뷰를 통해 , 로컬에서 개인 적인 태스크들을 관리하거나 , 버그질라 같은 웹 기반 이슈 트래커와 연결하여 여러 사람이 공유하는 태스크들을 관리할 수 있습니다 . < 출처 : Mylyn 2.0: 태스크 중심 프로그래밍 >
  • 34. 이슈관리 시스템을 방치하면
  • 35. Trac 주요기능 - 위키
  • 36. Trac 주요기능 - 시간이력
  • 37. Trac 주요기능 - 로드맵 < 출처 : http://textcube.org/>
  • 38. Trac 주요기능 - 소스브라우저
  • 39. Trac 주요기능 - 티켓들보기 < 출처 : http://textcube.org/>
  • 40. Trac 주요기능 - 새로운티켓
  • 41. Trac 주요기능 - 검색
  • 42. 지속적인 통합* 흔히 발생하는 일반적인 위험을 줄여준다* 반복적인 수작업을 줄여준다* 언제 어느 때라도 배포할 수 있는 소프트웨어를 생성해낸다* 프로젝트 가시성을 보다 좋게 해준다* 개발 팀이 소프트웨어 제품에 대해 보다 큰 자신감을 갖게 해준다
  • 43. 지속적인 통합 컴포넌트 < 출처 : 지속적인 통합 >
  • 44. 피드백 장치 - 1피드백 장치 설명 이미지 빌드 상태를 때에 맞춰 제공한 이메일 다. 빌드 상태와 관련한 경고를 RSS RSS 리더기로 보낸다 . 빌드 상태에 대해 셀폰에 텍스트 SMS 메시지를 보낸다 . < 출처 : 사람을 위한 자동화 : 지속적인 피드백 ( 한글 )>
  • 45. 피드백 장치 - 2피드백 장치 설명 이미지 시각적 방식으로 피드백을 보낸 X10 다 . LAVA 램프와 빨간 경고등이 대표적인 예이다   빌드 상태를 알려주는 또 다른 시               Ambient Orb 각적인 방식이다 . 특정 정보에 따라 커스터마이징 될 수 있다 . Windows 태스크바에서 빌드 상태 모니터 를 알려준다 . < 출처 : 사람을 위한 자동화 : 지속적인 피드백 ( 한글 )>
  • 46. 참고자료 - 소중한 것 먼저하기 v2.0- The Joel Test: 나은 코딩을 위한 12단계- 조인시 위키 : 위키를 이용한 업무지원 시스템의 개발 :- 위키를 활용한 협업 노하우- 버전관리 usnig CVS- Subversion 사용 HOWTO- 윈도우에서 Subversion 서버 운영하기
  • 47. 참고자료 - 지속적인 통합- 기민한 방법론 XP와 기민한 문화 이야기 강연 녹취- Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드- 지속적인 통합- TDD - 오픈 소스 스터디 - Confluence- 사람을 위한 자동화: 지속적인 피드백 (한글)- Eclipse를 활용한 효율적인 팀 개발 및 배포 전략- Mylyn 2.0: 태스크 중심 프로그래밍
  • 48. “ 질문과 답변”“ 질문과 답변”
  • 49. “ 감사합니다 .”