개발 프로세스, 논리적인 연결고리가 필요하다.

개발 프로세스는 SW 프로젝트에서 필요악이라고 생각이 든다. 분명 필요하지만, 어떻게 접근할 것인가에 따라서 독이 될 수도, 득이 될 수도 있는 면이 상존하고 있다. 개발 프로세스는 그 유형에 따라서 폭포수, 반복, 점증 등의 형태로 다양하게 표현될 수도 있지만, 무엇보다도 독이 되는 면은 어느 한 유형에만 집착하여 선후 작업에 대한 연관관계도 없는 작업을 강요하는 형태일 것이다.

개발 프로세스를 '필요악'이라고 표현하는 이유 중에 하나는 대부분의 프로젝트에서 득보다는 실을 너무 많이 안겨준 개인적인 경험에서이다. 물론 어떤 프로젝트에서는 의미있는 산출물을 만들면서 자신에게도 정말 도움이 되는 경우도 있었지만, 이러한 경우들은 구현의 상세한 부분보다 그러한 구현이 나타날때까지의 큰 개념적인 접근의 내용을 기술하는 경우였다. 또한, 각 산출물들 간에는 어느 정도 연결고리들이 존재하여 이전 산출물에서 이후 산출물을 만들어내는 논리적인 배경을 뒷받침해주는 경우가 실제 의미있는 산출물일 것이다. 

물론 개발 프로세스가 산출물 그 자체만을 의미하지는 않는다. 하지만, 눈에 보이는 결과물이 결국 산출물이다보니 본질적인 작업의 흐름이 아닌 작업의 결과만을 가지고 모든 것을 여기에 연결하곤 한다. 대표적인 예가 화면 목록과 개발 진척도를 연결하는 행위이다. 100개의 화면을 만든다면(실은 화면이 100개라는 기준 역시 상당히 애매한 표현이다. 하나의 화면에 탭 형태의 UI가 있다면 이를 1개의 화면으로 볼 것인가 아니면 탭의 수만큼 화면 갯수를 포함할 것인가. 혹은 팝업 화면은 어떻게 할 것인가 등등의 문제가 있다) 각 화면의 완성도(이 역시 애매한 표현으로 화면은 결국 기능의 완성을 위한 매개체이기 때문에 해당 화면에서 외부 시스템과의 연결이 있고 이러한 기능이 아직 구현할 준비가 안된 상태라면 이 화면은 외부 시스템 연결을 하기 위한 준비가 될때까지 미완성으로 남길 것인가)를 기준으로 진척 상황을 관리하는 형태가 된다.

개발을 분석/설계하는 과정에서의 목록은 큰 의미가 없으면 얼마든지 가변적일 수 있다. 개발 진척을 관리하려는 목적이라면 산출물 자체를 가지고 따져서는 절대 안된다. 보는 시각에 따라서 달라지는 기준은 측정 기준이 될 수 없다. 변하지 않고 누구든지 보편적으로 인정하는 것을 기준으로 삼아야 한다. 그리고, 이를 완성하기 위한 과정으로 개발 프로세스를 유연하게 적용하여 각 산출물들의 연관을 지어야 한다. 어떤 기준은 단순한 화면에 관련한 산출물만을 필요로 하고, 또 다른 기준은 추상화가 어느정도 이루어진 핵심 개념을 포함하는 설계 모델이 될 수도 있다. 모든 기준을 화면으로만 관리하는 것은 전체 진척에 있어서도 상당한 모순이 발생될 수도 있으며, 수치상 100% 완료라고 하더라도 시스템은 여기저기서 문제를 끌어안고 있는 시한 폭탄이 될 수 있다.

연결고리가 없는 개발 프로세스 상의 작업은 개발자에게 의미없는 작업이 될 수 밖에 없으며, 결국 최종적으로 시스템을 구현하는 사람이 코드를 구현하고 다시 재작업해야 하는 결과를 낳게 된다.