[Mendix] Agile Awareness 3

The Agile Methodology (인식, 방법론)

- Values and principles of Agile. (애자일의 가치와 원칙)
- Importance of the Agile mindset.(애자일 사고방식의 중요성)
- Team, roles and their responsibilities.(팀, 역할 및 책임)
- Artifacts, which you’ll work with on a daily basis.(매일 작업하게 될 아티팩트)
- Scrum events (some of them also known as Agile ceremonies). (스크럼 이벤트; 그 중 일부는 애자일 행사라고 함)

 

** artifacts는 사람이 만든 산출물 정도로 해석

 

회사 전략을 재고하고 포트폴리오가 어떻게 생겼는지 정의

그녀의 아이디어, 목표 및 비전을 대표하고 추진할 제품소유자(PO)가 필요하다는 것을 깨달았습니다.

Waterfall 방법론 사용 시 구성	Agile 사용시 구성
요구 사항 수집을 담당한 분석가. 디자인을 만든 건축가, 애플리케이션을 프로그래밍한 개발자. 앱 테스트를 전담한 테스터.	애자일 팀이 조직됨에 따라 그녀는 제품 소유자, 비즈니스 소유자 및 스크럼 팀 과 협력해야 한다는 것을 의미한다는 것을 깨닫습니다 .

 

Agile Mindset

4가지 가치를 정의하고, 애자일 접근 방식을 특징짓는 12가지 원칙을 공식화 했습니다. 

Agile 커뮤니티에서 Agile Manifesto로 알려져 있다.

 

Being Agile is however not enough, you can only achieve results by being Agile and doing Agile

그러나 애자일만으로는 충분하지 않습니다 . 애자일하고 애자일을 수행 해야만 결과를 얻을 수 있습니다 !

 

애자일 가치와 원칙에 따라 검사, 조정 및 제공하여 애자일을 실천하는 것이 중요하다. 사고방식을 강화하는 유일한 방법은 실행하는 것이다. 소규모 교차 기능 팀 맥락에서의 협업은 성공의 전제 조건입니다.

 

 

애자일 사고방식을 채택하기 위한 여정의 시작
- 작업을 더 작은 조각으로 나눕니다. 업무의 범위는 작아지지만 집중할 수 있고 빠른 결과를 낼 수 있습니다.
- 가능한 한 빨리 피드백을 받고 제공하며 정기적으로 수행하십시오. 실수는 개선의 방법이지만 요구 사항을 충족하는 제품을 제공하기 위해 가능한 한 빨리 피드백을 받고 싶습니다.
- 개방적이고 투명하게 소통합니다. 더 나은 의사 소통은 Scrum 팀과 프로젝트에 관련된 다른 이해 관계자의 기대치를 관리하는 데 도움이 됩니다.
- 소유권을 가져라. 자체 관리 팀의 맥락에서 프로젝트 관리자가 없으므로 작업에 대한 주도권, 책임 및 소유권을 가지십시오. 스크럼 팀은 최종 제품에 대한 책임이 있지만 이러한 소유권과 책임은 스크럼 팀에 관련된 모든 사람의 누적된 결과입니다.

 

가치
Agile Manifesto는 몇 가지 가치를 식별하여( 여기에서 원래 설명을 확인 하십시오 ) 일부 항목의 우선 순위를 다르게 지정하고 일부 측면을 다른 측면보다 우선시해야 함을 나타냅니다.

1. 프로세스 및 도구를 통한 개인 및 상호 작용 . 이는 프로세스와 도구가 중요하지 않다는 의미가 아니라 개인 간 협업이 중요하며 투명하고 신뢰할 수 있는 커뮤니케이션에 투자하고 작업해야 함을 나타냅니다.
2. 문서보다 작동하는 소프트웨어 . 기존의 Waterfall 접근 방식은 광범위한 문서를 생성했지만 본질적으로 작동하는 소프트웨어를 제공하는 것이 설명보다 더 큰 가치가 있습니다. 애자일은 문서를 제거하는 것이 아니라 문서가 아닌 완벽하게 작동하는 제품에 초점을 둡니다.
3. 계약 협상을 통한 고객 . 고객과 딱딱한 합의를 하고 사전에 정확한 세부 사항을 정의하는 것보다 훨씬 더 나은 접근 방식은 최상의 솔루션을 찾기 위해 고객과 협력하여 계약을 맺는 것입니다. 데모 및 제품 검토를 위해 고객의 가용성을 준비하는 것은 팀에서 개발한 제품의 정확성을 확인하기 위한 필수 단계입니다.
4. 계획에 따른 전환에 대응 . 당신이 계획한 대로 되는 일은 없습니다. 사전에 모든 세부 단계를 포함하는 정교한 계획을 개발하는 대신 그 과정에서 우선 순위를 조정하고 프로젝트의 경계를 유연하고 변경에 대해 개방적으로 유지하는 것이 훨씬 좋습니다.

