SI 프로젝트에서도 애자일은 가능하다

[June Kim]

http://younghoe.info/844

여러분들의 의견은?

[송홍진]

애자일이라는 것이 정확히 정형화된 어떤 프로세스로 정의된다면 힘들것 같지만..

 

필요한 부분에 부분적으로 애자일적인 마인드를 도입한다면 못할 것도 없을 것 같습니다.

 

개인적으로 모든 개발에는 유지보수가 필연적으로 발생하고 유지 보수의 싸이클은 짧을 수록 좋다는 견해에서 애자일적인 마인드는 매우 유용하다고 생각합니다.

 

다만 우리 나라에서는 애자일의 본연의 마인드 보다는 하나의 정형적인 프로세스 자체로 받아들이고 적용하려는 노력이 더 큰 것 같습니다.
 

때문에 이런 논의가 필수불가결에 발생되는 것은 아닐런지?

 

짧은 저의 생각이었습니다.

 

악플은 사절.. 진보된 반론은 환영입니다. 한수 가르침을...
 

On 6/13/08, June Kim <june...@gmail.com> wrote:

http://younghoe.info/844

여러분들의 의견은?

[Youngrok Pak]

흥미로운 글이군요.

일단 첫번째 느낌은, 제목 자체에 동의하지만 제목이 잘못된 것 같다는 것. 사실 애자일 방법론 자체가 태동한 것이 SI
프로젝트 아니었던가요. 프랙티스들도 대부분 SI를 염두에 두고 있죠. 그래서 뭔가 당연한 이야기인 것 같으면서 잘못된 것
같다는 느낌을 받는 듯.

내용에서도 공감하면서 이의를 제기하고 싶은 묘한 부분들이 눈에 띕니다.

>SI 프로젝트에서도 애자일 프로세스를 적용한다면 상황파악과 대인기술이 뛰어난 동시에 기술적인 이해도 충분한 전문가가 필요하다.

공감하면서도 반대합니다. 일단, 전제를 약간 바꾸고 싶습니다. "SI 프로젝트에서 애자일 프로세스를 적용한다면"이 아니고
"SI 프로젝트에서 성공하고 싶다면"으로 말이죠. 저런 전문가가 없으면 어떤 방법론으로도 성공하기 힘들겠죠.

대인 기술 이야기도 약간 의문 부호가 찍힙니다. 업체 간의 표면적인 관계는 담당자들의 대인 기술이 결정하는 경우가 많지만 실제
실무자들의 관계에서 중요한 것은 대인 관계 역량이 아니라 accountability가 아닌가 싶습니다. 서로가 서로에게
accountable하면 대인 기술이 아무리 엉망이라도 관계가 잘 유지되는 것 같습니다.

기술적인 이해도가 높아야 한다는 것도 맞는 말이지만, 자칫 처음부터 기술적 역량이 뛰어난 사람이 있어야 한다는 말로 해석될 수
있다는 점에서는 경계하고 싶네요.

>관리층에 개발자의 언어를 관리자의 언어로 전달할 수 있는 사람이 반드시 필요하다.

이 표현도 공감하면서 반발하고픈 표현입니다. 제가 생각하는 옳은(?) 표현은 이렇습니다.

개발자들은 자신의 일을 상대방이 쓰는 언어로 설명할 수 있어야 한다.

커뮤니케이터 뿐 아니라 개발자들 모두가 의사소통할 때 상대방의 언어로 이해시킬 수 있는 능력이 필요하다는 것이죠. 대상도
관리자 뿐 아니라, 고객, 디자이너, 자기 회사 경영진 등등 다양한 대상이 될 수 있죠.

우리 회사도 요즘 SI 프로젝트를 하나 하고 있습니다. XP의 프랙티스들을 상당히 많이 활용하고 있죠. 하면서 드는 생각이,
어떤 프랙티스를 적용하건 Baby Step이 중요하다는 것입니다. 저 멀리 있는 XP의 목표를 현실에 바로 적용하려고 들면
마찰이 생기지만 현재 상태를 기준으로 한 발만 전진하면 마찰 없이 수용이 가능합니다. 비용이 많이 드는 프랙티스도 한 번에
적용하기보다 천천히 조금씩 적용하는 게 좋습니다. TDD나 Continuous Integration도 적용 비용이 상당히 큰
편인데 이런 것도 각각의 프랙티스가 주는 장점들을 조금씩만 가져오도록 부분적으로 적용해나갈 수 있습니다. 물론, 이 한 발
전진하는 방법을 찾아내는 것이 쉬운 일은 아니지만요.

