적응 형 S / W 개발-퀵 가이드

애자일이란?

문학적 용어로 "민첩하다"라는 단어는 빠르고 쉽게 움직일 수있는 사람 또는 빠르고 명확하게 생각하고 행동 할 수있는 사람을 의미합니다. 비즈니스에서 "애자일"은 작업을 계획하고 수행하는 방법을 설명하는 데 사용되며 필요에 따라 변경하는 것이 작업의 중요한 부분임을 이해합니다. 비즈니스 "민첩성"은 회사가 항상 시장 변화를 고려할 수있는 위치에 있음을 의미합니다.

소프트웨어 개발에서 "애자일"이라는 용어는 "요구 사항, 기술 및 사람의 변화-변화에 대응하는 능력"을 의미합니다.

애자일 선언

Agile Manifesto는 2001 년 소프트웨어 개발자 팀에 의해 발표되었으며, 변화하는 요구 사항과 고객 참여를 수용하는 개발 팀의 중요성을 강조했습니다.

Agile 선언문은 다음과 같습니다.

우리는 소프트웨어를 개발하고 다른 사람들이 그렇게하도록 도와줌으로써 더 나은 소프트웨어 개발 방법을 찾고 있습니다. 이 작업을 통해 우리는 가치를 얻었습니다.

프로세스 및 도구에 대한 개인 및 상호 작용.
포괄적 인 문서에 대한 작업 소프트웨어.
계약 협상을 통한 고객 협력.
계획에 따라 전환에 응답합니다.

즉, 오른쪽 항목에는 가치가 있지만 왼쪽 항목에는 더 가치가 있습니다.

민첩성의 특징

다음은 민첩성의 특성입니다-

민첩한 소프트웨어 개발의 민첩성은 권한이 부여되고 자체 구성되는 다 분야, 교차 기능 팀으로 전체 팀의 문화에 중점을 둡니다.
그것은 공동의 책임과 책임을 촉진합니다.
효과적인 커뮤니케이션과 지속적인 협업을 촉진합니다.
전체 팀 접근 방식은 지연 및 대기 시간을 방지합니다.
빈번하고 지속적인 전달은 팀이 요구 사항에 맞출 수 있도록 빠른 피드백을 보장합니다.
협업을 통해 구현, 결함 수정 및 변경 수용시 다양한 관점을 적시에 결합 할 수 있습니다.
진행 상황은 지속적이고 지속 가능하며 예측 가능하며 투명성을 강조합니다.

애자일 방법론

Agile 방법의 초기 구현에는 Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development, Dynamic Systems Development Method (DSDM)가 포함됩니다. 애자일 선언문이 2001 년에 발표 된 이후,이를 통칭하여 애자일 방법론이라고합니다.

이 튜토리얼에서는 애자일 방법론을 배웁니다. Adaptive Software Development.

적응 형 소프트웨어 개발이란 무엇입니까?

적응 형 소프트웨어 개발은 적응 형 관행으로의 이동이며, 결정 론적 관행은 복잡한 시스템과 복잡한 환경의 맥락에서 남겨 둡니다. 적응 형 소프트웨어 개발은 복잡한 시스템을 구축하기위한 기술로서 협업과 학습에 중점을 둡니다. RAD (Rapid Application Development) 및 Evolutionary Life Cycles의 모범 사례에서 발전했습니다. 그런 다음 적응 형 소프트웨어 개발이 확장되어 관리를위한 적응 형 접근 방식을 포함하고 추측은 계획을 대체합니다.

Jim Highsmith는 2000 년 Adaptive Software Development에 대한 책을 출판했습니다. Highsmith의 말로-

“적응 형 소프트웨어 개발은 진화 모델과 같이 주기적이며, 점점 더 복잡 해지는 시스템의 예측할 수없는 영역을 반영하여 추측, 협업, 학습이라는 단계 이름을 사용합니다. 적응 개발은 두 가지 주요 방식으로 진화 유산보다 더 나아갑니다. 첫째, 결정론을 출현으로 명시 적으로 대체합니다. 둘째, 라이프 사이클의 변화를 넘어 관리 스타일의 더 깊은 변화로 이어집니다.”

SDLC (Software Development Life Cycle) 모델은 소프트웨어 개발 프로젝트의 각 단계에서 수행되는 활동을 설명하는 프레임 워크입니다.

소프트웨어 개발 수명주기에서 활동은 5 단계로 수행됩니다.

Requirements Gathering− 개발할 소프트웨어에 대한 요구 사항이 수집됩니다. 이러한 요구 사항은 고객 / 사용자가 이해할 수있는 언어로 작성됩니다. 도메인 별 용어가 권장됩니다.
Analysis − 수집 된 요구 사항은 구현 관점에서 분석되고 소프트웨어 사양은 기능 요구 사항 및 비 기능 요구 사항을 모두 포함하도록 작성됩니다.
Design −이 단계에는 개발을 위해 선택한 기술을 기반으로 소프트웨어 아키텍처 및 구현 세부 사항에 도달하는 것이 포함됩니다.
Construction −이 단계에서는 코드가 개발되고, 단위 테스트, 통합, 통합 테스트 및 빌드가 생성됩니다.
Testing− 빌드 된 소프트웨어의 기능 테스트는이 단계에서 수행됩니다. 여기에는 비 기능적 요구 사항 테스트도 포함됩니다.

이러한 활동을 수행하는 방법에는 두 가지가 있습니다.

Prescriptive − 프레임 워크에 정의 된대로 규정 된 방식으로 활동을 수행하는 방법을 제공하는 SDLC 모델.
Adaptive− 따라야 할 특정 규칙과 함께 활동을 수행하는 데 유연성을 제공하는 SDLC 모델. 애자일 방법은 대부분이 접근 방식을 따르며 각 방법에는 규칙이 있습니다. 그러나 적응 형 또는 민첩한 접근 방식을 따른다고해서 어떠한 규율도 따르지 않고 소프트웨어가 개발되는 것은 아닙니다. 이것은 혼돈으로 이어질 것입니다.

특정 SDLC 모델이 좋거나 나쁘다고 말할 수 없다는 것을 이해해야합니다. 그들 각각은 고유의 강점과 약점을 가지고 있으므로 특정 상황에 적합합니다.