원칙
Agile Manifesto에 의해 공식화된 4가지 가치 옆에는 12가지 Agile 원칙이 있습니다( 여기에서 원래 설명을 확인하십시오 ). 애자일 소프트웨어 개발이 어떻게 이루어져야 하는지 나열합니다. 원칙 목록:

01. 가치 있는 소프트웨어를 조기에 지속적으로 제공합니다. 우리의 최우선 순위는 귀중한 소프트웨어를 조기에 지속적으로 제공하여 고객을 만족시키는 것입니다.
02. 변화 를 수용하십시오 . 개발 후반에도 변화하는 요구 사항을 환영합니다. 민첩한 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.
03. 빈번한 배송 . 더 짧은 기간을 선호하여 몇 주에서 몇 달 사이에 작동하는 소프트웨어를 자주 제공합니다.
04. 기업인과 개발자가 함께 합니다. 비즈니스 사람과 개발자는 프로젝트 전체에서 매일 함께 작업해야 합니다.
05. 동기 부여된 개인 . ****의욕이 있는 개인을 중심으로 프로젝트를 구축합니다. 그들에게 필요한 환경과 지원을 제공하고 그들이 일을 완수할 것이라고 믿으십시오.
06. 대면 대화 . 개발 팀에게 또는 개발 팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.
07. 작업 소프트웨어 . 작동하는 소프트웨어는 진행 상황의 주요 척도입니다.
08. 지속 가능한 개발 . 민첩한 프로세스는 지속 가능한 개발을 촉진합니다. 스폰서, 개발자 및 사용자는 무한정 일정한 속도를 유지할 수 있어야 합니다.
09. 기술적 우수성 . 기술 우수성과 우수한 디자인에 대한 지속적인 관심은 민첩성을 향상시킵니다.
10. 단순성 . 단순성(완료되지 않은 작업량을 최대화하는 기술)은 필수적입니다.
11. 자기 조직화 팀 . 최고의 아키텍처, 요구 사항 및 디자인은 자체 구성 팀에서 나옵니다.
12. 정기적 반영 및 조정 . 정기적으로 팀은 효율성을 높이는 방법에 대해 숙고한 다음 그에 따라 행동을 조정하고 조정합니다.

 

 

가치와 원칙의 연결
이러한 원칙을 분석하면 그 중 일부가 앞에서 설명한 4가지 Agile 가치의 다양한 측면을 다루고 있음을 알 수 있습니다. 

- 문서보다 작동 하는 소프트웨어

- 가치는 작동하는 소프트웨어

- 가치 있는 소프트웨어의 조기 및 지속적인 전달 및 빈번한 전달 원칙 (=> 고객을 만족시키려면 진행 상황을 측정하고 완료된 기능에 대한 통찰력을 얻고 팀 속도(예: 소프트웨어를 제공하는 데 걸린 시간)를 파악하는 것이 중요))

 

Embrace Change 원칙 은 계획 가치 에 따른 변경에 대한 대응에 가장 가깝습니다 . 그러나 규칙적인 반영 및 조정과 결합 하여 단순성 과 기술적 우수성원칙, 그들은 프로세스 부분과 지속적인 개선을 다룹니다. 변화하는 요구 사항의 빠른 속도를 고려할 때 개발 프로세스에 따라 변화하는 요구 사항의 유연성을 허용하는 것이 필수적입니다. 애자일 방법론은 개발 후반에도 변화를 환영합니다. 비즈니스 요구 사항이 아무리 자주 변경되더라도 팀은 우수한 설계가 민첩성을 향상시키므로 기술 우수성에 지속적으로 주의를 기울여야 합니다. 변경 관리의 일환으로 비즈니스 요구 사항이 변경될 때마다 기술 설계의 유효성을 평가하는 것이 중요합니다. 우수한 기술 설계를 무시하면 팀 속도가 느려지고 소프트웨어 제공이 지연될 수 있습니다. 지속적인 개선의 또 다른 측면은 수행해서는 안 되는 작업을 제거하고 가능할 때마다 작업을 자동화하여 단순성에 초점을 맞추는 것입니다.

