신속한 소프트웨어 개발

Agile software development
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

소프트웨어 개발에서 민첩한(가끔 12개 쓴)[1]관행 등을 자신의 customer(s)/end userᆬ,[2]적응 계획, 점진적 발전으로, 조속한 인도., 걸쳐 지속적인 개선이고 유연한 반응과 여러 직종의 일을 하는 자기 조직 팀의 공동의 노력을 통해 요구 사항 발견과 해결책 개선을 포함한다.sc요건, 용량 및 해결해야 [3][4]할 문제에 대한 이해에 문제가 있습니다.

2001년 신속한 변화를 위한 소프트웨어 [5]개발 매니페스토에서 널리 알려진 이러한 가치와 원칙은 Scrum 및 Kanban을 [6][7]포함한 광범위한 소프트웨어 개발 프레임워크에서 도출되고 이를 뒷받침합니다.

민첩한 프랙티스와 가치를 도입하면 소프트웨어 프로페셔널, 팀 및 조직의 효율이 향상된다는 증거는 많지만, 경험적 증거는 혼재되어 있어 [8][9]찾기 어렵습니다.

역사

반복적이고 증분적인 소프트웨어 개발 방법은 [10]1957년부터 [14]추적할 수 있으며, 1970년대 초에 진화적인 프로젝트 관리[11][12] 및 적응형 소프트웨어[13] 개발이 등장했습니다.

1990년대에는 많은 경량 소프트웨어 개발 방법이 과도한 규제, 계획 및 미세 [15]관리로 표현된 일반적인 중량 방식(종종 폭포라고 함)에 대응하여 발전했습니다.이러한 경량화 방법에는 [16][17]1991년부터의 신속한 애플리케이션 개발(RAD), 1994년부터의 통합 프로세스(UP) 및 동적 시스템 개발 방법(DSDM), 1995년부터의 Scrum, 1996년부터의 Crystal Clear and Extreme Programming(XP) 및 1997년부터의 FDD(Feature-Driven Development)가 포함됩니다.이러한 모든 것이 신속한 변화를 위한 선언이 발표되기 전에 시작되었지만, 이제는 이를 총칭하여 신속한 변화를 위한 소프트웨어 개발 [7]방법이라고 합니다.

이미 1991년부터 린 경영에서 파생된 제조[18][19] 및 경영[20] 사고방식에 대해 유사한 변화가 진행되고 있다.

2001년에는 17명의 소프트웨어 개발자가 유타주 스노우버드의 리조트에서 만나 경량 개발 방법에 대해 논의했습니다.Kent Beck (익스트림 프로그래밍), Ward Cunningham (익스트림 프로그래밍), Dave Thomas (PragProg, Ruby), Jeff Sutherland (Scrum), Ken Schwaber (Scrum), Jim Highsmith (어댑티브 소프트웨어 개발), Alistair Cockburn (Robert Cry) 등입니다. Martin (SOLID), Mike Beedle (Scrum), Arie van Bennekum, Martin Fowler (OOAD 및 UML), James Grenning, Andrew Hunt (PragProg, Ruby), Ron Jeffries (익스트림 프로그래밍), Jon Kern, Brian Marickrudd (Ste, T)이들은 함께 신속한 변화를 위한 소프트웨어 [5]개발을 위한 매니페스토를 발표했습니다.

2005년 Cockburn과 Highsmith가 이끄는 그룹은 프로젝트 관리 원칙의 부록인 PM 상호의존 [21]선언을 작성하여 신속한 소프트웨어 개발 방법에 따라 소프트웨어 프로젝트 관리를 안내했습니다.

2009년 마틴과 함께 일하는 그룹은 소프트웨어 개발 원칙의 연장선인 소프트웨어 공예 정신 선언을 작성하여 전문적인 행동과 숙달에 따라 민첩한 소프트웨어 개발을 안내했습니다.

2011년, Agile Alliance는 민첩한 실무 가이드([22]2016년에 Agile Glossary로 명칭 변경)를 작성했습니다. 이는 민첩한 실무자 전 세계 커뮤니티의 해석 및 경험 지침과 함께 신속한 변화를 위한 실무, 용어 및 요소의 작업 정의에 대한 진화된 오픈 소스 요약입니다.

신속한 변화를 위한 소프트웨어 개발을 위한 선언

신속한 변화를 위한 소프트웨어 개발 가치

소프트웨어 개발과 다른 사용자의 지원을 결합한 경험을 바탕으로 성명서의 작성자들은 다음과 같은 가치를 [5]부여한다고 선언했습니다.

  • 프로세스와 툴을 통한 개인과 상호작용
  • 포괄적인 문서보다 소프트웨어 작업
  • 계약 협상을 통한 고객 협업
  • 계획에 따른 변경에 대한 대응

즉, 양쪽 모두 가치가 있고 오른쪽 항목을 고려해야 하지만, 왼쪽 항목은 사람들이 자신의 작품에 접근하는 방식에 더 많은 영향을 미칠 것이라고 저자들은 생각했다.

Scott Ambler가 [23]설명했듯이:

  • 도구와 프로세스도 중요하지만 유능한 사람들이 효과적으로 협력하는 것이 더 중요합니다.
  • 좋은 문서는 소프트웨어의 작성 방법과 사용 방법을 이해하는 데 도움이 되지만 개발의 주요 포인트는 문서가 아니라 소프트웨어를 만드는 것입니다.
  • 계약도 중요하지만 고객과 긴밀히 협력하여 고객이 필요로 하는 것을 발견하는 것을 대신할 수는 없습니다.
  • 프로젝트 계획도 중요하지만 기술이나 환경의 변화, 이해관계자의 우선순위, 문제 및 해결책에 대한 사람들의 이해를 수용하기에는 너무 경직되어서는 안 됩니다.

저자들 중 일부는 매니페스토의 가치와 원칙에 따라 소프트웨어 개발을 추진하는 비영리 단체인 Agile Alliance를 결성했습니다.Jim Highsmith는 Agile Alliance를 대표하여 성명서를 소개하면서 다음과 같이 말했습니다.

애자일 운동은 반방법론이 아닙니다.사실 많은 사람들이 방법론이라는 단어의 신뢰성을 회복하고 싶어 합니다.우리는 균형을 되찾고 싶다.델은 모델링을 채용하고 있습니다만, 먼지투성이의 기업 저장소에 도표를 작성하기 위한 것은 아닙니다.델은 매뉴얼을 채택하고 있습니다만, 유지보수가 이루어지지 않고 거의 사용되지 않는 수백 페이지의 문서는 취급하지 않습니다.델은 계획을 세웁니다만, 격동의 환경에서의 계획의 한계를 인식하고 있습니다.XP, SCRUM 또는 기타 Agile 방법론을 "해커"로 낙인찍는 사람들은 방법론과 해커라는 용어의 원래 정의를 모두 알지 못합니다.

--

신속한 변화를 위한 소프트웨어 개발 원칙

신속한 변화를 위한 소프트웨어 개발을 위한 매니페스토는 12가지 [25]원칙을 기반으로 합니다.

  1. 귀중한 소프트웨어를 조기에 지속적으로 배포하여 고객 만족도를 높입니다.
  2. 개발 후기까지 요구사항 변경을 환영합니다.
  3. 가동 중인 소프트웨어를 몇 개월이 아닌 몇 주 동안 자주 배포합니다.
  4. 비즈니스맨과 개발자의 긴밀한 일상 협력
  5. 프로젝트는 신뢰할 수 있는 동기부여가 있는 사람을 중심으로 구축됩니다.
  6. 대면 대화는 최고의 커뮤니케이션 형태입니다(공동 장소).
  7. 작동하는 소프트웨어는 진보의 주요 척도입니다.
  8. 지속 가능한 개발로 일정한 속도를 유지할 수 있습니다.
  9. 기술적 우수성과 우수한 설계에 대한 지속적인 주의.
  10. 단순성(미처리 작업량을 최대화하는 기술)은 필수적입니다.
  11. 최고의 아키텍처, 요건 및 설계는 자체 조직 팀을 통해 구현됩니다.
  12. 팀은 정기적으로 어떻게 하면 더 효과적일 수 있는지 성찰하고 그에 따라 조정한다.

개요

XP에서 사용되는 민첩한 개발 기술인 페어 프로그래밍.

반복적, 증분적, 진화적

대부분의 민첩한 개발 방법은 제품 개발 작업을 조금씩 세분화하여 사전 계획 및 설계의 양을 최소화합니다.반복 또는 스프린트는 일반적으로 1주에서 4주까지의 짧은 시간 범위(타임 박스)입니다.각 반복 작업에는 계획, 분석, 설계, 코딩, 단위 테스트 및 수용 테스트 등 모든 기능을 수행하는 교차 기능 팀이 포함됩니다.반복이 끝나면 이해관계자에게 작업 중인 제품이 시연됩니다.이를 통해 전반적인 위험을 최소화하고 제품이 변화에 [26]빠르게 적응할 수 있습니다.반복은 시장 릴리스를 보증하기에 충분한 기능을 추가하지 못할 수 있지만, [27]각 반복의 마지막에 사용 가능한 릴리스(버그를 최소화한 릴리스)를 확보하는 것이 목표입니다.점진적인 개발을 통해 제품은 최종 출시일이 [28]아닌 각 반복 단계에서 "자주, 그리고 조기에" 실패할 수 있는 여지가 생깁니다.제품 또는 새로운 기능을 출시하려면 여러 번 반복해야 할 수 있습니다.작동하는 소프트웨어는 [25]진보의 주요 척도입니다.

