내 용 | |
?접하게 되었을 때의 흥분이 아직도 생생하게 기억이 납니다. 어쩌면 이렇게 개발의 문제점을 정확하게 지적할까? 무엇보다 재미있을 꺼 같았습니다. 물론 현재 처한 위치를 고려할 때 적용하기는 어려웠지만, 꼭 한번 재미있게 적용해보고 싶은 방법론입니다. 한마디로 XP는 개발자 위주의 개발방법론이라 할 수 있습니다. 이 글은 Agile 소프트웨어 방법론인 XP(eXtreme Programming)에 관한 프로젝트 사례입니다. XP를 실전에 적용하고 싶은 분들은 구체적인 방법들과 분위기를 느낄 수 있을 겁니다.
1 처음에
"eXPerience인 OS"나"eXtra Performance인 CPU"등 항으로 여러가지로 화제의 XP입니다만, 본리포트는 이것들에 앞서 XP의 기를 내거는 극단류 "eXtreme Programming" 를 3개월 실천한 체험기(와 같은 것)입니다.
2 Extreme Programming
Extreme Programming(이하 XP)는 근년 화제의 라이트 웨이트인 소프트웨어 개발 프로세스입니다.XP의 개요등에 대해서는 서적, Web 사이트, 잡지 등등, 여러가지 곳에서 소개되고 있기 때문에 여기에서는 생략 하고 싶다고 생각합니다(만약 아시는 바가 아닌 경우, 우선eXtreme Programming FAQ가 참조되는 것을 추천합니다).
3 프로젝트 개요
목적
가전전용 분산 미들웨어의 prototype의 개발을 목적으로 하고 있습니다.
개발 기간
실질 약 4개월간.
릴리스는 2회,
모듈(궁)수 배급량은 제6 모듈(궁)수 배급량까지의 예정입니다.
사용 툴·환경
OS - 기본적으로는 Redhat Linux 7.1 (Windows98, 2000, MacOS9도 적당)
개발 환경 - Squeak2.8 (Smalltalk)
테스트·툴 - SUnit2.7
빌드·툴 - 자기 부담
팀
개발자는 매우 개발 경험 풍부한 Smalltalker3명(Smalltalk 원리주의!), 신참자 Smalltalker2명의 합계 5명.거기에 고객 1명(주 3일간 온 사이트·커스터머)을 대면시킨 합계 6명으로 프로젝트·팀을 구성해 있습니다.
팀의 암호는 「1 시합(1 프로젝트) 완전 연소」입니다.
5 XPer의 하루
XP프로젝트의 전형적인 하루를 간단하게 소개합니다.
10시 40분
XPer의 아침은 스탠드 업·미팅으로부터 시작됩니다.
팀 리더의, 「이제 미팅을 시작합니다」라고 하는 소리에 반응해, 팀은 집합합니다.
일동이 기립해,
전날까지의 진행 상황의 확인
전날의 작업으로 떠오른 문제점과 그 해결책의 확인
오늘 임하는 태스크의 결정
페어의 결정
등을 실시해, 전원의 의지·인식의 통일을 잽니다.
기립한 미팅은 자연과 여분의 회화가 생략해져 신속하게 진행합니다.
또, 미팅 종료 시에는, 모두가 생각해 들들의 액션을 잡으면서 어떤 서적의 일절을 읽어 내려 많이 기세(기성!?)(을)를 올립니다.
(스탠드업 미팅의 직접적인 장점이라면, 회의에 좀 더 집중할 수 있고, 흐지부지하게 회의가 길어지는 현상을 막 을 수 있다는 걸 들 수 있겠지요.)
10시 50분
미팅이 끝나면(자) 각 페어로 나누어져 작업 개시입니다.
페어는 1대의 PC에 둘이서 향합니다.
드라이버는 키보드와 마우스를 조종해 코딩을 하면서 그 내용에 대해 파트너에게 계속 설명해 파트너는 맞장구나 공격을 넣으면서 코드의 리뷰를 합니다(회화를 다 써버리지 않는 것이 즐겁게 하는 요령입니다).
설계, 클래스명, 메소드명, 변수명등의 결정은 페어내에서의 동의가 있으면 자꾸자꾸 진행시켜 나갑니다.
또, 페어 프로중에 페어로 결정할 수 있는 범위를 넘는 것 같은 문제에 부딪칠 때도 있습니다.
그럴 때에는, 전원 집합의 신호(MSG,종치기)를 보냅니다.
집합의 신호를 받은 멤버는 작업을 중단해, 소리를 지르면서 집합합니다.
그리고 전원이 문제된 페어로부터 나온 문제에 대해 해결의 방책을 가다듬습니다.
만약 그 자리에서 용이하게 해결하지 않는 것 같은 문제였을 경우는 새로운 태스크로서 일으키기로 해, 카드로 기록해 둡니다.
12시 30분
점심시간.
동반도 점심식사입니다.
타인과 같은 메뉴를 주문해선 안 된다
만약 같은 메뉴를 주문하면(자), 후일 카레집에서 가장 매운 카레를 먹지 않으면 안 된다
등이라고 하는 룰을 정해 메뉴 규칙의 번에 열전을 펼치고 있습니다.
13시 30분
오전중에 계속해, 페어·프로그래밍을 계속합니다.
태스크를 달성할 수 있으면(자) 그 내용을 결합시켜, 최신의 이미지·파일을 작성합니다.
결합 후의 이미지가 유니트·테스트를 모두 패스하면, 그 파일을 서버에 올라가,게시판에 초인종을 울려 새로운 이미지가 생겼다고 신호를 보냅니다.
신호를 받은 각 페어는 최신의 이미지를 서버로부터 다운로드해, 그것을 사용해 작업을 계속합니다.
17시 00분
타이머의 벨이 울려, 이제 작업을 끝내는 시간인 것을 알립니다.그리고, 각 페어는 그 날의 작업을 정리하기 시작합니다.
작업 내용이 결정된 순서에, 각 페어는 그 날의 작업 내용을 결합시켜 갑니다.
내용이 충돌 하는 경우는, 실제로 코딩을 한 당사자들에게 확인을 취하면서 신중하게 머지 합니다.
작성한 이미지·파일은 반드시 유니트·테스트에 걸쳐 동작을 확인합니다.각 페어의 환경에서는 테스트를 패스하고 있어도 각 페어의 작업을 하나에 결합한 단계에서 버그를 일으켜 테스트에 패스하지 않는다고 하는 것이 빈번하게 일어납니다.
이후, 버그의 수정, 결합 후의 이미지의 동작 확인등에 시간을 소비합니다.
19시 30분
모든 작업 내용의 결합을 끝내 테스트를 패스시키면(자) 그 날의 작업은 종료입니다.
결합 작업의 종료를 확인하면(자), 작업항목에 완료확인 주석을 붙이고 벨을 울려 기쁨을 뿌려, 전원이 그 기쁨을 공유하는 것을 강요합니다.
만약 전테스트에 통하지 않았으면, XP본래의 모습이면 테스트에 통하지 않는 코드는 버리게 되는 것입니다만, 실제의 곳은(작업분이 아깝기 때문에…) 요점 수정 개소로서 남겨 두어 다음날의 작업에 돌리고 있습니다.
기본적으로는 여기까지로 종료.귀가합니다.
주 40시간 노동 만세.
(……페어 프로에서의 피로는 쇄락이 되지 않습니다.1일 8시간은 한계 라인입니다)
(우리나라에서는 꽤나 요원한 얘기인듯 싶습니다;;;)
21시 30분
충돌 부분의 회피에 대실패
테스트가 통하지 않는 이유가 전혀 판명되지 않고
새로운 문제점이 자크자크 노출
자기 부담 빌드·툴에 버그 판명
등등의 이유로 잔업하는 날도(마마) 있습니다.
6 프랙티스의 실천 상황 (XP의 주요 실천사항을 말합니다^^)
프랙티스의 실천 상황에 대해.
프랙티스 실천 상황
페어·프로그래밍 기본적으로 코딩 작업은 페어로 가고 있습니다.그러나 프로그래머가 홀수 인원수인 일도 있어, 코드안에는 솔로에서의 작업도 포함되어 있습니다.
실험 SUnit를 이용해 단체 테스트를 실시하고 있습니다.유감스럽지만 테스트 퍼스트는 전혀 실천되고 있지 않습니다.
계속적 인테그레이션 매일 빌드, 테스트를 실시하고 있습니다.
metaphor(은유,별명) 시스템을 비유하는 것 같은 metaphor는 사용하고 있지 않습니다.순진·metaphor(그대로 metaphor)로 시종 하고 있습니다.
심플·디자인 태스크를 달성하기 위해 개념모형에 주력 하도록 하고 있습니다.또, 과잉에 임시 방편의 코드가 되지 않게 주의하고 있습니다.
리팩토링 적당 가고 있습니다.체제에 큰 설계 변경을 걸치는 것 같은 경우는 태스크로서 실행하고 있습니다.
계획 게임 릴리스 계획은 온 사이트·커스터머를 섞어 1회.모듈수 배급량 계획도, 매모듈수 배급량의 첫날에 온 사이트·커스터머를 섞어 가고 있습니다.
오픈·워크 스페이스 부스를 하나 전세내 작업을 하고 있어, 전원이 근처에 모여 작업하고 있습니다.화이트 보드가 없는 것이 유감인 곳입니다.
공동 소유권 파일·서버에 이미지·파일을 두고 있어 누구나가 그것을 변경할 수가 있습니다.버젼의 관리는 수작업으로 가고 있습니다.
주 40시간 노동 다소 오버 기색입니다.
온 사이트·커스터머 기본적으로 주에 3일, 온 사이트에서 들어가 있습니다.
코딩 표준 코딩 규약은 있습니다만 그다지 참고에는 되고 있지 않습니다.클래스명, 변수명등의 붙이는 방법은 페어에 일임 되고 있어 코드의 정형은 Squeak에 표준으로 실려 있는 포매터 맡김입니다.
작은 릴리스 4개월간으로 2회의 릴리스를 예정하고 있습니다.
매일의 데이타베이스 이행 데이타베이스는 이용하고 있지 않습니다.
7 잡다감구상등
페어·프로그래밍 (짝 프로그래밍이라고도 합니다)
JDK+editplus 에디터의 환경을 주로 사용해 온 신참자의 Smalltalker로서는, 당초 Smalltalk 독특한 개발 환경을 좀처럼 이해할 수 없었습니다.그러나 페어 프로로 이용법의 노하우를 실제로 체험하는 것으로, 어느 타이밍에 어떠한 조작을 실시하면 좋은 것인지 곧바로 이해할 수 있었습니다.한 명의 경우에 비해, 그 습득 속도에 각별한 차이가 있다고 느꼈습니다.
큰 리팩토링 (리팩토링을 의미한듯 싶습니다^^;)
설계에 크게 변경을 더하는 것 같은 단위의 리파크타링을 실시하는 경우, 기존의 시험대가 일제히 도움이 되지 않는 사람이 되어 버립니다.이번 프로젝트에서도 큰 리파크타링을 실시한 결과, 1주간의 간전테스트의 반이 에러 혹은 실패해, 전체적으로 개발이 정체하게 되어 버렸습니다.필요한 것을 필요하게 된 시점에서 작성하는 XP입니다만, 체제의 주간 부분은 어느 정도 굳혀 두지 않으면, 다음에 큰 일이다라고 느꼈습니다.
테스트·퍼스트 (테스트 퍼스트 혹은 테스트 주도 개발 방법을 말합니다.)
테스트 퍼스트는 전혀 실천되고 있지 않습니다.
테스트·퍼스트에 익숙하지 않았다
테스트·퍼스트를 강제하고 있지 않다
”코드를 써, 움직이면서 설계한다”감각으로 프로그래밍을 진행시키기 (위해)때문에, 테스트를 쓰는 것이 촌스럽다
…등을 원인으로서 생각됩니다만, 결국,
테스트·코드를 쓰는 것보다도 실전 코드를 쓰는 (분)편이 즐겁다고 느끼고 있다
…그렇다고 하는 것이 근본적인 곳에서는 없을까요.
모듈(궁)수 배급량 계획
궁수 배급량 계획에서는, 각 태스크는 견적이 최대에서도 3일이 되도록(듯이) 나누고 있습니다.
작은 단위입니다만 착실하게 프로젝트가 진행하는 것을 볼 수가 있어 매일의 의지에 직결하고 있다고 느꼈습니다.
악기
악기를 몇개인가 준비해, 각각의 소리에 의미를 갖게하고 있습니다.용건 마다 알려 돌 필요가 없기 때문에 편리합니다.
이번 사용하고 있는 악기와 그 의미는 이하와 같은 것입니다.
악기 의미
차임벨 팀이 소리를 높이면서 전원 집합
뻐꾸기 소리 서버에 새로운 이미지 파일이 업 되었다
업무 종료안내 이제 작업 종료의 시간이므로 키리가 좋은 곳으로 작업을 중단해
완료 벨 단체 테스트를 모두 패스했으므로 모두 기뻐해라
의지 증진 상품
게시판을 통한 약간의 소품이 즐거움을 증진 해 줍니다.
상품 설명
쥐-절구의 다리.버그 방편자에게 공격을 넣는다.
남 같아 남자가 아닌 모자.리파크타링 시에 용기가 나와?
UML 안경.모델링 능력이 업 업
그 외에도 여러가지 갖추고 있습니다.
XP의 결점
눈치챈 XP의 결점을 이하에 듭니다.
빈번하게 설계가 바뀌는 상황을 상정하고 있을 것이지만, 큰 설계의 변경에 대해서 약하다(어느 개발 수법에서도 같지만, XP는 설계의 변경 빈도가 높다고 생각된다)
문서가 곧바로 진부화 하기 위한(해), 도중부터 참가하는 멤버가 시스템을 이해하는 것이 큰 일
스킬의 낮은 기술자와 페어를 짜면(자), 고스킬의 기술자의 작업 스피드가 손상된다
최후에
XP는 즐겁습니다.
조그만 시스템의 문제를 잘 이해하며 와글와글 떠들면서의 작업은 즐겁다
공동 작업의 결과로 지식이 빨리 몸에 대해 즐겁다
불필요한 문서를 작성하지 않아 좋은 것은 즐겁다
정보 전달이 빨라서 고객의 요구에 따라, 착실하게 전진하고 있는 것이 즐겁다
팀의 독자적인 문화가 있고 그 일원이 되어 있어 즐겁다( 팀외의 사람이 들어 올 수 없는 것도 있습니다만…)
더 많은 정보는 한국 XP 사용자 모임 홈페이지를 참조하세요. http://xper.org
|