Business People and Developers Together 원칙은 계약 협상 가치 에 대한 고객과 관련 이 있습니다. 협업 장벽을 제거하고 개발자와 비즈니스가 매일 상호 작용하도록 허용하면 투명성이 향상되고 기대치를 관리하는 데 도움이 됩니다. 정기적으로 검토 세션에 비즈니스 담당자를 참여시키면 개발자가 귀중한 피드백을 얻고 활용해야 하는 제품 및 비즈니스 가치를 더 잘 이해할 수 있습니다.

---

Agile Team, Roles and Responsibilities

 

Mendix는 스크럼 팀을 핵심 팀 과 주제 전문가 (SME) 의 접합점으로 간주

 

SME는 팀이 UX/UI, QA, 테스트 및 통합과 같은 주제에 대한 자세한 지식을 요구할 때 참여합니다. SME는 일반적으로 여러 스크럼 팀에 참여하므로 각 특정 스크럼 팀에서 제공해야 하는 제품에 대해 최종 책임을 지지 않습니다. 이것은 제품 제공을 책임지는 핵심 팀입니다.

 

핵심 팀 자체는 제품 소유자 , 스크럼 마스터 및 여러 비즈니스 엔지니어 (후자는 일반적으로 개발 팀 이라고 함 )로 구성됩니다. 핵심 팀의 구성원은 풀타임으로 헌신합니다. 서로 다른 스크럼 팀 간에 구성원을 전환하는 것이 권장되지 않는다는 것이 경험을 통해 입증되었습니다

 

 

 

 

제품 소유자(PO) 

비즈니스와 개발 팀 간의 연락 담당자입니다. PO는 프로젝트 이해 관계자의 기대치를 추적하고 프로젝트 요구 사항을 정의하며 우선 순위를 지정합니다. 또한 제품 소유자는 요구 사항의 비전과 가치를 팀에 전달할 책임이 있습니다. 또한 PO는 사용자 피드백을 관리합니다. 이러한 피드백과 비즈니스 요구 사항을 기반으로 PO는 지속적으로 우선 순위를 조정합니다.
스크럼 마스터 

역할: 

- 팀이 통제할 수 없는 일로 인해 막히면 이러한 장애물을 제거하는 것

- 팀이 민첩한 방식으로 작업하고 다른 사람들에게 모범 사례를 지도

 

스크럼 팀이 스크럼 방법론에 따라 작업할 수 있도록 하고 팀 내 프로세스를 최적화하는 데 중점을 둡니다. (회의를 촉진하고 다양한 스크럼 이벤트를 조직하는 것이 포함)(강의 3.5에서 이에 대해 배우게 될 것입니다).

소규모 스크럼 팀에서 선임 개발자는 일반적으로 자신이 담당하는 다른 개발 작업 옆에 있는 스크럼 마스터의 책임을 맡습니다. 스크럼 마스터는 팀이 민첩한 방식으로 작업하고 다른 사람들에게 모범 사례를 지도하도록 합니다.
개발팀 은 실제로 앱을 만드는 사람들로 구성되어 있습니다. 그들은 제품 소유자가 제공한 입력을 기반으로 요구 사항을 기능으로 변환할 책임이 있습니다. Mendix Dev Team은 일반적으로 엔지니어, 디자이너, 설계자, 테스터 등 2~3명의 구성원으로 구성됩니다. 이 구성원은 서로 다른 기술과 잠재적으로 다른 경험 수준을 가지고 있습니다. 비즈니스 요구 사항을 분석하고 개발 작업을 수행할 수 있습니다. 주어진 스프린트에서 제품을 제공하는 데 전문성이 필요한 경우 SME와 긴밀히 협력합니다.

Scrum 팀인 SME에 대해 언급했지만 아직 비즈니스 이해 관계자는 다루지 않았습니다. 이들은 다음으로 구성됩니다.