사실 우리 회사도 처음에는 어려움을 좀 겪었습니다. 원래 10시 반 출근 4시 퇴근이 원칙인데 이 프로젝트를 시작한 후로 한
3주간은 거의 매일 6시, 7시까지 일했습니다. 뭔가 그렇게 해야할 것만 같은 상황이 되더군요. 그래서 한 분은 지쳐서 2주간
휴가를 내셨고 남은 세 명도 좀 지쳐갔죠. 하지만 회고를 통해서 근무시간을 다시 줄여나갈 방법들을 하나씩 찾아서 적용했고
그래서 이번 주는 다시 4시 안팎에 퇴근하는 상황으로 돌아왔습니다.

어찌보면 애자일 프랙티스 전체를 한 마디로 요약할 수 있는 게 Baby Step이 아닐까 싶기도 합니다. SI든 뭐든 Baby
Step으로 갈 수 있다면 뭐든 적용할 수 있지 않을까요.

2008년 6월 13일 (금) 오후 10:40, June Kim <june...@gmail.com>님이 작성한 메시지:
>
> http://younghoe.info/844
>
> 여러분들의 의견은?
>
> >

[영회]

저 역시 흥미롭군요. 사실 제가 글을 쓰게 된 동인은 지인의 글이지만, 이건 아니다 싶은 마음에 충동적으로 날린겁니다. 제 글
은 대부분 별로 논리적인 글도 아니고, 길어야 10분 이내에 메모하듯 쓴 글인데.. 그걸 논리적으로 분석하셔서 반론을 주신 점
이 또한 흥미롭습니다.

감정 > 논리 > 감정... 일케 되는건가?

여기에 답글을 다는 이유 역시, 이분야에서 확고한 위치에 계신 창준님께서 사실 별로 상관도 없는 저에게 커멘트 달라 하시니 반가
운 마음에 왔다가 흥미롭기도 하고, 조금 기분이 나쁘기도 하고(내면에선 아마도) 해서 답글을 합니다.

제가 쓰고도... 말이 안되는 문구가 많지만 그대로 뒀습니다. 저한테는 그 정도 써서 뭔가 메시지만 있으면 그만이니까..^^

한 가지 의미있는 반론을 써 둔다면, 저는 알 수 없는 규모의 알 수 없는 조직에서 짠 하고 프로젝트를 하는 직업을 갖고 있
죠. 영록씨랑 제 입장은 많이 다를껍니다. 의사결정권자에게 조언으로나마 '단계적', '전략적' 등등의 표현을 쓸 수야 있지만,
대개는 단기간에 눈으로 볼 수 있는 무엇을 원하죠. 그러면서 최근에 느낀 팁이랄만한 것들을 기록한 것 뿐이고, 이것을 사실 애자
일 프로세스라고 부르는 것은 잘못된 표현이죠. 사실 제가 글을 다시 회상해보면(다시 읽기는 귀찮아서) 팀과 팀원이 애자일하게 움
직일 수 있도록 도와주는 도구와 절차 정도를 논한거네요. 원문에 애자일 프로세스와 별로 상관없는 내용을 엮어놓아서 저도 같은 컨
택스트로 이동한 모양입니다. ^^

[영회]

이렇게 떠나려니 좀 아쉬워서 제가 갖고 있는 애자일에 대한 이야기를 짧게만 하면..

처음 애자일 관련 서적, 문서를 접할 때 느낀 것은.. 프로그래밍을 통해서 도를 닦으라는
생활철학 지침 같다는 것이었죠.. 그리고, 대규모 프로젝트에서 그보다 훨씬 격한 수련을 하시는 분이
운 좋게도 눈앞에 계셔서... 저한테는 무리다 싶었고..
(수련은 말한 것도 없고, 프랙티스를 곧이 곧대로 하는 것까지)

그저 요즘에는 일부 프랙티스를 시범적으로 도입해보고, 소화가 가능한 범주 내에서 잘 쓰고 있습니다.
학습 비용이 들지만, 금새 뚜렷한 효과를 볼 수 있더군요.

