Lean Software Development - 1

Lean production

린(Lean)이라는 단어의 사전적 의미를 보게되면 Without much flesh , (of meat)with little or no fat, 여윈, 기름기가 없이 살코기만의, 라는 뜻으로 해석된다. 린 생산방식(Lean production)이라는 것은 미국의 MIT(매사추세츠 공과 대학)의 연구그룹이 1990년 도요타생산방식으로 대표되는 일본식 생산시스템에 붙인 이름이다. 린 생산방식이란 생산현장의 원자재와 재공품의 흐름을 분석하고 제조설비의 배치를 최적화해 중소제조업체의 생산성을 20%이상 높여주는 기법이다.

린 생산은 세계적 수준에 이른 반복공정으로써 시간을 중요시하는 새로운 반복공정 생산시스템이다. 제2차 세계대전 후 일본의 도요타와 오노가 린 생산의 개념을 가장먼저 개척하였다. 린 생산은 일본의 자동차산업에서 가장 많이 볼 수 있지만, 세계 곳곳에 퍼져, 많은 자동차회사들이 린 생산을 도입하였다.

린 생산방식은 수공업생산방식과 대량생산방식의 장점을 결합한 것으로서 수공업생산방식에서 오는 원가상승 및 대량생산방식의 융통성 부족 문제를 극복한다. 이렇게 하기 위하여 린 생산방식에서는 조직의 모든 부문에서 다능공(多能工) 팀을 편성하여 융통성 있는 자동화기계를 사용하여 매우 다양한 제품을 적정량씩 생산한다.

린 생산방식은 대량생산방식에 비해 '작은(lean)' 것이다. (lean production 이라는 용어는 IMVP의 연구자인 John Krafcik이 만들었음.) 공장에서 필요한 노동력, 생산에 필요한 면적, 공작기계 투자액, 신제품개발 소요시간이 절반에 지나지 않는다. 더욱이 린 생산방식에서 필요한 재고는 대량생산방식의 절반에 훨씬 못 미치면서도 결점수는 대폭 감소되며 점점 더욱 다양한 제품을 생산하는 것이다.

Lean 생산 방식의 Agile 적용 – Lean Software Development 7가지 원칙

1. 낭비를 제거하라

“고객을 위한 가치를 창조하지 않는 모든 것은 낭비다”

낭비 제거는 가장 기본적인 린 원칙이며, 다른 모든 원칙은 이 원칙에 바탕을 두고 있다. 그러므로 린 개발을 수행하는 첫 번째 단계는 낭비를 찾는 법을 배우는 것이고, 두 번째는 낭비가 발생하는 가장 큰 이유를 찾아내고, 이를 제거하는 것이며 다음 단계는 아직 낭비 요소가 남은 원인을 찾아내고 낭비를 제거하는 것이며, 이후에 이를 반복한다.

• 미완성 작업

완성되지 않은 소프트웨어는 그대로 사장될 위험이 크고, 다른 개발 작업에 방해가 될 수도 있다. 그러나 그보다 더 큰 문제는 결국 그것이 사용될지 안될지 알 수가 없다는 사실이다.

• 가외 프로세스

문서 작업은 자원을 소비하고 결과를 내는데 시간이 걸리게 만들 뿐 아니라 품질 문제를 숨기고 그다지 보람도 없으면서 갈수록 쓸모가 없어진다. 아무도 읽으려 하지 않는 문서 작업은 가치를 부가하지 않는다. 어떤 문서 작업이 가치 있는지를 확인하는 가장 좋은 방법은 그것이 만들어지기를 기다리는 사람이 있는지 확인하는 것이다.

• 가외 기능

이것은 위험을 야기할 수도 있으며 심각한 시간 낭비다. 시스템의 모든 코드는 수정될 때마다 추적, 컴파일, 통합, 테스트되어야 하고, 전체 시스템의 일부로 유지되어야 한다. 코드의 한 줄, 한 줄은 시스템의 복잡도를 높이고 잠재적인 결함 요소를 가진다.

• 직무 전환

한 사람을 여러 프로젝트에 투입하는 것은 낭비의 근원이다. 소프트웨어 개발자가 프로젝트를 전환하려면, 생각을 모으고 새로운 작업 흐름에 익숙해지기 까지 매번 상당한 시간을 필요로 한다. 여러 팀에 속하는 것은 더 많은 중단과 더 많은 업무 변경을 야기한다. 이러한 직무 전환 시간은 낭비다.

• 대기

어떤 일이 일어나기를 기다리 것은 큰 낭비다. 프로젝트 시작 전 지연, 인원 구성의 지연, 과도한 요구사항 문서 작업으로 인한 지연, 검토와 고객 승인 시 생기는 지연, 테스트에서의 지연, 배포에서의 지연은 모두 낭비다.

• 이동

개발은 집중을 요구하는 활동이므로 층을 이동하게 되면 생각보다 훨씬 많은 시간이 걸린다. 질문에 답을 얻는데 걸린 시간보다 개발자가 다시 집중하는데 걸리는 시간이 몇 배 더 클 것이다. 애자일 소프트웨어 개발에서 개발자, 테스트 담당자, 고객 등 관련된 모든 사람이 하나의 작업 공간에서 작업하도록 권장하는 이유가 여기에 있다.

• 결함

결함 때문에 발생하는 낭비는 발견되기까지 걸린 시간과 결함의 파급력에 비례한다. 결함으로 인한 낭비를 감소시키려면 즉시 테스트하고 자주 통합하고 가능한 빨리 완성하여 릴리즈 하는 것이 좋다.