소프트웨어 개발에서의 Agile

최근 수행했던 프로젝트에서 있었던 일이다...

기획과 디자인은 시도 때도 없이 요구사항과 디자인을 변경했다...그리고 이러한 것을 Agile 문화라고 표현했다.....

그 얘기를 들으면서 아직도 소프트웨어 개발에 있어서 Agile은 멀었구나 ... 라는 것을 느꼈다...

그러면 진정한(?) 또는 올바른 Agile 이란 무엇을까? .... 여러가지 정의와 개념들이 난무하지만 단, 한가지 공통적인 내용은 

"무조건 자주 변경하는 것이 Agile은 아니다" 라는 내용이다. 즉, 사람들이 Agile 이라는 변명하에서의 무조건적인 변경과 수정을 가장 경계하고 있다는 말이다.

그러면 어떻게 해야 할까? 답은 아주 간단하다. 변경과 수정하려면 올바른 방법으로 수행하면 된다. 

그러면 올바른 방법은 무엇일까? "분석-설계-구현-테스트" 아주 단순하고 고리타분한 것 같지만 지금까지 이어내려오고 있는 진리같은 원칙이다.

Agile 이란 자주 분석-설계-구현-테스트 를 하라는 의미... 즉, 공정의 Iteration 을 많이 하라는 의미이고 이는 기존의 Waterfall 방법론이 단 한번의 Iteration 을 가지는 것에 대한 단점을 보완하는 소프트웨어 이행지침에 일종이다. 

요구사항의 무조건적인 변경만으로는 분석-설계-구현-테스트 의 올바른 공정을 진행할 수 없고 이는 Agile 로 연결되지 않는다.

이러한 Agile 을 수행할때 각각의 Iteration 들이 제각각의 방향과 전략으로 수행된다면 이 또한 산으로 가게 된다. 

따라서 Agile 을 이행하기 위해서는 사전에 정확하고 정밀한 Architecture 를 수립해서 올바른 품질측정지표들과 의사결정지표들을 가지고 각각의 Agile Iteration 이 Architecture의 범위내에서 벗어나지 않고 진행되어야만 올바른 Agile 을 수행할 수 있는 것이다.