[Sangchel Hwang]

agile paradox에서 본 내용중에 한마디가 생각납니다.

agile is easy and difficult.

애자일은 금방 이해가 갈정도로 그 내용은 쉽지만 실천은 쉽지 않습니다.
^^

2008/6/14 영회 <ahnyo...@gmail.com>:

--
http://moai.tistory.com

[gyehong park]

영록님이 재미있는 견해를 제공해 주셨군요. 그 중에서 하나 딴지를 걸어봅니다.

 

1. 관리층에 개발자의 언어를 관리자의 언어로 전달할 수 있는 사람이 반드시 필요하다.

2. 개발자들은 자신의 일을 상대방이 쓰는 언어로 설명할 수 있어야 한다.

 

저는 위 글들이 다음과 비슷한 뜻이라고 생각합니다.

3. 관리층과 의사소통을 잘 해야한다.

4. 개발자는 의사소통을 잘 해야한다.

4번보다는 5번이 보다 많는 뜻이라고 생각합니다.

5. 사람은 의사소통을 잘 해야한다.

그래서 영회님과 영록님의 초점은 서로 다른다고 생각합니다.

 

저는 이런 의미에서 영회님이 주목한 관리층과의 소통에 동감을 표시합니다.

관리층에서는 개발이 어떻게 진행되고 있는지를 보다 알기 어렵습니다. 일단 관리층과 의사소통을 할 수 있는 것들이 아주 적습니다. 관리층과 만날 수 있는 부분은 계약, 결과 이 정도가 아닐까요? (또 모가 있을까요? ^^;; 컨설팅? 실무진관의 관계?) 그렇게 보면 재성님의 계약에 관련된 부분과 영회님의 '관리층과의 의사소통'은 좋은 화두가 될 수 있다고 보여집니다.

 

최근에 계약이나 관리층과의 의사소통에 대해서 고민을 했었습니다. 아직은 실험 진행 중인 상태구요. 이 부분에 대한 다양한 상황과 시도들을 모아보는 것도 재미있을듯 보입니다.

 

자야하는데 잠이 안와서 대충...

P.S :  관리층에 개발자의 상황을 관리자에게 전달할 수 있는 것이 필요하다. 꼭 사람이나 언어일 필요는 없지 않을까 하는 생각이 들었습니다. 영록님이 이야기하고 싶었던 것이 이것이었을까요? ^^;

[June Kim]

1) SI에 부분적인 애자일 적용 가능합니다. 특히 계획하기, 그리고 조정하기 등은 상당히 많은 SI 프로젝트에 도입
가능하다고 봅니다. 두 세 이터레이션만 지나면 거의 즉각적으로 효과를 볼 수 있습니다.

저는 애자일이 기본적으로 "냉철한 현실을 직시해서 따뜻한 가슴으로 함께" 해결하자로 봅니다. 이 "냉철한 현실을 직시해서"
부분이 현 SI 업체들에게 어필할 수 있다고 봅니다.애자일은 좋은 게 좋은 거다가 아닙니다. 무서울 만큼 현실을 직시하게
해줍니다. 애자일은 예측가능성이 높습니다.

2) 고객사에서 애자일을 이해한다면, 그들을 설득할 수 있다면 가장 좋지만, 그게 아니더라도 부분적 적용은 가능합니다. 나날이
개선되는 것이 의미있는 프로젝트라면.

3) 저는 좀 나이브한 생각일지는 몰라도 SI 쪽에 혁신의 여지가 굉장히 많이 남아있다고 생각합니다. 정말 고객에게 중요한
것을 월등하게 처리해주면 어떤 방법을 쓰느냐가 크게 문제되지 않을 것입니다. 머지 않아 국내 SI업계에 와해성
혁신(disruptive innovation)이 일어나리라 봅니다. 그리고 이 와해성 혁신은 얼마 후에 대다수의 존속성
혁신(sustaining innovation) 업체들을 몰아내게 되리라 추측합니다.

08. 6. 13, June Kim <june...@gmail.com>님이 작성:
> http://younghoe.info/844
>
> 여러분들의 의견은?
>

[JinYoung Heo]

