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.    낭비를 제거하라
고객을 위한 가치를 창조하지 않는 모든 것은 낭비다
낭비 제거는 가장 기본적인  원칙이며다른 모든 원칙은  원칙에 바탕을 두고 있다그러므로  개발을 수행하는  번째단계는 낭비를 찾는 법을 배우는 것이고 번째는 낭비가 발생하는 가장  이유를 찾아내고이를 제거하는 것이며 다음 단계는 아직 낭비 요소가 남은 원인을 찾아내고 낭비를 제거하는 것이며이후에 이를 반복한다
 
l  미완성 작업
완성되지 않은 소프트웨어는 그대로 사장될 위험이 크고다른 개발 작업에 방해가  수도 있다그러나 그보다  문제는 결국 그것이 사용될지 안될지  수가 없다는 사실이다.
l  가외 프로세스
문서 작업은 자원을 소비하고 결과를 내는데 시간이 걸리게 만들  아니라 품질 문제를 숨기고 그다지 보람도 없으면서갈수록 쓸모가 없어진다아무도 읽으려 하지 않는 문서 작업은 가치를 부가하지 않는다어떤 문서 작업이 가치 있는지를 확인하는 가장 좋은 방법은 그것이 만들어지기를 기다리는 사람이 있는지 확인하는 것이다.
l  가외 기능
이것은 위험을 야기할 수도 있으며 심각한 시간 낭비다시스템의 모든 코드는 수정될 때마다 추적컴파일통합테스트되어야 하고전체 시스템의 일부로 유지되어야 한다코드의   줄은 시스템의 복잡도를 높이고 잠재적인 결함 요소를 가진다.
l  직무 전환
 사람을 여러 프로젝트에 투입하는 것은 낭비의 근원이다소프트웨어 개발자가 프로젝트를 전환하려면생각을 모으고 새로운 작업 흐름에 익숙해지기 까지 매번 상당한 시간을 필요로 한다여러 팀에 속하는 것은  많은 중단과  많은 업무 변경을 야기한다이러한 직무 전환 시간은 낭비다.