비즈니스 소유자 , 주요 이해 관계자, 프로젝트 및 제품에 대한 최종 책임 및 최종 책임. 그는 제품 후원을 대표하는 수익 동인입니다. 비즈니스 소유자는 애자일 프로젝트에서 비즈니스 요구 사항을 대표해야 하는 제품 소유자에게 크게 의존합니다.
개발 중인 제품의 최종 사용자인 이해관계자 는 비즈니스의 전략적, 전술적, 운영적 수준을 나타냅니다. 이해 관계자는 일반적으로 스크럼 팀이 제공한 제품에 대한 피드백을 제공하기 위해 검토 세션에 참여합니다.

전체 스크럼 팀은 프로젝트가 성공할 수 있도록 협력합니다. 스크럼 팀의 목표는 전체 팀이 가능한 한 효과적이고 효율적으로 작업할 수 있는 모드에 도달하는 것입니다. 그들은 이상적으로 서로 교차 훈련하므로 팀의 성공은 한 사람에게 의존하지 않습니다. 자체 관리 팀의 민첩한 원칙을 기억하십니까? 스크럼 팀은 일이 일어나도록 스스로 조직합니다! 각 역할이 책임에 따라 이해하고 행동하는 올바른 팀을 갖는 것이 프로젝트를 성공적으로 완료하는 요소입니다!


Sophie는 첫 번째 팀을 만들기 시작합니다. 이 팀은 2~3명의 개발자로 구성될 가능성이 높으며 가장 경험이 많은 사람이 스크럼 마스터 역할을 맡게 됩니다. Sophie는 풀타임 스크럼 마스터를 고용하기에는 너무 이르다고 생각합니다. 그녀는 회사에서 여러 앱을 빌드하는 단계로 이동하는 나중 단계에서 이 작업을 고려할 수 있습니다. 전문 기능에 적합한 SME를 찾는 것은 상당히 어렵습니다. Sophie는 Mendix 전문가 서비스 또는 파트너와 협력할 수 있는 가능성을 탐색합니다. 소싱은 전문 지식을 활용하기 위한 예산을 예약해야 하는 Sophie에게 중요한 주제입니다. 코딩 경험이 전혀 없는 Sophie는 자신의 프로젝트에 어떤 SME가 필요할지 예측하기가 약간 어렵다는 것을 알게 되지만 숙련된 개발자가 이러한 예측을 수행하는 데 도움을 줄 수 있습니다.


이제 Agile 프로젝트에서 협업하게 될 다양한 역할에 대해 배웠습니다. 그런 팀이 매일 어떤 일을 하는지 알아볼 때입니다!

---

Artifacts 산출물

아티팩트는 모든 사람이 이 작업의 가치와 중요성을 이해하는 방식으로 팀에서 실행하는 작업을 나타내는 데 사용되는 포괄적인 용어.

스크럼 프로세스의 다양한 단계에서 사용

아티팩트의 생성/유지 관리에 대한 명확한 책임이 있다.

 

 

Sprint는 Scrum 프레임워크의 핵심

1주~4주 사이의 제한된 기간

Mendix 1-2주 동안 sprint를 사용한다. 

 

스프린트가 더 오래 지속되도록 허용하면 이해 관계자에게 제품을 제공하는 시간이 길어집니다. 이는 개발자가 제품을 요구 사항에 맞게 조정하기 위해 수행할 수 있는 피드백 및 개입을 연기합니다. 따라서 잦은 피드백과 빠른 개발을 위해 스프린트를 1-2주의 범위 내로 유지

 스프린트에는 목표가 있어야 한다. 모든 팀 구성원이 함께 공식화하며 일반적으로 스프린트 시작 시 동의한 만큼의 기능을 제공하는 것을 목표로 합니다. Sprint Backlog 및 Definition of Done을 ​​통해 무엇을 개발하고 전달해야 하는지에 대한 합의를 얻습니다.

 

Sprint Backlog는 사용자 스토리 형식으로 공식화된 요구 사항으로 구성됩니다. 이러한 사용자 스토리는 원래 제품 소유자가 만든 제품 백로그에서 가져옵니다. 지정된 스프린트 내에서 개발하도록 계획된 스크럼 팀은 선택된 모든 사용자 스토리를 처리하고 지정된 스프린트 내에서 완료하기 위해 노력합니다.

유저 스토리의 완성 여부는 Done의 정의에 따라 정의

스프린트 종료 시 전달된 모든 결과는 제품 증분을 형성하며 사용자 및 이해 관계자의 검토를 위해 제시됩니다. 이 피드백을 얻은 후 제품 백로그가 업데이트되고 우선 순위가 다시 지정되는 방식으로 모든 피드백을 통합하는 것은 제품 소유자의 책임입니다.

 

 