프로젝트에 대한 SDLC 모델을 선택할 때 이해해야합니다.

조직 컨텍스트
귀하의 기술 상황
팀 구성
고객 컨텍스트

예를 들어 소프트웨어 개발이 예측 가능한 경우 규범 적 접근 방식을 사용할 수 있습니다. 반면에 소프트웨어 개발을 예측할 수없는 경우 (예 : 요구 사항이 완전히 알려지지 않았거나 개발 팀이 현재 도메인 또는 기술 등에 대해 사전에 노출되지 않은 경우) 적응 형 접근 방식이 최선의 선택입니다.

다음 섹션에서는 업계 전반에 걸쳐 소프트웨어 개발 프로젝트를 실행하는 동안 발전된 가장 널리 사용되는 SDLC 모델을 이해할 수 있습니다. 또한 각각의 강점과 약점, 그리고 어떤 맥락에서 적합한 지 알게 될 것입니다.

Waterfall 모델은 널리 알려져 있고 이해되고 일반적으로 사용되는 고전적인 SDLC 모델입니다. 이는 1970 년 Royce에 의해 도입되었으며 여전히 업계의 다양한 조직에서 소프트웨어 개발을위한 일반적인 접근 방식으로 따르고 있습니다.

Waterfall 모델에서 각 수명주기 단계는 이전 수명주기 단계가 완료된 후에 만 시작할 수 있습니다. 따라서 피드백 루프가없는 선형 모델입니다.

폭포 모델 – 강점

Waterfall 모델의 강점은 다음과 같습니다.

이해하기 쉽고 사용하기 쉽습니다.
경험이없는 개발 팀에게 구조를 제공합니다.
이정표는 잘 알려져 있습니다.
요구 사항 안정성을 설정합니다.
관리 제어 (계획, 모니터링,보고)에 이상적입니다.
비용이나 일정보다 품질이 더 중요 할 때 잘 작동합니다.

폭포 모델 – 약점

Waterfall 모델의 약점 또는 단점은 다음과 같습니다.

이상화-현실과 잘 맞지 않습니다.
비현실적-프로젝트 초기에 정확한 요구 사항을 기대할 수 없습니다.
더 일반적인 탐색 적 개발의 반복적 인 특성을 반영하지 않습니다.
변경이 어렵고 비용이 많이 듭니다.
소프트웨어는 프로젝트가 끝날 때만 제공됩니다. 이로 인해-
- 심각한 결함 발견을 지연시킵니다.
- 쓸모없는 요구 사항을 전달할 가능성.
상당한 관리 오버 헤드로 소규모 팀 및 프로젝트에 비용이 많이들 수 있습니다.
분석가, 설계자, 개발자, 테스터 등 모든 단계에서 숙련 된 리소스가 필요합니다.
테스트는 개발이 완료된 후에 만 시작되며 테스터는 이전 단계에 관여하지 않습니다.
교차 기능 팀의 전문성은 각 단계가 사일로에서 실행되기 때문에 공유되지 않습니다.

폭포 모델을 언제 사용합니까?

다음과 같은 경우 폭포 모델을 사용할 수 있습니다.

요구 사항은 매우 잘 알려져 있습니다.
제품 정의가 안정적입니다.
기술은 잘 알려져 있습니다.
기존 제품의 새 버전.
기존 제품을 새 플랫폼으로 포팅.
구조화 된 교차 기능 팀이있는 대규모 조직.
커뮤니케이션 채널은 조직 내에서 그리고 고객과도 잘 구축되어 있습니다.

진화형 프로토 타이핑 모델

Evolutionary Prototyping 모델을 사용하는 소프트웨어 개발에서 개발자는 요구 사항 단계에서 프로토 타입을 구축합니다. 그런 다음 최종 사용자는 프로토 타입을 평가하고 피드백을 제공합니다. 피드백은 프로토 타입 또는 추가 기능에 대한 수정일 수 있습니다. 피드백을 바탕으로 개발자는 프로토 타입을 더욱 다듬습니다.

따라서 제품은 Prototype → Feedback → Refined Prototype Cycles를 통해 진화하므로 Evolutionary Prototyping이라는 이름이 붙습니다. 사용자가 제품의 기능 및 작업에 만족하면 프로토 타입 코드가 최종 제품 배송에 필요한 표준으로 올라갑니다.

진화 된 프로토 타이핑 모델 – 강점

Evolutionary Prototyping 모델의 장점 또는 장점은 다음과 같습니다.

고객 / 최종 사용자는 프로토 타입을보고 모이면 시스템 요구 사항을 시각화 할 수 있습니다.
개발자는 고객으로부터 학습하므로 도메인 또는 프로덕션 환경에 대한 모호함이 없습니다.
유연한 설계 및 개발이 가능합니다.
프로토 타입과의 상호 작용은 추가로 필요한 기능에 대한 인식을 자극합니다.
예상치 못한 요구 사항 및 요구 사항 변경 사항을 쉽게 수용 할 수 있습니다.
꾸준하고 가시적 인 진행 징후가 생성됩니다.
정확하고 유지 보수가 가능한 최종 제품을 제공합니다.

진화 된 프로토 타이핑 모델 – 약점

Evolutionary Prototyping 모델의 약점 또는 단점은 다음과 같습니다.

모델에서 규정 한 것은 아니지만 코드 및 수정 개발에서 구조화 된 개발을 포기하는 경향이 있습니다.
이 모델은 빠르고 더러운 방법으로 나쁜 평판을 받았습니다.
전반적인 유지 보수 가능성이 간과 될 수 있습니다.
고객은 최종적으로 프로토 타입의 제공을 요청할 수 있으며 개발자가 최종 단계 즉, 최종 제품의 표준화를 실행할 기회를주지 않습니다.
프로젝트는 영원히 계속 될 수 있으며 (지속적인 범위 확장 포함) 경영진은이를 인식하지 못할 수 있습니다.

진화형 프로토 타이핑 모델을 언제 사용해야합니까?

Evolutionary Prototyping 모델을 사용할 수 있습니다.

요구 사항이 불안정하거나 명확히해야 할 때
폭포 모델의 요구 사항 설명 단계로
사용자 인터페이스를 개발하려면
단기 데모 용
신규 또는 독창적 개발 용
신기술 구현 용