l  대기
어떤 일이 일어나기를 기다리 것은  낭비다프로젝트 시작  지연인원 구성의 지연과도한 요구사항 문서 작업으로 인한 지연검토와 고객 승인  생기는 지연테스트에서의 지연배포에서의 지연은 모두 낭비다.
l  이동
개발은 집중을 요구하는 활동이므로 층을 이동하게 되면 생각보다 훨씬 많은 시간이 걸린다질문에 답을 얻는데 걸린시간보다 개발자가 다시 집중하는데 걸리는 시간이     것이다애자일 소프트웨어 개발에서 개발자테스트 담당자고객  관련된 모든 사람이 하나의 작업 공간에서 작업하도록 권장하는 이유가 여기에 있다.
l  결함
결함 때문에 발생하는 낭비는 발견되기까지 걸린 시간과 결함의 파급력에 비례한다결함으로 인한 낭비를 감소시키려면 즉시 테스트하고 자주 통합하고 가능한 빨리 완성하여 릴리즈 하는 것이 좋다
 
 
2.    배움을 증폭하라
l  소프트웨어 개발에서의 품질
소프트웨어 개발에서 품질은 인식 통합성과 개념 통합성  차원에서 생각   있다인식 통합성이란 제품이 기능,사용성신뢰성경제성  전체적인 면에서 균형을 이루어 고객을 만족시킨다는 의미다반면 개념 통합성이란 시스템의 중심 개념이 유연하면서 응집력 있게  작동한다는 의미다.
l  소프트웨어 개발에 관한  가지 주장
하나는 처음부터 모든 설계와 코드가 완벽해야 한다고 개발자들이 확신하도록 독려하는 것이다다른 하나는 설계와 코드가 처음부터 정확하도록 하는 것보다는 소규모로 신속하게 빌드하는 사이클을 만드는 편이  좋다는 것이다처음부터 제대로 신중한 검토를 하고 진행하는 접근법은 구조화가   문제에는 좋지만 구조화되지 않은 문제에는 대게신속한 빌드하는 접근방법이 좋을 것이며 테스팅 비용이 매우 높다면 신중한 검토를 통해 지식을 얻는 편이 나을 것이다.
l  학습주기
리팩토링을 수반한 반복 시스템을 개발해 가면서 설계를 개선하는 방법은 지식을 생성하고조기에 해답을 찾고통합성 있는 시스템을 만드는 가장 효과적인 방법  하나라고 밝혀졌다그것은 이러한 접근법이 문제가 잘못 정의된 경우에 가장 효과적으로 지식을 생성하기 때문이다개발에서 가장 중요한 질문은 어떻게 해야 가장 효과적으로 배울 있는가?” 이고 대답은 짧은 학습 주기를 여러  거치면 된다는 것이다.
l  피드백
대부분의 상황에서 소프트웨어 개발 프로젝트가 문제에 부딪힐  환경을 개선하는 가장 효과적인 방법은 피드백을 줄이는 것이 아니라 늘리는 것이다.
n  결함을 쌓아두지 말고 코드를 작성하는 대로 바로 테스트하라
n  문서나 상세계획서를  만들지 말고코드를 작성해서 아이디어를 확인하도록 시도하라
n  사용자에게서 요구사항을  모으지 말고나중에 사용하게  사용자 화면   가지를 보여주고 의견을 수집하라.
n  사용할 도구를 고르는  너무 많은 노력을 들이지 말고현재 도구 가운데 제일 나은  개를 골라 테스트해 보라
n  한번에 전체 시스템을 바꿀 방법을 찾으려 애쓰지 말고기존 시스템에  기반의 화면을 만들어 여기에서 새로운 아이디어를 얻도록 노력 하라
개발자는 그들의 직접적인 고객이 누구인지와 그들에게 정기적인 피드백을 제공하는 방법을 알아야 한다문제가 발견되면 제일 먼저  일은 피드백 루프가 모두 완전한지 확인하는 것이다 말은 자신의 직접적인 고객이 누구인지 모두알아야 한다는 의미다.
l  반복(Iterations)
반복이란 짤게 정해진 기간 내에 설계프로그램테스트통합배포하여 소프트웨어의 유용성을 증가시키는 것을 말한다이것은 최종 제품의 일부로 실제 사용된다는 사실을 제외하고는 제품 개발 과정에서 만드는 프로토타입과 매우 유사하다 소프트웨어는 향후의 계속적인 반복을 통해 개선되기는 하지만처음 만들어질 때부터 작동되는 테스트를 거친통합된 코드다.
반복은 순차적 소프트웨어 개발에서 엄청난 피드백을 발생시키므로 고객과 개발자  시스템에 관심 있는 다양한 사람들 간에 훨씬 폭넓은 의사소통을 가능하게 한다.
 
 반복의 3가지 원칙
n  작은 단위 작업은 자원 활용도를 높임으로써 작업자 사이의 의사소통을 향상시키고 품질을 높인다작은 단위의 작업은 피드백 루프가 짧아서 다루기가 쉽다.
n  반복 주기가 짧아지면시스템은 예측보다 사실에  반응하게 된다.
n  반복은 작업자 개인이나 여러 팀과 고객 간의 의견을 동기화하는 접점이다반복은 기능을 완성하여 시스템을 릴리즈또는 선적할  있는 상태가  바로  지점이다.
 
 반복 주기의 초기에는 개발팀이 개발할 기능들의 난이도를 추정하고고객이나 고객 대표로 하여금 예상 비용을 감안하여 기능의 우선순위를 결정하게 하는 계획 세션을 수행한다가장 높은 비즈니스 가치를 먼저 제공하려면 가장 중요한기능을 먼저 개발해야 한다위험성이 높은 항목들도 나중으로 미루지 말고 일찍 시작하는 것이 좋다
 
 
