린 소프트웨어 개발
Lean software development |
| 시리즈의 일부 |
| 소프트웨어 개발 |
|---|
린 소프트웨어 개발은 린 제조 원칙과 프랙티스를 소프트웨어 개발 영역으로 변환한 것입니다.도요타 생산 시스템을 [1]채택하여 민첩한 커뮤니티 내에서 친린적인 서브 컬쳐의 지원을 받아 부상하고 있습니다.린은, 민첩한 조직을 서포트하는 견고한 개념의 프레임워크, 가치, 원칙, 및 경험으로부터 얻은 베스트 프랙티스를 제공합니다.
기원.
린 소프트웨어 개발이라는 용어는 2003년 Mary Poppendick과 Tom Poppendick이 쓴 동명의 책에서 유래했다.[2]이 책에서는 기존의 린 원칙과 22개의 툴 세트를 재작성하고 툴을 대응하는 민첩한 프랙티스와 비교합니다.Popendicks가 애자일 소프트웨어 개발 커뮤니티에 참여하면서 애자일 커뮤니티 내에서 이러한 개념이 더욱 널리 받아들여지고 있습니다.
린 원칙
린 개발은 린 제조 [4]원리에 매우 가까운 7가지 원리로 요약할 수 있습니다.
낭비를 제거하다
린 철학은 고객에게 부가가치를 주지 않는 모든 것을 낭비(무다)로 간주합니다.이러한 낭비에는 다음이 포함됩니다.[5]
낭비를 없애기 위해서는 그것을 인식할 수 있어야 한다.일부 활동을 우회할 수 있거나 우회하지 않고도 결과를 얻을 수 있다면 이는 낭비입니다.개발 과정에서 폐기된 부분적인 코딩은 낭비입니다.서류 작업이나 고객이 자주 사용하지 않는 기능 등의 추가 기능은 낭비입니다.작업자를 작업 간에 전환하는 것은 낭비입니다(컨텍스트 전환에 관여하는 사람이 시간을 소비하고 많은 경우 손실됩니다).다른 활동, 팀, 프로세스를 기다리는 것은 낭비입니다.작업을 완료하기 위해 필요한 재학습은 낭비입니다.결함과 낮은 품질은 낭비입니다.실질적인 가치를 창출하지 못하는 관리 오버헤드는 낭비입니다.
가치 스트림 매핑 기술은 낭비를 식별하기 위해 사용됩니다.두 번째 단계는 폐기물의 발생원을 지적하고 제거하는 것입니다.폐기물 제거는 겉으로 보기에 필수적인 프로세스와 절차마저 폐기될 때까지 반복적으로 이루어져야 합니다.
학습의 확대
소프트웨어 개발은 코드를 작성할 때 반복을 기반으로 하는 지속적인 학습 과정입니다.소프트웨어 설계는 개발자들이 코드를 작성하고 그들이 배운 것을 포함하는 문제 해결 과정입니다.소프트웨어 가치는 사용에 대한 적합성으로 측정되며 요구 사항을 준수하지 않습니다.
문서나 세부 계획을 추가하는 대신 코드를 작성하고 구축함으로써 다른 아이디어를 시도할 수 있습니다.최종 사용자에게 화면을 보여주고 의견을 얻음으로써 사용자 요건 수집 프로세스를 간소화할 수 있습니다.코드 작성 즉시 테스트를 실행하여 결함 축적을 방지해야 합니다.
짧은 반복 사이클을 사용하여 학습 프로세스를 가속화할 수 있습니다. 각 사이클은 리팩터링 및 통합 테스트와 함께 이루어집니다.고객과의 짧은 피드백 세션을 통해 피드백을 늘리면 현재 개발 단계를 파악하고 향후 개선을 위한 노력을 조정할 때 도움이 됩니다.짧은 세션 동안 고객 담당자와 개발 팀 모두 도메인 문제에 대해 자세히 알아보고 향후 개발을 위한 가능한 해결책을 찾습니다.따라서 고객은 기존 개발 노력의 결과를 바탕으로 자신의 요구를 더 잘 이해하고, 개발자는 이러한 요구를 더 잘 충족시키는 방법을 배우게 됩니다.고객과의 커뮤니케이션 및 학습 프로세스에서 또 하나의 아이디어는 설정 기반 개발입니다.이 개발은 가능한 솔루션이 아닌 미래의 솔루션의 제약 사항을 전달하는 데 중점을 두고 있으며,[jargon] 따라서 고객과의 대화를 통해 솔루션의 탄생을 촉진합니다.
가능한 한 늦게 결정하다
소프트웨어 개발은 항상 어느 정도 불확실성과 관련되므로, 불확실한 가정과 예측이 아닌 사실에 근거해 의사결정이 이루어질 때까지 가능한 한 지연시키면서 세트 기반 또는 옵션 기반 접근방식을 통해 더 나은 결과를 달성해야 한다.시스템이 복잡할수록 변화를 위한 용량이 더 많이 내장되어야 하며, 따라서 중요하고 중요한 약속의 지연을 가능하게 해야 한다.반복적 접근법은 이 원칙, 즉 시스템 출시 후 발견될 경우 비용이 많이 들 수 있는 변경에 적응하고 실수를 수정할 수 있는 능력을 촉진한다.
- 세트 기반 개발: 예를 들어 차량에 새로운 브레이크 시스템이 필요한 경우 세 팀이 동일한 문제에 대한 솔루션을 설계할 수 있습니다.각 팀은 문제 영역에 대해 학습하고 잠재적인 해결책을 설계합니다.해결책이 불합리하다고 판단되어 삭감된다.기간이 끝날 때, 살아남은 설계를 비교하고 하나를 선택합니다.아마도 다른 사람의 학습에 기초한 일부 수정이 있을 것입니다.이것은 가능한 마지막 순간까지 약속을 연기하는 좋은 예입니다.또한 소프트웨어 의사결정을 통해 대규모 사전 설계로 인한 위험을 최소화할 수 있습니다.또, 올바르게 동작하는 한편, 다른 복수의 실장(실장 마다, 내부)이 있습니다.이들은 여러 구현에서 동시에 모든 입력과 출력의 정확성을 체크하는 폴트 톨러런스 시스템을 구현하기 위해 사용될 수 있습니다.
신속한 소프트웨어 개발 접근방식은 고객에게 선택의 폭을 넓힐 수 있기 때문에 고객이 자신의 요구를 보다 잘 이해할 때까지 특정 중요한 결정을 지연시킬 수 있습니다.또한 이를 통해 나중에 변화에 적응하고 비용이 많이 드는 초기 기술 관련 의사결정을 방지할 수 있습니다.이는 계획이 관여되어서는 안 된다는 것을 의미하는 것은 아닙니다.반대로 계획 액티비티는 다양한 옵션에 집중하여 현재 상황에 적응하고 신속한 행동을 위한 패턴을 확립함으로써 혼란스러운 상황을 명확히 해야 합니다.다양한 옵션을 평가하는 것은 무료가 아니라 늦은 의사결정에 필요한 유연성을 제공하는 즉시 효과적입니다.
가능한 한 신속하게 제공
급속한 테크놀로지 진화 시대에 살아남는 것은 가장 큰 것이 아니라 가장 빠른 것입니다.주요 결함 없이 최종 제품이 빨리 제공될수록 피드백을 더 빨리 받아 다음 반복 작업에 통합할 수 있습니다.반복 횟수가 짧을수록 팀 내에서 학습과 커뮤니케이션이 향상됩니다.속도가 빠르면 결정이 늦어질 수 있습니다.스피드는 고객이 어제 요구했던 것이 아니라 고객의 현재 요구를 충족시켜 줍니다.이것은 그들이 더 나은 지식을 얻을 때까지 그들이 진정으로 필요로 하는 것에 대한 결정을 미룰 기회를 준다.고객은 고품질의 제품을 신속하게 배송하는 것을 중시합니다.
적시 생산 이념은 소프트웨어 개발에 적용할 수 있으며 소프트웨어 개발의 구체적인 요건과 환경을 인식할 수 있습니다.이는 필요한 결과를 제시하고 특정 반복에서 필요한 결과를 달성하기 위해 팀이 스스로 조직하고 작업을 분할하도록 함으로써 달성됩니다.처음에 고객은 필요한 정보를 제공합니다.이것은, 작은 카드나 스토리로 간단하게 나타낼 수 있습니다.개발자는 각 카드의 실장에 필요한 시간을 예측합니다.따라서 작업 조직은 셀프 풀링 시스템으로 바뀝니다.매일 아침 스탠드업 미팅에서 팀원 개개인은 어제의 작업, 오늘과 내일의 작업 내용을 확인하고 동료 또는 고객에게 필요한 정보를 요구합니다.이를 위해서는 프로세스의 투명성이 요구되며, 이는 팀 커뮤니케이션에도 도움이 됩니다.
이 원칙의 밑바탕에 깔린 속설은 서두르면 낭비가 된다는 것이다.다만, 린 실장에서는, 가능한 한 빨리 출력을 확인하고 분석하기 위해서, 신속히 전달하는 것이 좋은 프랙티스인 것을 알 수 있습니다.
팀 강화
대부분의 기업에서는 조직 내 의사결정에 대한 전통적인 믿음이 있어 왔습니다.관리자들은 직원들에게 자신의 일을 어떻게 해야 하는지 지시합니다.워크아웃 테크닉에서는 역할이 바뀝니다.매니저는 개발자의 말에 귀를 기울이는 방법을 배웁니다.이를 통해 어떤 조치를 취할 수 있는지 더 잘 설명하고 개선을 위한 제안을 할 수 있습니다.린 어프로치는, 「의욕 있는 개인을 중심으로 프로젝트를 구축해, 작업을 완수할 수 있도록 신뢰한다」[7]라고 하는 민첩한[6] 원칙을 따르고 있어, 진척을 촉진해, 에러를 발견해, 장해를 배제합니다.다만, 마이크로 관리는 실시하지 않습니다.
또 다른 잘못된 믿음은 사람을 자원으로 여기는 것이다.통계 데이터 시트의 관점에서는 사람이 자원일 수 있지만, 소프트웨어 개발이나 조직 비즈니스에서는 단순히 작업 목록뿐만 아니라 작업 완료 중에 방해받지 않는다는 보장 이상의 것이 필요합니다.사람들은 도달 가능한 현실 속에서 팀이 스스로 책임을 선택할 수 있다는 확신을 가지고 목적을 위해 일할 동기 부여와 더 높은 목적이 필요합니다.개발자는 고객에게 접근할 수 있어야 하며, 팀장은 어려운 상황에서 지원과 도움을 제공해야 하며, 회의론이 팀의 정신을 망치지 않도록 해야 합니다.사람들을 존중하고 그들의 일을 인정하는 것이 팀에 힘을 실어주는 한 가지 방법입니다.
무결성 구축
고객은 시스템에 대한 전반적인 경험을 가지고 있어야 합니다.이것이 소위 인식되는 무결성입니다. 즉, 광고, 제공, 배포, 액세스, 사용법, 가격, 문제 해결의 용이성 등이 그것입니다.
개념적 무결성은 시스템의 개별 구성 요소가 전체적으로 잘 연동되어 유연성, 유지보수성, 효율성 및 응답성의 균형을 유지한다는 것을 의미합니다.이는 문제 영역을 이해하고 순차적으로 해결하는 것이 아니라 동시에 해결함으로써 달성할 수 있습니다.필요한 정보는 1개의 큰 덩어리가 아닌 작은 배치 조각으로 수신되며, 가급적 서면 문서가 아닌 대면 커뮤니케이션을 통해 수신됩니다.정보 흐름은 고객에서 개발자, 그리고 역방향 등 양방향으로 일정해야 합니다.따라서 오랜 시간 고립된 개발 후에 대량의 스트레스를 받는 정보를 피할 수 있습니다.
통합 아키텍처를 향한 건전한 방법 중 하나는 리팩터링입니다.원래의 코드 베이스에 기능이 추가될수록, 한층 더 개선을 추가하는 것은 어려워집니다.리팩터링은 코드의 단순성, 명확성, 최소한의 기능 수를 유지하는 것입니다.코드의 반복은 불량 코드 설계의 신호이므로 (DRY 규칙을 적용하여) 피해야 합니다.완전하고 자동화된 구축 프로세스에는 시스템의 현재 상태와 동일한 버전 관리, 동기화 및 의미를 갖는 완전하고 자동화된 개발자 및 고객 테스트 스위트가 수반되어야 합니다.마지막으로 철저한 테스트를 통해 무결성을 검증하고 시스템이 고객이 원하는 대로 수행되도록 해야 합니다.자동화된 테스트는 생산 공정의 일부로 간주되기 때문에 가치를 추가하지 않으면 낭비로 간주해야 합니다.자동 테스트는 목표가 아니라 목적을 위한 수단, 특히 결함을 줄이는 수단이 되어야 합니다.
전체 최적화
최신 소프트웨어 시스템은 단순히 부품의 합일 뿐만 아니라 상호 작용의 산물이기도 합니다.소프트웨어의 결함은 개발 프로세스 중에 축적되는 경향이 있습니다.큰 태스크를 작은 태스크로 분해하고 개발 단계를 표준화함으로써 결함의 근본 원인을 찾아내야 합니다.시스템의 규모가 클수록 개발에 관여하는 조직이 많아지고, 다른 팀에 의해 개발되는 부분이 많아질수록, 각 벤더간에 명확한 관계를 확립하는 것이 중요해지고, 각 컴포넌트가 원활하게 상호작용하는 시스템을 구축할 수 있게 됩니다.개발 기간이 길수록 하청업체 네트워크가 단기 이익 최적화보다 훨씬 더 유리하며, 이로 인해 윈-윈 관계가 실현되지 않습니다.
구체적인 실제 상황에서 실행하기 전에 프로젝트의 모든 구성원들이 린 사고를 잘 이해해야 합니다.「큰 사고, 작은 행동, 실패, 신속한 [8]학습」– 이러한 슬로건은, 분야를 이해하는 것의 중요성과 소프트웨어 개발 프로세스 전체에 있어서의 린 원칙의 실장의 적합성을 정리하고 있습니다.작업환경에 관한 강한 '상식'과 함께 모든 린 원칙이 구현되어야만 소프트웨어 개발에 성공할 수 있는 토대가 마련됩니다.
린 소프트웨어 프랙티스
Popendicks가 "도구"라고 부르는 린 소프트웨어 개발 관행은 신속한 변화를 위한 소프트웨어 개발에서 원래 동등한 것을 약간 수정한 것입니다.이러한 관행의 예는 다음과 같습니다.
신속한 변화를 위한 소프트웨어 개발은 신속한 변화를 위한 선언에 명시된 가치와 원칙에 기초한 일련의 방법과 관행을 포괄하는 용어이기 때문에, 린 소프트웨어 개발은 신속한 변화를 위한 소프트웨어 개발 [9]방법으로 간주됩니다.
「 」를 참조해 주세요.
레퍼런스
- ^ Yasuhiro Monden(1998), 도요타 생산 시스템, Just-In-Time 통합 어프로치, 제3판, GA: Engineering & Management Press, ISBN0-412-83930-X.
- ^ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. ISBN 978-0-321-15078-3.
- ^ Mary Popendick: "소프트웨어 개발에서 리더십의 역할" https://www.youtube.com/watch?v=ypEMdjslEOI
- ^ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. pp. 13–15. ISBN 978-0-321-15078-3.
- ^ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. pp. 19–22. ISBN 978-0-321-15078-3.
- ^ "12 Principles Behind the Agile Manifesto - Agile Alliance". agilealliance.org. 4 November 2015.
- ^ Mark Lines; Scott W. Ambler (2012). Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise. IBM Press. pp. 54–. ISBN 978-0-13-281013-5.
- ^ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. pp. 182–. ISBN 978-0-321-15078-3.
- ^ "What is Agile Software Development?". agilealliance.org. 29 June 2015.
추가 정보
- Ladas, Corey (January 2008). Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press. ISBN 978-0-578-00214-9.
- Ries, Eric (September 2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business. ISBN 978-0307887894.