Sprint Backlog
스프린트 중에 Scrum 팀은 PO에서 생성한 제품 백로그에서 다음 반복의 일부로 제공할 항목을 식별합니다. 스크럼 팀이 작업하기로 선택한 항목은 스프린트 백로그의 일부가 됩니다.
모니터링을 위해 백로그 항목의 상태를 정기적으로 확인하고 업데이트해야 하며 모든 사람이 액세스할 수 있는 하나의 중앙 집중식 위치를 유지하여 이를 모니터링하는 것이 가장 좋습니다. 이러한 장소를 일반적으로 스크럼 보드라고 합니다. 물리적 스크럼 보드를 사용할 것인지 가상 스크럼 보드를 사용할 것인지는 팀이 결정해야 합니다. 각 사용자 스토리에는 신규, 진행 중 또는 완료 상태가 있습니다. 스크럼 마스터는 스크럼 보드가 정기적으로 업데이트되도록 합니다. 물리적 스크럼 보드를 사용하면 팀 진행 상황의 투명성이 높아진다는 이점이 있습니다(같은 방에 있는 사람들의 경우). 단점은 다른 모든 이해 관계자가 거리를 두고 스프린트의 상태를 참조할 수 있도록 사용자 스토리도 가상으로 등록해야 한다는 것입니다. 디지털 시대에 모두가 가상으로 협업하게 됩니다. 이 경우 팀은 스크럼 보드의 공유 및 실시간 조정이 가능한 가상 협업 도구를 선택해야 합니다.
Sophie는 팀에서 사용자 스토리를 관리하는 데 사용할 도구에 대한 결정도 내렸습니다. 그녀가 어떤 선택을 했는지 아십니까? 예, 그녀의 팀은 사용자 스토리를 유지 관리하는 기능을 제공하지만 시각적 대시보드 형태로 실행을 계획하고 모니터링할 수 있는 Mendix 개발자 포털을 사용할 것입니다.

Product Increment
제품 증분은 스프린트 동안 완료된 모든 사용자 스토리의 합계입니다. 스크럼은 반복적인 프로세스이므로 제품 증분은 반복적으로 발전하고 이전 제품 증분에 새로운 기능을 추가합니다. 마지막 스프린트가 끝날 때 제품 증분은 고객에게 제공될 요구된 제품을 나타냅니다. 제품이 승인 기준을 충족하는 경우에만 고객이 공식적으로 제품을 승인하고 출시를 위해 Go를 제공합니다.
제품 증분의 예로는 Tangram 앱의 대시보드를 들 수 있습니다.

Definition of Done
개발 팀이 제품 증가가 충족해야 하는 승인 기준을 알고 있는지 확인하기 위해 제품 소유자는 DoD(Definition of Done)라는 액세스 가능한 문서에서 해당 기준을 미리 정의해야 합니다. 프로젝트의 특정 컨텍스트에 따라 이러한 DoD는 개발된 제품이 요청된 기능을 제공하고 예상되는 품질 수준을 보장하는 데 도움이 됩니다. DoD는 각 제품 백로그 항목을 확인하는 데 사용해야 합니다.
Sophie의 팀이 Tangram 앱의 DoD에 포함하는 것이 중요하다고 판단한 몇 가지 기준을 살펴보겠습니다. 일반적으로 성공적으로 수행되면 확인해야 하는 단계로 작성됩니다. 예를 들면 다음과 같습니다.

- 검토된 코드
- 단위 테스트 통과
- 기능 테스트 통과
- 제품 소유자가 사용자 스토리를 수락했습니다.
이 강의에서는 제품 백로그, 사용자 스토리, 스프린트 백로그, 제품 증분 및 완료의 정의에 대해 배웠습니다. 일부 스크럼 이벤트 중에 이러한 아티팩트를 사용하게 됩니다. 

---

스크럼 이벤트

스크럼은 각 스프린트 주변의 프로세스를 구성하는 데 도움이 되는 여러 이벤트를 규정합니다. Sophie는 개발팀을 고용하고 그들에게 앱을 개발하라고 말할 수 없습니다. 그녀는 이 개발을 중심으로 프로세스를 조정하여 팀이 수행해야 하는 작업 범위, 전달해야 하는 시기, 완료된 작업을 표시하고 최종적으로 개발 프로세스가 진행된 방법을 반영하도록 해야 합니다. 운 좋게도 이러한 조직 작업은 스크럼 마스터의 책임이므로 Sophie는 이러한 모든 이벤트를 직접 계획할 필요가 없습니다! Scrum이 사용하는 네 가지 이벤트는 다음과 같습니다.

