애자일 소프트웨어 개발에 대한 간단한 동영상인데, 비주얼하게 잘 설명을 하고 있네요. 영어 자료입니다만 그리 어렵지는 않아요. ^^
애자일 개발의 방식 그 자체에 대해 설명하는 것은 아닙니다. 애자일 개발이 가져오는 가치에 대해 설명하고 있습니다.
애자일 개발에 관심이 있는 개발자라면 한번 봐두면 좋을 것입니다. 또한 강의 방식이나 비주얼 표현 방법을 눈 여겨 본다면 응용할 부분이 있을 겁니다. 쉬운 걸 쉽게 얘기하는 사람조차 별반 없으니까요.
댓글 6개:
재미있게 잘 보았습니다. 다만, 위 동영상의 설명만으로는 애자일의 경우, 소프트웨어의 릴리스 이후에도 개발팀이 상주 내지는 지속적인 개발이 항상 일어난다는 의미로 해석이 됩니다. 기존의 워터풀 형식에서는 릴리스 후에는 운영/관리 주기로 들어가서 버전업은 극히 필요할 때 외에는 하지 않는것이 일반적이라고 생각합니다만 애자일에서는 운영/관리와 지속적인 버전업(업데이트)가 발생한다는 얘기이군요. 위 설명에서는 비지니스적인 가치를 가지고 얘기를 하고 있지만 소프트웨어의 유지보수 및 지속적인 업데이트에 드는 비용은 애자일 쪽이 훨씬 더 들겠다는 생각이 들었습니다만.. 제 오해인가요?
To tuna님/ 이렇게 생각하시죠. 소프트웨어 개발의 라이프사이클 동안 애자일로 개발을 하는 것입니다.
그러므르 1.0, 2.0 등의 개발 기간이 이어진다는 가정 하에 동영상이 작성되었으며(SI만 생각하지 마시고요. 패키지, 인터넷 서비스도 생각하세요), 만일 인터발이 있다면 애자일 개발도 똑같이 적용됩니다.
기존 워터폴 개발에 비해 애자일 개발이 계속 개발팀이 상주해야한다거나 유지보수 비용이 더 드는 부분은 없다고 생각합니다.
개발하는 기간에 맞추어 생각하세요. ^^
바비님의 댓글을 읽고나서 다시 한번 위의 동영상을 보았습니다. 그 감상입니다.
(토다는 것처럼 느껴질 우려가 있습니다만 그런 의도는 없다는 것을 미리 밝힙니다. ^^)
적어도 위의 프레젠테이션의 설명에서는 애자일의 개발의 라이프사이클이란 것이 워터폴과 달리 릴리스 이후에도 지속된다고 보입니다.
워터폴 형식이 거대한 규모의 소수의 릴리스와 장기간의 유지/운영기간으로 이루어진다면 애자일의 경우 소규모의 지속적인 릴리스와 그 사이의 짧은 유지/운영기간으로 구성된다는 얘기를 하고 있는 듯 합니다. 그런 소규모의 지속적인 릴리스로 인해 비지니스의 니즈에 보다 신속하게 대응이 가능하고 그래서 비지니스적인 가치를 워터폴 형식에 비해 더 제공할 수 있다는 얘기로 생각이 됩니다.
하지만 제가 말했듯 지속적인 릴리스가 이루어지는 상황에선 개발이란 사이클이 빈번하게 반복되겠지요. (어쩜 애자일에서는 유지/보수란 라이프사이클은 존재하지 않고 계속해서 갱신해 가는 걸 말하는 게 아닐까요? 위 동영상에서는 그렇게도 생각이 됩니다만... ) 그리고 개발이란 라이프사이클은 유지보수에 비해 보다 많은 인원과 비용을 필요로 하는 것은 두말할 필요도 없겠지요. 더불어 위에서 언급되지는 않았지만 애자일은 고객의 상주를 조건으로 하지요. 그러니 현실적으로는 개발팀의 적어도 빈번한 상주 내지는 고객측 담당자의 개발팀특에의 상주가 필요하게 되겠네요.
즉 위의 모델대로 하려면 워터폴에 비해 보다 빈번한 개발 라이프 사이클이 도래하게 되며 그건 워터폴형식에 비해 시스템측의 관점에서만 보았을 때는 워터폴에 비해 비용이 더 발생하게 될 수도 있다는 얘기를 한 것입니다.
물론 비지니스적으로 창출된 가치가 시스템의 지속적인 릴리스의 비용을 상회한다면 충분히 타당성이 있는 얘기입니다만 그럼에도 불구하고 시스템적인 관점에서 비용이 더 발생할 수 있다는 사실엔 변함이 없습니다. 위 동영상에서는 그런 트레이드오프에 대한 언급이 없었기에 그걸 얘기한 것입니다.
( 그리고, 이건 조금 핀트를 벗어나는 얘기입니다만, 그렇게 빈번한 변경이 요구되는 시스템이 정말 엔터프라이즈 시스템에서 몇 퍼센트나 될까요?)
그리고, SI가 아니라 패키지, 인터넷 서비스의 경우를 말씀하셨는데, 전 아래와 같은 두가지를 이유로 위 동영상은 SI에 대해 얘길 하고 있다고 생각했습니다.(영어가 그리 뛰어나지 못하므로 잘못 이해했을 가능성도 있습니다만..)
1.저 동영상의 첫 부분 즈음에 엔터프라이즈 소프트웨어 솔루션에 대해 언급하고 있습니다.
2.또한 위 동영상에서는 처음 릴리스한 소프트웨어가 시간이 지나면 그 가치가 낮아진다고 하면서 대개의 경우 5년에서 7년이 지나면 더이상 비지니스적인 가치가 없어진다고 했습니다.(위 동영상에서는 허용가능한 비지니스적 가치 이하로 그래프가 내려가는 시기입니다) 즉 위 동영상에서 설명하는 대상은 7년 사이에 3번가량의 릴리스가 있는 시스템입니다.
하지만 패키지나 인터넷 서비스라면, 당연히 바비님이 말씀하시듯 애자일한 방법론을 적용해야 하겠지요. 특히나 요즘처럼 베타 서비스가 판을 치는 트랜드에서는 더더욱이요. ^^
제가 이 문제에 대해 생각을 하고 있는 이유는 위의 동영상은 비지니스적인 가치에 중점을 두고 얘길 풀어가지만 실은 그 외에도 비용이란 관점도 필요하지 않는가 하고 생각했기 때문입니다. 어쩜 위 동영상에는 등장하지 않지만 다른 섹션(?)에서는 언급했을 수도 있습니다만, 많은 컨설팅 또는 프레젠테이션들이 저렇게 듣기 좋은 소리만 하고 넘어가는 경우가 있어서..
이상 요즘 의심증이 심각한 넘이었습니다. ^^;;
To tuna님/ 애자일이 모든 경우에 좋은 것은 아닙니다. 새로운 것을 전파하는 사람들은 그것의 긍정적인 부분만 얘기하는 경향이 있지요.
그래서 결국 본인이 직접 적용해보는 것이 중요한 것이죠. 저의 경우 소규모 팀에서의 성과는 확실히 있었습니다. 다만 대규모 팀일 경우에는, 여러 이해관계의 상충을 극복하지 않고서는 애자일 개발의 적용 및 성공이 힘들 것으로 생각합니다.
실은 저 역시 현재 애자일은 아니지만 새로운 기술적 컨셉에 대한 전파활동을 본업으로 하고 있습니다. 하지만 새로운 개념이다 보니 너무 좋은 면만 강조하는 사람들이 주변에 많이 보입니다. 전 가급적 듣기 좋은 소리보다는 사실을 알려주려고 노력하는 편입니다. 그래서인지 저 동영상을 보니 메릿트 뒤에 숨겨진 어쩌면 존재할 지도 모르는 디메리트에 대한 얘기가 없다는 것이 걸리더군요. (참고로 저 역시 애자일 방법론에 의거해서 2년 반 가량 직접 개발한 경험은 있습니다만 애자일지지자들이 주장한 만큼의 효과는 얻지 못했습니다.)
이번에 제가 말씀드린 내용은 제가 애자일에 대해 평소 생각하던 문제이기도 하기에 혹시라도 고견을 들을 수 있을까 싶어 제기했던 것입니다.
마지막으로, 바비님은 강의방식이나 비쥬얼한 표현에 대한 얘길 한 것이었는데 엉뚱한 애자일얘기로 길게 끌어 죄송합니다.
재미난 토론이 있었네요~
아는 분이 했던 말이 기억납니다.
"Agile의 프랙티스는 마치 독과 같아서.
잘 되면 커다란 약이 되지만,잘못 하면 죽는다."
지나는 길에 코멘트 놓고 갑니다. 휙~
댓글 쓰기
댓글을 환영합니다.
스팸으로 인해 모든 댓글은 운영자의 승인 후 등록됩니다. 스팸, 욕설은 등록이 거부됩니다. 구글의 블로그 시스템은 트랙백을 지원하지 않습니다.