한번에 모든 일을 하기에는 너무 벅찬 경우가 있다. 설사 단계를 밟아 가려고 해도 일 전체가 주는 심리적 부담으로 아예 일 시작을 못하는 것이 다반사다.
그러므로
이 방법은 소프트웨어 개발 방법론에서 시작되었다. 프로그램이라는 것은 광의로 보아 "문제 해결"이다. 문제 해결과 이에 필요한 가장 효과적 과정 등에 대해 이토록 체계적인 연구를 다른 분야에서 찾아보기가 힘들다. 그러므로 이런 개발 방법론을 다른 분야에 적용한다.
IncrementalDevelopment는 쉽게 말해 "조금씩 목표로 접근하는 것"을 말한다. 예를 들어 경쟁력있는 웹 게시판을 만들려고 작심을 하고 컴퓨터 앞에 앉은 경우, 결국 몇시간을 아무것도 하지 못하고 멍하니 시간을 소진하기 쉽다. 이럴 경우 간단하게, 미리 만들어둔 데이타를 화면 상에 보여주는 기능만 하는 "가장 단순한 웹 게시판"을 만드는 것을 일차적 목표로 하고 그 일에 매진한다. 수행 중에는 저 멀리에 있는 목적지를 생각하지 말고 현재 하고 있는 것에 중심을 둔다. 다음 단계에 할 일은 "목적지에 조금이라도 가까워질 수 있는 최소한의 일"로 정한다.
FastFeedback과 함께 빠른 심리적 보상과 과정 중의 변화 적응력으로, 결과적으로는 초기에 투자 비용이 높은 방법보다 더 빨리, 더 높은 성취도를 얻을 수 있다.
옛날 일본 사무라이들의 수행 중 하나로, 뒷마당(앞마당도 좋다)에 어린 나무(빨리 자라는 나무라고 하던데.. 이름은 모름) 한그루를 심어두고 매일 물을 준 후 그 나무를 뛰어넘는 방법이 있다. 몇달이 지난 후에는 일반인으로써는 상상도 못할 높은 위치까지 도약이 가능해진다고 한다. 이게 바로 IncrementalDevelopment가 아닐까.
라이온이 만병통치약으로 생각하고 떠벌리는 방법론...거참, 한번에 목표에 접근 못하면 슬금슬금 문제를 파악하면서 접근해야지..모든사람이 천잰감...물론 한번에 문제해결에 도달하면 좋구~!
XP에서 논하는 점진적개발이란 결과적으로 그렇게 될 것이니, 이에 대하여 부담스러워 하지 말라는 정도의 의미로 받아들이면 좋을 것 같습니다. 개발 초기의 구상이 끝까지 가는 경우가 많이 있습니다. 이전에 저는 프로토타이핑이란 방법을 무지 좋아 했지만 이의 목적은 고객에게 결과물에 대한 데모를 보이고 고객의 목표를 끌어내기 위한, 또는 기술적 가능성을 점점하기 위한 수단이지 반드시 그러해야한다는 입장은 아닙니다. 오히려 초기에 가지는 목적과 개요정도를 확실히 하지 않으면 안된다고 봅니다. 개인적 개발이 아닌 바에야 목표를 제시하지 못하는 프로젝트는 시작되지도 못할 것입니다. ---이정호
개발 초기의 구상이 끝까지 가는 경우를 봤습니다. 대부분 실패하는 프로젝트였습니다. 만약 그렇지 않고 성공한 프로젝트를 알고계시다면 어떻게 그게 가능했는지 배우고 싶습니다. (40년도 넘게 개발을 해온 RonJeffries, KentBeck 같은 사람들도 분명 배우고 싶어할 겁니다.) 물론, 개발 초기부터 개발자와 고객(스테이크홀더) 간의 비젼공유(시스템 아키텍춰, 컨셉추얼 아키텍춰)의 필요성을 부정하는 것은 아닙니다. --김창준
MileStone vs InchPebble. -- 이지수궁금한 점이 있습니다. IncrementalDevelopment라는 것은 내가 어떤 방식으로 시작하든 항상 점진적으로 문제에 접근해 감으로써 그 결과물이 훌륭한 프로그램이 될 수 있다는 것인가요? 이런 식으로 생각해도 될런지는 모르겠지만.. local optimum이라는 한계가 있지는 않을까요? 물론 local optimum에라도 도달한다면, 훌륭하다고 칭찬받을 수 있을거 같긴 합니다만.. --naya
IncrementalDevelopment를 사용하고, 바로 코 앞만 생각하고 다른 생각은 절대 하지 않으면 로칼 옵티멈에 머무를 수도 있겠다고 생각합니다. 대부분은 로칼 옵티멈에 도달하면 주위를 둘러보고 반성해 보게 되죠. 글로벌 옵티멈을 구할 수 있는 상황이라면 애초에 목적지를 예측해서 그리로 직진하는 것이 좋을 것입니다. 하지만 세상은 완벽하지 않고 나도 완벽하지 못하며, 세상은 변하고 나도 변합니다. --김창준
DeleteMe IncrementalDevelopment와 local optimum은 분야가 약간 다른 거 같습니다. IncrementalDevelopment는 SoftwareEngineering의 문제로 소프트웨어 개발 단계를 어떤 식으로 이끌어갈 것인가에 관한 하나의 방법론이고, local optimum은 optimal solution을 찾는 알고리즘에서 better solution을 찾다보니 best solution이라고 생각했던 것이 global optimum이 아닌 local optimum인 경우를 말합니다. see GeneticAlgorithm SimulatedAnnealing --나를잊어줘
결국 메타포니까, 조금 느슨하게 생각해 주시길 부탁드립니다. 예컨대 XP의 ID적 방식(혹은 No 
BigDesignUpFront )을 접한 사람들이 늘 하는 비판 중 하나가, IncrementalDevelopment는 로칼 옵티멈에 빠질 수 있다는 것입니다. 우리가 늘 사용하는 메타포입니다. 수학적으로 도메인을 엄격히 구분하면 현실적 유용성을 잃을 수 있습니다. --김창준
BigDesignUpFront )을 접한 사람들이 늘 하는 비판 중 하나가, IncrementalDevelopment는 로칼 옵티멈에 빠질 수 있다는 것입니다. 우리가 늘 사용하는 메타포입니다. 수학적으로 도메인을 엄격히 구분하면 현실적 유용성을 잃을 수 있습니다. --김창준IncrementalDevelopment를 하다가 어떤 한계에 부딪히거나 처음 설계가 잘못되었다고 판단되는 시점이 있어서, 처음부터 재 설계가 필요한 경우가 있다. 다시 설계해야 한다고 판단되는 그 시기를 놓치지 말아야 한다. --아무개