Iterative Incremental 모델에서는 처음에 전체 시스템의 부분 구현이 구성되어 결과물 상태가됩니다. 향상된 기능이 추가되었습니다. 결함이있는 경우 이전 배송의 결함이 수정되고 작동중인 제품이 배송됩니다. 이 과정은 전체 제품 개발이 완료 될 때까지 반복됩니다. 이러한 프로세스의 반복을 반복이라고합니다. 모든 반복이 끝날 때마다 제품 증분이 제공됩니다.

반복적 증분 모델 – 강점

반복 증분 모델의 장점 또는 장점은 다음과 같습니다.

우선 순위가 지정된 요구 사항을 먼저 개발할 수 있습니다.
초기 제품 배송이 더 빠릅니다.
고객은 중요한 기능을 조기에 얻습니다.
초기 배송 비용을 낮 춥니 다.
각 릴리스는 제품 증분이므로 고객은 항상 작동중인 제품을 사용할 수 있습니다.
고객은 각 제품 증분에 대한 피드백을 제공 할 수 있으므로 개발 종료시 놀라움을 피할 수 있습니다.
요구 사항 변경 사항을 쉽게 수용 할 수 있습니다.

반복적 증분 모델 – 약점

반복 증분 모델의 단점은 다음과 같습니다.

효과적인 반복 계획이 필요합니다.
필요한 기능을 포함하고 나중에 변경할 수 있도록 효율적인 설계가 필요합니다.
증분 정의를 허용하려면 완전하고 완전한 기능의 시스템을 조기에 정의해야합니다.
일부는 다른 것들이 개발되기 훨씬 전에 개발되기 때문에 잘 정의 된 모듈 인터페이스가 필요합니다.
전체 시스템의 총 비용은 낮지 않습니다.

반복적 증분 모델을 언제 사용합니까?

반복 증분 모델은 다음과 같은 경우에 사용할 수 있습니다.

대부분의 요구 사항은 사전에 알려져 있지만 시간이 지남에 따라 발전 할 것으로 예상됩니다.
요구 사항에 우선 순위가 있습니다.
기본 기능을 빠르게 제공 할 필요가 있습니다.
프로젝트에는 긴 개발 일정이 있습니다.
프로젝트에는 새로운 기술이 있습니다.
도메인은 팀에 새로운 것입니다.

RAD (Rapid Application Development) 모델에는 다음 단계가 있습니다.

Requirements Planning phase − 요구 사항 계획 단계에서는 비즈니스 문제를 체계적으로 논의하기 위해 작업장을 수행해야합니다.
User Description phase − 사용자 설명 단계에서 자동화 된 도구는 사용자로부터 정보를 캡처하는 데 사용됩니다.
Construction phase − 건설 단계에서 코드 생성기, 화면 생성기 등과 같은 생산성 도구는 "완료 될 때까지 수행"접근 방식으로 타임 박스 내에서 사용됩니다.
Cut Over phase − 컷 오버 단계에서는 시스템 설치, 사용자 승인 테스트 및 사용자 교육이 수행됩니다.

신속한 애플리케이션 개발 모델 – 강점

Rapid Application Development 모델의 장점 또는 장점은 다음과 같습니다.

적은 팀원으로 사이클 시간이 단축되고 생산성이 향상되면 비용이 절감됩니다.
전체주기 동안 고객의 참여는 고객 만족도와 비즈니스 가치를 달성하지 못할 위험을 최소화합니다.
포커스는 WYSIWYG (what-you-see-is-what-you-get) 모드의 코드로 이동합니다. 이것은 구축되고있는 것이 옳은 것인지에 대한 명확성을 제공합니다.
모델링 개념을 사용하여 비즈니스, 데이터 및 프로세스에 대한 정보를 캡처합니다.

신속한 애플리케이션 개발 모델 – 약점

Rapid Application Development 모델의 장단점은 다음과 같습니다.

가속화 된 개발 프로세스는 사용자에게 빠른 응답을 제공해야합니다.
폐쇄를 달성하지 못할 위험.
레거시 시스템에서 사용하기 어렵습니다.
개발자와 고객은 단축 된 시간 내에 신속한 활동에 전념해야합니다.

신속한 애플리케이션 개발 모델을 언제 사용해야합니까?

Rapid Application Development 모델은 다음과 같은 경우에 사용할 수 있습니다.

사용자는 라이프 사이클 내내 참여할 수 있습니다.
프로젝트는 시간 제한이있을 수 있습니다.
기능은 증분으로 제공 될 수 있습니다.

Rapid Application Development 모델의 강점은 높이 평가되지만 업계에서는 거의 사용되지 않습니다.

나선형 모델은 폭포 모델에 위험 분석 및 RAD 프로토 타이핑을 추가합니다. 각주기는 Waterfall 모델과 동일한 일련의 단계를 포함합니다.

나선형 모델에는 4 개의 사분면이 있습니다. 자세히 논의하겠습니다.

사분면 1-목표, 대안 및 제약 결정

Objectives − 기능, 성능, 하드웨어 / 소프트웨어 인터페이스, 중요한 성공 요인 등
Alternatives − 구축, 재사용, 구매, 하도급 등
Constraints − 비용, 일정, 인터페이스 등

사분면 2-대안 평가, 위험 식별 및 해결

결정된 목표 및 제약 조건과 관련된 대안을 연구합니다.
경험 부족, 신기술, 빡빡한 일정 등과 같은 위험을 식별합니다.
프로젝트에 미치는 영향을 평가하고 필요한 완화 및 비상 계획을 식별하고이를 구현하는 식별 된 위험을 해결합니다. 위험은 항상 모니터링해야합니다.

사분면 3-차세대 제품 개발

일반적인 활동은 다음과 같습니다.

디자인 만들기
디자인 검토
코드 개발
코드 검사
테스트 제품

4 사분면-다음 단계 계획

일반적인 활동은 다음과 같습니다.

프로젝트 계획 개발
구성 관리 계획 개발
테스트 계획 개발
설치 계획 개발

나선형 모델 – 장점

나선형 방법의 장점 또는 장점은 다음과 같습니다.