• 스프린트 계획
• 스프린트 검토
• 스프린트 회고전
• 일일 스탠드업

 

이러한 이벤트 다음으로 스크럼 팀은 제품 백로그 개선 을 수행합니다 . 이것은 공식적인 스크럼 이벤트는 아니지만 다른 목록에 있는 이벤트와 마찬가지로 계획된 다른 모든 스크럼 이벤트 전에 정기적으로 개선됩니다. 이는 사용자 스토리 작업을 시작하기 전에 무엇을 작업해야 하는지 알아야 하기 때문입니다. 따라서 제품 백로그 개선이 필요합니다!

 

언급된 각 이벤트에는 전용 목표가 있고 많은 입력을 소비하며 여러 출력을 제공합니다. 아래는 2주 스프린트에 대한 일반적인 일정의 개요를 보여줍니다. 필요한 모든 이해 관계자가 의제에서 시간 슬롯을 예약하도록 미리 이 회의 흐름을 계획하는 것이 편리합니다.

먼저 시간 제약을 이해하고 나중에 각 이벤트에 대해 자세히 이야기합시다!

 

자, 스프린트는 스프린트 계획으로 시작하여 다가오는 2주를 시작합니다. 그런 다음 매일 스크럼 팀이 일일 스탠드업을 위해 모입니다. 이 회의는 15분 동안만 지속되며 기껏해야 아침에 구성되어 팀원들이 낮 시간 동안 특정 주제에 대해 협업할 수 있습니다. 두 번째 주말에는 Sprint Review 및 Sprint Retrospective 회의가 구성됩니다. 제품과 프로세스 자체를 반영하는 것을 목표로 합니다. Backlog Refinement는 주중에 일어나는 유일한 회의입니다. 변동성이 큰 요구 사항의 경우 매주 제품 백로그를 다시 방문해야 할 수 있습니다. 이를 통해 개발 팀은 향후 변경 사항을 더 잘 예측할 수 있습니다.

 

이전에 Sophie가 1주일 동안 스프린트를 실행하기로 결정한 것을 기억하십니까? 일반적으로 이것은 동일한 이벤트가 발생한다는 것을 의미하며, Daily Stand-up을 제외한 모든 이벤트의 기간만 2주 스프린트의 경우보다 시간이 조금 덜 걸립니다. 이는 계획하거나 검토해야 하는 사용자 스토리 수가 적기 때문입니다. 논의할 항목에 따라 일주일 동안 발생한 일이 적기 때문에 회고전이 더 짧아질 수도 있습니다.

 

Scrum Master는 이러한 이벤트를 계획하고 Sophie가 그녀의 의제에서 일정 시간을 차단했는지 확인했습니다. Sophie가 첫 번째 결과를 보고 싶어 한다는 것을 상상할 수 있습니다!

 

제품 백로그 개선
회의 주기는 제품 백로그 개선 회의에서 시작됩니다. 이 회의의 목표는 제품 백로그에서 선택한 사용자 스토리에 대한 상호 이해에 도달하는 것입니다. 제품 백로그는 다양한 사람들이 수정할 수 있기 때문에 이러한 정렬이 필요합니다. 방지하고 싶은 것은 이러한 이야기가 다양한 당사자에 의해 잘못 해석되는 것입니다. 이 회의 중에 백로그를 다듬을 수 있습니다. PO는 필요한 경우 백로그의 우선순위를 다시 지정합니다. 백로그 항목에 우선 순위를 지정하는 동안 PO는 이해 관계자의 요구와 바람을 고려합니다. 그러나 가장 중요한 것은 PO가 사용자 스토리가 활용할 비즈니스 가치에 초점을 맞추는 것입니다. 항목의 우선 순위를 위에서 아래로 지정하여 맨 위에 있는 항목이 먼저 처리되도록 하는 것이 중요합니다.

특정 사용자 스토리의 내용을 명확히 하기 위해 SME도 이 회의에 참여시켜야 할 수 있습니다. 그러나 일반적으로 이 회의에는 핵심 스크럼 팀의 모든 구성원이 참석합니다.

 