민첩한 접근법의 주요 장점은 시장 투입 속도와 리스크 완화입니다.일반적으로 사용자 요구 사항을 충족하지 못하는 제품을 엔지니어링하는 데 소요되는 시간과 비용 위험을 줄이기 위해 적은 양의 증분이 시장에 출시됩니다.

효율적이고 직접적인 커뮤니케이션

소프트웨어 개발을 위한 민첩한 매니페스토의 여섯 번째 원칙은 "개발팀 및 개발팀 간에 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화"입니다.화상회의가 널리 사용되지 않았던 2001년에 작성된 선언문은, 이것을 정보의 전달에 관해서 기술하고 있습니다만, 반드시 팀을 같은 장소에 둘 필요는 없습니다.

코로케이션의 원칙은 팀으로서의 정체성을 확립하고 커뮤니케이션을 개선하기 [29]위해 같은 팀의 동료들을 함께 배치해야 한다는 것이다.이를 통해 화이트보드 앞에서 직접 대화할 수 있어 전화, 지속 채팅, Wiki 또는 [30]이메일을 통해 질문과 답변을 주고받을 때 일반적으로 걸리는 시간을 단축할 수 있습니다.COVID-19 대유행 기간 동안 원격 작업이 널리 채택되고 툴링이 변경됨에 따라, 공동 위치 및 분산 작업을 중심으로 더 많은 연구가 수행되었으며[31], 이는 공동 위치의 관련성이 점점 낮아지고 있음을 보여준다.

어떤 개발 방법을 따르든 모든 팀은 고객 담당자(Scrum에서는 제품 소유자)를 포함해야 합니다.이 담당자는 이해관계자의 동의를 얻어 대리 행동을 취하며, 반복 중에 개발자가 질문에 답변할 수 있도록 개인적으로 약속합니다.반복이 끝날 때마다 프로젝트 이해관계자는 고객의 담당자와 함께 진행 상황을 확인하고 투자수익률(ROI)을 최적화하고 고객의 요구와 회사의 목표에 맞게 조정하기 위해 우선순위를 재평가합니다.이해관계자 만족도의 중요성은 각 단계의 마지막에 빈번한 상호 작용과 검토를 통해 자세히 설명되며, 이 접근법이 종종 고객 중심적인 [32]방법론으로 나타나는 이유입니다.

신속한 소프트웨어 개발에서 정보 라디에이터는 (보통 큰) 물리적 디스플레이, 스티커 메모 등이 있는 보드이며, 개발팀 근처에 눈에 띄게 배치되어 행인이 이를 볼 수 있습니다.제품 개발 [33][34]현황에 대한 최신 요약을 제공합니다.빌드 라이트 인디케이터를 사용하여 팀에게 제품 개발의 현재 상태를 알릴 수도 있습니다.

피드백 루프 및 적응 사이클이 매우 짧습니다.

신속한 변화를 위한 소프트웨어 개발의 일반적인 특징은 일일 스탠드업(Scrum 프레임워크에서는 일일 스크럼이라고 함)입니다.짧은 세션(예: 15분)에서 팀원들은 목표를 향해 나아가는 과정을 총체적으로 검토하고 접근방식을 조정할 필요가 있는지 여부를 합의합니다.합의된 시간 제한을 준수하기 위해 팀은 종종 간단한 코드화된 질문(예: 전날 완료한 내용, 그날 완료하려는 목표, 진행에 장애나 위험이 있는지 여부)을 사용하고 상세한 논의와 문제 해결을 스탠드업 [35]이후로 지연시킵니다.

품질 중시

지속적인 통합, 자동 유닛 테스트, 페어 프로그래밍, 테스트 중심 개발, 설계 패턴, 동작 중심 개발, 도메인 중심 설계, 코드 리팩터링 및 기타 기술 등의 특정 도구와 기술을 사용하여 품질을 개선하고 제품 개발의 [36]민첩성을 높일 수 있습니다.이는 처음부터 품질을 설계하고 구축하여 언제든지, 또는 적어도 모든 [37]반복의 마지막에 고객에게 소프트웨어를 시연할 수 있는 것을 전제로 합니다.

철학

기존의 소프트웨어 엔지니어링에 비해 민첩한 소프트웨어 개발은 주로 동적, 비결정적 및 비선형 특성을 가진 복잡한 시스템 및 제품 개발을 대상으로 합니다.정확한 추정치, 안정적인 계획 및 예측은 초기에 얻기 어렵고 신뢰도가 낮을 수 있습니다.민첩한 실무자들은 가치 있는 증거를 [38]얻기 전에 필요한 믿음의 도약을 줄이려고 할 것입니다.요건과 설계는 긴급한 것으로 간주됩니다.이러한 경우, 초기 사양이 크면 많은 낭비가 발생할 수 있습니다. 즉, 경제적으로 건전하지 않습니다.다년간의 성공과 실패를 통해 얻은 이러한 기본적인 주장과 이전 업계 경험은 적응형,[39] 반복형 및 진화형 개발에 대한 민첩한 개발의 호감을 형성하는 데 도움이 되었습니다.

적응형 vs 예측형 예측형

개발 방법은 적응형에서 [40]예측형까지 연속체 상에 존재합니다.신속한 변화를 위한 소프트웨어 개발 방법은 이 연속체의 적응적인 측면에 있습니다.적응형 개발 방법의 핵심 중 하나는 일정 계획에 대한 롤링 웨이브 접근법입니다. 이 접근법은 이정표를 식별하지만 그에 도달하기 위한 경로에 유연성을 부여하고 이정표 자체를 [41]변경할 수도 있습니다.

적응형 방법은 변화하는 현실에 신속하게 적응하는 데 초점을 맞춥니다.프로젝트의 요구가 변경되면 적응형 팀도 변경됩니다.적응형 팀은 미래에 무슨 일이 일어날지 정확히 설명하는 데 어려움을 겪습니다.날짜가 멀수록 해당 날짜에 무슨 일이 일어날지에 대한 적응 방법이 모호해집니다.적응형 팀은 다음 주에 정확히 어떤 작업을 수행할지 보고할 수 없으며, 다음 달에 어떤 기능을 계획할지 보고할 수 없습니다.적응형 팀은 6개월 후의 릴리스에 대해 질문할 때 릴리스의 미션 스테이트먼트 또는 예상 가치 대 비용 스테이트먼트만 보고할 수 있습니다.

반면 예측 방법은 미래를 상세하게 분석하고 계획하는 데 초점을 맞추고 알려진 위험을 충족시킨다.극단적으로 예측 팀은 개발 프로세스의 전체 기간 동안 어떤 기능과 태스크를 계획했는지 정확하게 보고할 수 있습니다.예측 방법은 효과적인 초기 단계 분석에 의존하며, 이것이 매우 잘못되면 프로젝트의 방향을 바꾸는 데 어려움을 겪을 수 있습니다.예측 팀은 종종 가장 가치 있는 변경만을 고려하도록 변경 관리 위원회를 설립합니다.

리스크 분석을 사용하여 적응형([42]신뢰성 또는 가치 중심) 방법과 예측형(계획 중심) 방법 중 하나를 선택할 수 있습니다.Barry Boehm과 Richard Turner는 연속체의 각 면에 다음과 [43]같이 자신만의 홈그라운드가 있다고 제안한다.

개발 방법이 다른 홈그라운드
가치 중심 방식(애자일) 계획 주도의 방법(낙수) 형식적인 방법
중요도가 낮다 중요도가 높다 매우 중요함
시니어 개발자 하급 개발자(?) 시니어 개발자
요건이 자주 변경되다 요건은 자주 변경되지 않는다 제한된 요건, 제한된 기능, Worth의 법칙[clarification needed] 참조
개발자 수가 적다 다수의 개발자 모델링 가능한 요건
변화에 대응하는 문화 질서를 요구하는 문화 최고의 품질

신속한 대응과 폭포수 비교

신속한 변화를 위한 소프트웨어 개발 방법과 폭포의 차이점 중 하나는 품질과 테스트에 대한 접근 방식입니다.워터폴 모델에서 작업은 소프트웨어 개발 라이프 사이클(SDLC) 단계를 거칩니다(한 단계는 다른 단계가 시작되기 전에 완료됨). 따라서 테스트 단계는 분리되어 구축 단계에 따릅니다.그러나 신속한 변화를 위한 소프트웨어 개발에서는 테스트가 프로그래밍과 동일한 반복으로 완료됩니다.

테스트는 모든 반복(소프트웨어의 작은 부분을 개발하는 것)에서 이루어지기 때문에 사용자는 이러한 새로운 소프트웨어를 자주 사용하여 가치를 검증할 수 있습니다.사용자는 업데이트된 소프트웨어의 진정한 가치를 알게 되면 소프트웨어의 미래에 대해 더 나은 결정을 내릴 수 있습니다.각 반복마다 가치 회고 및 소프트웨어 재계획 세션을 갖는 Scrum은 일반적으로 2주밖에 반복하지 않으므로 팀이 계획을 지속적으로 조정하여 제공하는 가치를 극대화할 수 있습니다.이는 작업이 계획, 완료, 확인(검토 및 소급에서)되고 합의된 변경사항이 실행되므로 계획-실행-체크-액트(PDCA) 사이클과 유사한 패턴을 따른다.