많은 비용을 들이지 않고 위험을 조기에 표시합니다.
사용자는 신속한 프로토 타이핑 도구로 인해 시스템을 조기에 볼 수 있습니다.
중요한 고위험 기능이 먼저 개발됩니다.
디자인이 완벽 할 필요는 없습니다.
사용자는 모든 라이프 사이클 단계에 밀접하게 참여할 수 있습니다.
사용자의 초기 및 빈번한 피드백.
자주 평가되는 누적 비용.

나선형 모델 – 약점

나선형 방법의 단점 또는 약점은 다음과 같습니다.

다음 반복을 진행할 준비가되었음을 나타내는 목표, 검증 가능한 이정표를 정의하기 어려울 수 있습니다.
계획, 목표 재설정, 위험 분석 및 프로토 타이핑에 소요되는 시간은 오버 헤드가 될 수 있습니다.
위험을 평가하는 데 소요되는 시간은 작거나 위험이 낮은 프로젝트의 경우 너무 클 수 있습니다.
나선형 모델은 새 팀원이 이해하기 복잡합니다.
위험 평가 전문 지식이 필요합니다.
나선형은 무기한 계속 될 수 있습니다.
개발자는 비 개발 단계 활동 중에 재 할당되어야합니다.

스파이럴 모델을 언제 사용합니까?

Spiral 모델은 다음과 같은 경우에 사용할 수 있습니다.

프로토 타입 제작이 적절합니다.
위험 평가가 중요합니다.
프로젝트는 중간에서 높은 위험 수준입니다.
사용자는 자신의 요구 사항을 잘 모릅니다.
요구 사항은 복잡합니다.
제품 라인이 새로워졌습니다.
탐사 중 상당한 변화가 예상됩니다.
잠재적 인 비즈니스 변화로 인해 장기적인 프로젝트 약속이 현명하지 않습니다.

애자일 방법은 애자일 선언을 기반으로하며 본질적으로 적응 적입니다. 애자일 방법은 다음을 보장합니다.

팀 협업.
고객 협력.
지속적이고 지속적인 커뮤니케이션.
변화에 대한 대응.
작동하는 제품의 준비 상태.

몇 가지 애자일 방법이 등장하여 타임 박스 반복을 통해 반복적이고 점진적인 개발을 촉진했습니다. 애자일 방법은 적응 형이지만 특정 방법의 규칙은 우회 할 수 없으므로 규율적인 구현이 필요합니다.

애자일 방법 – 강점

Agile 방법의 장점 또는 장점은 다음과 같습니다.

초기 및 빈번한 릴리스.
변화하는 요구 사항 수용.
고객과 개발자 간의 일상적인 커뮤니케이션.
동기 부여 된 개인을 중심으로 구축 된 프로젝트.
자기 조직화 팀.
즉시 필요한 것에 초점을 맞춘 단순성.
미래를위한 건물이나 코드에 부담을주지 않습니다.
효과를 향상시키기 위해 행동을 조정하기위한 정기적 인 반성.

애자일 방법 – 약점

Spiral 방법의 단점 또는 단점은 다음과 같습니다.

고객 가용성이 불가능할 수 있습니다.
팀은 방법의 규칙을 따르는 경험이 있어야합니다.
반복에서 제공해야하는 기능을 신속하게 결정하려면 적절한 계획이 필요합니다.
팀은 평가 기술과 협상 기술을 가지고 있어야합니다.
팀은 효과적인 의사 소통 능력이 있어야합니다.
새로운 팀은 스스로 조직하지 못할 수 있습니다.
타임 박스 반복을 개발하고 제공하려면 규율이 필요합니다.
디자인은 단순하고 유지 관리가 가능해야하므로 효과적인 디자인 기술이 필요합니다.

애자일 방법은 언제 사용합니까?

Agile 방법은 다음과 같은 경우에 사용할 수 있습니다.

응용 프로그램은 시간이 중요합니다.
범위가 제한되고 덜 형식적입니다 (애자일 방법을 대규모 프로젝트로 확장하는 중이며 일부 애자일 방법에 대한 특정 확장이 진행 중입니다).
조직은 훈련 된 방법을 사용합니다.

초기 SDLC 모델은 안정성, 예측 가능성 및 수익 감소 관행에 더 중점을 둡니다. 인터넷 플랫폼과 같은 업계는 반품 환경, 예측 불가능하고 비선형 적이며 빠른 접근 방식을 늘리기 위해 움직이고 있습니다.

적응 형 소프트웨어 개발 (ASD)은 이러한 문제를 해결하기 위해 발전했습니다. 경영진의 관점에서 가장 중요한 요소 인 출현에 초점을 맞추고 제품 개발 관리 능력을 강화합니다.

Jim Highsmith의 말에서,“Adaptive Software Development 프레임 워크는 전통적인 소프트웨어 개발 방법론에 대한 수년간의 경험, RAD (Rapid Application Development) 기술에 대한 컨설팅, 실습 및 작성, 제품 개발 관리에 대해 첨단 기술 소프트웨어 회사와 협력 한 경험을 기반으로합니다. 관행”.

폭포 모델은 선형성과 예측 가능성이 특징이며 피드백이 적습니다. 일련의 순서로 볼 수 있습니다.Plan → Build → Implement.

Spiral 모델과 같은 Evolutionary Lifecycle 모델은 결정 론적 접근 방식을 적응 형 접근 방식으로 옮겼습니다. Plan → Build → Revise Cycles.

그러나 실무자의 사고 방식은 장기적인 예측 가능성이 단기적인 예측 가능성으로 바뀌면서 결정 론적이었습니다. RAD와 같은 Evolutionary Lifecycle 모델의 관행은 덜 결정적입니다.

적응 형 라이프 사이클

적응 형 모델은 다른 관점에서 구축됩니다. 진화 모델처럼 주기적이지만 단계의 이름은 점점 더 복잡 해지는 시스템의 예측할 수없는 특성을 반영합니다.

적응 형 개발은 두 가지 주요 방식으로 진화 적 유산보다 더 나아갑니다.

결정론을 Emergence로 명시 적으로 대체합니다.
라이프 사이클의 변화를 넘어 관리 스타일의 더 깊은 변화로 이어집니다.

적응 형 소프트웨어 개발 라이프 사이클의 세 단계는 다음과 같습니다.

