적응 형 소프트웨어 개발-사례

적응 형 소프트웨어 개발 관행은 지속적인 변화를 표준으로 받아들이도록 준비된 라이프 사이클과 함께 지속적인 적응에 대한 믿음에 의해 주도됩니다.

적응 형 소프트웨어 개발 라이프 사이클은 다음에 전념합니다.

지속적인 학습
방향 변경
Re-evaluation
불확실한 미래를 들여다 본다
개발자, 경영진 및 고객 간의 강력한 협업

적응 형 SDLC

적응 형 소프트웨어 개발은 RAD와 소프트웨어 엔지니어링 모범 사례를 결합합니다.

프로젝트 시작.
적응 형주기 계획.
동시 구성 요소 엔지니어링.
품질 검토.
최종 QA 및 릴리스.

적응 형 소프트웨어 개발 사례는 다음과 같이 설명 할 수 있습니다.

위에서 설명한 것처럼 적응 형 소프트웨어 개발 관행은 다음과 같이 세 단계에 걸쳐 있습니다.

추측 -시작 및 계획
- 프로젝트 시작
- 전체 프로젝트에 대한 타임 박스 설정
- 반복 횟수를 결정하고 각각에 타임 박스를 할당합니다.
- 각 반복에 대한 주제 또는 목표 개발
- 각 반복에 기능 할당
Collaborate − 동시 기능 개발
- 분산 된 팀을위한 협업
- 소규모 프로젝트를위한 협업
- 대규모 프로젝트를위한 협업
Learn − 품질 검토
- 고객의 관점에서 본 결과 품질
- 기술적 관점에서의 결과 품질
- 전달 팀 및 관행 팀 구성원의 기능이 활용하고 있습니다.
- 프로젝트 상태

추측-시작 및 계획

적응 형 소프트웨어 개발에서 추측 단계에는 두 가지 활동이 있습니다.

Initiation
Planning

Speculate에는 시작 및 계획 단계에서 반복적으로 실행할 수있는 5 가지 관행이 있습니다. 그들은-

프로젝트 시작
전체 프로젝트에 대한 타임 박스 설정
반복 횟수를 결정하고 각각에 타임 박스를 할당합니다.
각 반복에 대한 주제 또는 목표 개발
각 반복에 기능 할당

프로젝트 시작

프로젝트 시작에는 다음이 포함됩니다.

프로젝트의 사명과 목표 설정
제약 이해
프로젝트 조직 구축
요구 사항 식별 및 개요
초기 크기 및 범위 추정
주요 프로젝트 위험 식별

프로젝트 시작 데이터는 속도를 주요 측면으로 고려하여 예비 JAD 세션에서 수집해야합니다. 시작은 중소 규모 프로젝트의 경우 2 ~ 5 일, 대규모 프로젝트의 경우 2 ~ 3 주 동안 집중적으로 완료 할 수 있습니다.

JAD 세션 중에는 기능을 식별하고 객체, 데이터 또는 기타 아키텍처 모델의 개요를 설정하기에 충분한 세부 사항이 요구 사항이 수집됩니다.

전체 프로젝트에 대한 타임 박스 설정

프로젝트 착수 작업으로 인한 범위, 기능 세트 요구 사항, 추정 및 자원 가용성을 기반으로 전체 프로젝트에 대한 시간 상자를 설정해야합니다.

아시다시피, 추측은 추정을 포기하는 것이 아니라 추정이 잘못 될 수 있음을 받아들이는 것을 의미합니다.

반복 및 타임 박스

전체 프로젝트 범위와 불확실성의 정도에 따라 반복 횟수와 개별 반복 길이를 결정합니다.

중소 규모 애플리케이션의 경우-

반복은 일반적으로 4 주에서 8 주까지 다양합니다.
일부 프로젝트는 2 주 반복으로 가장 잘 작동합니다.
일부 프로젝트는 8 주 이상이 필요할 수 있습니다.

자신에게 맞는 시간을 선택하십시오. 반복 횟수와 각 반복 길이를 결정한 후 각 반복에 일정을 할당합니다.

주제 또는 목표 개발

팀 구성원은 각 반복에 대한 주제 또는 목표를 개발해야합니다. 이것은 Scrum의 Sprint Goal과 비슷합니다. 각 반복은 제품 기능을 보여줄 수있는 기능 세트를 제공하여 고객이 제품을 검토하고 피드백 할 수 있도록해야합니다.

반복 내에서 빌드는 통합 프로세스를 가능하게하고 제품을 개발 팀에 표시 할 수 있도록 매일 가급적이면 작업 기능을 제공해야합니다. 테스트는 기능 개발의 지속적이고 필수적인 부분이어야합니다. 프로젝트가 끝날 때까지 연기해서는 안됩니다.

기능 할당

개발자와 고객은 함께 각 반복에 기능을 할당해야합니다. 이 기능 할당에 대한 가장 중요한 기준은 모든 반복이 고객에게 상당한 기능을 가진 가시적 인 기능 세트를 제공해야한다는 것입니다.

반복에 기능을 할당하는 동안-

개발 팀은 기능 추정치, 위험 및 종속성을 제시하고이를 고객에게 제공해야합니다.
고객은 개발 팀에서 제공 한 정보를 사용하여 기능 우선 순위를 결정해야합니다.

따라서 반복 계획은 기능 기반이며 개발자 및 고객과 함께 팀으로 수행됩니다. 경험에 따르면 이러한 유형의 계획은 프로젝트 관리자의 작업 기반 계획보다 프로젝트에 대한 더 나은 이해를 제공합니다. 또한 기능 기반 계획은 각 프로젝트의 고유성을 반영합니다.

Collaborate ─ 동시 기능 개발

공동 작업 단계에서는 개발에 중점을 둡니다. 협업 단계에는 두 가지 활동이 있습니다.

개발 팀은 협력하여 작동하는 소프트웨어를 제공합니다.
프로젝트 관리자는 협업 및 동시 개발 활동을 촉진합니다.

협업은 개발 팀, 고객 및 관리자를 포괄하는 공유 창작 행위입니다. 공유 창조는 신뢰와 존중으로 촉진됩니다.

팀은 협력해야합니다-

기술적 문제
비즈니스 요구 사항
신속한 의사 결정

다음은 적응 형 소프트웨어 개발의 협업 단계와 관련된 관행입니다-

분산 된 팀을위한 협업
소규모 프로젝트를위한 협업
대규모 프로젝트를위한 협업

분산 된 팀을위한 협업

분산 된 팀이 관련된 프로젝트에서 다음 사항을 고려해야합니다.

다양한 동맹 파트너
광범위한 지식
사람들이 상호 작용하는 방식
상호 의존성을 관리하는 방법

소규모 프로젝트를위한 협업

소규모 프로젝트에서는 팀원이 물리적으로 근접하여 작업 할 때 비공식적 인 복도 채팅 및 화이트 보드 낙서를 통한 협업이 효과적이라는 것이 확인되었으므로 권장되어야합니다.

더 큰 프로젝트를위한 협업

규모가 큰 프로젝트에는 추가 관행, 협업 도구 및 프로젝트 관리자 상호 작용이 필요하며 상황에 따라 조정되어야합니다.

배우기-품질 검토

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

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

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

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

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

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

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

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

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

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

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

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

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

프로젝트 상태

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

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

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

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