3.    가능한 늦게 결정하라
l  동시 소프트웨어 개발
n  깊이 우선 접근법은 상위 수준의 의사결정을 하위 수준에 의존하게끔 만든다손실이 가장  실수는 시작할 중요한 부분을 고려하지 않아서 빚어진다 실수는 구체적인 사항으로 너무 빨리 진행할  발생하기쉽다일단 세부적인 경로를 정하고 나면되돌릴  없으며  사실을 깨닫지 못하는 경우가 많다 실수가 발생할 가능성이 있을  가장 좋은 방법은 계획 전반을 둘러보고 구체적인 결정을 미루는 것이다.
n  동시 개발  너비 우선 접근법을 채택하면 크고 비용이 많이 드는 문제를 너무 늦기 전에 발견할  있다.순차 개발 방식(깊이 우선)에서 동시 개발로 이동한다는 것은 상위 단계의 개념적 설계가 결정되면 비록구체적인 요구 조건들이 아직 조사 단계라 할지라도바로 가장 높은 가치가 있는 기능을 프로그래밍하기시작하는 것이다이것은 직관에 반하는 것처럼 들릴지도 모른다하지만  방법을  중요한 기능들의구현을 강요하는 방향으로 쫓아 가기 전에 , 여러 가지 다양한 선택을 시도하면서 배워 나갈  있게 해주는 탐색적 접근이다.
 
l  비용상승
순차 개발은 모든 결정을 가능한 빨리 내릴 것을 강조한다그러면 모든 변경 비용은 동일하게 매우 높다동시설계는 결정을 가능한  미룬다 이것은  가지 효과가 있다.
-      비용이  제약 조건의 수를 줄인다.
-      비용이  결정 사항을 너비 우선 방식으로 처리하면 좀더 바람직하게 결정할  있다.
-      대부분의 결정을 이뤄둔다특히 변화의 필요를 줄여준다.
-      대부분의 변화에서 비용 증가 요소를 급격하게 감소시킨다.
 소프트웨어 개발은 모든 설계에 대한 확정을 가능한 지연시킨다아직 확정되지 않은 결정은 변화시키기 쉽기 때문이다 소프트웨어 개발에서는 설계를 강건하고 변화에 유연하도록 개발하라고 강조한다 설계방식은 불가피한 변화를 받아들이고 여러 종류의 변화에 손쉽게 적응할  있도록 시스템을 구성한다.
 
l  책임이 따르는 마지막 순간
동시 개발은 결정을 책임이 따르는 마지막 순간” 결정하지 모해 중요한 대안이 제거되기 직전까지 결정을미루는 것을 가능하게 해준다마지막 순간으로 결정을 미루는  가지 팁이 있다.
 
n  부분적으로 완료된 설계 정보를 공유하라.
설계가 릴리즈되기 전에 완전해야 한다는 관념은 동시 개발의 가장  적이다.
n  작업자들  직접 협력 체계를 구성하라
구체적인 사항을 이해하는 사람들과 반드시 직접 의사소통 해야 한다.
n  변화를 수용하는 방법에 대한 감각을 개발하라.
객체지향 설계와 컴포넌트 기반 개발 기법을 사용하라.
-       모듈을 사용하라 : 인터페이스에 대한 고객의 요구사항이 안정될 때까지 모듈의 내부 설계 결정을 미루어라.
-       인터페이스를 사용하라 : 구현과 인터페이스를 분리하라구현은 변하더라도고객에게 제공되는 인터페이스는 동일하게 유지하라.
-       매개변수를 사용하라.
-       추상화 기법을 사용하라
-       순차 프로그래밍을 피하라 : 절차적 프로그래밍이 아닌 선언적 프로그래밍을 사용하라.
-       자신만의 관성화된 도구 구축에 주의하라 : 프레임워크와 다른 도구에 대한 투자는 흔히 구현의 상세한 부분을 너무 일찍 결정하도록 하는 경우가 많다.
-       반복을 파하라.
-       관심을 분리하라 :  모듈은  정의된  가지 책임만을 맡아야 한다.
-       변화를 캡슐화 하라 : 변화하리라 예측되는 것을 캡슐 안쪽에 두어인터페이스가 안정되게 해야 한다.
-       미래에 필요한 기능은 구현을 미루어라
-       가외 기능을 피하라
n   분야에서 특히 중요한 것이 무엇인지 느끼는 감각을 계발하라.
n  결정을 언제 내려야 하는지 감각을 키워라
n  빨리 반응하는 능력을 키워라
신고

'Programming > Agile' 카테고리의 다른 글

Lean Software Development  (0) 2010.05.25
by Hazard 2010.05.25 14:11

티스토리 툴바