Speculate − 추측은 결정 론적 단어 계획, 제품 사양 계획 또는 프로젝트 관리 작업 계획을 대체합니다.
Collaborate − Collaborate는
- 전통적인 프로젝트 관리 감각으로 관리
- 출현에 필요한 협업 환경을 만들고 유지합니다.

협업 활동은 환경 변화 속도를 유지하면서 제품을 구축합니다.

Learn − Learn은 개발자와 고객 모두가 각 개발주기의 결과를 사용하여 다음 방향을 배우는 것을 목표로합니다.

이 장에서는 적응 형 소프트웨어 개발의 다양한 개념을 이해합니다.

복잡한 적응 시스템 (CAS) 이론

산타페 연구소의 Brian Arthur와 그의 동료들은 CAS (복합 적응 시스템) 이론을 사용하여 물리학, 생물학, 진화 및 경제학에 대한 이해를 혁신했습니다.

Brian Arthur는 20 년 이상 주류 경제학자들이 감소하는 수익, 균형, 결정 론적 역동성에 대한 근본적인 가정이 지배하는 그들의 견해가 더 이상 현실을 이해하기에 충분하지 않다는 것을 확신 시키려고 노력하면서 절정에 달했습니다. 새로운 세계는 증가하는 수익, 불안정성, 원인과 결과를 결정할 수없는 것 중 하나입니다.

두 세계는 행동, 스타일 및 문화가 다릅니다. 그들은-

다양한 관리 기법
다양한 전략
다른 이해

복잡한 소프트웨어 개발

소프트웨어 응용 프로그램의 범위가 폭발적으로 증가함에 따라 소프트웨어 개발 조직조차도 위에서 언급 한 것과 유사한 모순을 겪고 있습니다.

One World는 안정성과 예측 가능성의 기본에 뿌리를 둔 경영 관행에서 파생 된 결정 론적 개발로 대표됩니다 (Arthur의 용어로는 수익 감소를 의미 함).
Second World는 예측할 수없고 비선형 적이며 빠른 반품 환경의 감소에서 증가하는 산업으로 대표됩니다.

이 두 번째 세계의 문제를 해결하기 위해 Jig Highsmith는 결정 론적 소프트웨어 개발과는 다른 적응 형 소프트웨어 개발 프레임 워크를 제공했습니다.

적응 형 소프트웨어 개발은 복잡한 시스템을 해결하는 데 중점을 둡니다.

개발 수명주기를위한 적응 형 소프트웨어 개발.
적응 형 관리 기법은 기존의 프로젝트 관리 관행과는 다른 사고 방식을 요구합니다.

이 자습서에서는 이러한 구현을 모두 이해할 수 있습니다.

적응 형 소프트웨어 개발 (ASD)은 두 가지 관점을 기반으로합니다.

이 장의 첫 번째 섹션에 제공된 CAS (복합 적응 시스템) 이론에 기반한 개념적 관점.
실용적 관점
- 결정 론적 소프트웨어 개발 방법론에 대한 수년간의 경험.
- RAD (Rapid Application Development) 기술에 대한 컨설팅, 실습 및 작성 제품 개발을 관리하기 위해 첨단 기술 소프트웨어 회사와 협력합니다.

이 장에서는 적응 형 소프트웨어 개발의 개념적 관점을 이해하게됩니다.

CAS (복합 적응 시스템) 개념

CAS (Complex Adaptive Systems) 이론에는 많은 개념이 있습니다. 적응 형 소프트웨어 개발은 이러한 개념 중 두 가지를 기반으로합니다.

Emergence
Complexity

출현

복잡한 소프트웨어 제품 개발 프로젝트에서 결과는 본질적으로 예측할 수 없습니다. 그러나 성공적인 제품은 항상 이러한 환경에서 나옵니다.

이는 CAS (Complex Adaptive Systems) 이론에 설명 된대로 Emergence에 의해 발생할 수 있습니다. 그것은 새들의 무리를 짓는 행동이라는 간단한 예로 이해할 수 있습니다.

새 무리를 관찰 할 때 다음을 알 수 있습니다.

각 새는
- 다른 새를 포함하여 환경의 다른 물체와 최소 거리를 유지하십시오.
- 주변의 새와 속도를 일치시킵니다.
- 주변에있는 인식 된 새들의 질량 중심으로 이동합니다.
그룹에 대한 행동 규칙은 없습니다. 유일한 규칙은 개별 새의 행동에 관한 것입니다.
그러나 새로운 행동, 즉 새들의 무리가 존재합니다. 잘못된 새가 따라 잡기 위해 서두르면 무리가 장애물 주위로 쪼개지고 반대편에서 개혁됩니다.

이것은 적응 개발에서 가장 어려운 정신 모델 변화의 요구 사항을 보여줍니다. 개인의 자유를 관리하고 조직하는 방법에서 창의적인 새로운 질서가 자발적인 자기 조직화에서 예측할 수없이 출현한다는 개념에 이르기까지.

개발 외에도 경영 관점에서도 출현은 가장 중요한 개념입니다.

복잡성

소프트웨어 개발 맥락에서 복잡성은 약-

개발자, 고객, 공급 업체, 경쟁 업체 및 주주와 같은 팀의 개인, 숫자 및 속도.
크기와 기술적 복잡성.

적응 형 소프트웨어 개발 관행

적응 형 소프트웨어 개발은 소프트웨어 관리 관행에 대해 다른 관점을 제공합니다. 아래 섹션에서 품질과 RAD라는 두 가지 중요한 관행을 이해할 수 있으며, 둘 다 요구 사항 수집에 영향을 미칩니다.

이 자습서의 적응 형 소프트웨어 개발 사례 장에서 모든 사례에 대한 세부 정보를 찾을 수 있습니다.

품질

복잡한 환경에서 "처음부터 올바르게 수행"이라는 오래된 관행은 처음에는 올바른 것이 무엇인지 예측할 수 없기 때문에 작동하지 않습니다. 올바른 가치를 창출하기위한 목표가 있어야합니다. 그러나 복잡한 환경에서는 범위 (기능, 성능, 결함 수준), 일정 및 리소스와 같은 가치 구성 요소의 조합과 순열이 너무 커서 최적의 값이있을 수 없습니다. 따라서 초점은 경쟁 시장에서 최고의 가치를 제공하도록 전환하는 것입니다.

RAD 관행

RAD Practices는 일반적으로 다음과 같은 조합을 포함합니다.