이 반복적인 접근방식은 프로젝트 마인드가 아닌 제품을 지원합니다.따라서 개발 프로세스 전체에서 유연성이 향상됩니다.프로젝트에서는 요건이 처음부터 정의되고 고정되므로 나중에 변경하기가 어렵습니다.반복적인 제품 개발을 통해 소프트웨어는 비즈니스 환경 또는 시장 요구 사항의 변화에 따라 발전할 수 있습니다.

코드 대 문서

IEEE Computer에 보낸 서한에서 Steven Rakitin은 신속한 변화를 위한 소프트웨어 개발에 대해 "또 하나의 소프트웨어 엔지니어링 규율을 해치는 시도"라고 말하며 "우리는 모든 시간을 코딩에 소비하고 싶다"고 번역했습니다. 실제 프로그래머는 [44]문서를 작성하지 않습니다.

이는 신속한 변화를 위한 소프트웨어 개발 지지자들에 의해 논란이 되고 있는데, 이들은 개발자가 관련 목표를 달성하기 위한 최선의 방법이라면 문서를 작성해야 하지만 정적 [45]문서를 작성하는 것보다 그러한 목표를 달성하기 위한 더 나은 방법이 종종 있다고 말합니다.스콧 앰블러 그 문서가 되어야 한다"겨우 충분히 좋은"(JBGE)[46]너무 많이 또는 포괄적인 문서 보통 낭비를 초래할 수 있으며, 반면에 너무 작은 문서는 또한 정비, 통신,를 배우문제를 일으킬 수 있기 때문에 보통 code,[45]과 일치하지 않습니다 개발자들 거의 상세한 문서를 신뢰하다고 명시하고 있다.왕과지식 공유.Alistair Cockburn은 Crystal Clear 방법에 대해 다음과 같이 썼다.

Crystal은 개발을 일련의 협동 게임으로 간주하며, 이 문서는 다음 게임에서 다음 번 승리를 거두는 데 충분하다고 생각합니다.Crystal의 작업 제품에는 사용 사례, 위험 목록, 반복 계획, 핵심 도메인 모델 및 선택에 대한 정보를 제공하는 설계 노트가 포함됩니다.그러나 이러한 문서에는 템플릿이 없고 설명도 모호하지만 목표는 명확하며 다음 게임을 위한 충분한 문서입니다.저는 항상 이것을 우리 팀에 특징짓는 경향이 있습니다: 만약 내일 팀에 합류한다면 무엇을 알고 싶습니까?

--

신속한 소프트웨어 개발 방법

소프트웨어 개발 라이프 사이클[48] 지원
신속한 변화를 위한 통합 프로세스(AUP)는 통합 프로세스(반복적이고 증분적인 소프트웨어 개발 프로세스 프레임워크)를 기반으로 합니다.

신속한 변화를 위한 소프트웨어 개발 방법은 광범위한 소프트웨어 개발 라이프 [48]사이클을 지원합니다.일부 방법(예: XP, 실용적인 프로그래밍, 민첩한 모델링)은 실무에 중점을 두고 있으며, 일부 방법(예: Scrum, Kanban)은 업무 흐름 관리에 중점을 두고 있습니다.요구사항 사양 및 개발 활동을 지원하는 기업도 있고(예: FDD), 전체 개발 수명 주기(예: DSDM, RUP)를 대상으로 하는 기업도 있습니다.

민첩한 소프트웨어 개발 프레임워크는 다음과 같습니다.

프레임워크 주요 기여자
적응형 소프트웨어 개발(ASD) 짐 하이스미스, 샘 바이어
민첩한 모델링 스콧 앰블러, 로버트 세실 마틴
신속한 변화를 위한 통합 프로세스(AUP) 스콧 앰블러
규율된 민첩한 제공 스콧 앰블러
동적 시스템 개발 방법(DSDM) 제니퍼 스테이플턴
익스트림 프로그래밍(XP) 켄트 벡, 로버트 세실 마틴
기능 주도 개발(FDD) 제프 드 루카
린 소프트웨어 개발 메리 포펜디크, 메리 포펜디크
린 스타트업 에릭 리스
칸반 오노 타이이치
신속한 애플리케이션 개발(RAD) 제임스 마틴
스크럼 켄 슈워버, 제프 서덜랜드
스크럼반
신속한 변화를 위한 확장 프레임워크 - SAFe Scaled Agile, Inc.

신속한 변화를 위한 소프트웨어 개발 관행

신속한 변화를 위한 소프트웨어 개발은 요구사항, 설계, 모델링, 코딩, 테스트, 계획, 리스크 관리, 프로세스, 품질 등과 같은 분야를 망라하는 많은 구체적인 실무에 의해 지원됩니다.민첩한 소프트웨어 개발에는 다음과 같은 특징이 있습니다.[49]

연습 주요 기여자
수용 테스트 주도 개발(ATDD)
민첩한 모델링
신속한 테스트
잔량 (제품 및 스프린트) 켄 슈바버
행동 주도 개발(BDD) 댄 노스, 리즈 키오
연속연동(CI) 그래디 부치
여러 부서로 구성된 팀
데일리 스탠드업 / 데일리 스크럼 제임스 오 코플린
도메인 주도 설계(DD) 에릭 에반스
반복 및 증분 개발(IID)
페어 프로그래밍 켄트 벡
플래닝 포커 제임스 그레닝, 마이크 콘
리팩터링 마틴 파울러
회고전
스크럼 이벤트(인쇄 계획, 스프린트 리뷰 및 소급)
예에 의한 사양
스토리 기반 모델링 알베르트 ü도르프
테스트 주도 개발(TDD) 켄트 벡
타임박스
사용자 사례 알리스테어 콕번
속도 추적

메서드 커스터마이즈

문헌에서 다른 용어는 '방법 맞춤', '방법 단편 적응' 및 '상황적 방법 공학'을 포함한 방법 적응의 개념을 말한다.메서드 맞춤은 다음과 같이 정의됩니다.

인간 에이전트가 컨텍스트, 의도 및 메서드 조각 간의 응답성 변경 및 동적 상호 작용을 통해 특정 프로젝트 상황에 대한 시스템 개발 접근 방식을 결정하는 프로세스 또는 능력입니다.

--

상황적합성은 신속한 변화를 위한 방법과 보다 계획적인 소프트웨어 개발 방법을 구별하는 특징으로 간주되어야 하며, 신속한 변화를 위한 방법을 통해 제품 개발 팀은 [51][50]개별 제품의 요구에 따라 작업 관행을 조정할 수 있습니다.CMM [52]컨텍스트에서 맞춤화된 DSDM 등 대부분의 민첩한 방법이 메서드 [48]맞춤에 적합할 수 있습니다.및 XP는 Rule Description Practices(RDP; 규칙 설명 프랙티스) [53]기법으로 맞춤 제작되었습니다.그러나 모든 민첩한 지지자들이 슈바버가 "애초에 문제가 완벽한 방법론을 가지고 있지 않다고 생각하면서 문제를 일으켰던 이유"라고 지적한 것에 동의하는 것은 아닙니다.기업의 변화[필요]에 초점을 맞춰야 합니다.[54]Bas Vodde는 이러한 관점을 강화하여 요소를 선택하고 선택해야 하는 기존의 대규모 방법론과는 달리 Scrum은 기본을 제공하며, 그 위에 추가 요소를 추가하여 [55]그 사용을 현지화하고 컨텍스트화할 수 있습니다.실무자들은 시스템 개발 방법, 특히 교칙에 따라 민첩한 방법을 거의 사용하지 않으며, 종종 내부 [56]방법을 만들기 위해 방법의 몇 가지 방법을 생략하거나 맞춤화할 수 있습니다.

실제로는 다양한 도구를 사용하여 방법을 맞춤화할 수 있습니다.Unified Modeling Language 등의 범용 프로세스 모델링 언어를 사용하여 소프트웨어 개발 방법을 맞춤화할 수 있습니다.그러나 SEMAT의 소프트웨어 엔지니어링의 본질 이론과 같은 메서드 엔지니어링 전용 툴도 존재합니다.[57]

대규모, 오프쇼어 및 분산형

갖춘 환경 특정 유형의 적합한 애자일 소프트웨어 개발 널리, 전문가들의 작은 팀 그린필드 projects,[43][58]고 도전과 한계를 민첩한 소프트웨어 개발 방법의 채택에서 유산 기반 시설과 불행 있는 커다란 조직에서 겪는에 일하는 것도 포함되게 보였습니다.derstood를 클릭합니다.[59]

이에 따라 대규모 개발(20명 이상의 개발자)[60][61] [62][63]또는 분산형 개발팀과의 과제 등 다양한 전략과 패턴이 발전하고 있으며, 현재 이러한 과제를 완화하거나 회피하려는 몇 가지 인식된 프레임워크가 있습니다.

이러한 모든 것이 효과적인지, 즉 민첩한 개발의 정의에 부합하는지에 대해서는 많은 상반된 관점이 있으며, 이는 여전히 활발히 진행 중인 연구 [60][64]분야입니다.

신속한 변화를 위한 소프트웨어 개발을 분산된 환경(여러 비즈니스 지역에 분산된 팀)에서 적용하는 경우 일반적으로 신속한 변화를 위한 분산 소프트웨어 개발이라고 합니다.목표는 각 접근 방식이 제공하는 고유한 이점을 활용하는 것입니다.분산 개발에서는 세계 각지에 전략적으로 팀을 구성하여 소프트웨어를 구축할 수 있습니다.가상으로 24시간 소프트웨어를 구축할 수 있습니다(일반적으로 팔로우 더 선 모델이라고 불립니다).한편, 민첩한 개발은 투명성을 높이고, 지속적인 피드백을 제공하며, 변화에 대응할 때 유연성을 높입니다.