그런데 논의의 주제는 한국의  SI 에서 애자일이 가능한가 인거죠? 저 지난주에

 

http://www.agileitx.com/conference/reston/2008/06/index.html

 

에 참가했었는데.. 많은 분들이 SI 영역에서 일하고 계시더라구요. ㅎㅎㅎㅎ -_-;; 애자일 방법론은 물론이고  TDD도 많이..-_-a

 

쫌 부러웠어요. ㅎㅎㅎ

 

그쪽에서는 안된다면 른 이유로 안되는 것이지 꼭  SI 라서 안된다고 생각하지는 않는 것 같더군요.

 

08. 6. 28, June Kim <june...@gmail.com>님이 작성:

[Hubert Shin]

어느 프로젝트나 한계점은 있는 것 같습니다.

하지만 SI에서는 정해진 비용, 인력, 기간의 압박 때문에
그 한계점을 구성원으로 하여금 훨씬 더 크게 체감하도록 만드는것 같고요

전, Agile 의 여러 practice들이 프로젝트에 자연스럽게 융화될때까지 얼마나 걸리는지와
구성원에 대한 배려심이 SI에서 잔뼈가 굵은 고객과 관리자들을 설득하는데 가장 중요한 요소라고 생각합니다.

관리자의 강력한 의지가 있고 고객이 그 관리자를 신뢰하고 있는 상황이라면
고객의 인내심이 조금 더 연장될 수는 있겠죠.

하지만 결국,
그 인내심은 기간과 반비례하고, 배려심에 비례합니다.

전 그래서 Coach 의 역할이 매우 중요하다고 생각합니다.
프로젝트 구성원들에게 익숙해지면서 거부감을 최소화하기 위한 노력을 지속적으로 해야합니다.

아예 받아들일 수 없는 대상이라면,
포기하든지 혼자서 실천하여 주변사람에게 퍼트리는 방법을 선택해야겠지요.

즐거운 토론이네요 ^^

2008년 7월 2일 (수) 오전 11:33, JinYoung Heo <clas...@gmail.com>님이 작성한 메시지:

[강석천]

이상적인 이야기인지 모르겠지만..

The Goal 같은 책의 경우 throughput 을 위해서 리드타임을 돈으로 바꾸려는 시도까지 합니다. 결과적으로 그 편이
최종 이익을 고려했을 때 더 이득이라는 계산에서 입니다.

그러한 점에서 SI 등에의 프로젝트의 경우는 어떨지 궁금합니다. 계약 기간의 연장이나 프로젝트 실패는 곧 리스크이고 손해일것인
데, 좀 더 장기적 안목으로 여러 불확실성이 야기시키는 리스크에 대한 보험으로서 리드타임이 짧은 팀, 혹은 애자일 팀을 끌여들이
려는 시도는 없을까요?

----
그리고 조금 질문을 바꿔서, '애자일이 가능하다고 한다면, 구체적으로 무엇이 어떤 모습으로 가능하다는 뜻일까요?' 조금 더 각개
격파(?) 할 수 있지 않을까요?

고객회사와의 빠른 피드백? 실질적인 가치를 매일 전달하는 개발? 유닛테스트 & TDD? 지속적인 디자인 개선? 지속적인 통합?
페어 프로그래밍? 프로세스 개선을 위한 매일매일의 노력? 혹은 이를 가능하게 하는, 변화에 대해 포용하는 사람들의 마인드?

10%의 애자일, 30%의 애자일, 60%의 애자일, 80% 이상의 애자일이 있다면, 각 스펙트럼 대비 모양새들이 어떨지가 궁금
합니다. :)

[JinYoung Heo]

대기업 중심의 SI 에서 아직 애자일팀을 도입하지 않는 이유는 그들이 보기에 - 이젠 그들이라고 해야할 처지가 되었군요 ㅎㅎ -  너무

이상적이라고 생각하기 때문이 아닐까 합니다. 왜 그 유명한 명언 있잖아요? "좋긴한데.. 우리한테는 맞지않아" -_-a

사실 제가 생각하기에는 워터펄 방식에서 성공을 기대하는게 더 이상적이긴 합니다만 ㅎㅎ.

게다가 그 바닦은 생각보다 상당히 얼키고 설켜 있어서 "좋은데!(논리적이던 감성적이던)" 만으로는 적용하기가 꽤 까다로운 동네죠.