진화하는 라이프 사이클
고객 포커스 그룹, JAD 세션, 기술 리뷰
타임 박스 프로젝트 관리
지속적인 소프트웨어 엔지니어링
전쟁 실이있는 전용 팀

RAD 프로젝트는 고유 한 적응 형, 창발적인 풍미를 가지고 있습니다. 많은 IT 조직이 RAD에 반대합니다. 그러나 Microsoft와 다른 회사는 근본적인 세계관에 대한 의문을 제기하기 때문에 RAD에 필적하는 기술을 사용하여 엄청나게 크고 복잡한 소프트웨어를 제작했습니다.

RAD 관행과 Microsoft 프로세스는 모두 실행중인 적응 형 개발의 예입니다. 그들에게 레이블 (즉, 적응 형 개발)을 부여하고 과학적 지식 (즉, CAS 이론)이 증가하고 있다는 사실을 깨닫는 것이 작동하는 이유를 설명합니다. 이는 이러한 관행을보다 광범위하게 사용할 수있는 기반을 제공해야합니다.

적응 형 소프트웨어 개발은 RAD 관행에서 발전했습니다. 팀 측면도 이러한 관행에 추가되었습니다. 뉴질랜드에서 캐나다에 이르기까지 다양한 프로젝트 및 제품 유형에 대한 회사는 적응 형 소프트웨어 개발을 사용했습니다.

Jim Highsmith는 2000 년 Adaptive Software Development를 출판했습니다.

적응 형 소프트웨어 개발 관행은 변화를 수용 할 수있는 능력을 제공하고 거의 계획과 학습없이 진화하는 제품으로 격동적인 환경에서 적응할 수 있습니다.

ASD 수명주기의 단계

적응 형 소프트웨어 개발은 복잡한 시스템의 예측 불가능 성을 반영하는 단계 이름과 함께 진화 모델과 같이 주기적입니다. 적응 형 개발 수명주기의 단계는 다음과 같습니다.

Speculate
Collaborate
Learn

These three phases reflect the dynamic nature of Adaptive Software Development. The Adaptive Development explicitly replaces Determinism with Emergence. It goes beyond a mere change in lifecycle to a deeper change in management style. Adaptive Software Development has a dynamic Speculate-Collaborate-Learn Lifecycle.

The Adaptive Software Development Lifecycle focuses on results, not tasks, and the results are identified as application features.

Speculate

The term plan is too deterministic and indicates a reasonably high degree of certainty about the desired result. The implicit and explicit goal of conformance to plan, restricts the manager's ability to steer the project in innovative directions.

In Adaptive Software Development, the term plan is replaced by the term speculate. While speculating, the team does not abandon planning, but it acknowledges the reality of uncertainty in complex problems. Speculate encourages exploration and experimentation. Iterations with short cycles are encouraged.

Collaborate

Complex applications are not built, they evolve. Complex applications require that a large volume of information be collected, analyzed, and applied to the problem. Turbulent environments have high rates of information flow. Hence, complex applications require that a large volume of information be collected, analyzed, and applied to the problem. This results in diverse Knowledge requirements that can only be handled by team collaboration.

Collaborate would require the ability to work jointly to produce results, share knowledge or make decisions.

In the context of project management, Collaboration portrays a balance between managing with traditional management techniques and creating and maintaining the collaborative environment needed for emergence.

Learn

The Learn part of the Lifecycle is vital for the success of the project. Team has to enhance their knowledge constantly, using practices such as −

Technical Reviews
Project Retrospectives
Customer Focus Groups

Reviews should be done after each iteration. Both, the developers and customers examine their assumptions and use the results of each development cycle to learn the direction of the next. The team learns −

About product changes
More fundamental changes in underlying assumptions about how the products are being developed

The iterations need to be short, so that the team can learn from small rather than large mistakes.

Speculate - Collaborate - Learn Cycle as a Whole

As you observe from the Speculate-Collaborate-Learn cycle, given above, it is obvious that the three phases are nonlinear and overlap.

We observe the following from an Adaptive framework.

It is difficult to Collaborate without Learning or to Learn without Collaborating.
It is difficult to Speculate without Learning or to Learn without Speculating.
It is difficult to Speculate without Collaborating or to Collaborate without Speculating.

Adaptive Software Development Lifecycle has six basic characteristics −

Mission focused
Feature based
Iterative
Time-boxed
Risk driven
Change tolerant

In this chapter, you will understand these six characteristics of Adaptive Software Development.

Mission-focused

For many projects, the overall mission that guides the team is well articulated, though the requirements may be uncertain at the beginning of the project. Mission statements act as guides that encourage exploration in the beginning but have a narrow focus over the course of a project. A mission provides boundaries rather than a fixed destination. Mission statements and the discussions that result in those statements provide direction and criteria for making critical project tradeoff decisions.

Without a clear mission and a constant mission refinement practice, iterative lifecycles become oscillating lifecycles, swinging back and forth with no progress in the development.

Feature-based

The Adaptive Software Development Lifecycle is based on application features and not on tasks. Features are the functionality that are developed during an iteration based on the customer’s priorities.

Features can evolve over several iterations when the customers provide feedback.

The application features that provide direct results to the customer after implementation are primary. A customer-oriented document such as a user manual is also considered as a feature. The other documents such as the data model, even if defined as deliverables are always secondary.

Iterative

The Adaptive Software Development Lifecycle is iterative and focuses on frequent releases in order to obtain feedback, assimilate the resulting learning and setting the right direction for further development.

Time-boxed

In Adaptive Software Development Lifecycle, the iterations are time-boxed. However, one should remember that time-boxing in Adaptive Software Development is not about time deadlines. It should not be used to make the team work for long hours challenging a collaborative environment or for compromising on the quality of the deliverables.

In Adaptive Software Development, time-boxing is considered as a direction for focusing and forcing hard tradeoff decisions as and when required. In an uncertain environment, in which change rates are high, there needs to be a periodic forcing function such as a timebox to get the work finished.

Risk-driven

In Adaptive Software Development, the iterations are driven by identifying and evaluating the critical risks.

Change-tolerant

Adaptive Software Development is change-tolerant, viewing change as the ability to incorporate competitive advantage, but not as a problem for development.

