문서를 영문으로 보려면 영문 확인란을 선택하세요. 마우스 포인터를 텍스트 위로 이동시켜 팝업 창에서 영문 텍스트를 표시할 수도 있습니다.
번역
영문

Lean 소프트웨어 개발

By David J. Anderson. David J. Anderson 세 책의 저자는 과 민첩 한 관리: Kanban에도 있는, 2012에 게시 된 Kanban: 기술 비즈니스를 위한 성공적인 혁신적인 변경, [1] 2010에 게시 된, 소프트웨어 엔지니어링에 대한 민첩 한 관리: 비즈니스 결과 대 한 제약 조건 이론 적용, [2] 2003에서 게시 된. 그는 1997~1999년에 싱가포르에서 Agile 소프트웨어 개발 방법인 기능 주도 개발 방법을 만드는 팀의 구성원이었습니다. 저 MSF CMMI Process Improvement에 작성 하 고 그는 소프트웨어 엔지니어링 협회에서 기술 참고 co-authored "CMMI 및 Agile: 모두 수용 하는 이유!" 그는 간결한 시스템 소사이 어 티의 창립자 했습니다 (http://www.leansystemssociety.org). 그 간결한 Kanban 대학 Inc. CEO, 공인된 교육 및 품질 기구 Kanban 교육의 전 세계 파트너 네트워크를 통해 제공 되 고 그는 국제 관리 교육 및 컨설팅, David J. 잠재 고객 Anderson & Associates Inc. 더 나은 관리 정책과 의사 결정을 통해 기술 비즈니스가 성능을 개선하도록 도와주는 (http://www.agilemanagement.net)입니다.

2011 년 11 월 2012 년 11 월 업데이트.

Anderson은 Lean 소프트웨어 개발을 설명합니다.

Lean, 소프트웨어 개발, 프로젝트 관리, Team Foundation Server

Lean 소프트웨어 개발이라는 용어는 1992년 10월에 Stuttgart Germany에 위치한 유럽 연합의 ESPRIT 이니시티브에서 주최한 컨퍼런스의 제목으로 처음에 사용되었습니다. 독립적으로 다음 연도인 1993년에 Robert “Bob” Charette는 소프트웨어 프로젝트의 위험을 더 잘 관리하는 방법을 찾는 자신의 작업의 일부로 "Lean 소프트웨어 개발" 개념을 제안했습니다. James Womack, Daniel Jones, and Daniel Roos가 그들의 저서인 세계를 변화시키는 컴퓨터: Lean 생산의 이야기[3]에서 제안하여 1991년에 생긴 "Lean"이라는 영어 용어는 Toyota에서 사용한 관리 접근법을 설명합니다. 소프트웨어 개발에 Lean을 적용할 수 있다는 아이디어는 이 용어가 제조 프로세스와 산업 엔지니어링의 추세와 관련되어 맨 처음 사용된 1-2년 후에야 구축되었습니다.

1995년 출판한 두 번째 책에서 Womack과 Jones[4]은 Lean Thinking의 다섯 가지 핵심 요소를 정의했습니다. 다음과 같습니다.

  • 값 스트림

  • 선형

  • 완벽

이는 다음 10년 동안 Lean에 대한 기본 정의가 되었습니다. 제안된 완벽함의 추구는 낭비를 제거하여 달성됩니다. 5개의 기둥이 있었지만 실제로 광범위한 대상과 공명한 것은 낭비적인 활동을 시스템적으로 식별 및 제거하여 완벽을 추구하는 5번째 기둥이었습니다. Lean은 1990 년대 후반과 21 세기 초반에 걸쳐 낭비를 제거하는 방법하고만 관련이 있습니다.

Womack과 Jones의 Lean 정의는 보편적으로 공유되지 않습니다. Toyota에서 관리의 원칙은 훨씬 미묘합니다. 영어로 한 단어인 “낭비(waste)”는 세 가지 일본어로 더욱 풍부하게 설명됩니다.

  • Muda – 문자 그대로 “낭비”를 의미하지만 비부가가치 활동을 의미

  • Mura – “공평”을 의미하며 “흐름의 가변성”으로 해석됨

  • Muri – “과중한 부담” 또는 “불합리”를 의미

비부가 가치 활동, 흐름 다듬기 및 과중한 부담 제거를 통해 완벽을 추구합니다. 또한, 토요타의 방법은 사람에 대한 기본적인 존경심을 바탕으로 20세기 품질 보증 및 W와 같은 통계적 제어 엑스퍼트 교육에 영향을 받았습니다. Edwards Deming에 의해서도 알려졌습니다.

불행하게도 주제에 대한 저자 정의만큼이나 많은 Lean에 대한 정의가 있습니다.

Bob Charette는 유타 주 Snowbird에서 열린 2001년 회의에 초대되었지만 참석할 수 없었습니다. 여기에서 애자일 소프트웨어 개발을 위한 선언문[5]이 작성되었습니다. 이 역사적인 회의의 부재에도 불구하고, Lean Software Development는 소프트웨어 개발에 대한 여러 Agile 접근 방법 중 하나로 간주되었습니다. Jim Highsmith dedicated a chapter of his 2002 book[6] to an interview with Bob about the topic. 나중에 Mary & Tom Poppendieck은 3[7,8,9] 서적의 시리즈를 저술했습니다. 21세기의 첫 몇 년간 Lean 원칙은 Agile 메서드가 더 나은 이유를 설명하는데 사용되었습니다. Lean은 Agile 방법이 거의 “낭비”를 포함하지 않았으므로 더 나은 경제적 결과를 생성했다고 설명했습니다. Lean 원칙은 Agile 방법을 채택하기 위한 “권한 제공자”로 사용되었습니다.

최근 몇 년간 Lean 소프트웨어 개발은 관련된 고유의 규칙을 통합하였지만 Agile 무브먼트의 규칙들은 포함하지 않았습니다. 이러한 진화는 Lean 제품 개발 아이디어와 Donald G의 작업의 아이디어 합성으로 시작되었습니다. Reinertsen[10,11], 비Agile 대규모 시스템 엔지니어링의 비Agile 세계와 James Sutton Peter Middleton[12]의 저서에서 영감을 얻은 아이디어입니다. 또한 Eli Goldratt 및 W의 작업도 동기화했습니다. Edwards Deming and developed a focus on flow rather than waste reduction[13]. 2005년 무렵 Reinertsen의 요청으로 저는 진행 중인 작업을 제한하고 시스템이 프로세스할 준비가 되었을 때만 새로운 작업을 '가져오는' Kanban 시스템의 사용을 도입했습니다. Alan Shalloway는 2009년 저서의 항목[14]에서 Lean 소프트웨어 개발에 대한 자신의 생각을 추가했습니다. 2007년 이후 뉴 소프트웨어 개발 작업의 진행 중인 새 힘으로 Lean이 출현하여 흐름 개선, 위험 관리 및 의사 결정 개선(관리) 향상에 중점을 두고 있습니다. Kanban은 IT 관련 작업의 Lean 이니셔티브를 위한 주요 도구가 되었습니다. 폐기물 제거가 아니라 흐름에 초점을 맞추는 것이 소프트웨어 개발 같은 지식 작업에서 연속적인 개선을 위한 더 나은 catalyst임이 증명되었습니다.

구체적인 Lean 소프트웨어 개발 방법이나 프로세스가 없기 때문에 Lean 소프트웨어 개발을 정의하기가 어렵습니다. Lean은 개인 소프트웨어 프로세스, V 모델, 나선형 모델, EVO, 기능 위주 개발, 익스트림 프로그래밍, 스크럼 또는 테스트 위주 개발과 동등하지 않습니다. 소프트웨어 개발 주기 프로세스 또는 프로젝트 관리 프로세스가 Lean 소프트웨어 개발 이동 값과 Lean 소프트웨어 개발 원칙에 부합하는 'lean'이라고 경우 할 수 있습니다. 따라서 Lean 소프트웨어 개발 뒤에 오는 간단한 조리법을 예상하지 못할 수 있습니다. Lean 원리를 이해하고 Lean의 핵심 가치를 채택함으로써 자신의 소프트웨어 개발 프로세스를 조정할 수 있습니다.

Lean 소프트웨어 개발 내에는 여러 가지 사상이 있습니다. 최대 및 이라고 할 선행 학교 Donald Reinertsen, Jim Sutton 영일 Shalloway, Bob Charette, Mary Poppendeick, David J. 포함 간결한 시스템 사회입니다. Anderson. 메리와 톰 Poppendieck 작업 전에 대형 소사의 전개 및 김덕훈 Larman, Bas Vodde의 작업으로 그 신조를 개별적으로 의미[15,16], 및 최근에 Jim Coplien[17]. 이 문서에서는 그 신조에 표현 된 대로의 간결한 시스템 사회 관점 광범위 하 게 대표 하 고 합성 및 아이디어의 요약을 제공 하는 것입니다.

간결한 시스템 소사이 어 티의 신조 게시[18] 2012 간결한 소프트웨어에 & 회의 시스템[19]. 1 년 이전에 게시 된 값 집합에 기반을 두었습니다. 이러한 값은 다음과 같습니다.

  • 인간 조건 적용

  • 지식 작업에서는 복잡성과 불확실성이 당연하다는 것을 인정

  • 더 나은 경제적 결과를 얻기 위해 작업합니다.

  • 더 나은 사회적 결과를 사용하는 동안

  • 검색, 도입 및 광범위한 분야의 아이디어 질문

  • 값 기반 커뮤니티는 양의 변경 속도와 깊이를 향상시킵니다.

소프트웨어 개발처럼 지식 작업은 사람에 의해 수행됩니다. 우리 인간은 본질적으로 복잡하지만 논리적인 사상가이고 감정과 합리적으로 극복할 수 없는 일부 기본적인 동물적인 특성에 의해 움직입니다. 작업하는 시스템 또는 프로세스를 설계할 때 심리학 및 신경 심리학을 고려해야 합니다. 사회적 동작도 수용할 수 있어야 합니다. 인간은 본질적으로 감정적, 사회적 및 종족적이며 동작은 피로와 스트레스에 따라 바뀝니다. 성공적인 프로세스는 인간 조건을 거부하고 논리적이고 컴퓨터와 같은 동작을 가정하는 게 아니라 인간 조건을 포함 및 수용하는 프로세스입니다.

고객과 시장의의 동작을 예측할 수 있습니다. 프로세스를 통한 작업 흐름과 작업자 컬렉션은 예측할 수 없습니다. 결함 및 필요한 재작업을 예측할 수 없습니다. 소프트웨어 개발 내의 많은 수준에서 고유의 기회 또는 임의의 동작이 있습니다. 프로젝트의 목적, 목표 및 범위는 제공되는 동안 변경되는 경향이 있습니다. 이러한 불확실성 및 변동성 중 일부는 처음에 알 수 없었지만 연구하고 계량화할 수 있고 위험을 관리할 수 있다는 측면에서 알 수 있습니다. 하지만 몇몇 불확실성은 미리 알 수 없으며 적절하게 예측할 수 없습니다. 그래서 Lean 소프트웨어 개발 시스템은 전개되는 이벤트에 대응할 수 있어야 하며 시스템은 변화하는 환경에 적응할 수 있어야 합니다. 따라서, 모든 린 소프트웨어 개발 프로세스는 전개된 이벤트에 프로세스 적용을 허용하는 프레임워크 내에 존재해야 합니다.

Lean 소프트웨어 개발 같은 인간의 활동은 보다 경제적인 결과를 생성하는 데 초점을 맞추어야 합니다. 자본주의란 사업의 가치와 고객의 이익에 모두 기여할 때 인정됩니다. 투자자와 비즈니스 소유자는 투자 수익을 거두어야 합니다. 직원 및 근로자는 작업을 수행할 때 기울인 노력에 상응하는 보상을 받을 자격이 있습니다. 고객은 공정한 가격을 지불한 것에 대해 약속받은 대가로 좋은 제품 또는 서비스를 제공받을 충분한 자격이 있습니다. 최대한 효과적인 방법으로 투자자나 소유자가 자본 배치를 관리하면서 저렴한 비용으로 고객에게 더 많은 가치를 전달하는 것이 더 나은 경제적 성과에 포함됩니다.

더 나은 경제적 결과는 이러한 작업을 수행하는 대가로 제공되어서는 안 됩니다. 인간의 조건을 수용하여 사람을 존중하고 사람의 심리적 및 사회적 본성을 존중하는 작업의 시스템을 제공하는 작업 공간을 만드는 것이 필수적입니다. 최선의 작업을 하기 위한 최선의 장소를 만드는 것이 Lean 소프트웨어 개발 커뮤니티의 핵심적인 가치입니다.

Lean 소프트웨어 및 시스템 커뮤니티는 Lean 소프트웨어 개발 프로세스를 지원하는 몇 가지 원칙에 동의하는 것 같습니다.

  • 시스템 사고 및 디자인 방식 준수

  • 응급 출력은 복잡한 적응 시스템의 컨텍스트를 설계함으로써 영향을 받을 수 있습니다.

  • 사람을 존중(시스템의 일부로)

  • 과학적 방법 사용(드라이브 개선)

  • 리더십 권장

  • 표시 유형(작업, 워크플로 및 시스템에)을 생성합니다.

  • 유동 시간 감소

  • 효율성을 높이기 위해 낭비 감소

이는 종종 Lean 문서를 최적화할 전체 시스템(또는 프로세스)의 출력인 "전체 최적화"로 언급하며 전체를 마법처럼 최적화길 바라면서 실수로 부품을 최적화해서는 안 됩니다. 대부분의 전문가들은 결과가 true이고 최적화 부분(로컬 최적화)으로 인해 차선의 결과나 초래된다고 생각합니다.

Lean 시스템 사고 및 디자인 방식은 고객 등 외부 이해 관계자의 시스템에 대한 요구와 해당 관계자가 요청하는 바람직한 결과를 고려해야 합니다. 우리는 요구의 특성을 연구하여 배송할 시스템의 기능과 비교해야 합니다. 고객이 지불하는 소위 '값 요청'과 값 요청에 대한 공급 실패에 기인하는 일반적인 재작업 또는 추가 요청인 '실패 요청'이 포함됩니다. 요청 실패는 다음과 같이 두가지 형태로 나타납니다. 이전에 전달된 값 요청 및 부가 서비스에 다시 응하거나 제공된 값 요청 실패를 지원합니다. 소프트웨어 개발에서 실패 요청은 일반적으로 버그 수정에 대한 요청과 고객 만족 또는 도움말 데스크 기능에 대한 요청입니다.

시스템 디자인 방식을 통해 디자인과 개선 과정을 프로세스하려면 PDSA(Plan-Do-Study-Act) 방식도 따라야 합니다. 서유럽 에드워드 데밍은 자연 철학 시스템 동작을 연구하는 것을 함축하는 "연구"와 "기능"이란 단어를 사용했습니다. 이 시스템은 소프트웨어 개발 프로세스와 이를 작동하는 모든 사람으로 구성되어 있습니다. 이는 제공된 특징이나 기능(Agile 자료에서 "개발속도"라고 언급된)의 기간, 품질 및 수량 측면 등에서 관찰 가능한 동작입니다. 이러한 메트릭에는 가변성이 표시되고 평균과 변화의 확산을 조사하여 우리의 기능 이해력을 개발할 수 있습니다. 이것이 요구사항과 고객의 기대에 일치하지 않는 경우, 시스템은 격차를 없애도록 다시 디자인되어야 합니다.

Deming은 또한 기능이 시스템 디자인에 의해 95%의 영향을 받고, 개인의 역량은 단 5%만 기여한다는 것을 가르쳤습니다. 즉, 우리는 요구되는 능력과 실제 능력과의 차이를 비난하지 않고 그들이 성공할 수 있도록 시스템을 다시 설계함으로써 사람들을 존경할 수 있습니다.

시스템 디자인을 이해하려면 시스템 기능의 다이내믹스와 영향을 미치는 방식에 대해 과학적으로 이해를 해야 합니다. 모델은 시스템의 움직임을 예측하도록 개발되었습니다. 가능한 많은 모델이 있지만 몇 가지 인기 있는 모델이 공통으로 사용됩니다. 경제적 비용의 이해, 사용자 가치 제품이나 서비스 생산과 관련된 트랜잭션 및 조정 비용, 제약 조건에 대한 이론-병목 현상에 대한 이해, 심오한 지식의 이론 – 가변성을 시스템 디자인에 공통적인 것으로 또는 특수하거나 시스템 디자인의 외적인 것으로 연구 및 인식

복잡한 시스템은 반복적으로 실행할 때 응급 출력을 생성하는 시작 조건과 간단한 규칙을 갖고 있습니다. 응급 출력은 주어진 시작 조건을 예측하기 어렵거나 불가능합니다. 컴퓨터 과학은 "The Game of Life”가 복잡한 시스템의 예인지 실험합니다. 복잡 적응 시스템 내에는 자기 자각과 현재 규칙 집합을 사용하여 원하는 결과를 얼마나 얻을 수 있는가를 반영하는 내부 메서드를 가지고 있습니다. 복잡한 적응 시스템은 간단한 규칙을 변경하고 현재 결과와 원하는 결과 간 갭을 제거하기 위해 자체 적응을 선택할 수 있습니다. 재생하는 동안 규칙을 다시 작성할 수 있도록 적응된 수명 게임은 복잡한 적응 시스템이 될 수 있습니다.

소프트웨어 개발 프로세스에서 복잡한 적응 시스템의 "간단한 규칙"은 프로세스 정의를 구성하는 정책입니다. 여기에서 핵심 원칙은 소프트웨어 제품 및 서비스 개발이 명확한 활동이 아니므로 자체를 적용할 수 없는 정의된 프로세스가 예측할 없는 이벤트에 대한 적절한 응답이 아니라는 믿음에 기반합니다. 따라서 시스템 사고 및 설계 방법의 일부로 설계된 프로세스를 적용할 수 있어야 합니다. 정책 수정을 통해 적응합니다.

Lean 소프트웨어 개발에 대한 Kanban 방식은 kanban 끌어오기 시스템 정책을 "간단한 규칙"으로 간주하고 작업과 워크플로우를 시각화하는 조건을 시작하여 이 개념을 사용합니다. 이 플로우는 시스템 다이내믹스 이해를 사용하여 관리하며 해당 조직은 프로세스 개선을 이해, 제안 및 구현하는 데 과학적인 방법을 사용합니다.

Lean 커뮤니티는 작업자가 자신이 수행하는 작업에 대해 상사보다 더 많이 알고 있을 경우 그 작업자를 지식 작업자라고 진술하는 지식 작업에 대한 Peter Drucker의 정의를 채택합니다. 이를 통해 작업을 수행 하는 방법 및 작업을 수행하는 방법을 개선하기 위한 프로세스 수정 작업에 대한 의사 결정을 위해 작업자를 최선의 방법으로 배치해야 하는 암시가 발생합니다. 따라서 작업자의 음성을 존중해야 합니다. 작업자는 작업을 완료하고 원하는 결과를 얻기 위해 스스로 조직할 수 있는 힘을 갖추어야 합니다. 이들에게는 Lean 문서에서 언급된 대로 프로세스 개선 기회 또는 "kaizen 이벤트"를 제안 및 구현할 수 있도록 권한이 부여됩니다. 근로자가 제한 규칙을 인식할 수 있도록 프로세스 정책을 명시적으로 만드는 것은 근로자를 존중하는 또 다른 방법입니다. 분명하게 정의된 규칙은 공포와 용기를 가질 필요성을 제거함으로써 자기 조직화를 장려합니다. 사용자에게 권한을 부여하고 명시적으로 선언된 정책 집합을 제공하여 인간적인 조건을 존중하는 핵심 가치를 지킵니다.

작업 수행 방법과 Lean 소프트웨어 개발 시스템이 작동하는 방법의 다이내믹스를 이해하려면 모델을 사용해야 합니다. 시스템과 그 기능을 관찰 및 연구한 다음 그 동작을 예측하는 모델을 개발하고 적용합니다. 연구에서 양적 데이터를 수집하고, 이를 사용하여 시스템이 수행되는 방법을 이해하며 프로세스가 변경될 때 나타나는 결과에 대해 예측합니다.

Lean 소프트웨어 및 시스템 커뮤니티는 시스템 기능을 이해하기 위해 기간과 개발속도에 대한 통계적 프로세스 제어 차트와 스펙트럼 분석 히스토그램 같은 통계 방법을 사용합니다. 또한 이러한 도구를 다음과 같은 모델을 사용합니다. 병목 현상을 이해하기 위한 제한 사항의 이론, 시스템 내부적인 변화 대 시스템 외부에서 영향을 미치는 변화를 이해하기 위한 심오한 지식의 시스템 그리고 고객이 소중히 여기는 제품이나 서비스를 만든 후에 단순히 조정, 설치, 배송 또는 정리하기 위해 수행된 작업 형식으로 경제적 비용 분석입니다. 현재 재무 위험 관리의 재무 옵션 이론을 실제 의사 결정에 적용하는 실제 옵션 이론 같은 일부 다른 모델을 사용하고 있습니다.

우리가 연구한 과학적 방법은 다음을 제안합니다. 우리는 모델을 기반으로 결과를 가정합니다. 우리는 이러한 예측에 따라 시스템을 방해합니다. 우리는 이러한 방해로 인해 모델이 예측한 결과가 발생하는지 여부를 다시 관찰합니다. 그렇지 않은 경우 데이터를 체크아웃하고 모델이 정확한지 여부를 다시 고려합니다. 모델을 사용하여 프로세스 개선을 과학적인 활동으로 이동하고 직감에 기반하여 미신적인 활동에서 프로세스 개선을 자유롭게 합니다.

리더십과 관리는 동일하지 않습니다. 관리는 프로세스 디자인, 정책 수립, 수정 및 삭제, 전략 및 운영 결정, 자원 수집, 재정 및 시설 제공 그리고 전략, 목표 및 원하는 결과 같은 컨텍스트에 대한 정보 전달 같은 활동입니다. 리더십은 비전, 전략, 전술, 용기, 혁신, 판단, 옹호 및 기타 추가 특성에 대한 것입니다. 리더십은 조직 내의 어떤 사람도 할 수 있고 해야 합니다. 작업자의 작은 리더십 역할로 Lean 소프트웨어 개발 프로세스를 만드는 데 필요한 변경 내용을 제공할 수 있는 많은 개선이 이루어졌습니다.

지식 작업은 표시되지 않습니다. 아무것도 보이지 않으면 거의 관리할 수 없습니다. 완료 될 때까지 개인, 기술 및 부서의 네트워크를 통해 수행 중인 작업 및 이 작업의 흐름에 표시 유형을 생성해야 합니다. 프로세스 흐름을 시각화는 방법을 찾고 모든 사람이 보고 생각할 수 있도록 프로세스 정책을 구체적으로 만들어 프로세스 디자인에 표시 유형을 만들어야 합니다. 이 모든 것이 표시되면 과학적 방법을 사용할 수 있고 잠재적인 개선에 대한 대화가 공동 작업 및 목표가 될 수 있습니다. 작업 및 워크플로가 표시되지 않는 경우 및 프로세스 정책이 명시적이 아닌 경우에는 공동 프로세스 개선이 거의 불가능합니다.

소프트웨어 개발 전문가와 소프트웨어 엔지니어링을 공부하는 학생은 전통적으로 활동에 소요한 작업 시간 측정에 초점을 맞추었습니다. Lean 소프트웨어 및 시스템 커뮤니티는 어떤 작업을 처리하기 위해 실제로 경과한 달력 시간을 측정하는 것이 더 유용하다는 사실을 알아냈습니다. 이는 일반적으로 사이클 시간이라고 하며 수행된 작업의 경계로 정규화됩니다. 예를 들어, 분석부터 개발 준비에 해당하는 사이클 타임을 통해 사용자 스토리 분석, 설계, 개발, 시험 및 생산 환경 배포 준비를 위한 대기 시간과 같은 작업 목록에 소요되는 총 경과 시간을 측정할 수 있습니다.

여러 가지 방식으로 작업이 프로세스를 통과하는 데 걸리는 시간에 집중하는 것이 중요합니다. 긴 사이클 시간은 버그 비율에서 비선형 성장과 관련이 있는 것으로 표시되었습니다. 따라서 짧은 사이클 시간은 더 높은 품질로 이어집니다. 이는 우습게 보일 수도 있지만 큐잉되어 인간이 실제로 건드리지 못하도록 버그가 코드에 삽입되는 카운터 직감적입니다. 전통적으로 소프트웨어 엔지니어링 전문가와 이를 연구하는 학생들은 이 유휴 시간을 무시했습니다. 그러나 경험에 따르면 사이클 시간이 초기 품질에 중요하다는 것을 보여줍니다.

Alan Shalloway 또한 '작업 유도'의 개념에 대해 이야기했습니다. 그는 작업 수행이 지연되는 것이 해 온 것 보다 더 많은 작업 수행으로 이어질 수 있다고 전망했습니다. 예를 들어, 발견된 오류를 발견하고 즉시 수정하면 20분이 소요됩니다. 그러나, 오류를 수정하기 위하여 오류를 검사하고 보류하여 몇 일 또는 몇 주를 대기한다면 여러 시간이 소요될 것입니다. 따라서 사이클 시간 지연은 추가 작업을 "발생" 시켰습니다. 이 작업은 방지할 수 있으므로 Lean 용어로는 “낭비”로 보아야 합니다.

사이클 시간에 중점을 두는 세 번째 이유는 업무 관련 이유입니다. 모든 기능, 함수 또는 사용자 스토리에는 값이 있습니다. 이 값은 불확실할 수 있지만, 그럼에도 불구하고 값이 있습니다. 값은 시간에 따라 달라질 수 있습니다. 가치의 개념은 시간이 지나면서 달라지며 경제적으로 시장 수익 함수로 표현할 수 있습니다. 함수에서 값의 분산을 모델 불확실성에 표시할 경우라도 작업 항목의 시장 수익 함수가 이해되면 "지연 비용"을 평가할 수 있습니다. 지연 비용을 사용하면 사이클 시간에 값을 부여할 수 있습니다.

일부 작업 항목의 경우 시장 수익 함수는 미래의 알려진 날짜에 시작됩니다. 예를 들어, 미국 공휴일인 7월 4일에 사용되도록 설계된 기능은 그날 이전에 값을 가지지 않습니다. 이러한 예제의 경우 사이클 시간을 단축하고 약간의 확신을 가지고 사이클 시간을 예측할 수 있습니다. 이상적으로, 이 기능이 필요 이상으로 너무 빨리 또는 지연 비용이 발생할 정도로 늦지 않고 필요할 때에 맞춰 도착할 수 있도록 작업을 시작하는 것이 좋습니다. Just-in-time 배달을 사용하면 사용 가능한 리소스로 이루어진 최적의 사용이 가능합니다. 조기 배달은 우리가 다른 작업을 하고 있고, 암시적으로 지연 기회 비용이 발생할 수도 있음을 의미합니다.

이러한 세 가지 이유 때문에 Lean 소프트웨어 개발에서 시간의 흐름을 최소화하고 시간 흐름을 예측할 수 있는 기록 데이터를 찾는 것입니다. 목표는 버그의 실패 수요, 버그를 수정할 발생하는 지연으로 인한 과도한 부담에 따른 낭비를 최소화하고 지연 비용과 지연의 기회 비용을 방지함으로써 제공되는 값을 극대화하는 것입니다.

모든 값 추가 활동에서는 설치, 정리 및 전달 등의 모든 활동이 필요하지만 자신의 권리에서 값을 추가하지는 마십시오. 예를 들어,프로젝트를 수행할 때는 소프트웨어 요구사항 작업 계획 증가(설치 활동), 환경 및 코드 분기 버전 제어(구성 관리 및 설치 작업으로 통칭), 릴리스 계획 및 수행(배달 활동), 고객에게 설명(배달 활동), 환경 해체 및 재구성(정리 활동)을 개발하는 과정을 반복합니다. 경제 용어로 설치, 정리 및 배달 활동은 부가 가치 작업을 수행하는 트랜잭션 비용입니다. 이러한 비용 (또는 간접비)은 Lean에서 낭비로 간주됩니다.

모든 형태의 통신 오버헤드는 폐기물로 간주할 수 있습니다. 프로젝트 상태를 확인하고 작업을 예약하여 팀 구성원에게 할당하는 회의는 경제 언어로 조정 비용으로 간주됩니다. 모든 조정 비용은 Lean Thinking에서 낭비입니다. Lean 소프트웨어 개발 방법에서는 팀 구성원을 배치하고 일간 회의 같은 짧은 대면 회의 및 카드 벽 같은 시각적 컨트롤을 사용하여 조정 비용을 제거하거나 절감하려 합니다.

Lean 소프트웨어 개발에서 낭비의 세 번째 일반적인 형태는 오류 요청입니다. 요청 실패는 소프트웨어 개발 시스템의 부담입니다. 요청 실패는 일반적으로 낮은 품질의 부작용으로 생성된 작업의 재작업 또는 새로운 형태의 작업입니다. 소프트웨어 개발 요청이 실패하는 가장 일반적인 형태는 소프트웨어를 의도한 대로 사용하지 않아 발생한 버그, 생산 결함 및 고객 지원 활동입니다. 오류를 요청하는 진행 중인 작업의 비율을 종종 오류 부하라고 합니다. 오류 요청에 대한 가치 추가 작업의 비율은 시스템 효율성의 척도입니다.

모든 비부가치 트랜잭션과 조정 비용을 포함한 총 작업에 대한 부가가치 작업의 %로 효율성의 수준을 결정합니다. 트랜잭션과 조정 비용이 없고 오류 부하가 100% 효율적으로 간주되지 않는 시스템입니다.

일반적으로 서양의 관리 과학에서는 작업의 일괄 처리 크기를 늘려 효율성을 개선할 수 있다고 가르칩니다. 일반적으로 트랜잭션 및 조정 비용은 고정되어 있거나 일괄 처리에서 증가와 함께 약간만 상승합니다. 결과적으로 큰 작업 배치가 더 효율적입니다. 이 개념은 "규모의 경제"로 알려져 있습니다. 그러나 기술 작업 문제에서 조정 비용은 일괄 처리 크기에 비선형적으로 증가하는 경향을 보이지만, 트랜잭션 비용은 종종 선형적으로 증가할 수도 있습니다. 따라서, 기존의 20 세기 방식은 소프트웨어 개발같은 기술 작업의 문제에 적절하지 않습니다.

효율성을 향상 시키기 위해 작은 일괄 처리 크기를 유지하면서 오버헤드를 줄이는 데 더 잘 초점을 맞춥니다. 따라서 효율적인 Lean 방법은 낭비를 줄이는 것입니다. Lean 소프트웨어 개발 방법은 신속하고 저렴하며 빠른 계획 방법, 낮은 통신 오버 헤드 및 kanban 시스템에서 시각적 컨트롤 같은 효과적인 낮은 오버 헤드 조정 메커니즘에 초점을 맞춥니다. 배달의 트랜잭션 비용을 줄이기 위해 자동화된 테스트와 자동화된 배포를 장려하기도 합니다. 최신 버전 제어 시스템과 가상화 사용 같은 환경 설정 및 해체 비용을 최소화하는 최신 도구를 사용하면 소프트웨어 개발의 작은 일괄 처리의 효율성을 쉽게 향상시킬 수 있습니다.

Lean 소프트웨어 개발은 실습을 규정하지 않습니다. 실제 프로세스 정의가 원칙과 가치를 잘 지키고 있는지 보여주는 것이 더 중요합니다. 그러나 일반적으로 다양한 사례를 채택하고 있습니다. 이 섹션에서는 이 중 몇 가지 단한 개요를 제공합니다.

누적 흐름도는 2005년 이후 Team Foundation Server에서 보고의 표준 일부가 되었습니다. 누적 흐름도는 워크플로의 각 상태에서 누적 작업 항목의 영역 그래프를 그립니다. 이는 정보가 풍부하고 처리량 비율(또는 "개발속도")뿐만 아니라 프로세스의 단계 간 평균 주기 간격을 파생시키는 데 사용할 수 있습니다. 소프트웨어 개발 수명 주기 프로세스마다 누적 흐름도에서 다른 시각적 서명을 생성합니다. 전문가들은 영역 그래프에 표시되는 프로세스에서 오작동의 패턴을 인식할 수 있습니다. 실제 Lean 프로세스는 일정한 속도로 부드럽게 상승하며 색이 고르게 분산된 영역을 보여줍니다. 그림은 거칠게 표시된 단계 또는 볼 수 있는 색 블록 없이 부드럽게 나타납니다.

가장 기본적인 형태로 누적 흐름도는 작업 항목 주기의 특정 단계에서 특정한 단계의 진행 중인 작업 수량을 시각화하는 데 사용됩니다. 이는 병목 구간을 감지하고 “mura”(흐름의 변동성)의 효과를 관찰하는 데 사용할 수 있습니다.

Lean 소프트웨어 개발팀은 작업을 시각화하고 흐름을 관찰하기 위하여 시스템의 누적 흐름도를 사용할 뿐만 아니라 물리적인 보드 또는 프로젝션 전자 시각화 시스템을 사용합니다. 이러한 시각화 작업을 통해 팀 구성원은 누적되는 진행 중인 작업을 관찰하고 병목 현상 및 "mura" 효과를 확인할 수 있습니다. 또한 시각적 컨트롤을 사용하면 팀 구성원은 선택 작업을 자기 조직하고 계획이나 특정 관리 방향이나 개입 없이 함께 협력할 수 있습니다. 이러한 시각적 컨트롤은 종종 “카드 벽” 또는 때때로(잘못하여) “kanban 보드”라고도 합니다.

칸반 시스템은 Lean 제조에서 채택된 방법입니다. 워크플로우의 모든 해당 단계에서 진행 중인 작업의 수량을 제한하기 위해 물리적인 카드로 구성된 시스템을 사용합니다. 이러한 제한된 진행 중인 작업 시스템에서 새 작업을 특정 상태로 "끌어와" 작업을 진행할 수 있다는 것을 가리키는 무료 kanban만 있을 경우에 새 작업을 시작하는 "끌어 오기"를 만듭니다.

린 소프트웨어 개발에서 칸반은 가상적이며 작업 항목 형식의 워크플로워의 주어진 단계의 최대수를 설정하여 추적됩니다. 일부 구현에서는 전자 시스템은 가상 kanban을 추적하고 새 작업을 시작할 수 있을 때 신호를 제공합니다. 신호는 전자 메일 같은 경고 형식이거나 시각적일 수 있습니다.

가상 kanban 시스템은 하나 또는 여러 개의 작업 항목 형식을 나타내는 시각적 가상 kanban 시스템을 제공하기 위해 시각적 컨트롤과 종종 결합됩니다. 이러한 시스템은 "kanban 게시판" 또는 "전자 kanban 시스템"으로 부릅니다. 시각적 가상 kanban 시스템은 Team Foundation Server 라는 Visual WIP[20]라는 Team Foundation Server용 플러그인으로 사용 할 수 있습니다. 이 프로젝트는 스웨덴의 Hakan Forss에 의해 오픈 소스로 개발되었습니다.

Lean 소프트웨어 개발의 경우 작업은 대개 "반복" 또는 "증가"라고 하는 작은 일괄 처리로 수행되거나 "단일 부분 흐름" 라고 하는 작업 항목 흐름에서 독립적으로 수행해야 합니다. 단일 부분 흐름의 경우 완료되지 않은 작업이 실수로 해제되지 않을 경우 완료된 작업을 제공할 수 있는 복잡한 구성 관리 전략이 필요합니다. 이는 일반적으로 버전 제어 시스템에서 분기 전략을 사용하여 달성됩니다. 8명의 소규모 팀에서 또는 2 주 미만의 기간에 진행할 수 있는 배치를 일반적으로 소규모 배치 작업으로 간주됩니다.

작은 배치 및 단일 부분 흐름으로 인해 백로그 또는 큐 또는 작업을 보충하는 비즈니스 소유자와 자주 상호 작용을 해야 합니다. 또한 자주 릴리스하는 기능도 필요합니다. 비즈니스 사용자와 자주 상호 작용을 하고 자주 배송하려면 트랜잭션과 두 활동의 조정 비용을 축소해야 합니다. 이를 달성하는 일반적인 방법은 자동화를 사용하는 것입니다.

Lean 소프트웨어 개발에서 단일 부분 흐름을 경제적으로 사용하고 높은 품질과 고장 수요를 감소시키기 위해 높은 수준의 자동화를 기대합니다. 디자인 패턴 배포와 소스 코드의 반복적인 낮은 가변성 생성을 자동화하기 위해 자동화된 테스트, 자동화된 배포 및 소프트웨어 팩터를 사용하는 것은 Lean 소프트웨어 개발 프로세스에서 흔합니다.

Lean 용어에서, kaizen란 용어는 "지속적인 향상"을 의미하고 kaizen 이벤트는 향상을 기대하고 프로세스 또는 도구를 변경하는 행위를 의미합니다.

Lean 소프트웨어 개발 프로세스는 여러 가지 활동을 사용하여 kaizen 이벤트를 생성합니다. 이들은 여기에 나열됩니다. 이들 각각의 작업은 기능에 부정적인 영향을 주는, 결과적으로 요구에 대한 대응 능력에 악영향을 주는 문제에 대한 대화를 고무시키기 위해 디자인 되었습니다. 지식 작업에서 kaizen의 핵심은 다른 팀과 다른 기술을 가진 사람의 그룹에서 발생하는 문제에 대해 대화를 불러 일으켜야 한다는 것입니다.

대개 최대 50의 소프트웨어 개발자 팀은 일반적으로 진행 중인 작업의 시각화를 표시하는 화이트보드 같은 비주얼 컨트롤 시스템 전면에서 만납니다. 이들은 작업 흐름에 영향을 미치는 동적 흐름과 요소에 대해 논의합니다. 특히 외부적으로 차단된 작업과 버그로 인해 지연된 작업에 포커스를 맞춥니다. 프로세스의 문제는 종종 일련의 시작 모임을 통해 명백해집니다. 결과는 문제를 토론하는 회의 후에 더 작은 그룹이 남아 있고 솔루션이나 프로세스 변경을 제안할 수 있다는 것입니다. kaizen 이벤트가 따릅니다. 이러한 자발적인 모임은 종종 이전 문헌에서는 자발적인 품질 집단이라고 했습니다. 이러한 자발적인 모임은 실제로 kaizen 문화권의 핵심입니다. 관리자는 조직 내에서 Lean의 채택을 주도하기 위해 매일의 일간 회의 후에 kaizen 이벤트가 나타나도록 권장합니다.

프로젝트 팀은 최근 성능에 맞게 정기적 모임을 예약할 수 있습니다. 이는 종종 특정 프로젝트 결과물 완료되거나 Agile 소프트웨어 개발 시 반복이나 스프린트로 알려진 개발의 시간 박스형 증가 후에 완료됩니다.

일반적으로 회고는 "잘한 것은 무엇입니까?", "우리가 무엇을 다르게 할까요?" 그리고 "무엇을 우리가 중지할까요?" 같은 질문을 하여 리플렉션에 대해 일화적인 접근방식을 사용합니다.

회고는 일반적으로 kaizen 이벤트에 대해 제안된 백로그를 만듭니다. 팀은 구현을 위해 이 중 일부의 우선 순위를 지정할 수 있습니다.

작업 검토는 일반적으로 회고보다 크며 전체 가치 스트림의 담당자를 포함합니다. 받은 요청을 표시하고 요청에 대해 전달할 수 있는 기능을 반영하는 객관적이고 정량적인 데이터를 제시하는 12개의 부서에 공통입니다. 일반적으로 작업 검토는 매월 이루어집니다. 운영 검토와 회고 간의 중요한 차이는 운영 검토는 기능 집합을 더 확장한다는 것입니다. 일반적으로 프로젝트 프로젝트 포트폴리오와 다른 이니시티브를 확장하고 목표와 정량적 데이터를 사용합니다. 회고를 비교하여 설명하면 회고는 단일 프로젝트로 범위가 지정되는 경향이 있습니다. 회고는 분석, 개발 및 테스트 같은 몇 개 팀을 포함하며 일반적으로 속성상 일화적입니다.

운영 검토는 팀 간의 성능에 영향을 미치는 동적에 대한 토론을 불러 일으킵니다. 한 팀이 다른 팀에서 처리하는 오류 요청을 생성합니까? 아마도 실패 요구는 파괴적으로 두 번째 팀은 최선을 다할 기회를 놓치고 기대치를 달성하지 못할 수 있습니다. 작업 검토는 이런 문제를 논의하고 변경을 제안할 기회를 제공합니다. 일반적으로 작업을 검토하면 우선 순위가 지정되어 향후 구현에 대해 일정을 계획할 수 있는 잠재적인 kaizen 이벤트의 작은 백로그가 생성됩니다.

단일 Lean 소프트웨어 개발 프로세스와 같은 일은 없습니다. 프로세스가 Lean 소프트웨어 개발 값과 원칙에 명확하게 부합하는 경우 간결하다고 할 수 있습니다. Lean 소프트웨어 개발은 실습을 규정하지 않지만 일부 활동은 일반적이 되었습니다. Lean 조직은 워크플로와 진행 중인 작업의 시각화와 흐름의 움직임과 흐름의 움직임의 영향을 주는 요인(병목 현상, 인스턴트 비사용 가능 시간, 변동성 및 낭비)의 이해를 통해 kaizen을 권장합니다. 프로세스 개선은 변동성 소스를 줄이고 낭비를 제거하며 흐름을 개선하거나 가치 제공을 향상하거나 위험을 관리하는 방식으로 제안 및 정당화됩니다. 따라서 Lean 소프트웨어 개발 프로세스는 항상 발전하고 속해 있는 고유한 조직에 맞게 조정될 수 있습니다. 하나의 조직에서 다른 조직으로 단순히 프로세스 정의를 복사하여 다른 컨텍스트에서 작동하길 예상할 수 없습니다. 사용 중인 프로세스가 처음에 관찰된 프로세스와 같다는 것을 확인하기 위해 몇 주 또는 몇 달 후에 조직으로 돌아갈 수도 있습니다. 항상 발전할 것입니다.

세 개의 폼("mura", "muri," 및 "muda")에서 소량의 폐기물만 표시되고 효율적인 위험 관리를 통해 값의 제공을 최적화한다고 표시될 경우 Lean 소프트웨어 개발 프로세스를 사용하는 조직은 Lean하다고 할 수 있습니다. Lean에서 완벽함의 추구는 항상 여행입니다. 대상이 없습니다. 진정한 Lean을 실행하는 조직은 항상 더욱 개선할 점을 찾습니다.

Lean 소프트웨어 개발은 여전히 새로운 필드이고 향후 10년에 걸쳐 계속 발전할 것입니다.

  1. Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010

  2. Anderson, David J. 소프트웨어 엔지니어링을 위한 애자일 매니지먼트: 비즈니스 결과에 제약 이론 적용(Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results), Prentice Hall PTR, 2003년

  3. Womack, James P., Daniel T. Jones과 Daniel Roos, 세계를 변화시킨 기계: The Story of Lean Production, 2007년 업데이트 버전, Free Press, 2007

  4. Womack, James P., and Daniel T. Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, 2nd Edition, Free Press, 2003

  5. Beck, Kent et al, The Manifesto for Agile Software Development, 2001 http://www.agilemanifesto.org/

  6. Highsmith, James A., Agile Software Development Ecosystems, Addison Wesley, 2002

  7. Poppendieck, Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesely, 2003

  8. Poppendieck, Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2006

  9. Poppendieck, Mary and Tom Poppendieck, Leading Lean Software Development: Results are not the Point, Addison Wesley, 2009

  10. Reinertsen, Donald G., Managing the Design Factory, Free Press, 1997

  11. Reinertsen, Donald G., The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009

  12. Sutton, James and Peter Middleton, Lean Software Strategies: Proven Techniques for Managers and Developers, Productivity Press, 2005

  13. Anderson, David J. 소프트웨어 엔지니어링을 위한 애자일 매니지먼트: 비즈니스 결과에 제약 이론 적용(Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results), Prentice Hall PTR, 2003년

  14. Shalloway, Alan, and Guy Beaver and James R. Trott, Lean-Agile Software Development: Achieving Enterprise Agility, Addison Wesley, 2009

  15. Larman, Craig 그리고 Bas Vodde, Scaling Lean과 Agile 개발: 사고와 대규모 스크럼용 조직 도구, Addison Wesley Professional, 2008

  16. Lean & Agile 개발을 확장하는 방법: 대규모의 스크럼으로 큰 다중 사이트 및 근해 제품 개발, Addison Wesley Professional, 2010

  17. Coplien, James O. and Gertrud Bjornvig, Lean Architecture: for Agile Software Development, Wiley, 2010

  18. http://leansystemssociety.org/credo/

  19. http://lssc12.leanssc.org/

  20. http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/

표시: