문체로 보아 애초에 XP 를 도입하실 생각은 별로 없어보이는데요 ;) (비꼬는거 아닙니다. 기분나쁘시다면 죄송합니다)
개인적으로 XP 의 가장 중요한사항은 코치(Coach)라고 생각합니다. 그것도 XP 에 대해 아주 잘 이해하고 있는 코치여야 합니다.
잘못 생각하신 것 같네요 :) 지금도 그렇지만 프로젝트를 맡으면 항상 방법론이나 프로세스를 적용하는 일을 해왔습니다. 다만 XP를 곧이 곧대로 적용하지 않을 뿐입니다. 어차피 XP도 'best practice 모음' 정도의 성격이 짙기 때문에 선별적 도입이 가능하다고 봅니다.
특히 페어프로그래밍 같은 경우 실무에서 도입에 어려움이 많습니다. 단위테스트는 다른 스레드에서 언급한 이유로 가능하면 제한적으로 쓰려고 합니다. 반면에 코드 공유의 개념이나 빠른 이터레이션, 자동화된 빌드, 소스 관리 시스템의 사용 등등은 가능하면 그대로 지키려고 노력 중입니다.
XP에서 중요한 건 그 중 몇 가지 항목을 그대로 따라하는가가 아니라 주어진 개발 환경을 얼마나 agile하게 바꿀 수 있는가 하는 점이라고 생각합니다.
---------------------------- [서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
잘못 생각하신 것 같네요 :) 지금도 그렇지만 프로젝트를 맡으면 항상 방법론이나 프로세스를 적용하는 일을 해왔습니다. 다만 XP를 곧이 곧대로 적용하지 않을 뿐입니다. 어차피 XP도 'best practice 모음' 정도의 성격이 짙기 때문에 선별적 도입이 가능하다고 봅니다.
특히 페어프로그래밍 같은 경우 실무에서 도입에 어려움이 많습니다. 단위테스트는 다른 스레드에서 언급한 이유로 가능하면 제한적으로 쓰려고 합니다. 반면에 코드 공유의 개념이나 빠른 이터레이션, 자동화된 빌드, 소스 관리 시스템의 사용 등등은 가능하면 그대로 지키려고 노력 중입니다.
XP에서 중요한 건 그 중 몇 가지 항목을 그대로 따라하는가가 아니라 주어진 개발 환경을 얼마나 agile하게 바꿀 수 있는가 하는 점이라고 생각합니다.
어떤 방법론이던지 선별적인 도입, tailoring 은 진정한 방법론적용이라고 볼 수 없습니다. XP 의 덕목들은 그 자체가 언급하신대로 best practice 이며 대가들의 연구결과입니다. 입맛대로 몇가지만 골라쓰고 유용하지 않다고 평가하는것은 적절치 않습니다.
더군다나 pair programming 은 XP 의 핵심덕목이며 그 자체가 다른덕목들과 연결되어지는것이 많습니다. (collective code ownership 등등) 상황이 어떻든 pair 를 하지 않고서 XP 를 도입해보았다고 언급하는것 자체가 어불성설입니다.
RUP + XP 를 tailoring 한다는분들을 많이 보아왔는데 과연 한가지 방법론이라도 제대로 이해하고 그렇게 하는것인지 의심스러울때가 많습니다.
어떤 방법론이던지 선별적인 도입, tailoring 은 진정한 방법론적용이라고 볼 수 없습니다. XP 의 덕목들은 그 자체가 언급하신대로 best practice 이며 대가들의 연구결과입니다. 입맛대로 몇가지만 골라쓰고 유용하지 않다고 평가하는것은 적절치 않습니다.
더군다나 pair programming 은 XP 의 핵심덕목이며 그 자체가 다른덕목들과 연결되어지는것이 많습니다. (collective code ownership 등등) 상황이 어떻든 pair 를 하지 않고서 XP 를 도입해보았다고 언급하는것 자체가 어불성설입니다.
RUP + XP 를 tailoring 한다는분들을 많이 보아왔는데 과연 한가지 방법론이라도 제대로 이해하고 그렇게 하는것인지 의심스러울때가 많습니다.
* 투표하고 옵시다 -_-;
좋습니다. 그럼 저는 XP를 써본적이 없습니다. 하지만 경우에 따라 페어프로그래밍이나 단위테스트 없는 XP - 님의 말씀대로라면 XP가 아닌 제 나름의 방법론으로 충분히 생산성 향상을 얻을 수 있었습니다.
참고로 'collective code ownership'은 꼭 페어를 통해서 얻어지는 것은 아닙니다. 오히려 이를 위해서는 팀원 전체의 이해를 돕는 설득과 무엇보다 코딩 컨벤션의 엄격한 적용이 훨씬 중요합니다. likejazz님이 실제 실무에서 장시간 XP를 적용해 보셨다면 (말씀하시는 것으로 보아 그렇게 믿겠습니다만) 충분히 이해 하시리라 생각합니다.
제가 아는 한은 외국의 개발관련 사이트나 하다 못해 슬래쉬 닷만 봐도 XP를 상당히 자유롭게 변형하여 적용하는 사례가 많이 있습니다(그걸 'XP'라고 부를 지 말지는 모르겠습니다). 외국의 경우라고 무조건 올바른 건 아니지만 XP는 어디까지나 하나의 예시고 가이드라인일 뿐 어떤 생산성 향상을 위한 'silver bullet'은 아닙니다.
RUP를 보셨겠지만 오히려 RUP 매뉴얼과 예시에서 likejazz님께서 부정하시는 'tailoring'을 매우 강조하고 있습니다. 왜냐하면 언듯보아 다분히 산출물 지향적으로 보이는 RUP가 소규모 그룹에서도 적용 가능하다는 것을 보여주기 위한 것입니다.
그리고 XP가 지향하는 'best practice'라는 것 자체가 빠르게 변화하고 또 업무의 성격에 따라 차이가 있습니다. 즉, 같은 단위 테스트라도 예를들어 암호화 모듈을 만들 때와 대규모 분산 어플리케이션을 만들 때 그 효용성과 방법이 크게 차이가 난다는 뜻입니다. 심지어 많은 프로그래머들이 바이블로 인식하는 GoF같은 디자인 패턴 조차 끊임없이 변화하고 지금도 새로운 패턴들이 나타나거나 사라지는 일을 반복하고 있습니다. 즉 소프트웨어 디자인이라는 분야 자체가 매우 유동적이라는 뜻입니다.
소프트웨어 공학이나 방법론의 목적은 높은 생산성과 유지보수 가능한 코딩을 하는 것이지 XP를 같은 특정 agenda를 교조적으로 적용하는 것은 아닙니다.
---------------------------- [서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
eXtream Programming을 도입하셨습니까?
슬래쉬닷에 놀러갔다가 다음 URL을 보니, 미국에는 XP 쓰는 사람들이 지천에 널린건지 아니면 슬래쉬닷에 찾아오는 사람들중에 XP 사용자가 유난히 많은건지 종잡을 수 없군요.
http://slashdot.org/article.pl?sid=03/10/01/2255221
XP 도입을 해보고픈 생각을 안해본건 아니지만 많이 망설여 지게 됩니다. 저 길고 긴 쓰레드를 읽어 보니 더 모르겠군요 -_-;;
필드에서 XP로 프로젝트를 수행하시는 분들, XP로 프로젝트를 성공으로 이끌었던분들, XP때문에 망했다는 분들의 고견을 모두 다 듣고 싶습니다. XP 어떻게 생각하십니까?
ps. pair programming을 포함하는 완전(?)한 xp를 의미합니다.
산넘어 산
완전한 XP라....근무시간에 프로그래머 둘이 몇 시간 씩 붙어서
완전한 XP라....
근무시간에 프로그래머 둘이 몇 시간 씩 붙어서 '농땡이' 부리다가 일주일에 40시간만 일하고 집에가는 회사가 그렇게 많을까요? :)
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
완전한 XP라는 표현을 쓴것은 일부분을 차용해서 사용한다면 XP가 아닌것
완전한 XP라는 표현을 쓴것은 일부분을 차용해서 사용한다면 XP가 아닌것 같아서 그렇게 썼습니다.
pair programming, TDD, iteration, customer괴롭히기등이 모두 모여야 xp가 추구하는 "무엇"에 가까워 지는것 같기도 하고요. 그래야 디버깅 시간의 극적 단축으로 40시간 근무후 즐거운 주말을 보낼수 있겠죠. ^^
수정: 아래글보고 waterfall은 뺐습니다. :)
산넘어 산
XP
"두 사람이서 농땡이"라는 부분은 아마 짝 프로그래밍을 일컫는 것 같습니다.
짝 프로그래밍을 하면 본인도 모르게 훨씬 더 열심히 일하게 됩니다. 그래서 가끔 자본가들의 프로그래머 노동력 착취수단이 될 수 있겠다는 농담을 하기도 합니다.
그리고 주당 40시간은 이제 "지속가능한 속도"로 변경되었습니다. 속도를 유지할 수 있다면 가끔 초과근무도 괜찮다고 합니다.
waterfall을 언급하셨는데, XP는 반복적(iterative)이면서 점진적(incremental)입니다. waterfall하고는 반대입니다.
XP를 조직에 도입하려면 http://xper.org/wiki/xp/XP_b5_b5_c0_d4 참조하세요.
투표해주신 분에 비해 답글 달아 주신분이 너무 적네요.자신의 경험
투표해주신 분에 비해 답글 달아 주신분이 너무 적네요.
자신의 경험에 의거해서 이런 경우에는 좋았던거 같고, 이런 경우는 최악이다등의 경험담을 남겨주시면 많은 사람들 (사실은 저에게 -_-)에게 복음이 될텐데요.
특히나 망했다는 경험담을 꼭 듣고 싶습니다.
산넘어 산
Re: XP
저도 페어 프로그래밍의 이점은 어느 정도 알고 있지만, 문제는 그런 효용성을 과연 일반적인 국내 IT업체의 관리자들에게 설득할 수 있느냐가 아닐까 싶습니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
망한 경험담
어떤 프로세스이건 망하는 경우가 있습니다. 만약 제대로 훈련되지 않은 사람들이 개발을 한다면 어떠한 프로세스를 사용해도 망할 것입니다.
소위 망하는 경우의 수가 성공하는 경우의 수보다 훨씬 많기 때문에 저는 실패공학을 그리 권하진 않습니다만 굳이 망하는 경험담이 궁금하시다면 XP가 망한 경험담보다 스탠디쉬 그룹의 카오스 리포트(구글)를 참고하시는 것이 더 많은 도움이 되리라 믿습니다.
제 주변에서 XP를 사용했는데 큰 성공을 하지 못한 경우는 대부분 카오스 리포트가 뽑는 실패요인(특히 순위가 높은 것)을 상당수 갖고 있었습니다.
참고 자료:
* http://www.pm2go.com/sample_research/chaos_1994_1.php
* http://www.softwaremag.com/archive/2001feb/CollaborativeMgt.html
p.s. 흥미롭게도 주변에서 보고 듣는 XP 실패경험담은 종종, "XP가 아닌 무언가"의 실패경험담인 경우가 있는 것 같습니다.
읽고 생각해 볼 자료:
* http://groups.yahoo.com/group/extremeprogramming/files/Are%20You%20Getting%20XPd%20On.pdf
* http://www.xprogramming.com/xpmag/are_we_doing_xp.htm
* http://groups.yahoo.com/group/extremeprogramming/files/Ten%20Cheap%20Actions.doc
Re: XP
설득된다면 도입할 생각이 있으신가요 ?
문체로 보아 애초에 XP 를 도입하실 생각은 별로 없어보이는데요 ;) (비꼬는거 아닙니다. 기분나쁘시다면 죄송합니다)
개인적으로 XP 의 가장 중요한사항은 코치(Coach)라고 생각합니다. 그것도 XP 에 대해 아주 잘 이해하고 있는 코치여야 합니다.
어설프게 책 몇권읽고 XP 를 한답시고 둘이서 짝지어 프로그래밍하다가 제대로된 방법을 찾지못해 헤메다 실패하는 경우를 많이 보아왔습니다.
다른 방법론도 마찬가지지만 XP 역시 제대로 방법론을 리드해줄수있는 코치의 필요성이 절대적이라고 생각합니다.
--
Sang-Kil Park
Re: XP
잘못 생각하신 것 같네요 :) 지금도 그렇지만 프로젝트를 맡으면 항상 방법론이나 프로세스를 적용하는 일을 해왔습니다. 다만 XP를 곧이 곧대로 적용하지 않을 뿐입니다. 어차피 XP도 'best practice 모음' 정도의 성격이 짙기 때문에 선별적 도입이 가능하다고 봅니다.
특히 페어프로그래밍 같은 경우 실무에서 도입에 어려움이 많습니다. 단위테스트는 다른 스레드에서 언급한 이유로 가능하면 제한적으로 쓰려고 합니다. 반면에 코드 공유의 개념이나 빠른 이터레이션, 자동화된 빌드, 소스 관리 시스템의 사용 등등은 가능하면 그대로 지키려고 노력 중입니다.
XP에서 중요한 건 그 중 몇 가지 항목을 그대로 따라하는가가 아니라 주어진 개발 환경을 얼마나 agile하게 바꿀 수 있는가 하는 점이라고 생각합니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
Re: XP
어떤 방법론이던지 선별적인 도입, tailoring 은 진정한 방법론적용이라고 볼 수 없습니다. XP 의 덕목들은 그 자체가 언급하신대로 best practice 이며 대가들의 연구결과입니다. 입맛대로 몇가지만 골라쓰고 유용하지 않다고 평가하는것은 적절치 않습니다.
더군다나 pair programming 은 XP 의 핵심덕목이며 그 자체가 다른덕목들과 연결되어지는것이 많습니다. (collective code ownership 등등) 상황이 어떻든 pair 를 하지 않고서 XP 를 도입해보았다고 언급하는것 자체가 어불성설입니다.
RUP + XP 를 tailoring 한다는분들을 많이 보아왔는데 과연 한가지 방법론이라도 제대로 이해하고 그렇게 하는것인지 의심스러울때가 많습니다.
* 투표하고 옵시다 -_-;
--
Sang-Kil Park
Re: XP
좋습니다. 그럼 저는 XP를 써본적이 없습니다. 하지만 경우에 따라 페어프로그래밍이나 단위테스트 없는 XP - 님의 말씀대로라면 XP가 아닌 제 나름의 방법론으로 충분히 생산성 향상을 얻을 수 있었습니다.
참고로 'collective code ownership'은 꼭 페어를 통해서 얻어지는 것은 아닙니다. 오히려 이를 위해서는 팀원 전체의 이해를 돕는 설득과 무엇보다 코딩 컨벤션의 엄격한 적용이 훨씬 중요합니다. likejazz님이 실제 실무에서 장시간 XP를 적용해 보셨다면 (말씀하시는 것으로 보아 그렇게 믿겠습니다만) 충분히 이해 하시리라 생각합니다.
제가 아는 한은 외국의 개발관련 사이트나 하다 못해 슬래쉬 닷만 봐도 XP를 상당히 자유롭게 변형하여 적용하는 사례가 많이 있습니다(그걸 'XP'라고 부를 지 말지는 모르겠습니다). 외국의 경우라고 무조건 올바른 건 아니지만 XP는 어디까지나 하나의 예시고 가이드라인일 뿐 어떤 생산성 향상을 위한 'silver bullet'은 아닙니다.
RUP를 보셨겠지만 오히려 RUP 매뉴얼과 예시에서 likejazz님께서 부정하시는 'tailoring'을 매우 강조하고 있습니다. 왜냐하면 언듯보아 다분히 산출물 지향적으로 보이는 RUP가 소규모 그룹에서도 적용 가능하다는 것을 보여주기 위한 것입니다.
그리고 XP가 지향하는 'best practice'라는 것 자체가 빠르게 변화하고 또 업무의 성격에 따라 차이가 있습니다. 즉, 같은 단위 테스트라도 예를들어 암호화 모듈을 만들 때와 대규모 분산 어플리케이션을 만들 때 그 효용성과 방법이 크게 차이가 난다는 뜻입니다. 심지어 많은 프로그래머들이 바이블로 인식하는 GoF같은 디자인 패턴 조차 끊임없이 변화하고 지금도 새로운 패턴들이 나타나거나 사라지는 일을 반복하고 있습니다. 즉 소프트웨어 디자인이라는 분야 자체가 매우 유동적이라는 뜻입니다.
소프트웨어 공학이나 방법론의 목적은 높은 생산성과 유지보수 가능한 코딩을 하는 것이지 XP를 같은 특정 agenda를 교조적으로 적용하는 것은 아닙니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...