반복의 필요성은 사실 검증하고 말고 할 것도 없다.
우리의 삶은 늘 시행착오를 통해 반복적인 학습을 하면서 성장하기 때문이다.
프로젝트라고 해서 달라질 것은 없다.

어제 PM이 설계모델의 수준에 대해서 물었다. 솔직히 대답했다.
모델을 가장 잘 파악하고 있는 PL은 문제를 간파했다.
개발자(모델러)들의 업무 이해도가 매우 낮다는 점...
그럼에도 불구하고, 파일럿 압박 때문에 심도있는 분석이 어려운 상황

개발자에게 복잡하고 생소한 업무를 분석하면 한계가 있다.
어떤 경우는 그 바닥에 수년간 종사해도 정의하지 못하는 것들이 태반이다.
소프트웨어 개발자에게 최고의 무기가 될 수 있는 것은 구현해보는 것이다.
구현해내는 과정에서 해당 업무를 이해할 수 있다.
구현해나가는 과정 자체가 업무를 이해하게끔 유도한다.
업무에 대한 이해가 없이 고객의 요구를 제대로 구현하는 것은 불가능하다.

그런데 모든 업무를 다 분석하고 설계, 구현으로 나아간다면...
업무 분석을 제대로 할 수 있을까?

1) 업무 범위가 작거나
2) 업무에 엄청나게 해박한 사람이 분석하거나
3) 업무에 변화를 주지 않으려고 하는 경우가 아니라면

보편적으로는 업무를 나눠서 구현해보고
시행착오를 통한 학습을 통해서 업무 이해도와 자신감을 키우는 것은 분명 득이 된다.

분명 반복은 개발자의 업무 이해도와 생산성에 엄청난 차이를 주었다.

또한, 반복은 SoC(Separation of Concerns)에도 유익하다.
하나의 업무흐름을 먼저 구현해보고 나면 기술적인 문제에서 약간은 자유로와진다.
아무리 간단해보이는 구현이라도 초반에는 잡다한 환경구성과 (새로운 툴 도입 등으로 인한) 기술 습득에 노력이 필요하기 때문이다.
그런 과정을 한번 겪고 나면 더욱 업무에 집중할 수 있다.