> "'Agile' 이라는 단어는 사실상 의미가 없는 지경까지 전복(subvert) 되었고, 애자일 커뮤니티의 경우 대체로 컨설턴트와 벤더들이 서비스와 제품을 판매하는 장소가 되어버렸습니다."
그 이유는 이미 모두 아는 바와 같이 어떤 방법이 상업적(혹은 프로젝트)의 성공을 보장하지는 않기 때문입니다. 심지어 게임 한정으로 애자일이 다른 접근법들보다 통계적으로 더 유의미한 결과를 내지는 않는다는 연구도 있었습니다:
"위대한 게임 개발팀은 모든 구성원이 스튜디오의 개발 방법론을 잘 훈련하여 따르도록 합니다 [1]. 또한 게임 개발 중에도 지속적으로 수고를 들여 개발 방법을 갈고닦아 개선합니다. 그럼에도 불구하고 우리는 애자일과 애자일-스크럼, 혹은 워터폴 개발 방법 사이에서 통계적으로 유의미한 성과 차이를 발견하지 못 하였습니다 [2]. 개발 방법론 중 성과에 차이를 보인 것은 아무런 개발 방법론이 없는 경우였습니다: 우리의 연구는 팀원이 많던 적던 개발 방법론이 없는 것은 재앙적이라는 사실을 발견하였습니다.
개발 방법론에 보편적인 정답은 없습니다. 스스로 생각하기에 여러분의 팀과 프로젝트에 가장 적절하다고 판단되는 개발 방법론을 선택하세요."
그럼에도 불구하고 제가 애자일의 접근법(좀 더 정확히는 스크럼, XP와 칸반)을 선호하는 이유는 제가 당면한 문제를 해결해주기 때문입니다(It works!) 같은 이유로 "애자일 선언문"에서 제가 가장 좋아하는 대목은 "우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다."입니다. 그것은 어떤 이론에 근거해서 방법론을 만든 게 아니라, 실제로 '내가 해보고 효과를 봤고, 다른 사람들에게도 추천했더니 역시 효과가 있었다.'는 것을 기초로 하기 때문입니다. 켄 슈와버와 마이크 비들이 쓴 Agile Software Deveopment with Scrum에서도 실천법을 먼저 발명하고, 나중에 그 이론적 근거를 발견하는 여정이 언급됩니다. 그리고 그 관점이라면, 언젠가 누군가가 애자일을 더 발전시킬 수도 있고, 애자일보다 더 나은 것을 발명할 수도 있다고 생각합니다.
다른 모든 도구들과 마찬가지로 애자일은 만병통치약이 아니니, 누군가에게는 효과를 낼테고, 누군가에게는 효과가 없을 거라고 생각합니다. 그래서 이제는 누군가가 애자일로 성공했다고 특별히 더 용기를 얻거나, 혹은 실패했다고 해서 특별히 낙담하지 않습니다. 동시에 더 나은 방법이 있다면, 언제든 시험하고 적응할(inspect and adapt) 의사가 충만합니다. 그게 스크럼이 제게 준 진정한 교훈이니까요.
저는 아래 설명에는 공감하며, 나머지는 그려러니 합니다.
> "'Agile' 이라는 단어는 사실상 의미가 없는 지경까지 전복(subvert) 되었고, 애자일 커뮤니티의 경우 대체로 컨설턴트와 벤더들이 서비스와 제품을 판매하는 장소가 되어버렸습니다."
그 이유는 이미 모두 아는 바와 같이 어떤 방법이 상업적(혹은 프로젝트)의 성공을 보장하지는 않기 때문입니다. 심지어 게임 한정으로 애자일이 다른 접근법들보다 통계적으로 더 유의미한 결과를 내지는 않는다는 연구도 있었습니다:
"위대한 게임 개발팀은 모든 구성원이 스튜디오의 개발 방법론을 잘 훈련하여 따르도록 합니다 [1]. 또한 게임 개발 중에도 지속적으로 수고를 들여 개발 방법을 갈고닦아 개선합니다. 그럼에도 불구하고 우리는 애자일과 애자일-스크럼, 혹은 워터폴 개발 방법 사이에서 통계적으로 유의미한 성과 차이를 발견하지 못 하였습니다 [2]. 개발 방법론 중 성과에 차이를 보인 것은 아무런 개발 방법론이 없는 경우였습니다: 우리의 연구는 팀원이 많던 적던 개발 방법론이 없는 것은 재앙적이라는 사실을 발견하였습니다.
개발 방법론에 보편적인 정답은 없습니다. 스스로 생각하기에 여러분의 팀과 프로젝트에 가장 적절하다고 판단되는 개발 방법론을 선택하세요."
(출처: https://masterfarseer.blogspot.com/2015/03/5.html )
그럼에도 불구하고 제가 애자일의 접근법(좀 더 정확히는 스크럼, XP와 칸반)을 선호하는 이유는 제가 당면한 문제를 해결해주기 때문입니다(It works!) 같은 이유로 "애자일 선언문"에서 제가 가장 좋아하는 대목은 "우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다."입니다. 그것은 어떤 이론에 근거해서 방법론을 만든 게 아니라, 실제로 '내가 해보고 효과를 봤고, 다른 사람들에게도 추천했더니 역시 효과가 있었다.'는 것을 기초로 하기 때문입니다. 켄 슈와버와 마이크 비들이 쓴 Agile Software Deveopment with Scrum에서도 실천법을 먼저 발명하고, 나중에 그 이론적 근거를 발견하는 여정이 언급됩니다. 그리고 그 관점이라면, 언젠가 누군가가 애자일을 더 발전시킬 수도 있고, 애자일보다 더 나은 것을 발명할 수도 있다고 생각합니다.
다른 모든 도구들과 마찬가지로 애자일은 만병통치약이 아니니, 누군가에게는 효과를 낼테고, 누군가에게는 효과가 없을 거라고 생각합니다. 그래서 이제는 누군가가 애자일로 성공했다고 특별히 더 용기를 얻거나, 혹은 실패했다고 해서 특별히 낙담하지 않습니다. 동시에 더 나은 방법이 있다면, 언제든 시험하고 적응할(inspect and adapt) 의사가 충만합니다. 그게 스크럼이 제게 준 진정한 교훈이니까요.