애자일 데이터 과학-방법론 개념

이 장에서는 "애자일"이라고하는 소프트웨어 개발 수명주기의 개념에 초점을 맞출 것입니다. 애자일 소프트웨어 개발 방법론은 1-4주의 짧은 반복으로 증분 세션을 통해 소프트웨어를 구축하는 데 도움이되므로 개발이 변화하는 비즈니스 요구 사항에 맞춰 조정됩니다.

Agile 방법론을 자세히 설명하는 12 가지 원칙이 있습니다.

고객 만족

귀중한 소프트웨어를 조기에 지속적으로 제공하여 요구 사항에 중점을 둔 고객에게 가장 높은 우선 순위를 부여합니다.

새로운 변화를 환영합니다

소프트웨어 개발 중에 변경이 허용됩니다. 애자일 프로세스는 고객의 경쟁 우위에 맞게 작동하도록 설계되었습니다.

배달

작동하는 소프트웨어는 1 ~ 4 주 내에 고객에게 제공됩니다.

협동

비즈니스 분석가, 품질 분석가 및 개발자는 프로젝트의 전체 수명주기 동안 협력해야합니다.

자극

프로젝트는 동기 부여 된 개인의 클랜과 함께 설계되어야합니다. 개별 팀 구성원을 지원할 수있는 환경을 제공합니다.

개인적인 대화

대면 대화는 개발 팀과 정보를 전송하는 가장 효율적이고 효과적인 방법입니다.

진행 상황 측정

진행률 측정은 프로젝트 및 소프트웨어 개발의 진행 상황을 정의하는 데 도움이되는 핵심입니다.

일정한 속도 유지

애자일 프로세스는 지속 가능한 개발에 중점을 둡니다. 비즈니스, 개발자 및 사용자는 프로젝트를 지속적으로 진행할 수 있어야합니다.

모니터링

민첩한 기능을 향상시키기 위해 기술적 우수성과 좋은 디자인에 정기적으로주의를 기울여야합니다.

간단

애자일 프로세스는 모든 것을 단순하게 유지하고 간단한 용어를 사용하여 완료되지 않은 작업을 측정합니다.

자체 구성 용어

민첩한 팀은 스스로 구성되어야하며 최상의 아키텍처로 독립적이어야합니다. 요구 사항 및 디자인은 자체 조직 된 팀에서 나옵니다.

작업 검토

팀이 작업 진행 상황을 반영 할 수 있도록 정기적으로 작업을 검토하는 것이 중요합니다. 적시에 모듈을 검토하면 성능이 향상됩니다.

데일리 스탠드 업

일일 스탠드 업은 팀원 간의 일일 상태 회의를 의미합니다. 소프트웨어 개발과 관련된 업데이트를 제공합니다. 또한 프로젝트 개발의 장애물을 해결하는 것을 의미합니다.

사무실 위치에 관계없이 애자일 팀이 어떻게 구성되어 있더라도 매일 스탠드 업은 필수 관행입니다.

일일 스탠드 업의 기능 목록은 다음과 같습니다.

매일 스탠드 업 미팅 시간은 약 15 분입니다. 더 오래 연장해서는 안됩니다.
스탠드 업은 상태 업데이트에 대한 토론을 포함해야합니다.
이 회의 참가자는 일반적으로 회의를 빨리 끝내려는 의도로 서 있습니다.

사용자 스토리

스토리는 일반적으로 요구 사항이며 간단한 언어로 몇 개의 문장으로 구성되며 반복 내에서 완료되어야합니다. 사용자 스토리에는 다음과 같은 특성이 포함되어야합니다.

모든 관련 코드에는 관련 체크인이 있어야합니다.
지정된 반복에 대한 단위 테스트 케이스입니다.
모든 승인 테스트 케이스를 정의해야합니다.
이야기를 정의하는 동안 제품 소유자의 수락.

스크럼이란?

스크럼은 애자일 방법론의 하위 집합으로 간주 될 수 있습니다. 경량 프로세스이며 다음 기능을 포함합니다.

일관된 순서로 따라야하는 일련의 관행을 포함하는 프로세스 프레임 워크입니다. 스크럼의 가장 좋은 예는 반복 또는 스프린트를 따르는 것입니다.
이는 "경량"프로세스로서 지정된 기간 동안 생산적인 결과를 극대화하기 위해 프로세스가 가능한 한 작게 유지된다는 의미입니다.

스크럼 프로세스는 전통적인 애자일 접근 방식의 다른 방법론과 비교할 때 차별화 된 프로세스로 유명합니다. 다음 세 가지 범주로 나뉩니다.

Roles
Artifacts
타임 박스

역할은 프로세스 전체에 포함 된 팀 구성원과 역할을 정의합니다. 스크럼 팀은 다음 세 가지 역할로 구성됩니다.

스크럼 마스터
제품 소유자
Team