사용자 스토리를 다듬는 동안 팀은 사용자 스토리에 스토리 포인트를 할당해야 합니다. 이전에 우리는 이러한 스토리 포인트가 사용자 스토리의 복잡성과 팀이 사용자 스토리를 해결하기 위해 투입해야 하는 예상 노력을 나타낸다고 언급했습니다. Mendix에서 스토리 포인트를 나타내는 데 사용되는 가중치는 피보나치와 같은 시퀀스(1, 2, 3, 5, 8, 13, 20, 40 및 100)를 기반으로 합니다.

 

사용자 스토리를 달성하는 데 필요한 노력을 정의할 때 고려해야 할 세 가지 요소가 있습니다.

• 사용자 스토리의 세부 사항
• 완료의 정의
• 허용 기준

 

사용자 스토리의 복잡성에 대해 의견이 일치하지 않는 경우 가장 극단적인 의견을 가진 팀원이 자신의 주장을 논의합니다. 일반적으로 정교한 대화를 통해 문제를 밝히고 팀 구성원은 이야기의 무게에 대한 합의에 도달합니다.
이를 달성할 수 있는 방법 중 하나는 포커를 계획하는 것입니다. 모든 사람이 사용자 스토리에 가중치 포인트를 할당하고(자신이 "가치" 있다고 생각하는 대로) 포인트가 가장 낮고 가장 높은 항목만 논의되는 기술입니다. .

이 스프린트의 결과로 달성된 세련된 사용자 스토리는 스프린트 계획 이벤트에 대한 입력으로 사용됩니다.

스프린트 계획
스프린트 계획은 스크럼 마스터, 제품 소유자 및 전체 애자일 개발 팀이 참여하는 협업 프로세스입니다. 스크럼 마스터는 회의를 진행하기 위해 존재합니다. Scrum Master는 SME의 참여가 필요한 경우에도 주의를 기울입니다. 제품 소유자는 제품 백로그 항목의 세부 사항과 각각의 수락 기준을 명확히 할 책임이 있습니다. PO는 Product Backlog Refinement 회의 중에 답변되지 않은 질문이 해결되고 기타 모든 불확실성이 가능한 한 많이 해결되도록 합니다. 개발팀은 Sprint 약속을 충족하는 데 필요한 작업과 노력을 정의합니다.

제품 소유자는 스프린트 동안 개발팀이 명확한 목표와 초점을 갖도록 합니다. 스프린트 계획 중에 개발 팀은 주어진 스프린트에 대해 어떤 사용자 스토리를 선택할지 결정합니다. 범위를 정의함으로써 개발 팀은 스프린트가 끝날 때까지 선택된 사용자 스토리를 고품질로 달성하겠다는 약속을 합니다. 팀 속도는 한 스프린트 동안 팀이 얼마나 많은 것을 달성할 수 있는지를 결정하는 요소입니다. 팀 속도를 알면 팀은 스프린트에서 얼마나 많은 사용자 스토리를 다룰 수 있는지 거의 정확하게 정의할 수 있습니다. 선택한 모든 사용자 스토리의 스토리 포인트를 집계하기만 하면 팀에서 선택한 워크로드의 실행 가능성을 확인할 수 있습니다.

팀 속도는 프로젝트 중에 변경될 수 있습니다. 안정적인 팀에서 작업하고 프로젝트를 더 잘 이해하는 조건에서는 팀 속도가 증가할 수 있습니다. 그러나 팀이 어떤 종류의 개편을 겪는 경우에도 감소할 수 있습니다. 일반적으로 팀 구성을 변경하면 팀 속도에 부정적인 영향을 미칩니다.

스프린트 검토 스프린트
가 끝나면 스크럼 마스터는 스프린트 검토를 구성합니다. 이 이벤트는 제품 소유자, 관리자 및 최종 사용자에게 Sprint의 결과를 보여주기 위한 것입니다. 제품을 검토할 때 출발점은 일련의 사용자 스토리를 처리하도록 범위가 설정된 스프린트 목표입니다.

데모 중에 허용 기준을 사용하여 제시된 증분이 완료의 정의를 충족하는지 확인합니다. PO 및 기타 이해 관계자로부터 받은 피드백으로 인해 다음 스프린트에 새로운 사용자 스토리가 추가되거나 제품 백로그가 약간의 조정이 필요할 수 있습니다.

