익스트림 프로그래밍 현업에서 가능한가?

제목을 보면 개발자들이 많이 읽어볼것같네요ㅋ  익스트림 프로그래밍이라는 책을 학생때 읽어보고, 다시 직장다니면서 읽어보니 꿈과 이상, 그리고 현실 이라는 단어가 생각나네요ㅎ 전 개발자는 아니구요^^ 학생때 개발을 잡다하게 공부했고 현재는 기획을 시작한지 몇개월 되지 않은 초보기획자입니다. XP책을 읽고 적는 짧은 생각이니 돌 던지지 말아주세요~~

익스트림 프로그래밍 (Extreme Programming) - 변화를 포용하라 2판 국내도서>컴퓨터/인터넷 저자 : 과학독서아카데미,한솔편집부 / 김창준,정지호역 출판 : 인사이트 2006.07.25 상세보기

익스트림 프로그래밍 현업에서 가능하다고 생각하시나요? 여러분은 어떻게 생각하세요? 학생때 이 책을 읽었을때는, 개선사항이 있거나 새로운 프로젝트를 시작할때 현업에서는 [하루종일, 그리고 단기간안에, 체계적으로] 해결할 수 있구나 하는 생각을 했어요. 개발 공부를 할 때는 익스트림 프로그래밍을 하는 직장이 두번째 꿈이었죠^^ 왜 두번째 꿈이냐구요?ㅋ 첫번째 꿈은 기획자였어요^^;;  XP를 현업에서 구현하기에는 많은 장애물이 있는것 같아요. [운영,우선순위,비용,리소스] 등등...이런 장애물들을 무시하고 24시간 코딩할 수 있다면 얼마나 좋을까요?ㅋ


XP에서 강조하고자 하는게, 설계 → 구현 → 테스트 → 개선 → 테스트 → 개선 → 테스트 → 개선....입니다. 테스트와 개선 작업을 통해서 초기에 했던 설계 작업과 다른  결과물이 나올수도 있지만, 결과물에 대해서는 누구나 만족할수 있을거예요. 누구나 만족할수 있는...ㅎㅎㅎ


개인적으로는 UML을 더 선호합니다. 준비된 설계와 계속되는 설계의 수정, 그리고 완벽한 테스트...하지만 아주 큰 프로젝트가 아닌 이상 UML은 많이 사용하지 않는것같아요. 문서 작성하다가 프로젝트 시간의 절반이 다 지나가버리거든요...ㅎㅎ 소프트웨어 공학을 배울때 프로젝트 개요부터 DFD,화면설계,MINI SPEC 등등...을 PPT에 넣어서 제출하는데 슬라이드수가 많은 팀은 500장 가까이 나오는 팀도 있었어요. 과연 저렇게 할 필요가 있을까 하는 생각도 많이 했거든요ㅎ 하지만 그짓을 반복하다 보니, 초기 설계단계와 기록하는게 중요하다는걸 알게되었어요. UML도 정리할수록 스킬이 향상 되어갔죠ㅋㅋ (순전히 제 생각임ㅎ UML이 제 스타일에 맞는 방법론이었다고 생각해요ㅋ)


그래서 최근에 하나의 프로젝트를 진행하면서 팀을 나누어서 해봤어요. 완벽한 설계를 바탕으로 한달에 한번 모이는걸로 프로젝트를 진행해보자는 재미있는 생각이었죠^^ 결과는...프로젝트 중단이라는 결과를 만들었어요ㅋ 자주 모이지 않으니 팀원들의 프로젝트에 대한 열정도 식어가고, 가장 큰 문제는 프로젝트에 대한 의견 공유가 어렵다는것이죠. 시나나리오까지 모두 나왔는데..ㅠㅠ 이번에 XP 책을 두번째 보면서 느낀점이...역시 프로젝트를 할때는 자주 자주 만나서 토론하고 의견을 공유해한다는것이예요ㅋ 그리고 최대한 프로젝트를 원시적으로 쪼갤수 있을때까지 쪼개야 한다는것까지 깨달았죠. 프로젝트의 환경에 따라서 적용되는 방법론이 달라지듯, 개발진행 스타일도 많이 달라니는것같아요ㅎ 


글에 필요없는 살들이 붙어서 핵심이 없어 보이네요ㅋ 뭐~핵심은 이거예요. 학생때 XP책을 읽었을때는 현업에서 이렇게만 한다면 재미있을거야라는 생각을 가지고 있었지만, 현업에 와서 개발자들이 일하는것을 지켜보고 같이 일하면서...XP를 하는게 가능할까? 직군별로 나뉘어 있으면서 피드백이 필요할때마다 자주 모여야하고, 또한 한가지 일만 진행하는것이 아니라 다른 업무까지 함께 하면서 XP가 가능할까? 그리고 XP가 현업에서 가능할까라는 것에 가장 큰 의문을 던지게 만든것은 바로....고객이 아닌 함께 일하는 팀원 또는 결정권자의 피드백을 다 수용할 것인가?ㅋ


아~그리고 [익스트림 프로그래밍]은 개발을 공부하는 학생들이 꼭 읽어야 할 필독서라고 생각해요ㅋ