스크럼 아티팩트는 각 구성원이 알아야 할 주요 정보를 제공합니다. 정보에는 제품, 계획된 활동 및 완료된 활동의 세부 사항이 포함됩니다. 스크럼 프레임 워크에 정의 된 아티팩트는 다음과 같습니다.

제품 백 로그
스프린트 백 로그
번 다운 차트
Increment

시간 상자는 각 반복에 대해 계획된 사용자 스토리입니다. 이러한 사용자 스토리는 스크럼 아티팩트의 일부를 형성하는 제품 기능을 설명하는 데 도움이됩니다. 제품 백로 그는 사용자 스토리 목록입니다. 이러한 사용자 스토리는 우선 순위가 지정되고 사용자 회의에 전달되어 어느 것이 채택되어야하는지 결정합니다.

왜 스크럼 마스터인가?

스크럼 마스터는 팀의 모든 구성원과 상호 작용합니다. 이제 스크럼 마스터와 다른 팀 및 리소스의 상호 작용을 살펴 보겠습니다.

제품 소유자

스크럼 마스터는 다음과 같은 방식으로 제품 소유자와 상호 작용합니다.

사용자 스토리의 효과적인 제품 백 로그를 달성하기위한 기술을 찾고 관리합니다.
팀이 명확하고 간결한 제품 백 로그 항목의 요구 사항을 이해하도록 지원합니다.
특정 환경에서 제품 계획.
제품 소유자가 제품의 가치를 높이는 방법을 알도록합니다.
필요할 때 스크럼 이벤트를 촉진합니다.

스크럼 팀

스크럼 마스터는 여러 방법으로 팀과 상호 작용합니다.

조직의 스크럼 채택 코칭.
특정 조직에 스크럼 구현 계획.
직원과 이해 관계자가 제품 개발의 요구 사항과 단계를 이해하도록 돕습니다.
특정 팀의 스크럼 적용 효과를 높이기 위해 다른 팀의 스크럼 마스터와 협력합니다.

조직

스크럼 마스터는 여러 방식으로 조직과 상호 작용합니다. 아래에 몇 가지가 언급되어 있습니다.

코칭 및 스크럼 팀은 자체 조직과 상호 작용하며 교차 기능의 기능을 포함합니다.
스크럼이 아직 완전히 채택되지 않았거나 승인되지 않은 영역에서 조직과 팀을지도합니다.

스크럼의 이점

Scrum은 고객, 팀 구성원 및 이해 관계자가 협업 할 수 있도록 지원합니다. 여기에는 타임 박스 접근 방식과 제품 소유자의 지속적인 피드백이 포함되어 제품이 작동 상태에 있는지 확인합니다. 스크럼은 프로젝트의 다양한 역할에 이점을 제공합니다.

고객

스프린트 또는 반복은 더 짧은 기간 동안 고려되며 사용자 스토리는 우선 순위에 따라 설계되고 스프린트 계획에 포함됩니다. 모든 스프린트 제공, 고객 요구 사항이 충족되도록 보장합니다. 그렇지 않은 경우 요구 사항이 기록되고 스프린트를 위해 계획되고 취해집니다.

조직

스크럼 및 스크럼 마스터의 도움을받는 조직은 사용자 스토리 개발에 필요한 노력에 집중할 수 있으므로 작업 과부하를 줄이고 재 작업을 방지 할 수 있습니다. 이는 또한 개발 팀의 효율성 향상과 고객 만족도를 유지하는 데 도움이됩니다. 이 접근 방식은 시장의 잠재력을 높이는데도 도움이됩니다.

제품 관리자

제품 관리자의 주된 책임은 제품의 품질을 유지하는 것입니다. 스크럼 마스터의 도움으로 작업을 용이하게하고 빠른 응답을 수집하며 변경 사항을 흡수하는 것이 쉬워집니다. 또한 제품 관리자는 설계된 제품이 모든 스프린트의 고객 요구 사항에 따라 정렬되었는지 확인합니다.

개발팀

타임 박스 특성과 짧은 시간 동안 스프린트를 유지하는 개발 팀은 작업이 제대로 반영되고 전달되는지 확인하는 데 열광합니다. 작동하는 제품은 반복 할 때마다 각 레벨을 증가 시키거나 "스프린트"라고 부를 수 있습니다. 모든 스프린트를 위해 설계된 사용자 스토리는 반복에 더 많은 가치를 더하는 고객 우선 순위가됩니다.

결론

Scrum은 팀워크로 소프트웨어를 개발할 수있는 효율적인 프레임 워크입니다. 민첩한 원칙에 따라 완벽하게 설계되었습니다. ScrumMaster는 가능한 모든 방법으로 Scrum 팀을 돕고 협력합니다. 그는 계획된 계획을 고수하고 계획에 따라 모든 활동을 수행하도록 돕는 개인 트레이너 역할을합니다. ScrumMaster의 권한은 프로세스를 넘어서는 절대 안됩니다. 그는 잠재적으로 모든 상황을 관리 할 수 있어야합니다.