팀이 이 회의 중에 진행되는 토론을 기반으로 다음 단계를 결정하는 것이 매우 중요합니다. 스프린트 검토의 결과는 PO가 승인한 잠재적인 새 백로그 항목 세트입니다.

스프린트 회고
회고 회의는 일반적으로 각 스프린트가 끝날 때 또는 주요 개발 주기가 끝날 때 개최되며 커뮤니케이션 채널을 여는 데 중요합니다. 제품 소유자가 제품 증분을 검토한 후에는 스크럼 팀이 회고전을 개최할 때입니다. 스크럼 소유자가 진행하는 이 회의에서 모두가 잘 된 점, 개선해야 할 점 또는 수행해야 하는 새로운 개입에 대한 피드백을 제공합니다. 이러한 회의는 최대 1.5시간이 소요될 수 있습니다. 완료된 스프린트의 프로세스, 인력 및 조직적 측면을 반영할 수 있는 좋은 기회입니다.

스크럼 마스터는 모든 팀원이 편안하게 피드백을 공유할 수 있는 환경을 만들어야 합니다. 모든 구성원은 나머지 팀과 관련하여 솔직한 의견을 공유할 수 있어야 합니다.

이 회의에서 평가할 수 있는 몇 가지 사항이 있습니다.

• 무엇이 잘되었고 무엇을 계속해야 하는가?
• 무엇이 잘 되지 않았으며 어떻게 개선할 수 있습니까?
• 팀원이 시작할 수 있는 새로운 작업은 무엇이며 그 이유는 무엇입니까?

 

가장 일반적인 설정은 각 팀 구성원이 범주당 5개의 항목을 나열하는 것입니다. 그런 다음 투표를 통해 팀은 새 스프린트 프로세스에 포함될 세 가지 개선 사항을 결정할 수 있습니다. 여기에서 일반적인 함정 중 하나는 한 번에 너무 많이 변경하려고 시도하여 원하는 프로세스로 이어지지 않는다는 것입니다. 모든 개선점은 전체 팀의 책임이지만 각 개선점에 소유자를 지정하여 모니터링하는 것이 편리합니다.

Daily Stand-Up
Daily Stand-Up 회의에서 스크럼 팀 구성원은 자신의 진행 상황을 팀과 공유합니다. 이 회의에는 일반적으로 개발자가 참석하지만 PO도 환영합니다. 모든 개발자는 다음을 공유합니다.

• 나는 어제 무엇을 했는가?
• 오늘은 무엇을 할까요?
• 나를 방해하는 것, 장애물은 무엇입니까?

 

모든 사람이 물리적으로 일어서야 하는 회의를 개최하는 것이 빠르고 효과적이라는 것이 입증되었습니다. 스탠드업 회의가 지정된 15분을 초과하지 않도록 하려면 그러한 회의를 개최하기 위한 몇 가지 규칙을 다루는 것이 중요합니다. 이 회의의 목표는 스크럼 마스터를 업데이트하는 것이 아니라 팀원들에게 알리는 것입니다. 이 회의는 해결책을 자세히 설명하거나 문제를 해결하기 위한 것이 아니라 의견이나 도움이 필요한 경우 다른 사람에게 알리기 위한 것입니다. 또한 팀은 일반적으로 계획된 항목과 완료된 항목의 목록(일반적으로 번다운 차트라고 함)을 살펴봅니다. 이 목록은 완료된 작업량과 스프린트 종료 시 필요한 총 작업량을 측정합니다.

대규모 애자일 팀의 경우 일일 스탠드업이 15분 제한을 초과하는 경향이 있습니다. 이 문제를 해결하기 위해서는 스크럼 마스터가 주도적으로 스크럼 보드의 사용자 스토리를 살펴보고 팀원을 개입시키지 않고 사용자 스토리의 상태를 브리핑해야 합니다. 항목을 오른쪽에서 왼쪽으로 논의하면(예: 완료, 진행 중 및 신규 항목 처리) 가장 중요한 항목이 먼저 다루어집니다.

 

각 개발자에게 모든 단일 사용자 스토리의 상태를 보고하도록 요청하는 것은 효율적이지 않을 수 있습니다. 여러 개발자가 참여하는 복잡한 사용자 스토리의 경우 반복을 피하십시오. 스크럼 마스터가 보고서 부분을 인계하고 다른 사람들에게 이러한 복잡한 항목의 상태를 알리도록 하십시오.

---