규제 도메인

신속한 변화를 위한 소프트웨어 개발 방법은 처음에는 중요하지 않은 제품 개발에 가장 적합한 것으로 간주되었기 때문에 의료 기기, 제약, 금융, 핵 시스템, 자동차 및 항전 분야 등과 같은 규제 영역에서의 사용은 제외되었습니다.그러나 최근 몇 년 동안 이러한 [65][66][67][68][69]도메인에 대한 신속한 변화를 위한 몇 가지 이니셔티브가 있었다.

ISO 26262, ISO 9000, ISO 9001, ISO/IEC 15504 등 규제 영역에 적용될 수 있는 수많은 표준이 있습니다.규제 [70]대상 도메인에서는 특히 중요한 문제가 많이 있습니다.

  • 품질보증(QA): 관리된 프로페셔널 프로세스와 제품의 신뢰성과 정확성을 뒷받침하는 체계적이고 고유한 품질관리.
  • 안전 및 보안:사용자의 안전 위험을 완화하고 의도하지 않은 악의적인 오용으로부터 사용자를 안전하게 보호하기 위한 공식적인 계획 및 리스크 관리.
  • 트레이서빌리티:규제 준수에 대한 감사 가능한 증거를 제공하고 추적 및 문제 조사를 용이하게 하는 문서.
  • 검증 및 검증(V&V): 소프트웨어 개발 프로세스 전체에 포함되어 있습니다(사용자 요건 사양, 기능 사양, 설계 사양, 코드 리뷰, 유닛 테스트, 통합 테스트, 시스템 테스트 등).

경험과 채용

신속한 변화를 위한 소프트웨어 개발 방법은 실제로 모든 프로그래밍 패러다임 또는 언어와 함께 사용할 수 있지만, 원래는 Smalltalk, Lisp, 이후 Java, C# 등의 객체 지향 환경과 밀접하게 관련되어 있었습니다.신속한 변화를 위한 방법을 처음 채택한 팀은 대개 전례가 없는 시스템에서 작업하는 중소 규모의 팀들이었습니다. 시스템 개발 중에 요구사항이 확정되기 어렵고 변경될 가능성이 높았습니다.이 섹션에서는 민첩한 소프트웨어 개발 방법 및 민첩한 [71]팀의 품질과 성능을 측정하기 위한 다양한 기술을 도입하려고 할 때 조직이 직면하는 일반적인 문제에 대해 설명합니다.

민첩성 측정

내부 평가

민첩성 측정 지수는 특히 제품 개발의 5가지 차원(기간, 리스크, 신규성, 노력 및 상호작용)[72]에 대해 개발을 평가합니다.다른 기술은 측정 가능한[73] 목표를 기반으로 하며, 한 연구에 따르면 속도가 민첩성의 지표로 사용될 수 있습니다.또한 팀이 신속한 변화를 위한 소프트웨어 개발 방식을 사용하고 있는지 여부를 판단하기 위한 신속한 자가 평가(Nokia 테스트,[74] Karlskrona 테스트,[75] 42점 테스트)[76]도 있습니다.

여론 조사

신속한 변화를 위한 소프트웨어 개발 방법을 사용하여 품질, 생산성 및 비즈니스 만족도가 향상되었다고 보고된 초기 연구 중 하나는 2002년 11월부터 2003년 [77]1월까지 Shine Technologies가 실시한 설문 조사입니다.

2006년부터 소프트웨어 개발 커뮤니티의 수천 명의 참가자를 대상으로 매년 이와 유사한 설문 조사인 '애자일(State of Agile)'이 실시되고 있습니다.이는 민첩성, 교훈 및 모범 사례의 인식된 이점에 대한 추세를 추적합니다.각 조사에서는 신속한 변화를 위한 소프트웨어 개발이 소프트웨어 제공 시간을 단축하고 변화하는 고객 우선 순위를 관리하는 능력을 향상시키며 생산성을 [78]향상시킨다는 의견이 증가하고 있습니다.또한 설문 조사에서는 기존의 프로젝트 [79][80]관리에 비해 민첩한 제품 개발 방법이 일관되게 더 나은 결과를 얻고 있습니다.한편, 민첩한 개발 방법이 아직 너무 어려서 그들의 [81]성공에 대한 광범위한 학술적 연구를 할 수 없다는 보고도 있다.

일반적인 민첩한 소프트웨어 개발 함정

신속한 변화를 위한 소프트웨어 개발을 구현하고 있는 조직과 팀은 종종 신속한 변화를 위한 프로세스를 [82]강요하는 팀 등 폭포 개발 같은 기존 방식에서 전환하기 어려운 상황에 직면합니다.이들은 민첩한 안티 패턴 또는 보다 일반적으로 민첩한 냄새라고 불립니다.다음은 일반적인 예입니다.

전체적인 제품 설계의 결여

신속한 변화를 위한 소프트웨어 개발의 목표는 문서화가 아닌 실제 소프트웨어 생산에 더 집중하는 것입니다.이는 프로세스가 고도로 제어되고 시스템의 사소한 변경으로 지원 문서를 대폭 수정해야 하는 워터폴 모델과는 대조적입니다.그러나, 이것은 어떠한 분석이나 설계도 없이 완전히 수행하는 것을 정당화하지는 않습니다.설계에 주의를 기울이지 않으면 처음에는 빠르게 진행되지만, 그 후에는 시스템 확장을 시도할 때 상당한 재작업이 필요할 수 있습니다.신속한 변화를 위한 소프트웨어 개발의 주요 특징 중 하나는 반복적이라는 것입니다.올바르게 수행되면 시스템 개발과 재사용의 공통성 및 기회가 [83]발견됨에 따라 설계가 나타납니다.

진행 중인 반복에 스토리 추가

신속한 변화를 위한 소프트웨어 개발에서는 일반적으로 (사용 사례 설명과 유사) 스토리가 요구 사항을 정의하는 데 사용되며, 반복은 팀이 [84]특정 목표에 전념하는 짧은 기간입니다.진행 중인 반복에 스토리를 추가하는 것은 작업 흐름에 악영향을 미칩니다.이러한 항목은 제품 백로그에 추가되어야 하며 이후 반복 시 또는 드물게 반복이 [85]취소될 수 있습니다.

이것은 이야기가 확장될 수 없다는 것을 의미하지 않는다.팀은 새로운 정보를 다루어야 하며, 이는 스토리에 대한 추가 작업을 발생시킬 수 있습니다.새로운 정보로 인해 반복 중에 스토리가 완성되지 않으면 다음 반복으로 넘어가야 합니다.하지만, 새로운 정보가 이야기의 원래 우선순위를 바꿨을 수도 있기 때문에, 그것은 남아있는 모든 이야기보다 우선되어야 한다.

스폰서 지원 부족

신속한 변화를 위한 소프트웨어 개발은 개발 프로세스를 최적화하고 소프트웨어 개발 라이프 사이클의 일관성을 확보하기 위해 노력하는 소프트웨어 개발 팀에 의해 조직 내에서 풀뿌리 작업으로 구현되는 경우가 많습니다.스폰서 지원이 없으면 팀은 비즈니스 파트너, 다른 개발 팀 및 경영진으로부터 어려움과 저항에 직면할 수 있습니다.또한 적절한 자금과 [86]자원이 없으면 어려움을 겪을 수 있습니다.이로 인해 [87]고장 가능성이 높아집니다.

트레이닝 부족

한 조사에서 VersionOne에서 수행한 응답자 실패한 민첩한 implementations[88]의 팀을 위한 가장 중요한 원인으로 민첩한 소프트웨어 개발의 폭포가 민첩한 소프트웨어 devel에 어떤 실제적인 규칙이 있다는 뜻과 같은 다른 접근법에 비해 줄어든 과정의 덫에 빠진 불충분한 훈련을 언급했다를 발견했다.opme없습니다.[citation needed]

제품 소유자 역할이 올바르게 채워지지 않았습니다.

제품 소유자는 개발 활동에서 비즈니스를 대표할 책임이 있으며 대부분의 경우 가장 까다로운 역할입니다.[89]

흔히 있는 실수는 제품 소유자 역할을 개발팀의 누군가가 채우는 것입니다.이를 위해서는 기업의 실질적인 피드백 없이 팀이 우선순위를 결정할 필요가 있습니다.이들은 내부적으로 비즈니스 문제를 해결하려고 하거나 팀 외부에서 지시를 내릴 때 작업을 지연시킵니다.이로 인해 종종 주의가 산만해지고 [90]협업이 중단됩니다.

팀이 집중되어 있지 않다

신속한 변화를 위한 소프트웨어 개발을 위해서는 팀이 제품의 약속을 이행해야 합니다.즉, 해당 제품에 대해서만 작업에 집중해야 합니다.그러나 여유 용량이 있는 것으로 보이는 팀원들은 다른 업무를 맡을 것으로 예상되기 때문에 팀이 [91]맡은 업무를 완수하는 데 도움을 주기 어렵습니다.

과도한 준비/계획

팀은 준비나 계획에 너무 많은 시간을 소비하는 함정에 빠질 수 있습니다.이는 신속한 변화를 위한 소프트웨어 개발에 익숙하지 않은 팀에게 공통된 함정이며, 팀은 모든 사례를 완벽하게 이해하고 사양을 지정해야 한다고 생각합니다.팀은 자신 있는 스토리만 가지고 전진할 준비가 되어 있어야 하며, 그 후 반복 작업(대부분 백로그 개선 또는 그루밍이라고 함)을 계속적으로 발견하고 준비해야 합니다.

