상세 컨텐츠

본문 제목

린(Lean) 방법론 - 특징, 적용, 의견

카테고리 없음

by 화천사장 2023. 12. 27. 12:29

본문

반응형

소프트웨어 개발 방법론 중에 하나인

린 (Lean) 방법론에 대해 알아봅니다. 

 

Lean(린) 개발 방법론은 Toyota에서 시작된 매우 유명한 방법론입니다. 

비용 절감, 효율성 향상, 낭비 제거 이외에도 목표가 많겠지만, 이 세 가지가 핵심 목표입니다. 

 

주의) 린 스타트업과는 유사하다고 볼 수 있지만, 조금 다름니다. 이 부분은 다음에 논의하도록 합시다.

 

[목차]

특징

아래와 같은 원칙을 이야기합니다. 

  • 가치 제공 ( Value ) 
    • 고객에게 가치 있는 것을 제공합니다. 
    • 가치는 소프트웨어의 기능을 포함하여, 비기능, 외적인 부분들을 포함하여 고려합니다.
  • 가치 스트림 맵핑 ( Value Stream Mapping ) 
    • 소프트웨어 개발 전체 프로세스를 시각화 합니다.
    • 시각화된 흐름을 분석하여 비효율성을 식별해 내고, 이를 개선하도록 노력합니다.
  • 품질 ( Quality ) 
    • 개발 속도보다는 품질을 중요시합니다. 
    • 오류를 최소 하도록 노력하고, 지속적인 개선을 통해 높은 품질을 유지하도록 합니다.
  • 낭비 제거 ( Eliminate Waste ) 
    • 린(Lean)에서 특히 강종하는 부분으로, 낭비를 최소화합니다. 
    • 불필요한 개발(업무), 반복, 대기 시간 등을 최소화할 수 있도록 노력합니다. 
  • 빠른 반응 ( Quick Response ) 
    • 고객의 요구 사항의 변화에 빠르게 대응하고, 유연하게 대응할 수 있는 능력을 강화합니다. 
  • 지식 및 인재의 활용 ( Utilize Knowledge and Expertise ) 
    • 조직의 내부 지식과 전문성을 최대 활용하여 문제를 해결하고 혁신을 이끌어 낼 수 있도록 노력합니다.  

적용 방법

아래와 같은 단계를 고려합니다. 

  1. 가치 도출 
    • 프로젝트의 목표와 고객이 원하는 가치를 명확히 이해합니다. 
    • 고객의 요구사항을 중심으로 가치를 도출하고, 도출된 가치가 소프트웨어에 어떻게 반영될 수 있는지 고려합니다. 
  2. 가치 스트림 맵핑 
    • 전체 개발 프로세스를 시각화하고, 가치 스트림 맵핑을 수행합니다. 
    • 이를 통해 비효율성과 낭비를 식별할 수 있고 개선할 수 있는 있습니다. 
  3. 지속적인 개선 
    • 주기적인 회고와 피드백을 수용하고, 개선 부분을 분석하고 적용합니다. 
  4. 스크럼, 칸반과의 통합 
    • 개발 프로세스의 반복의 방법 중에 스크럼, 칸반을 고려할 수 있습니다. 
    • 이를 통해 팀 간의 협업을 보다 강화시킬 수 있습니다. 
  5. 작은 배포 단위로의 분리 
    • 작은 단위의 변경 사항을 주기적으로 배포하여 보다 빠른 피드백을 얻어 개선합니다. 
    • 더불어, 문제를 조기에 반경하고 수정하는 것을 강조합니다.
  6. 문제 해결 및 지식 공유 
    • 문제의 해결하고, 그에 대한 지식을 공유하여 모든 구성원의 지속적인 학습을 장려합니다. 

의견

개인적으로 Toyota와 프로젝트를 진행한 적이 있었습니다. 린(Lean) 개발 방법론을 처음으로 경험했을 때의 설렘은 지금도 기억에 남습니다. 그 프로젝트는 3년 동안 진행됐었는데, 그때의 개발 프로세스와 문서화는 정말 완벽했습니다. 물론, 상세한 내용을 모두 소개하기는 어렵지만, 린 방법론은 전통적인 접근 방식을 유지하면서도 가벼움과 빠름을 강조하는 것 같았습니다.


특히, Toyota는 프로젝트 중에 'DRBFM (Design Review Based on Failure Mode)'라는 단계를 강조합니다. 이것도 하나의 방법론이기는 하지만, 이 단계는 정말 어렵기도 했지만, 그만큼 효과가 뛰어났습니다. 여기서 나온 문서들은 다른 프로젝트에서도 활용되고 공유되는데, 이것들은 유사한 문제 상황에서 그 문제를 해결하는데 도움이 되는 문서들이 됩니다. 

 

여러 프로젝트에서 유사한 문제가 발생할 때, 이 문서들을 검토하면 단서를 찾을 수 있을 뿐만 아니라, 더 나은 해결책을 찾을 수도 있습니다

이것이 정말 그럴까요? 확신은 못 드리겠지만, DRBFM 관정을 한 번이라도 경험해 보신다면, 아마도 '이것이 문서다!'라는 생각을 하실 수 있을 것입니다.

이 부분은 제 개인적인 경험이기도 하지만, 팀원들이나 동료들에게도 적극 권장하고 싶은 내용입니다.

기획가 되면, 추후 별도의 공간에서 소개해보려고 합니다

 

반응형

티스토리툴바