The Adaptive Software Development practices are driven by a belief in continuous adaptation, with the lifecycle equipped to accepting continuous change as the norm.

Adaptive Software Development Lifecycle is dedicated to −

Continuous learning
Change orientation
Re-evaluation
Peering into an uncertain future
Intense collaboration among developers, management, and customers

Adaptive SDLC

Adaptive Software Development combines RAD with Software Engineering Best Practices, such as −

Project initiation.
Adaptive cycle planning.
Concurrent component engineering.
Quality review.
Final QA and release.

Adaptive Software Development practices can be illustrated as follows −

As illustrated above, Adaptive Software Development practices are spread across the three phases as follows −

Speculate − Initiation and planning
- Project Initiation
- Establishing time-box for the entire project
- Decide on the number of iterations and assign a time-box to each one
- Develop a theme or objective for each of the iterations
- Assign features to each iteration
Collaborate − Concurrent feature development
- Collaboration for distributed teams
- Collaboration for smaller projects
- Collaboration for larger projects
Learn − Quality Review
- Result quality from the customer's perspective
- Result quality from a technical perspective
- The functioning of the delivery team and the practices team members are utilizing
- The project status

Speculate - Initiation and Planning

In Adaptive Software Development, the speculate phase has two activities −

Initiation
Planning

Speculate has five practices that can be executed repetitively during the initiation and planning phase. They are −

Project initiation
Establishing time-box for the entire project
Decide on the number of iterations and assign a time-box to each one
Develop a theme or objective for each of the iterations
Assign features to each iteration

Project Initiation

Project Initiation involves −

Setting the project's mission and objectives
Understanding constraints
Establishing the project organization
Identifying and outlining requirements
Making initial size and scope estimates
Identifying key project risks

The project initiation data should be gathered in a preliminary JAD session, considering speed as the major aspect. Initiation can be completed in a concentrated two to five day effort for a small to medium sized projects, or two to three weeks effort for larger projects.

During the JAD sessions, requirements are gathered in enough detail to identify features and establish an overview of the object, data, or other architectural model.

Establishing Time-box for the Entire Project

The time-box for the entire project should be established, based on the scope, feature-set requirements, estimates, and resource availability that result from project initiation work.

As you know, Speculating does not abandon estimating, but it just means accepting that estimates can go wrong.

Iterations and Time-box

Decide on the number of iterations and the individual iteration lengths based on the overall project scope and the degree of uncertainty.

For a small to medium sized application −

Iterations usually vary from four to eight weeks.
Some projects work best with two-week iterations.
Some projects might require more than eight weeks.

Choose the time, based on what works for you. Once you decide on the number of iterations and the lengths of each of the iterations, assign a schedule to each of the iterations.

Develop a Theme or Objective

The team members should develop a theme or objective for each iteration. This is something similar to the Sprint Goal in Scrum. Each iteration should deliver a set of features that can demonstrate the product functionality making the product visible to the customer to enable review and feedback.

Within the iterations, the builds should deliver working features on a preferably daily basis enabling integration process and making the product visible to the development team. Testing should be an ongoing, integral part of the feature development. It should not be delayed until the end of the project.

Assign Features

Developers and customers should together assign features to each iteration. The most important criteria for this feature assignment is that every iteration must deliver a visible set of features with considerable functionality to the customer.

During the assignment of features to the iterations −

Development team should come up with the feature estimates, risks, and dependencies and provide them to the customer.
Customers should decide on feature prioritization, using the information provided by the development team.

Thus iteration planning is feature-based and done as a team with developers and customers. Experience has shown that this type of planning provides better understanding of the project than a task-based planning by the project manager. Further, feature-based planning reflects the uniqueness of each project.

Collaborate ─ Concurrent Feature Development

During the Collaborate phase, the focus is on the development. The Collaborate phase has two activities −

The Development team collaborate and deliver working software.
The project managers facilitate collaboration and concurrent development activities.

Collaboration is an act of shared creation that encompasses the development team, the customers and the managers. Shared creation is fostered by trust and respect.

Teams should collaborate on −

Technical problems
Business requirements
Rapid decision making

Following are the practices relevant to the Collaborate phase in Adaptive Software Development −

Collaboration for distributed teams
Collaboration for smaller projects
Collaboration for larger projects

Collaboration for Distributed Teams

In the projects involving distributed teams, the following should be considered −

Varying alliance partners
Broad-based knowledge
The way people interact
The way they manage interdependencies

Collaboration for Smaller Projects

In the smaller projects, when team members are working in physical proximity, Collaboration with informal hallway chats and whiteboard scribbling should be encouraged, as this is found to be effective.

Collaboration for Larger Projects

Larger projects require additional practices, collaboration tools, and project manager interaction and should be arranged on the contextual basis.

배우기-품질 검토

적응 형 소프트웨어 개발은 '실험 및 학습'개념을 장려합니다.

실수와 실험을 통해 학습하려면 팀 구성원이 부분적으로 완성 된 코드와 아티팩트를 일찍 공유해야합니다.

실수 찾기
그들로부터 배우십시오
큰 문제가되기 전에 작은 문제를 찾아 재 작업을 줄입니다.

각 개발 반복이 끝날 때 배워야 할 4 가지 일반적인 범주가 있습니다.

고객의 관점에서 본 결과 품질
기술적 관점에서의 결과 품질
전달 팀과 실무팀의 기능
프로젝트 상태

고객의 관점에서 본 결과 품질

적응 형 소프트웨어 개발 프로젝트에서는 고객의 피드백을받는 것이 최우선 과제입니다. 이를 위해 권장되는 방법은 고객 포커스 그룹입니다. 이 세션은 애플리케이션의 작동 모델을 탐색하고 고객 변경 요청을 기록하도록 설계되었습니다.

고객 포커스 그룹 세션은 jad 세션과 유사한 촉진 세션이지만 요구 사항을 생성하거나 프로젝트 계획을 정의하는 대신 애플리케이션 자체를 검토하도록 설계되었습니다. 고객은 반복으로 인해 작동하는 소프트웨어에 대한 피드백을 제공합니다.

기술적 관점에서 본 결과 품질