일상 스탠드업에서의 문제 해결

매일의 스탠드업은 모든 팀원이 정보를 배포하는 집중적이고 시기 적절한 미팅이어야 합니다.문제 해결이 발생하는 경우, 종종 특정 팀원만 관여할 수 있으며, 잠재적으로 팀 전체의 시간을 최대한 활용하지 못할 수 있습니다.매일 스탠드업 중에 팀이 문제 해결에 착수할 경우, 일반적으로 스탠드업이 [92]완료된 직후에 하위 팀이 논의할 수 있을 때까지 보류해야 한다.

태스크 할당

신속한 변화를 위한 소프트웨어 개발의 의도된 이점 중 하나는 팀이 문제에 가장 가까운 선택을 할 수 있도록 하는 것입니다.또한 의사결정에 보다 시기적절하게 정보를 사용할 수 있도록 가능한 한 구현에 가까운 선택을 해야 한다.팀원이 다른 사람에 의해 또는 프로세스 초기에 태스크를 할당받으면 현지화되고 시기적절하게 의사결정을 하는 이점이 [93]상실될 수 있습니다.

또한 작업이 할당되면 팀 구성원이 특정 역할(예를 들어 팀 구성원 A는 항상 데이터베이스 작업을 수행해야 함)로 제한되므로 교차 [93]훈련의 기회가 제한됩니다.팀원 스스로 자신의 능력을 확장하고 교차 훈련 기회를 제공하는 작업을 수행할 수 있습니다.

Scrum Master를 기여자로 합니다.

민첩한 가치와 원칙에 부합한다고 주장하는 Scrum 프레임워크에서 Scrum 마스터 역할은 Scrum 프로세스를 준수하고 이 프로세스를 통해 Scrum 팀을 코칭할 책임이 있습니다.일반적인 함정은 스크럼 마스터가 기여자 역할을 하는 것이다.Scrum 프레임워크에 의해 금지되지는 않지만 Scrum Master는 개발 태스크가 아닌 Scrum Master 역할을 수행할 수 있는 능력을 먼저 확보해야 합니다.스크럼 마스터의 역할은 [94]제품을 만드는 것이 아니라 프로세스를 촉진하는 것입니다.

스크럼 마스터가 있으면 멀티태스킹도 실행할 수 없는 컨텍스트스위치가 너무 많아질 수 있습니다.또한 스크럼 마스터는 팀이 전진할 수 있도록 장애물을 제거할 책임이 있기 때문에 개별 작업을 진행함으로써 얻을 수 있는 이점은 용량 [95]부족으로 인해 지연되는 장애물을 초과할 수 없습니다.

테스트 자동화 부족

민첩한 개발의 반복적인 특성으로 인해 종종 여러 차례의 테스트가 필요합니다.자동화된 테스트를 통해 반복적인 유닛, 통합 및 회귀 테스트의 영향을 줄이고 개발자와 테스터가 보다 가치 있는 [96]작업에 전념할 수 있습니다.

테스트 자동화는 반복적인 소프트웨어 개발에 필요한 지속적인 리팩터링도 지원합니다.개발자가 테스트를 신속하게 실행하여 리팩토링이 애플리케이션의 기능을 변경하지 않았음을 확인할 수 있도록 하면 작업 부하가 감소하고 청소 작업에서 새로운 결함이 발생하지 않았음을 확신할 수 있습니다.

기술적 부채의 증가를 허용하다

신기능 제공에 주력하면 기술부담이 증가할 수 있습니다.팀은 결함 복구 및 리팩터링에 시간을 할애해야 합니다.기술 부채는 생산 결함으로 인해 팀이 더 이상 [97]진행하지 못하게 되면서 계획되지 않은 작업량을 늘림으로써 계획 능력을 저해합니다.

시스템이 진화함에 따라 시스템의 엔트로피가 자연스럽게 [98]증가하므로 리팩터링하는 것이 중요합니다.시간이 지남에 따라 지속적인 유지보수가 부족하면 결함 및 개발 [97]비용이 증가합니다.

반복에서 너무 많은 작업을 수행하려고 합니다.

일반적인 오해는 신속한 변화를 위한 소프트웨어 개발로 지속적인 변경이 가능하지만 반복 백로그는 반복 [99]중에 완료할 수 있는 작업에 대한 합의입니다.WIP(Work-In-Progress)[100]가 너무 많으면 컨텍스트스위칭이나 큐잉 등의 효율이 저하됩니다.그 팀은 추가 업무를 [101]떠맡아야 한다는 압박감을 느끼지 말아야 한다.

고정 시간, 리소스, 범위 및 품질

신속한 변화를 위한 소프트웨어 개발은 시간(반복 기간), 품질 및 이상적인 리소스를 미리 해결합니다(다만, 개발자가 프로덕션 인시던트를 처리하는 태스크에서 종종 떨어져 있는 경우 고정된 리소스를 유지하는 것은 어려울 수 있습니다). 한편, 범위는 여전히 다양합니다.고객 또는 제품 소유자는 종종 반복에 대해 고정된 범위를 요구합니다.단, 팀은 정해진 시간, 자원 및 범위(일반적으로 프로젝트 관리 삼각관계)에 전념하는 것을 꺼려해야 합니다.신속한 변화를 위한 소프트웨어 개발의 고정된 시간과 리소스에 범위를 추가하려는 노력은 품질 [102]저하로 이어질 수 있습니다.

현상 소진

신속한 대응에 초점을 맞춘 업무와 지속적인 업무 특성상 딜리버리 [103]팀원들 사이에 지칠 위험이 높아집니다.

신속한 관리

주요 기사:신속한 관리

신속한 변화를 위한 프로젝트 관리는 반복적인 개발 프로세스로, 사용자 및 이해관계자로부터 지속적으로 피드백을 수집하여 올바른 사용자 환경을 구축합니다.신속한 프로세스를 수행하기 위해 스크럼, 익스트림 프로그래밍, 린 및 칸반 [104]등 다양한 방법을 사용할 수 있습니다.신속한 변화를 위한 관리라는 용어는 신속한 변화를 위한 소프트웨어워 선언에 명시된 원칙에 따라 매우 유연하고 상호작용적인 방식으로 신제품 또는 서비스 개발을 제공하는 것을 목표로 하는 엔지니어링, 정보기술 및 기타 비즈니스 영역의 설계 및 구축 활동을 관리하는 반복적이고 증분적인 방법에 적용됩니다.e [105]개발신속한 프로젝트 관리 메트릭을 통해 혼동을 줄이고, 취약점을 식별하며, 개발 주기 전체에 걸쳐 팀의 성과를 측정할 수 있습니다.서플라이 체인(supply-chain)의 민첩성은 서플라이 체인(supply-chain)이 오퍼와 수요의 불확실성과 변동성에 대처하는 능력입니다.신속한 변화를 위한 서플라이 체인(supply-chain)은 용량을 빠르게 증감할 수 있기 때문에 빠르게 변화하는 고객 수요에 대응할 수 있습니다.마지막으로, 전략적 민첩성은 환경의 진화에 따라 조직의 행동 방침을 변경할 수 있는 능력입니다.전략적 민첩성의 핵심은 외부 변화를 충분히 조기에 인식하고 이러한 변화하는 [104]환경에 적응할 수 있도록 리소스를 할당하는 것입니다.

신속한 변화를 위한 X 기술은 극단적인 프로젝트 관리라고도 할 수 있습니다.성과물이 단계별로 제출되는 반복 라이프[106] 사이클의 변형입니다.민첩한 개발과 반복적인 개발의 주요 차이점은 신속한 변화를 위한 방법은 각 제공 사이클([107]반복)에서 성과물의 작은 부분을 완성하는 반면, 반복적인 방법은 전체 성과물 세트를 시간이 지남에 따라 발전시켜 프로젝트가 거의 끝날 무렵에 완성된다는 것입니다.반복적 방법과 민첩한 방법 모두 보다 순차적인 프로젝트 조직 형태로 전개되는 다양한 장애에 대한 반응으로 개발되었습니다.예를 들어, 기술 프로젝트가 복잡해짐에 따라 최종 사용자는 점진적인 프로토타입을 볼 수 없는 상태에서 장기적인 요구사항을 정의하는 데 어려움을 겪는 경향이 있습니다.반복 개발 중인 프로젝트는 지속적으로 피드백을 수집하여 요구사항을 개선할 수 있습니다.

민첩한 관리는 또한 팀원들 [108]간의 커뮤니케이션과 과거 작업에 대한 성찰을 촉진하는 단순한 프레임워크를 제공합니다.기존의 폭포 계획을 사용하고 민첩한 개발 방식을 채택한 팀은 일반적으로 전환 단계를 거치며, 원활한 전환 과정을 안내하는 민첩한 코치의 도움을 받는 경우가 많습니다.민첩한 코칭에는 일반적으로 푸시 기반 및 풀 기반 민첩 코칭의 두 가지 스타일이 있습니다.여기서 "밀어넣기 시스템"은 스프린트(밀어넣기 작업)에 어떤 작업을 장착할 수 있는지에 대한 사전 추정(예: 스크럼)을 참조할 수 있으며, "풀 시스템"은 작업이 가능한 경우(예: 칸반)[clarification needed]에만 작업이 수행되는 환경을 참조할 수 있다.신속한 변화를 위한 관리 접근법도 채용되어 비즈니스 및 정부 부문에 적용되고 있습니다.예를 들어 미국 연방정부 내에서 미국 국제개발청(USAID)은 프로그래밍을 [109]반복하고 적응시키기 위해 협업, 학습 및 적응(CLA) 전략을 통합하는 데 초점을 맞춘 협업 프로젝트 관리 접근방식을 채택하고 있다.