단적인 예로 뭐 어떻게 보면 전혀 다른 의미일 수도 있겠습니다만, 제가 S모사의 신입사원이던 2003년에, 계열사의 대규모 차세대

시스템 구축 프로젝트에서 자바 1.3x를 썼습니다.

제가 "아니 왜 1.4 안써요? 나온지도 꽤 되었고 성능도 더 좋다는데..." 라고 물었을때의 대답은 "검증이 안되었기 때문" 이었습니다.

1.4가 첫 릴리즈 된게 2002년 초였고 저 프로젝트는 2003년 여름의 끝자락이었는데도 말이죠.

논리적이던(인터넷의 여러 측정 자료등을 보면 확실히 향상 되었고, 게다가 나온지 1년이나 되었으며 그간 버전업도 있어서 안정적이고 충분한

검증의 시간을 가졌고) 감성적이던(신버전인데!! 외국 애들도 프로젝트에 잘 쓰고 있는데!!) 옳은 거지만 혹시나 썼다가 문제가 생길경우 1.4를

쓰자고 했던 사람이나 파트가 뒤집어쓸께 뻔하니깐 안했던 겁니다. 물론 이것말고도 다른 이유 (지금 추측컨데 - 이건

순전히 추측입니다. 그 당시에는 이정도까지 생각을 못했으니깐 - 고객이 IBM 장비를 신뢰하니깐 운영체제로 AIX를 집어 넣어야 겠는데

AIX용 자바 1.4가 없었거나 좀 문제가 있었더라 같은것도..) 도 있었을 수 도 있겠죠.

물론 애자일 방법론의 경우 모르는 사람이 더 많다도 중요한 원인이겠습니다만, 이래저래 현재의 풍토는 상당히 복잡한 양상을 보여준다는 것입니다.

그렇다고 전혀 안된다는 이야기는 아닙니다 ㅎㅎ.

상황은 복잡하긴 하지만 제가 생각하는 파해법은 간단해서 누군가 최악의 경우 뒤집어 쓸 각오로 선빵(?)을 날린 후 그 프로젝트가 홈런을 치면 됩니다.

물론 그 홈런에 애자일 방법론에서 기인한다는 것을 증명해야하는 과정이 따라야겠습니다만, 일단 그렇게 해서라도 윗선에 이게 실제 써먹을 수 있고

좋다는 걸 보여주는 것이죠.

현재 S사의 어떤 프로젝트가 애자일 방법론을 적용해서 진행하고 있습니다. (누군가 선빵을 날렸습니다. ㅎㅎ. 물론 프로젝트 내부의 찬동자(!)도

있었지만 다른 부서에서 해당 프로젝트에 해보지 않겠느냐고 제안을 했으니, 프로젝트로서는 최악의 경우에도 손해볼 장사는 아니므로 가능했던...)

전 이 프로젝트가 꼭 대박 성공했으면 좋겠습니다. 막 너무 성공해서 신문에도 나고 그럴정도로 말이죠. 아마 그럼 너도 나도 눈에 불을 켜고

달려들 겁니다. :-)

물론 저는 부드럽게 스며들듯이 퍼지는 것을 좋아 합니다만, 때로는 강공도 필요하지 않을까 합니다 (/-_-)/

2008년 7월 6일 (일) 오후 7:20, 강석천 <free...@gmail.com>님이 작성한 메시지:

[Sangchel Hwang]

예 저도 허진영선임(아 이제 선임이 아닌데..^^;) 말대로 성공했으면 좋겠습니다.

2008/7/7 JinYoung Heo <clas...@gmail.com>:

--
http://moai.tistory.com

[영회]

말씀하신 내용이 오히려 실용적이네요.
아래 분이 말씀한 것처럼 방법론을 애자일과 비애자일로 구분해서 넣고 빼는 식이 오히려 더 현실성이 낮아 보입니다.
애자일을 썼다고 대대적으로 공표하면 애자일을 모르는 사람들에게 타겟이 되기 싶고
어떤 일들은 별 효과가 없는 때에 나타나서 '그것봐라 내가 그럴 줄 알았어'라고 할 수도 있습니다.
방법론 이름이야 뭐면 어떻습니까.