적응 형 소프트웨어 개발 프로젝트에서는 기술 아티팩트에 대한주기적인 검토가 중요합니다. 코드 검토는 지속적으로 수행되어야합니다. 기술 아키텍처와 같은 다른 기술 아티팩트에 대한 검토는 매주 또는 반복이 끝날 때 수행 할 수 있습니다.

적응 형 소프트웨어 개발 프로젝트에서 팀은 주기적으로 자체 성능을 모니터링해야합니다. 회고전은 팀이 팀으로서 함께 자신과 작업에 대해 배우도록 권장합니다.

반복 종료 회고는 다음과 같은 정기적 인 팀 성과 자체 검토를 용이하게합니다.

작동하지 않는 항목을 확인하십시오.
팀이 더 많은 일을하기 위해 필요한 것.
팀이 덜하기 위해 필요한 것.

프로젝트 상태

프로젝트 상태 검토는 추가 작업을 계획하는 데 도움이됩니다. 적응 형 소프트웨어 개발 프로젝트에서 프로젝트 상태를 결정하는 것은 기능 기반 접근 방식이며, 각 반복의 끝은 완료된 기능으로 표시되어 소프트웨어가 작동합니다.

프로젝트 상태 검토에는 다음이 포함되어야합니다.

프로젝트는 어디에 있습니까?
프로젝트와 계획은 어디에 있습니까?
프로젝트는 어디에 있어야합니까?

적응 형 소프트웨어 개발 프로젝트의 계획은 추론 적이므로 위의 질문 2보다 3 번 질문이 중요합니다. 즉, 프로젝트 팀과 고객은 계속해서 스스로에게 "지금까지 배운 것이 무엇인지, 그리고 그것이 우리가 가야 할 방향에 대한 우리의 관점을 바꾸는가?"라고 스스로에게 물어야합니다.

기존 소프트웨어 관리의 흐름도는 다음과 같습니다.

전통적인 소프트웨어 관리는 명령 제어라는 용어가 특징입니다.

많은 조직이 최적화, 효율성, 예측 가능성, 제어, 엄격함 및 프로세스 개선의 전통에 빠져 있습니다. 그러나 신흥 정보화 시대 경제는 적응성, 속도, 협업, 즉흥성, 유연성, 혁신 및 유연성을 필요로합니다.

Harvard 비즈니스 리뷰 및 관리 책은 권한 부여, 참여 관리, 학습 조직, 인간 중심 관리 등과 같은 용어를 제시했지만 이들 중 어느 것도 현대 조직을 관리하는 데 적용되지 않습니다.

적응 형 소프트웨어 개발의 맥락에서 그 격차는 훨씬 더 넓어 보이며 다른 분야에서 성공적으로 입증 된 적응 형 관리 기술을 고려해야합니다.

적응 형 관리

적응 형 관리는 자원 관리자가 이해 관계자 및 과학자와 팀으로 함께 작업하는 환경에서 성공적으로 입증되었으며 다음 목표를 가지고 있습니다.

관리되는 시스템이 사람의 개입에 어떻게 반응하는지 알아보기.
향후 자원 정책 및 관행을 개선합니다.

적응 형 관리의 기본 원칙은 많은 자원 관리 활동이 결과를 미리 예측할 수 없기 때문에 실험이라는 것입니다. 이러한 실험은 향후 개선을위한 학습 기회로 사용됩니다.

적응 형 관리는 새로운 정보와 다양한 이해 관계자의 목표 및 선호도 설정에 대해 적시에 대응할 수있는 능력을 높이기위한 것입니다. 이해 관계자가 분쟁을 묶고 질서있게 논의하도록 장려하며 환경 불확실성을 조사하고 더 잘 이해하고 있습니다.

적응 형 관리는 이해 관계자와 관리자 및 기타 의사 결정자가 지식의 한계와 불완전한 정보에 대해 조치를 취할 필요성을 인식하도록 도와줍니다.

적응 형 관리는 다음 사항을 명확히함으로써 내린 결정을 변경하는 데 도움이됩니다.

결정은 잠정적입니다.
경영진의 결정이 항상 옳을 필요는 없습니다.
수정이 예상됩니다.

적응 형 관리 방식에는 두 가지 유형이 있습니다.

수동적 적응 관리.
능동적 적응 관리.

패시브 적응 관리

적응 형 관리는 과학적 지식을 향상시켜 불확실성을 줄이는 것을 목표로합니다.

수동적 적응 관리 내에서 기존 정보와 이해를 바탕으로 선호하는 단일 작업 과정이 선택됩니다. 관리 조치의 결과를 모니터링하고 그 결과에 따라 후속 결정을 조정합니다.

이 접근 방식은 학습 및 효과적인 관리에 기여합니다. 그러나 선택한 조치 과정을 넘어서는 조건에 대한 과학 및 관리 능력을 향상시키는 능력이 제한됩니다.

능동적 적응 관리

Active Adaptive 관리 방식은 관리 조치를 취하기 전에 정보를 검토합니다.

그런 다음 단일 모델이 아닌 생태계 및 관련 반응 (예 : 인구 통계 학적 변화, 레크리에이션 사용)의 다양한 경쟁적인 대체 시스템 모델이 개발됩니다. 관리 옵션은 이러한 대체 모델의 평가를 기반으로 선택됩니다.

리더십-협업 관리

적응 형 관리는 적응 형 소프트웨어 개발에 가장 적합한 것입니다. 접근 방식에는 자원 관리자, 즉 사람과 함께 일하고 사람의 개입을 허용하며 우호적 인 환경을 조성 할 수있는 관리자가 필요합니다.

소프트웨어 개발에서 리더는 종종 이러한 책임을 맡습니다. 우리는 지휘관보다 지도자가 더 필요합니다. 리더는 협력자이며 팀과 함께 일합니다. 협업 리더십은 적응 형 개발에서 가장 많이 찾는 연습입니다.

지도자는 다음과 같은 자질을 가지고 있습니다-

방향을 잡고 설정하십시오.
관련된 사람들에게 영향을주고 지침을 제공합니다.
팀을 공동 작업, 촉진 및 거시 관리합니다.
방향을 제시하십시오.
재능있는 사람들이 혁신적이고 창의적이며 효과적인 결정을 내릴 수있는 환경을 만듭니다.
때때로 그들이 명령을 내릴 필요가 있지만 그것이 그들의 지배적 인 스타일이 아니라는 것을 이해하십시오.