Lean 소프트웨어 개발

린 소프트웨어 개발 방법론은 도요타자동차에서 하드웨어 제품 생산의 낭비를 줄이기 위해 개발된 린의 개념을 소프트웨어 개발에 적용하기 위해 탄생했다.

 

린의 의미는 “낭비를 제거한”이라는 뜻으로 최고의 효율성을 내기위한 방법론이라고 생각해도 될 것이다. 생각해보자 소프트웨어 개발에 낭비를 줄일 수 있는 방법일 것이다.

린 소프트웨어의 개발 원칙은 다음과 같다.

 

Amplify Learning

지식을 창출한다. 소프트웨어 개발하는 과정을 학습의 관점으로 본다. 개발을 통해 고객의 요구사항을 이해하고 문제를 해결하는 현재의 개발 방법이 적합한지 학습해야 한다. 고객과의 소통을 통해 도메인을 파악할 수 있고, 전체 최적화 관점에서는 개별 프로세스를 이해해야 개별 프로세스의 불필요한 낭비를 찾아 수정할 수 있다.

만약 고객과의 커뮤니케이션 중 몰랐던 사실이 발견되면 이는 기존의 계획이 잘못된 방식이며 새로운 방식을 적용해야 함을 뜻한다. 개발하고 있는 방향을 지속적으로 고객과의 검토를 통해 확인하고 고객의 니즈를 학습하는 기법을 적용하는 것이 핵심이다.

 

defer decision

결정을 미룬다.  왜 미룰까? 개발의 과정에서 의사결정은 매우 중요한 요소이다. 이 결정에 따라 비용이 달라진다. 린 소프트웨어 방법론은 2010년대 미국 실리콘밸리 스타트 업에게 적용되는 경우가 많다.  스타트 업은 보다 싸고 빠르게 고객의 니즈를 파악해 펀딩이 떨어지기 전 기업의 가치를 인정받아야 하는 조직이다.  그런데 의사결정을 미루다니 약간의 역설이 아닌가도 싶다.

이는 결정을 구분하는 것이다. 적은 비용으로 돌이킬 수 있는 의사결정은 신속하게 진행하고 비용이 크거나 결과가 필요한 의사결정은 최대한 미루는 것이다.  최대한 미루고 미루어서 중요한 의사결정 (예를 들어 아키텍처, 도메인 설계)는 마지막 순간에 내리라는 의미이다.

 

build quality in

미완성 작업을 최소화해야 한다. 미완성 작업이 낭비를 초래하는 이유는 재작업 또는 변경가능성이 높아지기 때문이다. 이를 줄이기위해선 일괄 작업의 크기를 줄여야 한다.

 

eliminate waste

낭비를 제거한다.  상품 기획의 낭비, 상품개발의 낭비를 조심해야 한다.

고객이 원하지 않는 기능을 기획하는 행위는 상품 기획의 낭비이다.

이는 기능 개발, 문서화, 시간, 돈을 연쇄적으로 낭비하게 되어 전체 소프트웨어의 품질을 낮출 수 있다. 상품 개발의 낭비는 개발과정에서 발생하며 재작업, 대기시간 등이 발생한다. 고객의 불편사항 및 가치를 빠르게 파악해 기획한 후 필요한 기능을 애자일 방법론을 적용해 개발을 하면 기획 낭비와 개발 낭비를 최대한 줄일 수 있다.

 

empower the team

개발팀을 존중하라. 개발팀을 통제하는 관리자는 목표 달성을 위해 개발팀을 재촉하는 경우가 많다. 이러는 것이 아닌 개발팀이 목표달성을 위해 최선을 다할 것이라고 신뢰하고, 방법을 팀에게 맡기는 방식이 좋다. 이는 개발팀에게 의사결정권을 위임함으로 써 책임을 팀에게 나눌 수 있고 빠른 실행력을 갖게 되기 때문이다.

 

deliver fast

빠르게 소프트웨어를 인도해야 한다. 고객의 니즈를 전달하는 속도는 니즈의 양과 개발 속도가 결정하는데, 개발속도가 동일해도 불필요 개발을 최소화하면 동일 시간 내에 고객의 만족도는 증가한다.  고객이 필요하지 않는않은 기능을 제외하는 시간은 그렇게 하지 않는 것보다 더 많은 시간을 갖게 된다.  주어진 시간에 많은 기능을 제공하여 고객의 만족도를 높이는 것은 린의 원칙에 어긋난다.

 

optimize the whole

전체를 최적화한다. 부분 최적화에 집중하는 것이 아닌 전체 최적화에 집중하는 것이다. 각자의 성과를 최적화하는데 집중하면 제조의 과잉생산의 함정에 빠지기 되는데, 이는 보다 많은 요구사항 목록을 만들게 되어 업무가 비 대해진다. 많은 양이 아닌 보다 빠르게 고객에게 가치를 전달하는 것이 더 중요하다.

 

결과적으로 린의 핵심은 모든 낭비를 제거하여 빠르고 품질 좋은 소프트웨어를 만들기 위한 방법론이라고 할 수 있다.