저는 실제 SI 프로젝트에서 애자일 선언에 입각한 접근을 행해서 효과를 거둔 바 있습니다. 정확하게는 현재도 거두고 있죠.
그 중에서 하나를 소개하자면 OPPM(One Page Project Management)를 보고 인용한 것인데
프로젝트 계획 시점에서 전체를 다루는 WBS는 고객사 내규가 허용하는한 구체적인 액티비티는 명기하지 않고 목적 중심으로 작성해
죠.
그리고, 실행계획은 스프린트라는 반복주기 단위로 처음에는 2주 단위.. 그리고 프로젝트 중반 이후부터는 4주로 했다가 현재는 6
주 단위로 작성합니다.
필연적으로 변할 수 밖에 없는 부분을 조기에 고정하려고 욕심을 부리다가 소모하는 시간이
following a plan 이나 comprehensive documentation에 해당하고 그 시간을 아끼면
working s/w를 만드는데 쓸 수도 있고, 변화할 부분을 고정하지 않았기에 Responding to change에 유리하
죠.
계획의 2단 분리는 일정 변경으로 유발할 수 있는 고객사 결제 등을 피할 수 있어서 시간을 벌어주었죠.

비슷한 사례 중의 하나로 요구사항 범위 확정건이 있는데요.
우리는 12주 안에 결과를 만들어 보여줘야 할 일이 있었는데요.
문제는 고객도 잘 모르는 요구사항에 대해서 정의하고 만들어야 한다는 점이었습니다.
그런 상황에서 지나치게 요구사항을 정의하고, 필요한지 어떤지도 잘 모르는 기능을 위해
UI 프로토타이핑이나 다양한 계층의 현업 인터뷰 소집으로 인한 시간 소비가 위험해보였습니다.
하여.. 2주만에 요구사항에 대한 최소한의 검증 기준만 세워두고 모호한 것은 바로 구현에 들어갔습니다.
모호한 것 우선해서 개발을 했죠. 그래서 모호한 것은 대충 구현된 프로토타입(throw-away가 아닌)을 보여주고 컨셉 불일치
부터 확인을 했습니다.
그런 후에는 살을 붙이면 되었고, 결국 빠듯해보이던 일정에 무리없이 구현을 할 수 있었습니다.
가장 큰 성공요인 중에 하나가 고객과 다른 생각을 하지 않는다는 점을 주기적으로 확인하는 과정에 있었고
그 매개체는 working s/w 였습니다. 물론, UI나 API요소가 강한 것은 그 부분부터 구현했고, 저장방식이 중요한 녀석
은 DB 스키마나 클래스 자료구조부터 구현해서 보여줬죠.

그 밖에도 훨씬 많은 프랙티스가 있습니다. 애자일 프랙티스로 정리된 것 말고...
저희가 실전에서 응용해서 효과를 낸 것들 말이죠.
흥미를 갖는 분이 있다면.. 프로젝트 종료후 자체적으로 제작하는 보고서를 일부 발췌해서 공유할 수 있을 듯 합니다.
일반화 하긴 힘들겠지만, 하나씩 사례가 모이고 발전하다 보면... :)

[Hubert Shin]

영회님 말씀 잘 읽었습니다. 제가 있는 프로젝트에서도 많은 도움이 될 것 같군요.

하지만, 한편으로는 더 답답해지는군요.
OOPM의 방식 인용을 적용할 수 있는 환경이 부럽기만 합니다.

전 공공기관 프로젝트에 있습니다.

고객이 여러 계층에 있고, 정치적인 외압이 자주 발생하는 곳입니다.
접촉할 수 있는 것은 하위단계의 고객이고, 하위단계 고객과 아주 좋은 관계를 유지하고 있더라도
정치가 그룹에 아주 가까운 상위그룹이 빈번하게 프로젝트를 휘저어 놓습니다.

이런 경우, 결국 변경사항에 대한 비용을 산정하는 일은
최초 기능점수(Function Point)를 산정하는 이들의 몫입니다.
이들은 싸우고 싸워서, 고객에게 조금이라도 예산을 더 떼어내도록 만들죠