신속한 변화를 위한 방법은 Project Management Body of Knowledge 가이드(PMBOK 가이드 제6판)의 제품 개발 라이프 사이클 정의에 기재되어 있습니다.

"프로젝트 라이프 사이클에는 일반적으로 제품, 서비스 또는 결과 개발과 관련된 단계가 하나 이상 있습니다.이를 개발 수명 주기(...)라고 합니다. 적응 수명 주기는 민첩하거나 반복적이거나 증분적입니다.반복 시작 전에 상세 범위가 정의되고 승인됩니다.적응형 라이프 사이클은 민첩성 또는 변화 주도 라이프 사이클이라고도 합니다.][110]

소프트웨어 개발 외부의 응용 프로그램

신속한 변화를 위한 브라질 2014 컨퍼런스

Jean-Loup Richet(ESSEC Strategic Innovation & Services 연구소 연구원)에 따르면, "이 접근방식은 소프트웨어 이외의 제품 및 프로젝트 관리 전반, 특히 혁신과 불확실성 분야에서 효과적으로 활용될 수 있습니다."그 결과, 현재의 고객의 요구를 최적으로 만족시키는 제품 또는 프로젝트가 실현되어 비용, 낭비, 시간을 최소한으로 억제할 수 있기 때문에, 기업은 종래의 [111]어프로치보다 단기간에 이익을 얻을 수 있습니다.

신속한 변화를 위한 소프트웨어 개발 방법은 소프트웨어 제품 개발에 광범위하게 사용되어 왔으며, 객체 기술 [112]등 소프트웨어의 특정 특성을 사용하는 것도 있습니다.그러나 이러한 기술은 컴퓨터, 의료기기, 음식, 의류, 음악 [113]등 비소프트웨어 제품 개발에 적용될 수 있습니다.신속한 변화를 위한 소프트웨어 개발 방법은 비개발 IT 인프라 구축 및 마이그레이션에서 사용되어 왔습니다.신속한 변화를 위한 소프트웨어 개발의 광범위한 원칙 중 일부는 비즈니스 민첩성 또는 신속한 변화를 위한 비즈니스 관리라는 용어로 일반적인 관리[114](예: 전략, 거버넌스, 리스크, 재무)에도 적용되고 있습니다.

신속한 변화를 위한 소프트웨어 개발 패러다임은 자녀 양육 등 삶의 다른 분야에서도 사용할 수 있습니다.아동 발달에서의 성공은 의사소통, 적응 및 인식이라는 몇 가지 기본적인 관리 원칙에 기초할 수 있다.TED 토크에서 Bruce Feiler는 어떻게 기본적인 민첩한 패러다임을 [115]가정 관리와 육아에 적용했는지에 대해 설명했습니다.

비판

민첩한 업무는 대규모 조직 및 특정 유형의 [116]개발에서 잠재적으로 비효율적인 것으로 알려져 있습니다.많은 조직에서는 신속한 변화를 위한 소프트웨어 개발 방법이 지나치게 극단적이며 신속한 변화를 위한 소프트웨어 개발 요소와 계획 중심 접근 [118]방식을 혼합한 하이브리드[117] 방식을 채택하고 있습니다.동적 시스템 개발 방법(DSDM)과 같은 일부 방법에서는 기본 원칙을 희생하지 않고 규율적인 방식으로 이를 시도합니다.

민첩한 프랙티스의 도입이 증가하고 있는 것은, 기존의 베스트 프랙티스를 새로운 전문 용어로 간단하게 기술해, 개발 전략에 모든 사고방식을 짜맞추는 것, [119]결과보다 방법을 잘못 강조하는 관리 유행이라는 비판도 받고 있습니다.