하지만, 프로젝트를 수행하면서, 그들을 비난하지 않은 경우는, 제가 있던 5년간 한번도 본 일이 없습니다.
그렇게 이야기하여 이정도면 되겠다라고 위안하고나서 후에,
납기 어기면 패널티 먹고, 회사 이름이 대문짝만하게 신문에 등장합니다.
그리고 기자들은 bias를 힘껏 넣어 뉴스에 건물을 롱샷으로 찍어주고 전화 목소리를 넣죠.  ^^;

전 이런 환경에서 XP 에서 이야기하는 customer on site 라는 프랙티스는 너무나 extreme 하고 이상적인게 아닌가 라는 생각을 합니다.

현재 적용하는 애자일 프랙티스 들에서 여러가지 가능성을 보고 있지만,
혹시 xper group 에서 저와 같은 고민을 가지고 계셨던 분들이 있다면,  여쭙고 싶습니다.

굳이 공공 프로젝트가 아니라도,
고객 계층이 상향식, 계단식으로 되어 있어서,
위와 비슷한 문제가 있었고 어떤 방식으로 개선 했다는 사례나 아이디어가 있을까요?

즐거운 하루 되십시오~

2008년 7월 8일 (화) 오전 2:56, 영회 <ahnyo...@gmail.com>님이 작성한 메시지:

[강석천]

On 7월8일, 오전2시56분, 영회 <ahnyoung...@gmail.com> wrote:
> 말씀하신 내용이 오히려 실용적이네요.
> 아래 분이 말씀한 것처럼 방법론을 애자일과 비애자일로 구분해서 넣고 빼는 식이 오히려 더 현실성이 낮아 보입니다.
> 애자일을 썼다고 대대적으로 공표하면 애자일을 모르는 사람들에게 타겟이 되기 싶고
> 어떤 일들은 별 효과가 없는 때에 나타나서 '그것봐라 내가 그럴 줄 알았어'라고 할 수도 있습니다.
> 방법론 이름이야 뭐면 어떻습니까.

주변에 도입하시는 분들 중 '이름 없이 실천하기' 로 도입하시는 분들이 좀 되는 것 같습니다. 말씀하신대로 '애자일' 로 타이틀
이 걸릴 경우 무언가 일이 안될 때 (새로운 것을 도입할 경우 학습 기간 중 혼란기가 있는 것이 어느정도 당연함에도 불구하고)
바로 공격받는 느낌입니다. 혹은 애자일 이전에의 이름없는 best practice들을 가꾸어오고 만들고 실천해오신 분들에게 자칫
하면 선을 그어버리는 잘못을 저지를 수도 있는 것 같습니다.

멋진데요! 최근 루비세미나 때 RoR 과 agile을 이야기하신 분들의 경우도 RoR 의 강점을 이야기하시면서 접근방법을 이야기
하신 것중 하나가 '불명확한 부분에 대해는 아에 프로토타입으로 대화하자' 였습니다.
'컨셉 불일치의 빠른 확인' , '고객과 다른 생각을 하지 않는다는 점을 주기적으로 확인하는 과정', 이를 위한 매개체로서의
'working s/w' 은 확실히 의미가 있어보이고 다른 프로젝트 때에도 적용하기 용이한 방법 같습니다.

[Youngrok Pak]

아직 창업한지 몇 달 되지도 않았지만 우리 회사의 사례도 도움이 되는 부분이 있을 것 같아서 잠깐 하나 더 남겨봅니다.

현재 우리 회사는 SI 프로젝트 하나에 병으로 참여하고 있습니다. 갑은 우리나라에서 까칠하기로 유명한 회사입니다. 납기 어기면 갑한테 먼저 한 방 맞고 을은 돈 깎자고 나옵니다. 회사 위치가 갑, 을 다 떨어져 있어서 커뮤니케이션하려면 전화나 메신저, 메일로 해야 합니다. 갑한테 직접 메신저나 전화로만 이야기했다가 을한테 보고 안하면 혼나기도 합니다--; 나름 공공 SI에서도 한 2년 있었는데 이것보다는 상황이 나았던 것 같습니다. 암튼, 이런 상황에서 SI를 하고 있는데...