Alistair Cockburn은 2011년 2월 12일 유타주 Snowbird에서 Agile Software Development 매니페스토 10주년 기념행사를 개최하여 최초 미팅과 그 이후 30명 이상의 참석자를 모았습니다.회의실에서 약 20마리의 코끼리 목록('논의할 수 없는' 민첩한 토픽/문제')이 수집되었습니다.여기에는 민첩한 소프트웨어 개발 관행과 컨텍스트의 제휴, 실패 및 한계(가능한 원인: 상업적 이익, 실패에 기초한 명확한 진전 방법 없음, 제한된 객관적 증거, 인식)가 포함됩니다.반복적인 편견과 추론 오류), 정치와 문화.[120]Philippe Kruchten은 다음과 같이 썼다.

민첩한 움직임은 어떤 면에서는 십대답다: 매우 자의식적이고, 끊임없이 거울에 비친 자신의 모습을 확인하며, 비판을 거의 받지 않고, 과거의 모든 지혜를 거부한다. 단지 과거의 유행과 새로운 용어를 채택하고 있다는 이유만으로, 때로는 건방지고 거만하다.그러나 나는 그것이 더 성숙하고, 더 개방적이고, 더 반영적이고, 따라서 더 효과적일 것이라고 의심하지 않는다.

--

"매니페스토"는 더 느린 전통적이고 숙고적인 과정을 더 "더욱"한 과정으로 대체해야 한다고 관리자에게 제안한 고등교육 관리와 리더십에 부정적인 영향을 미쳤을 수 있다.그 개념은 대학 [121]교수들 사이에서 거의 받아들여지지 않았다.

또 다른 비판은 민첩한 관리와 전통적인 관리 관행이 여러 면에서 서로 상반된다는 것입니다.이러한 관행에 대한 일반적인 비판은 잠재적 이점에도 불구하고 관행을 배우고 구현하는 데 드는 시간이 너무 비싸다는 것이다.기존 관리에서 신속한 변화를 위한 관리로 전환하려면 민첩성에 대한 완전한 복종과 프로세스를 끝까지 지켜보겠다는 조직의 모든 구성원들의 확고한 약속이 필요합니다.조직 전체의 불균등한 결과, 종업원의 대처 능력에 대한 과도한 변화, 이행의 마지막에 있어서의 보증의 부족 등의 문제는, 몇개의 [122]예에 지나지 않습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Rally (2010). "Agile With a Capital "A" Vs. agile With a Lowercase "a"". Archived from the original on 5 January 2016. Retrieved 9 September 2015.{{cite web}}: CS1 유지보수: 부적합한 URL(링크)
  2. ^ Collier, Ken W. (2011). Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Pearson Education. pp. 121 ff. ISBN 9780321669544. What is a self-organizing team?
  3. ^ Beck, Kent M.; Beedle, Mike; Bennekum, Arie van; Cockburn, Alistair; Cunningham, Ward; Fowler, Martin; Grenning, James; Highsmith, Jim; Hunt, Andy; Jeffries, Ron; Kern, Jon; Marick, Brian; Martin, R. C.; Mellor, Steve J.; Schwaber, Ken; Sutherland, Jeff; Thomas, Dave. "Manifesto for Agile Software Development". S2CID 109006295. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  4. ^ "What is Agile Software Development?". Agile Alliance. 8 June 2013. Retrieved 4 April 2015.
  5. ^ a b c Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). "Manifesto for Agile Software Development". Agile Alliance. Retrieved 14 June 2010.{{cite web}}: CS1 maint :url-status (링크)
  6. ^ Which is better – Kanban or Scrum?, 4 March 2016
  7. ^ a b Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. Addison-Wesley. p. 27. ISBN 978-0-13-111155-4.
  8. ^ Dybå, Tore; Dingsøyr, Torgeir (1 August 2008). "Empirical studies of agile software development: A systematic review". Information and Software Technology. 50 (9–10): 833–859. doi:10.1016/j.infsof.2008.01.006. ISSN 0950-5849.
  9. ^ Lee, Gwanhoo; Xia, Weidong (2010). "Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data on Software Development Agility". MIS Quarterly. 34 (1): 87–114. doi:10.2307/20721416. JSTOR 20721416. S2CID 26477249.
  10. ^ 제럴드 M. Weinberg는 Larman & Basili 2003 페이지 47-56에서 인용한 바와 같이, "우리는 IBM Service Bureau Corporation의 Bernie Dimsdale의 지시 하에 1957년 로스앤젤레스에서 증분 개발을 수행했습니다.그는 John von Neumann의 동료였다. 그래서 아마도 그는 그곳에서 그것을 배웠거나, 완전히 자연스러운 것으로 생각했을 것이다.Herb Jacobs(주로 우리 모두가 참여하긴 했지만)가 Motorola를 위해 대규모 시뮬레이션을 개발했던 것으로 기억합니다. 제가 알기로는 이 기술이 사용되었습니다.내가 기억하는 한, 우리 모두는 거대한 프로젝트의 폭포가 다소 어리석거나 최소한 현실을 모른다고 생각했다.폭포의 묘사가 우리에게 가져다 준 것은 우리가 '소프트웨어 개발'을 제외하고 이름 없는 무언가를 하고 있다는 것을 깨닫게 해준 것이라고 생각합니다.'"
  11. ^ "Evolutionary Project Management (Original page, external archive)". Gilb. Archived from the original on 27 March 2016. Retrieved 30 April 2017.
  12. ^ "Evolutionary Project Management (New page)". Gilb. Retrieved 30 April 2017.
  13. ^ Edmonds, E. A. (1974). "A Process for the Development of Software for Nontechnical Users as an Adaptive System". General Systems. 19: 215–18.
  14. ^ Gilb, Tom (1 April 1981). "Evolutionary development". ACM SIGSOFT Software Engineering Notes. 6 (2): 17. doi:10.1145/1010865.1010868. S2CID 33902347.
  15. ^ Swamidass, P. M., ed. (2000), "Heavyweight project organizationHEAVYWEIGHT PROJECT ORGANIZATION", Encyclopedia of Production and Manufacturing Management, Boston, MA: Springer US, pp. 261–262, doi:10.1007/1-4020-0612-8_400, ISBN 978-1-4020-0612-8, retrieved 22 June 2022
  16. ^ Martin, James (1991). Rapid Application Development. Macmillan. ISBN 978-0-02-376775-3.
  17. ^ Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less. McGraw-Hill. p. 3. ISBN 978-0-07-034223-1.
  18. ^ Iacocca Institute(1991)"21세기 제조 기업 전략:업계 주도형 뷰"이아코카 연구소, 리하이 대학, 베들레헴, 펜실베이니아 주
  19. ^ 프레슬리, A., J. 밀스, D.라일즈(1995).'기민한 항공우주 제조.넵콘 이스트 1995, 보스턴
  20. ^ Sanchez, Luis (November 2010). "A Review of Agile Manufacturing Systems". International Journal of Production Research (39(16):3561-3600).
  21. ^ Anderson, David (2005). "Declaration of Interdependence". Archived from the original on 27 January 2018. Retrieved 4 October 2018.
  22. ^ McDonald, Kent (1 November 2016). "How You Can Help Agile Alliance Help You". Agile Alliance Blog. Retrieved 4 July 2017.
  23. ^ "Examining the Agile Manifesto". Ambysoft Inc. Retrieved 6 April 2011.
  24. ^ Jim Highsmith (2001). "History: The Agile Manifesto". agilemanifesto.org.
  25. ^ a b Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). "Principles behind the Agile Manifesto". Agile Alliance. Archived from the original on 14 June 2010. Retrieved 6 June 2010.
  26. ^ Moran, A. (2014). Agile Risk Management. Springer Verlag. ISBN 978-3319050072.
  27. ^ Beck, Kent (1999). "Embracing Change with Extreme Programming". Computer. 32 (10): 70–77. doi:10.1109/2.796139.
  28. ^ Mergel, Ines (July 2016). "Agile innovation management in government: A research agenda". Government Information Quarterly. 33 (3): 516–523. doi:10.1016/j.giq.2016.07.004.
  29. ^ Preuss, Deborah Hartmann (13 October 2006). "Study: Co-Located Teams vs. the Cubicle Farm". InfoQ. Retrieved 23 October 2018.
  30. ^ Cockburn, Alistair (2007). "Agile Software Development: The Cooperative Game". www.pearson.com (2nd ed.). Addison-Wesley Professional. Retrieved 23 October 2018.
  31. ^ "Management Transformed Research".
  32. ^ Jain, Parita; Sharma, Arun; Ahuja, Laxmi (August 2018). "The Impact of Agile Software Development Process on the Quality of Software Product". 2018 7th International Conference on Reliability, Infocom Technologies and Optimization (Trends and Future Directions) (ICRITO). Noida, India: IEEE: 812–815. doi:10.1109/ICRITO.2018.8748529. ISBN 978-1-5386-4692-2. S2CID 195775457.
  33. ^ Cockburn, Alistair (19 June 2008). "Information radiator".
  34. ^ Ambler, Scott (12 April 2002). Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process. John Wiley & Sons. pp. 12, 164, 363. ISBN 978-0-471-20282-0.
  35. ^ Vasiliauskas, Vidas (2014). "Developing agile project task and team management practices". Eylean. Archived from the original on 15 September 2014. Retrieved 15 September 2014.
  36. ^ Jeffries, Ron; Anderson, Ann; Hendrickson, Chet (2001). Extreme Programming installed. Addison-Weslsy. pp. 72–147. ISBN 978-0201-70842-4.
  37. ^ Lisa Crispin; Janet Gregory (2009). Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley.
  38. ^ Mitchell, Ian (2016). Agile Development in Practice. Tamare House. p. 11. ISBN 978-1-908552-49-5.
  39. ^ Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. Addison-Wesley. p. 27. ISBN 978-0-13-111155-4.
  40. ^ Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6. 부록 A, 165-194페이지
  41. ^ Larman, Craig (2004). "Chapter 11: Practice Tips". Agile and Iterative Development: A Manager's Guide. p. 253. ISBN 9780131111554. Retrieved 14 October 2013.
  42. ^ Sliger, Michele; Broderick, Stacia (2008). The Software Project Manager's Bridge to Agility. Addison-Wesley. p. 46. ISBN 978-0-321-50275-9.
  43. ^ a b Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. pp. 55–57. ISBN 978-0-321-18612-6.
  44. ^ Rakitin, Steven R. (2001). "Manifesto Elicits Cynicism: Reader's letter to the editor by Steven R. Rakitin". IEEE Computer. 34 (12): 4. doi:10.1109/MC.2001.10095. S2CID 221106984. The article titled 'Agile Software Development: The Business of Innovation' ... is yet another attempt to undermine the discipline of software engineering ... We want to spend all our time coding. Remember, real programmers don't write documentation.
  45. ^ a b Scott Ambler. "Agile/Lean Documentation: Strategies for Agile Software Development".
  46. ^ Scott Ambler. "Just Barely Good Enough Models and Documents: An Agile Best Practice".
  47. ^ Geoffrey Wiseman (18 July 2007). "Do Agile Methods Require Documentation?". InfoQ. 견적
  48. ^ a b c Abrahamson P, Salo O, Ronkainen J, Warsta J (2002). Agile software development methods: Review and analysis (PDF) (Technical report). VTT. 478.
  49. ^ "Guide to Agile Practices". the Agile Alliance. Archived from the original on 9 February 2014.
  50. ^ a b Aydin, M.N.; Harmsen, F.; Slooten; Stagwee, R. A. (2004). "An Agile Information Systems Development Method in use". Turk J Elec Engin. 12 (2): 127–138.
  51. ^ Morris, David (2015). The Paradox of Agile Transformation: Why trying too hard to be Agile stops organisations from becoming truly agile. NZ: University of Auckland. doi:10.13140/RG.2.2.32698.08640.
  52. ^ Abrahamson, P., Warsta, J., Siponen, M.T. 및 Ronkainen, J.(2003)신속한 변화를 위한 새로운 방법: 비교 분석.ICSE '03, 244-254의 절차
  53. ^ Mirakhorli, M.; Rad, A.K.; Shams, F.; Pazoki, M.; Mirakhorli, A. (2008). "RDP technique: a practice to customize xp". Proceedings of the 2008 international workshop on Scrutinizing agile practices or shoot-out at the agile corral (APOS '08). ACM. pp. 23–32. doi:10.1145/1370143.1370149. ISBN 978-1-60558-021-0. S2CID 9528636.
  54. ^ Schwaber, K (2006) Scrum은 딱딱하고 파괴적이다.
  55. ^ Vodde, B (2016) The Story of LeSS.클로징 키노트스크럼 오스트레일리아, 멜버른2016년 4월
  56. ^ A. 라그스테트와 T. 달버그(2018).ISD 방법 선택의 희귀성 이해– 한정적 합리성과 기능적 우둔성PACIS 2018 Proceedings. 154. https://aisel.aisnet.org/pacis2018/154.
  57. ^ Park, J. S., McMahon, P. E., Myburgh, B.에센스로 구동되는 스크럼.ACM SIGSOFT 소프트웨어 엔지니어링 노트, 41 (1) 페이지 1~8.
  58. ^ Beck, K. (1999). Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley. ISBN 978-0-321-27865-4.
  59. ^ Evans, Ian. "Agile Delivery at British Telecom". Retrieved 21 February 2011.
  60. ^ a b W. Scott Ambler (2006) Dobb's Journal, 2006년 2월 15일자 Supersize Me.
  61. ^ 샤프, R.J. (2007)애자일리티 XL 시스템 및 소프트웨어 기술 컨퍼런스 2007 2016년 3월 13일 플로리다 주 Tampa의 Wayback Machine에서 아카이브
  62. ^ "Bridging the Distance". Sdmagazine.com. Retrieved 1 February 2011.
  63. ^ Fowler, Martin. "Using an Agile Software Process with Offshore Development". Martinfowler.com. Retrieved 6 June 2010.
  64. ^ 신속한 변화를 위한 프로세스 워크숍 II 여러 개의 신속한 변화를 위한 프로젝트 관리워싱턴: OOPSLA 2002
  65. ^ Cawley, Oisín; Wang, Xiaofeng; Richardson, Ita (2010). Abrahamsson, Pekka; Oza, Nilay (eds.). Lean/Agile Software Development Methodologies in Regulated Environments – State of the Art. Lean Enterprise Software and Systems. Lecture Notes in Business Information Processing. Vol. 65. pp. 31–36. doi:10.1007/978-3-642-16416-3_4. hdl:10344/683. ISBN 978-3-642-16415-6.
  66. ^ McHugh, Martin; McCaffery, Fergal; Coady, Garret (4 November 2014). Mitasiunas, Antanas; Rout, Terry; O'Connor, Rory V.; et al. (eds.). An Agile Implementation within a Medical Device Software Organisation. Software Process Improvement and Capability Determination. Communications in Computer and Information Science. Vol. 477. pp. 190–201. doi:10.1007/978-3-319-13036-1_17. ISBN 978-3-319-13035-4.
  67. ^ Wang, Yang; Ramadani, Jasmin; Wagner, Stefan (29 November 2017). An Exploratory Study on Applying a Scrum Development Process for Safety-Critical Systems. Product-Focused Software Process Improvement. Lecture Notes in Computer Science. Vol. 10611. pp. 324–340. arXiv:1703.05375. Bibcode:2017arXiv170305375W. doi:10.1007/978-3-319-69926-4_23. ISBN 9783319699257. S2CID 4585465.
  68. ^ "SafeScrum - SINTEF". Sintef.no. Retrieved 26 March 2019.
  69. ^ Thor Myklebust, Tor Stolhane, Geir Kjetil Hansen, Tormod Wien 및 Börge Haugset: 스크럼, 문서 및 IEC 61508-3:2010 소프트웨어 표준, http://www.sintef.no/globalassets/ec-61508-documentation-and-safescrum-psam12.pdf
  70. ^ Fitzgerald, B.; Stol, K.-J.; O'Sullivan, R.; O'Brien, D. (May 2013). Scaling agile methods to regulated environments: An industry case study. 2013 35th International Conference on Software Engineering (ICSE). pp. 863–872. doi:10.1109/ICSE.2013.6606635. hdl:10344/3055. ISBN 978-1-4673-3076-3. S2CID 192403.
  71. ^ Beck, Kent (2000). Extreme Programming Explained. Addison-Wesley. pp. 1–24. ISBN 978-0201616415.
  72. ^ Datta, Subhajit (2006). "Agility measurement index: a metric for the crossroads of software development methodologies". ACM-SE 44 Proceedings of the 44th annual Southeast regional conference. p. 271. doi:10.1145/1185448.1185509. ISBN 1595933158.
  73. ^ Peter Lappo; Henry C.T. Andrew. "Assessing Agility" (PDF). Archived from the original (PDF) on 15 September 2009. Retrieved 6 June 2010.
  74. ^ Joe Little (2 December 2007). "Nokia test, A scrum-specific test". Agileconsortium.blogspot.com. Retrieved 6 June 2010.
  75. ^ Mark Seuffert; Mayberg, Sweden. "Karlskrona test, A generic agile adoption test". Mayberg.se. Retrieved 5 April 2014.
  76. ^ "How Agile Are You? (Take This 42 Point Test)". allaboutagile.com/. Archived from the original on 5 May 2014. Retrieved 3 April 2014.
  77. ^ "Agile Methodologies Survey Results" (PDF). Shine Technologies. January 2003. Archived from the original (PDF) on 21 August 2010. Retrieved 3 June 2010. 95% stated that there was either no effect or a cost reduction ... 93% stated that productivity was better or significantly better ... 88% stated that quality was better or significantly better ... 83% stated that business satisfaction was better or significantly better
  78. ^ "2013 State of Agile report: Why Agile?". stateofagile.com. 27 January 2014. Archived from the original on 28 August 2014. Retrieved 13 August 2014.
  79. ^ StatusQu Agile, 신속한 변화를 위한 방법의 성공과 형태에 대한 두 번째 연구.2015년 7월 1일 취득
  80. ^ Ambler, Scott (3 August 2006). "Survey Says: Agile Works in Practice". Dr. Dobb's. Retrieved 3 June 2010. Only 6% indicated that their productivity was lowered ... No change in productivity was reported by 34% of respondents and 60% reported increased productivity ... 66% [responded] that the quality is higher ... 58% of organizations report improved satisfaction, whereas only 3% report reduced satisfaction.
  81. ^ "Answering the "Where is the Proof That Agile Methods Work" Question". Agilemodeling.com. 19 January 2007. Retrieved 2 April 2010.
  82. ^ Shore & Warden 2008, 47페이지
  83. ^ Beck, Kent (2000). Extreme Programming Explained. Addison-Wesley. pp. 48–49. ISBN 978-0201616415.
  84. ^ Rouse, Margaret. "Sprint (software development) definition". searchsoftwarequality.techtarget.com. Retrieved 2 October 2015.
  85. ^ Goldstein, Ilan (11 October 2011). "Sprint issues – when sprints turn into crawls". www.axisagile.com.au. Retrieved 8 June 2014.
  86. ^ "Project Roles and Responsibility Distribution". agile-only.com. Retrieved 15 June 2014.
  87. ^ Bourne, Lynda. "What Does a Project Sponsor Really Do?". blogs.pmi.org. Archived from the original on 7 June 2014. Retrieved 8 June 2014.
  88. ^ "9th State of Agile Report". Stage of Agile Survey. VersionOne. Archived from the original on 12 January 2015. Retrieved 8 June 2014.
  89. ^ Sims, Chris; Johnson, Hillary Louise (15 February 2011). The Elements of Scrum (Kindle ed.). Dymaxicon. p. 73.
  90. ^ Rothman, Johanna Rothman (25 August 2011). "When You Have No Product Owner at All". www.jrothman.com. Retrieved 8 June 2014.
  91. ^ Fox, Alyssa (8 April 2014). "Working on Multiple Agile Teams". techwhirl.com/. Retrieved 14 June 2014.
  92. ^ "Daily Scrum Meeting". www.mountaingoatsoftware.com. Retrieved 14 June 2014.
  93. ^ a b May, Robert. "Effective Sprint Planning". www.agileexecutives.org. Archived from the original on 28 June 2014. Retrieved 14 June 2014.
  94. ^ Berczuk, Steve. "Mission Possible: ScrumMaster and Technical Contributor". www.agileconnection.com. Retrieved 14 June 2014.
  95. ^ "How to Implement Agile Scrum". Retrieved 4 January 2022.
  96. ^ Namta, Rajneesh. "Thoughts on Test Automation in Agile". www.infoq.com. Retrieved 14 June 2014.
  97. ^ a b Band, Zvi (22 March 2014). "Technical Debt + Red October". Retrieved 8 June 2014.
  98. ^ Shore, James. "The Art of Agile Development: Refactoring". www.jamesshore.com. Retrieved 14 June 2014.
  99. ^ "Step 4: Sprint Planning (Tasks)". www.allaboutagile.com. Archived from the original on 29 June 2014. Retrieved 14 June 2014.
  100. ^ George, Claire (3 March 2014). "Why Limiting Your Work-in-Progress Matters". leankit.com. Retrieved 14 June 2014.
  101. ^ "Sprint Planning Meeting". www.mountaingoatsoftware.com. Retrieved 14 June 2014.
  102. ^ McMillan, Keith. "Time, Resources, Scope... and Quality". www.adeptechllc.com. Retrieved 15 June 2014.
  103. ^ "Current study on limitations of Agile". Procedia Computer Science. 78: 291–297. January 2016. doi:10.1016/j.procs.2016.02.056.
  104. ^ a b "The Procurement Call for Agile, What does it mean?". 1 November 2019.
  105. ^ Moran, Alan (2015). Managing Agile: Strategy, Implementation, Organisation and People. Springer. ISBN 978-3-319-16262-1.
  106. ^ 이그제큐티브 브리프, 프로젝트에 최적인 라이프 사이클은?PM Hut.2009년 10월 23일에 액세스.
  107. ^ "Agile Project Management". VersionOne. Retrieved 1 June 2015.
  108. ^ "What is Agile Management?". Project Laneways. Retrieved 1 June 2015.
  109. ^ USAID. "ADS Chapter 201 Program Cycle Operation Policy" 2019년 10월 23일 웨이백 머신에 보관.2017년 4월 19일 취득
  110. ^ 프로젝트 관리 연구소, 프로젝트 관리 지식 기구 가이드(PMBOK 가이드), 제6판
  111. ^ 리체, 장룹(2013).민첩한 혁신.사례 및 응용 연구, n°31.ESSEC-ISIS.ISBN 978-2-36456-091-8
  112. ^ Smith, Preston G (2007). Flexible Product Development. Jossey-Bass. p. 25. ISBN 978-0-7879-9584-3.
  113. ^ Newton Lee (2014). "Getting on the Billboard Charts: Music Production as Agile Software Development," Digital Da Vinci: Computers in Music. Springer Science+Business Media. ISBN 978-1-4939-0535-5.
  114. ^ Moran, Alan (2015). Managing Agile: Strategy, Implementation, Organisation and People. Springer Verlag. ISBN 978-3-319-16262-1.
  115. ^ "애자일 프로그래밍 - 가족을 위한 것"
  116. ^ Larman, Craig; Bas Vodde (13 August 2009). Top Ten Organizational Impediments to Large-Scale Agile Adoption. InformIT.
  117. ^ "Introduction to Hybrid project management". 20 July 2016.
  118. ^ Barlow, Jordan B.; Justin Scott Giboney; Mark Jeffery Keith; David W. Wilson; Ryan M. Schuetzler; Paul Benjamin Lowry; Anthony Vance (2011). "Overview and Guidance on Agile Development in Large Organizations". Communications of the Association for Information Systems. 29 (1): 25–44. doi:10.17705/1CAIS.02902.
  119. ^ Kupersmith, Kupe (4 July 2011). "Agile is a Fad".
  120. ^ a b Kruchten, Philippe (20 June 2011). "Agile's Teenage Crisis?". InfoQ.
  121. ^ Richard Utz, "Against Adminspeak", 고등교육 크로니클, 2020년 6월 24일
  122. ^ Cohn, Mike (2015). Succeeding With Agile. Pearson. pp. 5–10. ISBN 978-0-321-57936-2.

추가 정보

외부 링크