개발 플랫폼은 플래시인데 팀원 4명 중 한 명 빼고는 다 플래시 처음입니다. 아직 플래시 쓴지 얼마 안되서 TDD는 어떻게 하는지 몰라서 못하고 있습니다. 조금 알아보니까 asunit이 있는데 그닥 편리하지가 않더군요. 그래서, 대신 개발할 때 최대한 자주 실행해봅니다. 리팩토링할 때도 30초짜리, 1분짜리 리팩토링 하나 하고 실행해보고 합니다. 그래서 Test도 없이 2시간 걸리는 리팩토링을 해도 버그가 하나도 추가되지 않았던 적도 있었죠. 메소드 하나 만들 때도 "TDD를 한다면 이 메소드를 어떻게 만들 것인가"를 생각하면 도움이 많이 됩니다.

페어 프로그래밍도 가끔 재택 근무도 하고 출퇴근 시간이 다를 때도 있고 해서 못할 때가 많습니다. 그래서 일주일에 한 번 코드 리뷰를 하면서 같이 리팩토링도 하고 공유도 합니다.. 그래서 어떤 모듈이든 4명 중 아무나 작업할 수 있을 만큼 공유가 되고 있죠. 저희는 Truck Number가 3입니다.

플래시 쪽에 지식이 얕아서 아직 Integration 자동화는 구축하지 못했습니다. 그래서 매일 수동으로 ContinousIntegration을 합니다. 그게 오히려 프로젝트 구조를 단순하게 만드는 계기가 되기도 했죠. 도요타 방식 왈, 복잡한 것을 자동화하지 말고 복잡한 것을 단순하게 만든 다음 자동화하라.

Real Customer Involvement는 당근 꿈꾸기 힘든 상황입니다. 대신 가끔 우리 자신이 고객 모드가 됩니다. 물론 이럴 때 주로 나오는 내용은 나라면 이딴 거 안 써!지만-_- 가끔 그런 결과를 을이나 갑에게 피드백을 주는데 먹힐 때가 있습니다. 아직 뿌듯함?을 느낄 정도는 아니지만 시키는대로만 하는 SI보다는 좀더 애자일하지 않나 싶습니다.

XPI나 XPE, XPE2의 프랙티스만을 기준으로 본다면 우리 팀의 애자일 적용 점수는 30점이 안될지 모릅니다. 하지만 우리는 거의 70점 이상은 되는 애자일 팀이라고 자뻑 중이죠-_- 물론 70점이 만족할 정도는 아니지만 최소한 낙제는 아니니까...

아시는 분은 아시겠지만, 제가 잠시 애자일 컨설팅에서 김창준씨와 함께 일했던 적이 있었습니다. 그 때 애자일 컨설팅에 들어가려고 면접을 봤었는데, 이런 테스트를 했었습니다. 가상의 까칠한 팀원이 있고 그 사람이 페어 프로그래밍에 반대하는데 그 사람이 페어 프로그래밍을 하도록 컨설턴트 입장에서 설득해보라는 거였습니다. 전 그래서 하던대로 페어 프로그래밍의 장점을 주저리 주저리 늘어놓으면서 논쟁을 했죠. 그랬더니, 테스트 끝나고 나서 평가하기를, "코드 리뷰 이야기가 나왔는데 페어 프로그래밍이 코드 리뷰보다 좋다고 주장하기만 할 게 아니라 일단 상대의 주장을 인정해주고 코드 리뷰라도 한 번 해보자"라고 시작해보는 게 더 나았을 것 같다고 하더군요. 당시 그 말의 촛점은 상대의 주장을 인정해주면서 스며드는(?) 컨설팅의 기술 같은 거였다고 생각되는데, 전 그것도 인상적이었지만 한 편으로, 아, 애자일 프랙티스도 단계적으로 적용할 수 있는 거구나, 하는 깨달음을 얻었죠. 근데, 이런 거 얘기해도 되는 거겠죠 창준님? ^^


고등학교 때도 공부방법을 선생님이나 선배가 알려주는 대로 따라하지 말고 자신만의 학습법을 만들라는 이야기를 많이 들었는데, 애자일 방법론의 적용도 그런 측면이 중요하지 않나 싶습니다. 애자일 프랙티스의 가치와 원리는 이해하되, 원리를 훼손하지 않는 범위 내에서 적절히 튜닝해서 적용하는 것이 필요한 것 같습니다. 정석은 배우고 잊어버려라 같은 의미랄까요.