agile methodology beginner s guide agile method
애자일 방법론에 대한 완벽한 가이드 : (20 개 이상의 자세한 애자일 스크럼 방법론 자습서)
이것은 소프트웨어 개발자와 테스터가 매우 유명한 소프트웨어 개발 및 테스트를위한 Agile SCRUM 방법론 . 전체 프로세스의 실제 예와 함께 Agile Scrum 프로세스에서 사용되는 기본적이지만 중요한 용어를 배웁니다.
편의를 위해이 시리즈의 모든 애자일 자습서를 나열했습니다. 그들이 당신에게 큰 도움이되기를 바랍니다.
항목은 다룹니다: 애자일이란 무엇입니까, 스크럼이란 무엇입니까, 소프트웨어 개발 및 테스트의 애자일 방법론, 애자일 테스트, 애자일 스크럼 프로세스, 스크럼 팀 및 스크럼 마스터를 사용한 스크럼 방법론.
학습 내용 :
애자일 방법론 자습서 목록
튜토리얼 # 1 : 애자일 스크럼 방법론 (이 튜토리얼)
튜토리얼 # 2 : 애자일 선언
튜토리얼 # 3 : 스크럼 팀과 그들의 역할과 책임
튜토리얼 # 4 : 스크럼 아티팩트
튜토리얼 # 5 : 스크럼 이벤트
튜토리얼 # 6 : 스크럼에서 결함 심사
튜토리얼 # 7 : 자급 자족 스크럼 팀
튜토리얼 # 8 : 세 가지 아미고 원칙
튜토리얼 # 9 : SAFe – 확장 된 애자일 프레임 워크
튜토리얼 # 10 : 애자일 스크럼 퀴즈
더 많은 권장 애자일 스크럼 자습서 :
튜토리얼 # 11 : 최고의 애자일 추정 기법
튜토리얼 # 12 : 애자일 폭포 하이브리드 모델
튜토리얼 # 13 : 칸반 대 스크럼 대 애자일
튜토리얼 # 14 : JIRA Agile 튜토리얼
튜토리얼 # 15 : 애자일 회고 회의
튜토리얼 # 16 : SCRUM에서 비즈니스 분석가의 역할
튜토리얼 # 17 : 스크럼에서 QA의 역할
도구 및 인터뷰 질문 :
튜토리얼 # 18 : 애자일 테스트 도구
튜토리얼 # 19 : 최고의 애자일 프로젝트 관리 도구
튜토리얼 # 20 : 애자일 인터뷰 질문
튜토리얼 # 21 : 스크럼 인터뷰 질문
시리즈의 첫 번째 자습서 인 Agile Scrum 소개부터 시작하겠습니다.
애자일 개발 소개
소프트웨어 개발의 민첩성 :
Agile은 세계에서 가장 널리 사용되고 인정받는 소프트웨어 개발 프레임 워크 중 하나입니다.
대부분의 조직은 어떤 형태로든이를 채택했지만 채택 프로그램의 성숙도에는 아직 갈 길이 멀다. 이 튜토리얼 시리즈의 유일한 목표는 기술 및 비 기술 전문가를 Agile World에 온 보딩하는 것입니다.
애자일 사용의이면에있는 철학, 장점 및 실행 방법을 이해할 때까지 애자일 여정을 단계별로 안내합니다. 이 시리즈는 독자들이 애자일 및 스크럼 학습을 자신의 작업에 적용 할 수 있도록 준비하고 지원하는 것을 목표로합니다.
이 특정 자습서는 Agile이 필요한 이유와 생성 방법을 설명하는 데 전념합니다. 여기서 기본은 소프트웨어 개발 산업에서 Agile Adoption의 개념을 이해하는 것입니다.
애자일의 역사
애자일은 서로 다른 개발 방법론 배경을 가진 17 명이한데 모여서 개발 시간을 단축하고 문서 작업량을 줄일 수있는 소프트웨어 개발에 대한 가능한 대안 솔루션이 있는지 브레인 스토밍을하던 어느 날에 태어났습니다.
그 당시 소프트웨어 개발은 너무 오래 진행되어 프로젝트를 제공 할 준비가되었을 때 비즈니스가 진행되고 요구 사항이 변경되었습니다. 따라서 프로젝트는 정의 된 목표를 달성 할 수 있었음에도 비즈니스 요구를 충족 할 수 없었습니다.
따라서 서로 다른 소프트웨어 엔지니어링 기술의 챔피언이 모였고 회의의 최종 결과는이 시리즈의 다음 자습서에서 자세히 논의 할 '애자일 선언문'이라고 불렀습니다.
그러나 그날 태어난 애자일은 오늘날 우리가 조직에서 보는 것과는 다릅니다. 전문가들이 동의 한 방법론은 '가볍고'빠르다. 그러나이 회의에서 얻은 주된 승리는 제품의 빠른 제공과 지속적인 피드백이 소프트웨어 개발에서 성공을 거두는 열쇠라는 생각이었습니다.
기존의 폭포수 기술은 너무 번거롭고 최종 제품이 제공 될 준비가 될 때까지 피드백을 제공하지 않았습니다. 이것은 과정 수정의 범위가 없었고 전체 제품이 준비 될 때까지 고객이 진행 상황을 볼 수 없음을 의미했습니다. 그리고 그것은이 전문가들이 피하고 싶었던 것입니다.
그들은 이후 단계에서 재 작업 비용을 피하기 위해 지속적인 피드백을받을 수있는 솔루션을 원했습니다.
애자일 도전
당시 기존의 폭포수 기술은 너무 번거롭고 최종 제품이 제공 될 준비가 될 때까지 피드백을 제공 할 수 없었습니다. 팀이 처음에 한 단계를 완전히 완료하고 그 후에야 다음 단계로 진행했기 때문에 개발의 폭포 모델이라고 불렀습니다.
이것은 과정 수정의 범위가 없었고 전체 제품이 준비 될 때까지 고객이 진행 상황을 볼 수 없음을 의미했습니다. 그리고 그것은이 전문가들이 피하고 싶었던 것입니다. 그들은 이후 단계에서 재 작업 비용을 피하기 위해 지속적인 피드백을받을 수있는 솔루션을 원했습니다.
그렇기 때문에 애자일은 지속적인 피드백과 전달 속도에 관한 것만 큼 적응적이고 지속적인 개선에 관한 것입니다.
애자일 약속이란 무엇입니까?
애자일은 소프트웨어 개발에 설정된 관행을 적용하는 것만이 아닙니다. 또한 팀의 사고 방식에 변화를 가져와 더 나은 소프트웨어를 구축하고 함께 일하며 결국 행복한 고객이되도록 유도합니다.
애자일 가치와 원칙을 통해 팀은 더 나은 소프트웨어를 구축하는 데 초점을 맞추고 사고 프로세스를 변경할 수 있습니다.
애자일이란 정확히 무엇입니까?
애자일은 일련의 규칙이 아닙니다. 애자일은 일련의 지침이 아닙니다. 애자일은 방법론도 아닙니다. 오히려 Agile은 계획 및 프로세스에 대한 유연성, 적응성, 커뮤니케이션 및 작업 소프트웨어를 장려하는 일련의 원칙입니다. 이는 애자일 선언문에서 매우 간결하게 포착됩니다.
애자일 소프트웨어 개발을 통해 팀은 복잡한 프로젝트를 개발할 때보다 효율적이고 효과적으로 협력 할 수 있습니다. 그것은 쉽게 채택되고 훌륭한 결과를 보여주는 반복적이고 점진적인 기술을 실행하는 관행으로 구성됩니다.
애자일을 실행에 적용하기 위해 다양한 애자일 기반 방법과 방법이 있습니다. 이러한 방법과 방법론은 소프트웨어 설계 및 아키텍처, 개발 및 테스트에서 프로젝트 관리 및 제공에 이르기까지 소프트웨어 개발 산업의 모든 요구를 충족시킵니다.
뿐만 아니라 애자일 방법 및 방법론은 각 제공의 필수 부분으로 프로세스 개선의 범위를 엽니 다.
Agile은 자급 자족하고 교차 기능을 수행하는 팀이 반복을 통해 지속적으로 제공하기 위해 노력하고 최종 사용자로부터 피드백을 수집하여 프로세스 전반에 걸쳐 진화하는 소프트웨어 개발 접근 방식입니다.
애자일을 연습하는 방법?
다양한 다양한 산업에서 실제로 사용되고있는 다양한 애자일 방법론이 있습니다.
그러나 그중 가장 인기있는 방법은 다음과 같습니다.
- 스크럼
- Kanban
- 익스트림 프로그래밍
이러한 모든 방법론은 린 소프트웨어 개발에 초점을 맞추고 더 나은 소프트웨어를 효과적이고 효율적으로 구축하는 데 도움이됩니다.
이것이 바로 Agile 소개입니다. 이 부분은 팀이 애자일 모드와 사고 방식으로 작업하기 위해 채택해야하는 핵심 가치와 원칙을 이해하는 데 도움이되도록 구성되었습니다.
기민한 방법론
애자일 모델 소개 :
xml 파일 보는 방법
우리 모두 알고 있듯이 Agile은 소프트웨어 개발 방법론입니다.
또한 애자일 창립자들이 애자일 선언문에서 언급 한 가치와 원칙에 대해서도 배웠습니다. 초기 논의에서 우리는 또한 애자일 모델과 기존 폭포 모델의 차이점에 대해 다루었습니다.
이 튜토리얼에서는 애자일 방법론의 장단점에 대해 알게 될 것입니다.
스크럼이 무엇인지 볼까요? 애자일과 어떻게 다른가요? 그런 다음 여러 조직에서 사용하는 다양한 애자일 방법론과이를 사용하여 애자일을 구현하는 방법을 이해합니다.
또한 이러한 방법론의 차이점과 장단점을 이해할 수있을 것입니다.
애자일 방법론의 장점
다음은 애자일 방법론의 다양한 장점입니다.
- 고객은 각 반복 / 스프린트가 끝날 때마다 프로젝트 진행 상황을 지속적으로 확인합니다.
- 각 스프린트는 고객이 제공 한 완료 정의에 따라 기대를 충족하는 작업 소프트웨어를 고객에게 제공합니다.
- 개발 팀은 변화하는 요구 사항에 상당히 대응하고 있으며 고급 개발 단계에서도 변경 사항을 수용 할 수 있습니다.
- 고객이 계속 참여하도록하는 지속적인 양방향 커뮤니케이션이 있기 때문에 모든 이해 관계자 (비즈니스 및 기술)가 프로젝트 진행 상황을 명확하게 볼 수 있습니다.
- 제품의 디자인은 효율적이고 비즈니스 요구 사항을 충족합니다.
애자일 방법론의 단점
애자일 방법론에는 몇 가지 장점이 있지만 여기에는 몇 가지 단점도 있습니다.
그들은:
#1) 애자일 팀이이를 애자일에 문서가 필요하지 않다고 잘못 해석 할 수있는 포괄적 인 문서는 선호되지 않습니다. 따라서 문서화에 대한 엄격함이 사라집니다. 계속 진행하기에 충분한 정보인지 지속적으로 자문하여이를 피해야합니다.
#두) 때로는 프로젝트를 시작할 때 요구 사항이 명확하지 않습니다. 팀은 계속 진행하여 고객의 비전이 재조정되었음을 알 수 있으며 이러한 상황에서 팀은 많은 변경 사항을 통합해야하며 최종 결과도 측정하기 어렵습니다.
애자일 방법론의 유형
실제로 전 세계적으로 몇 가지 애자일 방법론이 있습니다. 가장 인기있는 네 가지 항목에 대해 자세히 알아 보겠습니다.
# 1) 스크럼
스크럼은 가장 인기있는 애자일 프레임 워크로 쉽게 간주 될 수 있습니다. 대부분의 실무자들은‘스크럼’이라는 용어를‘민첩’과 동의어로 간주합니다. 그러나 그것은 오해입니다. 스크럼은 애자일을 구현할 수있는 프레임 워크 중 하나 일뿐입니다.
스크럼이라는 단어는 스포츠 럭비에서 유래했습니다. 플레이어가 서로 맞물린 자세로 모여 상대를 밀어 붙이는 곳. 각 플레이어는 자신의 위치에서 정해진 역할을 가지며 상황의 요구에 따라 공격과 방어를 모두 할 수 있습니다.
마찬가지로 IT의 스크럼은 세 가지 구체적이고 명확하게 정의 된 역할을 가진 자율 관리 형 개발 팀을 믿습니다. 이러한 역할에는 다음이 포함됩니다. 제품 소유자 (PO), 스크럼 마스터 (SM) 및 프로그래머와 테스터로 구성된 개발 팀 . 그들은 스프린트라고하는 반복적 인 타임 박스 기간으로 함께 작동합니다.
첫 번째 단계는 PO에서 제품 백 로그를 생성하는 것입니다. 스크럼 팀이해야 할 일 목록입니다. 그런 다음 스크럼 팀은 최우선 순위 항목을 선택하고 스프린트라는 시간 상자 내에 완료하려고합니다.
이 모든 것을 기억하는 더 쉬운 방법은 3-3-5 프레임 워크를 암기하는 것입니다. 이는 스크럼 프로젝트에 3 개의 역할, 3 개의 아티팩트 및 5 개의 이벤트가 있음을 의미합니다.
이것들은 -
역할 : PO, 스크럼 마스터 및 개발 팀.
아티팩트 : 제품 백 로그, 스프린트 백 로그과제품 증분.
이벤트 : 스프린트, 스프린트 계획, 일일 스크럼, 스프린트 검토 및 스프린트 회고.
우리는 후속 튜토리얼에서 각각에 대해 더 자세히 알게 될 것입니다.
# 2) Kanban
Kanban은 카드를 의미하는 일본어 용어입니다. 이 카드에는 소프트웨어에서 수행 할 작업에 대한 세부 정보가 포함되어 있습니다. 목적은 시각화입니다. 모든 팀원은 이러한 시각 자료를 통해 수행해야 할 작업을 알고 있습니다.
팀은 이러한 Kanban 카드를 사용하여 지속적 배포를합니다. Scrum과 마찬가지로 Kanban은 팀이 효과적으로 작업하도록 돕고 자체 관리 및 협업 팀을 촉진합니다.
그러나이 둘 사이에도 차이가 있습니다. 스크럼 스프린트 중에 팀에서 작업중인 항목이 고정되어 스프린트에 항목을 추가 할 수없는 반면 Kanban에서는 사용 가능한 용량이있는 경우 항목을 추가 할 수 있습니다. 이는 요구 사항이 자주 변경 될 때 특히 유용합니다.
유사하게, 또 다른 차이점은 스크럼이 PO, 스크럼 마스터 및 개발 팀의 역할을 정의했지만 Kanban에는 이러한 사전 정의 된 역할이 없다는 것입니다.
또 다른 차이점은 스크럼이 제품 백 로그의 우선 순위를 제안하지만 Kanban에는 그러한 요구 사항이 없으며 전적으로 선택 사항이라는 것입니다. 따라서 Kanban은 조직이 덜 필요하고 비 부가가치 활동을 피하며 변화에 대한 대응이 필요한 프로세스에 적합합니다.
# 3) 린
Lean은 폐기물 감소에 초점을 맞춘 철학입니다. 어떻게하나요?
린에서는 프로세스를 부가가치 활동, 비 부가가치 활동 및 필수 비 부가가치 활동으로 나눕니다. 비 부가가치 활동으로 분류 될 수있는 모든 활동은 낭비이며 프로세스에서 낭비를 제거하여 더 효율적으로 만들어야합니다.
더 간결한 프로세스는 팀 목표를 달성하는 데 도움이되지 않는 작업에 더 빨리 전달되고 낭비되는 노력을 줄여줍니다. 이는 소프트웨어 개발주기의 모든 단계를 최적화하는 데 도움이됩니다. 그렇기 때문에 린 (Lean) 원칙이 린 제조에서 소프트웨어 개발에 적용되었습니다.
린 소프트웨어 개발은 아래에 표시된 7 가지 린 원칙을 적용하여 모든 IT 프로젝트에서 사용할 수 있습니다.
이름에서 알 수 있듯이 이것들은 매우 자명합니다. 낭비를 제거하는 것이 첫 번째이자 가장 중요한 린 원칙이며이를 수행하는 방법을 확인하고 활동을 가치 및 비 부가가치로 분류합니다.
비 부가가치 활동은 코드의 일부가 될 수 있으며, 코드의 안정성을 떨어 뜨리고 수반되는 노력을 늘리며 정당한 비즈니스 가치를 추가하지 않으면 서 많은 시간을 차지할 수 있습니다. 또한 모호한 사용자 스토리이거나 열악한 테스트이거나 큰 그림에서 필요하지 않은 기능을 추가 할 수도 있습니다.
학습을 증폭시키는 두 번째 원칙은 팀이 빠르게 변화하는 환경에서 제품을 제공하기 위해 다양한 기술이 필요하기 때문에 새로운 기술이 빠르게 등장하므로 이해하기 쉽습니다.
늦게 결정을 내리는 것은 예상되는 변경 사항이있는 경우와 같이 재 작업을 줄이는 상황에서 보람이있을 수 있으며, 비즈니스 요구 사항이 변경 될 때 팀이 작업을 다시 수행 할 필요가 없도록 지연하는 것이 좋습니다.
그러나 팀이이를 더 빠르게 제공하는 네 번째 원칙과 균형을 이루어야하기 때문에 여기에는 항상 절충점이 있습니다. 결정 지연은 전체 전달에 영향을주지 않아야하며 작업 속도를 줄여서는 안됩니다. 한 눈은 항상 완전한 그림에 있어야합니다.
팀에 권한을 부여하는 것도 요즘 매우 일반적이며 이는 심지어 애자일이 제안하는 것입니다. 권한이 부여 된 팀은 더 책임감 있고 더 빨리 결정을 내릴 수 있습니다. 권한이 부여 된 팀의 주인 의식은 더 나은 결과로 이어집니다. 팀에 권한을 부여하려면 스스로 조직하고 스스로 결정을 내릴 수 있어야합니다.
따라서 우리는 린과 애자일이 하나의 뚜렷한 차이점과 많은 공통점을 가지고 있음을 알 수 있습니다. 린 팀은 제품을 개선하는 데 도움을 줄 수 있지만, 애자일 팀은 실제로 제품을 빌드하는 팀입니다.
# 4) 익스트림 프로그래밍 (XP)
익스트림 프로그래밍은 또 다른 가장 인기있는 애자일 기술입니다. extremeprogramming.org에 따르면 첫 번째 XP 프로젝트는 1996 년 3 월 6 일에 시작되었습니다. 또한 XP가 커뮤니케이션, 단순성, 피드백, 존중 및 용기의 5 가지 방식으로 소프트웨어 프로젝트 개발에 영향을 미친다고 언급합니다. 이것을 XP의 가치라고합니다.
이 중에서 모든 것은 의사 소통으로 시작됩니다. XP 팀은 비즈니스 팀 및 동료 프로그래머와 정기적으로 협력하고 첫날부터 코드 작성을 시작합니다. 여기서 초점은 다른 시각 자료의 도움으로 가능한 한 대면 의사 소통에 있습니다.
익스트림 프로그래머는 간단한 코드를 작성하고 첫날부터 피드백을 받기 시작합니다. 초점은 초과하지 않거나 공유되지 않은 요구 사항을 예측하는 데 있습니다. 이것은 디자인을 단순하게 유지하고 요구 사항을 충족시킬 최소한의 제품을 생산합니다.
피드백은 팀이 더 나은 작업 품질을 개선하고 생산하는 데 도움이됩니다. 이것은 그들이 서로에게서 배우고 그들의 견해를 공유하는 방법을 배울 때 서로에 대한 존경심을 키우는 데 도움이됩니다.
이것은 또한 모든 사람의 최고의 아이디어를 모아 다른 사람들의 피드백을 받아 좋은 제품을 생산했다는 것을 알고 용기를줍니다. 따라서 그들은 또한 변경 사항을 포함하거나 작업에 대한 추가 피드백을받는 것을 두려워하지 않습니다.
이는 요구 사항이 자주 변경되는 프로젝트에서 특히 유용합니다. 지속적인 피드백은 팀이 용기를 가지고 이러한 변경 사항을 포함하는 데 도움이됩니다.
따라서 우리는 Scrum, XP, Kanban 및 Lean과 같은 다양한 애자일 방법론과 각각의 장단점을 보았습니다.
이제 우리는 그것들을 쉽게 구별 할 수 있고 그들 사이의 미묘한 차이를 인식 할 수 있습니다. 또한 이러한 각 방법론의 기본 사항을 배웠고 필요할 때 프로젝트에 적용하는 방법을 확인했습니다.
다음 부분에서는 스크럼에 대한 모든 것을 이해하겠습니다.
스크럼 방법론
SCRUM은 반복 모델과 증분 모델의 조합 인 애자일 방법론의 프로세스입니다.
전통의 주요 장애 중 하나 폭포 모델 첫 번째 단계가 완료 될 때까지 응용 프로그램은 다른 단계로 이동하지 않습니다. 그리고 우연히주기의 후반 단계에 약간의 변경 사항이있는 경우 이전 단계를 재검토하고 변경 사항을 다시 실행해야하므로 이러한 변경 사항을 구현하는 것이 매우 어려워집니다.
SCRUM의 주요 특징은 다음과 같습니다.
- 자기 조직화되고 집중된 팀.
- 거대한 요구 사항 문서가 없으며 오히려 매우 정확하고 요점 이야기가 있습니다.
- 교차 기능 팀은 단일 단위로 함께 작업합니다.
- 기능을 이해하려면 사용자 담당자와 긴밀한 커뮤니케이션을하십시오.
- 최대 1 개월의 명확한 타임 라인이 있습니다.
- 한 번에 전체 '일'을 수행하는 대신 스크럼은 주어진 간격으로 모든 작업을 수행합니다.
- 커밋하기 전에 리소스 기능과 가용성을 고려합니다.
이 방법론을 잘 이해하려면 SCRUM의 주요 용어를 이해하는 것이 중요합니다.
또한 읽으십시오 => Agile Scrum 프로세스를 사용하여 단기간에 고 가치 소프트웨어 기능을 제공하는 방법
중요한 SCRUM 용어
1) 스크럼 팀
스크럼 팀은 + 또는 – 두 명의 멤버로 구성된 7 명으로 구성된 팀입니다. 이 구성원은 역량의 혼합이며 제품 소유자 및 스크럼 마스터와 함께 개발자, 테스터, 데이터베이스 담당자, 지원 담당자 등으로 구성됩니다.
이 모든 구성원은 반복적이고 명확한 간격을 위해 긴밀한 협력으로 협력하여 해당 기능을 개발하고 구현합니다. SCRUM 팀 좌석 배치는 상호 작용에서 매우 중요한 역할을합니다. 그들은 칸막이 나 캐빈에 앉지 않고 거대한 테이블에 앉습니다.
2) 스프린트
Sprint는 작업이 완료되고 검토 준비 또는 프로덕션 배포 준비가되어야하는 미리 정의 된 간격 또는 시간 프레임입니다. 이 시간 상자는 일반적으로 2 주에서 1 개월 사이입니다.
휴대폰을위한 최고의 원격 스파이웨어
우리가 1 개월 스프린트주기를 따른다고 말하는 일상 생활에서, 그것은 단순히 우리가 한 달 동안 작업을하고 그 달 말까지 검토 할 준비를한다는 것을 의미합니다.
3) 제품 소유자
제품 소유자는 개발할 응용 프로그램의 주요 이해 관계자 또는 주요 사용자입니다. 제품 소유자는 고객 측을 대표하는 사람입니다. 그 / 그녀는 최종 권한을 가지고 있으며 항상 팀에서 사용할 수 있어야합니다.
누구든지 설명이 필요한 의심이있을 때 연락 할 수 있어야합니다. 제품 소유자는 스프린트 중간에 또는 스프린트가 이미 시작되었을 때 새로운 요구 사항을 할당하지 않고 이해하는 것이 중요합니다.
4) 스크럼 마스터
스크럼 마스터는 스크럼 팀의 촉진자입니다. 그는 스크럼 팀이 생산적이고 진보적인지 확인합니다. 장애가 발생하면 스크럼 마스터가 후속 조치를 취하고 팀을 위해 해결합니다. SCRUM Master는 PO와 팀 간의 중재자입니다.
그 / 그녀는 Sprint의 진행 상황을 PO에 계속 알려줍니다. 팀에 장애물이나 우려 사항이있는 경우 PO와 논의하여 해결합니다. 팀의 Daily Standup과 마찬가지로 PO와 함께 SCRUM Master의 스탠드 업이 매일 발생합니다.
추천 읽기 => 애자일 테스트 세계에서 훌륭한 팀 멘토, 코치 및 진정한 팀 수비수가되는 방법?
5) 비즈니스 분석가 (BA)
비즈니스 분석가는 SCRUM에서 매우 중요한 역할을합니다. 이 사람은 요구 사항 문서 (사용자 스토리가 생성되는 기준)에서 요구 사항을 마무리하고 초안을 작성하는 책임이 있습니다.
사용자 스토리 / 승인 기준에 모호한 부분이있는 경우 기술 (SCRUM) 팀에서 접근 한 다음 PO로 가져 가거나 가능한 경우 스스로 해결합니다. 대규모 프로젝트에서는 BA가 1 개 이상있을 수 있지만 소규모 프로젝트에서는 SCRUM Master가 BA 역할도 할 수 있습니다.
프로젝트 킥이 시작될 때 항상 BA를 취득하는 것이 좋습니다.
6) 사용자 스토리
사용자 스토리는 구현해야하는 요구 사항 또는 기능에 불과합니다.
스크럼에는 이러한 거대한 요구 사항 문서가 없지만 요구 사항은 일반적으로 다음과 같은 형식을 갖는 단일 단락으로 정의됩니다.
로
나는 원한다
달성하기 위해
예를 들어 :
관리자로서 사용자가 무단 액세스를 제한하기 위해 3 회 연속 잘못된 비밀번호를 입력하는 경우 비밀번호 잠금을 설정하고 싶습니다.
준수해야 할 사용자 스토리의 몇 가지 특성이 있습니다. 사용자 스토리는 짧고 현실적이어야하며 예측 가능하고 완전하며 협상 가능하고 테스트 가능해야합니다. 사용자 스토리는 스프린트 중간에 변경되거나 변경되지 않습니다.
PO가 적절한 수락 기준 세트로 사용자 스토리의 초안을 올바로 작성했는지 확인하는 것은 SCRUM 마스터와 BA (해당되는 경우)의 책임입니다.” 스프린트 릴리스에 영향을 미칠 변경 사항이있는 경우 해당 스토리는 스프린트에서 제외되거나 사용 가능한 시간에 따라 수행됩니다.
모든 사용자 스토리에는 팀이 잘 정의하고 이해해야하는 수용 기준이 있습니다.
승인 기준은 지원 문서를 제공하는 사용자 스토리를 자세히 설명합니다. 사용자 스토리를 더욱 구체화하는 데 도움이됩니다. 팀의 누구나 허용 기준을 작성할 수 있습니다. 테스트 팀은 이러한 허용 기준에 따라 테스트 케이스 / 조건을 기반으로합니다.
7) 에픽
에픽은 모호한 사용자 스토리이거나 정의되지 않고 향후 스프린트를 위해 보관되는 사용자 스토리라고 말할 수 있습니다.
인생과 연관 시키려고 노력하고 휴가를 떠난다 고 상상 해보세요. 다음 주에 갈 때 호텔 예약, 관광, 여행자 수표 등 모든 것이 준비되어 있습니다.하지만 내년 휴가 계획은 어떻습니까? XYZ 장소에 갈 수 있다는 막연한 생각 만 있지만 자세한 계획은 없습니다.
Epic은 내년의 휴가 계획과 똑같습니다. 당신이 가고 싶을 수도 있다는 것을 알고 있지만, 언제, 누구와 함께이 모든 세부 사항을 지금은 알지 못하는 곳입니다.
비슷한 방식으로 세부 사항이 아직 알려지지 않은 미래에 구현해야하는 기능이 있습니다. 대부분의 기능은 Epic으로 시작하여 구현 가능한 스토리로 분류됩니다.
8) 제품 백 로그
제품 백로 그는 모든 사용자 스토리가 보관되는 일종의 버킷 또는 소스입니다. 이것은 제품 소유자가 관리합니다. 제품 백로 그는 비즈니스 요구에 따라 우선 순위를 지정하는 제품 소유자의 위시리스트로 상상할 수 있습니다.
계획 회의 (다음 섹션 참조) 동안 제품 백 로그에서 하나의 사용자 스토리를 가져온 다음 팀은 브레인 스토밍을 수행하고이를 이해하고 수정하고 제품 소유자의 개입으로 취할 사용자 스토리를 집합 적으로 결정합니다.
9) 스프린트 백 로그
우선 순위에 따라 제품 백 로그에서 사용자 스토리를 한 번에 하나씩 가져옵니다. 스크럼 팀은 이에 대한 브레인 스토밍을 통해 실행 가능성을 결정하고 특정 스프린트에서 작업 할 스토리를 결정합니다. 스크럼 팀이 특정 스프린트에서 작업하는 모든 사용자 스토리의 집합 목록을 스프린트 백 로그라고합니다.
10) 스토리 포인트
스토리 포인트는 사용자 스토리의 복잡성을 정량적으로 나타냅니다. 스토리 포인트를 기반으로 스토리에 대한 추정과 노력이 결정됩니다.
스토리 포인트는 상대적이며 절대적이지 않습니다. 예상과 노력이 정확한지 확인하려면 사용자 스토리가 크지 않은지 확인하는 것이 중요합니다. 사용자 스토리가 더 정확하고 작을수록 추정치가 더 정확 해집니다.
각 사용자 스토리는 피보나치 시리즈 (1, 2, 3, 5, 8, 13 & 21)를 기반으로 스토리 포인트에 할당됩니다. 숫자가 높을수록 복잡한 것이 이야기입니다.
정확히 말하면
- 1/2/3 스토리 포인트를 주면 스토리가 작고 복잡성이 낮음을 의미합니다.
- 5/8로 포인트를 주면 중간 콤플렉스이고
- 13과 21은 매우 복잡합니다.
여기서 복잡성은 개발과 테스트 노력으로 구성됩니다.
스토리 포인트를 결정하기 위해 스크럼 팀 내에서 브레인 스토밍이 이루어지고 팀이 함께 스토리 포인트를 결정합니다.
개발팀은 특정 스토리에 3 개의 스토리 포인트를 제공 할 수 있습니다. 그 이유는 3 줄의 코드 변경 일 수 있기 때문입니다. 그러나 테스트 팀은이 코드 변경이 더 큰 모듈에 영향을 미칠 것이라고 생각하기 때문에 8 개의 스토리 포인트를 제공합니다. 테스트 노력은 더 클 것입니다. 어떤 스토리 포인트를 제공하든 정당화해야합니다.
그래서이 상황에서 브레인 스토밍이 일어나고 팀은 하나의 스토리 포인트에 공동으로 동의합니다.
스토리 포인트를 결정할 때마다 아래 요소를 염두에 두십시오.
- 다른 애플리케이션 / 모듈과 스토리의 종속성.
- 자원의 기술 세트.
- 이야기의 복잡성.
- 역사적 학습.
- 사용자 스토리의 허용 기준.
특정 이야기를 알지 못한다면 크기를 조정하지 마십시오.
스토리가 = 또는> 8 포인트 일 때마다 2 개 이상의 스토리로 나뉩니다.
11) 번 다운 차트
번 다운 차트는 스크럼 작업의 예상 대 실제 노력을 보여주는 그래프입니다.
특정 스프린트에 대해 일상적인 작업을 추적하여 스토리가 커밋 된 스토리 포인트의 완료를 향해 진행되고 있는지 여부를 확인하는 추적 메커니즘입니다.
예 :이를 이해하려면 아래 그림을 확인하십시오.
나는 가정했다 :
- 2 주 스프린트 (10 일)
- 스프린트에서 실제로 작업하는 2 개의 리소스.
'이야기' ->이 열은 스프린트에 대한 사용자 스토리를 보여줍니다.
'직무' ->이 열에는 사용자 스토리와 관련된 작업 목록이 표시됩니다.
'노력' ->이 열은 노력을 보여줍니다. 이제이 측정은 작업을 완료하기위한 총 노력입니다. 특정 개인의 노력을 묘사하지 않습니다.
'1 일차 – 10 일차' ->이 열에는 스토리를 완료하는 데 남은 시간이 표시됩니다. 시간은 이미 완료된 시간이 아니라 아직 남은 시간입니다.
'예상 노력' -> 총 노력입니다. '시작'의 경우 전체 개별 작업의 합계입니다. SUM (C5 : C15)
1 일 동안 완료해야하는 총 노력 수는 70/10 = 7입니다. 따라서 1 일이 끝날 때 노력은 70 – 7 = 63으로 감소해야합니다. 비슷한 방식으로 모든 작업에 대해 계산됩니다. 예상 노력이 0이되어야하는 10 일까지의 일수 (16 행)
'실제 노력 남음' -> 이름에서 알 수 있듯이 스토리를 완성하기 위해 실제로 남은 노력입니다. 실제 노력이 예상보다 증가하거나 감소 할 수도 있습니다.
내장 함수와 Excel의 차트를 사용하여이 번 다운 차트를 만들 수 있습니다.
번 다운 차트 단계는 다음과 같습니다.
- 모든 이야기를 입력합니다 (A5 – A15 열).
- 모든 작업을 입력합니다 (B5 – B15 열).
- 요일을 입력합니다 (Day 1 – Day 10).
- 시작 노력을 입력합니다 (작업 C5 – C15 합산).
- 공식을 적용하여 매일 '예상 노력'을 계산합니다 (1 일 ~ 10 일). D15 (C16- $ C $ 16 / 10)에 수식을 입력하고 모든 요일 동안 드래그합니다.
- 매일 실제 노력을 입력하십시오. 남은 실제 작업량을 합산하려면 D17 (SUM (D5 : D15))에 수식을 입력하고 다른 모든 날에는 드래그합니다.
- 그것을 선택하고 다음과 같이 차트를 만듭니다.
12) 속도
스크럼 팀이 스프린트에서 보관하는 총 스토리 포인트 수를 Velocity라고합니다. 스크럼 팀은 속도로 판단되거나 참조됩니다. 하지만 여기서의 목표는 최대 스토리 포인트를 달성하는 것이 아니라 스크럼 팀의 편안함 수준을 존중하는 양질의 결과물을 제공하는 것임을 명심해야합니다.
예를 들어 : 특정 스프린트의 경우 : 총 사용자 스토리 수는 아래와 같이 스토리 포인트가있는 8 개입니다.
따라서 여기서 속도는 스토리 포인트의 합계 = 30이됩니다.
완료의 정의 :
Sprint는 모든 스토리가 완료되고 모든 개발, 연구, QA 작업이 '완료 됨'으로 표시되고 모든 버그가 수정 된 경우 완료로 표시되며, 그 외에는 나중에 수행 할 수있는 버그 (완전히 관련되지 않았거나 덜 중요 함) 뽑아서 백 로그에 추가하면 코드 검토 및 단위 테스트가 완료되고 예상 시간이 작업에 투입된 실제 시간을 충족했으며 가장 중요한 것은 성공적인 데모가 PO와 이해 관계자에게 제공되었습니다.
SCRUM 방법론에서 수행 한 활동
# 1) 기획 회의
계획 회의는 Sprint의 시작점입니다. 전체 스크럼 팀이 모이는 회의이며 SCRUM Master는 제품 백 로그의 우선 순위에 따라 사용자 스토리를 선택하고 팀이 브레인 스토밍합니다.
토론을 기반으로 스크럼 팀은 스토리의 복잡성을 결정하고 피보나치 시리즈에 따라 크기를 조정합니다. 팀은 사용자 스토리 구현을 완료하기 위해 수행 할 노력 (시간 단위)과 함께 작업을 식별합니다.
많은 경우, 계획 회의는 '사전 계획 회의'로 진행됩니다. 스크럼 팀이 공식적인 계획 모임에 참석하기 전에하는 숙제와 같습니다. 팀은 계획 회의에서 논의하고 싶은 종속성 또는 기타 요소를 기록하려고합니다.
# 2) 스프린트 태스크 실행
이름에서 알 수 있듯이 스크럼 팀이 작업을 수행하고 사용자 스토리를 '완료'상태로 만들기 위해 수행 한 실제 작업입니다.
# 3) 일일 스탠드 업
스프린트주기 동안, 스크럼 팀은 매일 15 분 (스탠드 업 콜이 될 수 있으며, 하루를 시작하는 데 권장 됨) 동안 만나고 3 점을 설명합니다.
- 팀원은 어제 무엇을 했습니까?
- 팀원은 오늘 무엇을 할 계획 이었습니까?
- 장애 (로드 블록)가 있습니까?
이 회의를 진행하는 것은 스크럼 마스터입니다. 팀원이 어떤 종류의 어려움에 직면 한 경우 스크럼 마스터가 해결을 위해 후속 조치를 취합니다. 스탠드 업에서는 보드도 검토되고 자체적으로 팀의 진행 상황을 보여줍니다.
# 4) 검토 회의
모든 스프린트주기가 끝날 때 SCRUM 팀은 다시 만나 제품 소유자에게 구현 된 사용자 스토리를 보여줍니다. 제품 소유자는 승인 기준에 따라 스토리를 교차 검증 할 수 있습니다. 이 회의를 주재하는 것은 다시 스크럼 마스터의 책임입니다.
또한 SCRUM 도구에서 Sprint가 닫히고 작업이 완료로 표시됩니다.
# 5) 회고전
소급 회의는 검토 회의 후에 발생합니다.
SCRUM 팀은 다음 사항을 만나 논의하고 문서화합니다.
- Sprint (모범 사례) 동안 잘 된 것은 무엇입니까?
- 스프린트에서 잘되지 않은 것은 무엇입니까?
- 교훈
- 액션 아이템.
스크럼 팀은 계속해서 모범 사례를 따르고 '모범 사례가 아님'을 무시하고 결과적으로 스프린트 중에 배운 교훈을 구현해야합니다. 회고 회의는 SCRUM 프로세스의 지속적인 개선을 구현하는 데 도움이됩니다.
프로세스는 어떻게 이루어 집니까? 예!
SCRUM의 기술 용어에 대해 읽었습니다. 예제를 통해 전체 과정을 보여 드리겠습니다.
예:
1 단계 : 제품 소유자 1 명, 스크럼 마스터 1 명, 테스터 2 명, 개발자 4 명, DBA 1 명으로 구성된 9 명의 SCRUM 팀을 구성 해 보겠습니다.
2 단계 : 스프린트는 4 주 주기로 결정됩니다. 따라서 6 월 5 일부터 4 일까지 1 개월 Sprint가 있습니다.일7 월.
3 단계 : 제품 소유자는 제품 백 로그에 우선 순위가 지정된 사용자 스토리 목록이 있습니다.
4 단계 : 팀은 4에서 만나기로 결정일'사전 계획'회의를 위해 6 월.
- 제품 소유자는 제품 백 로그에서 1 개의 스토리를 가져 와서 설명하고 팀에 맡겨 브레인 스토밍합니다.
- 전체 팀은 사용자 스토리를 명확하게 이해하기 위해 제품 소유자와 직접 논의하고 소통합니다.
- 비슷한 방식으로 다양한 다른 사용자 스토리가 촬영됩니다. 가능하다면 팀은 계속해서 스토리의 크기를 조정할 수 있습니다.
모든 논의가 끝난 후 개별 팀 구성원은 워크 스테이션으로 돌아가서
- 각 이야기에 대한 개별 작업을 식별하십시오.
- 그들이 일할 정확한 시간을 계산하십시오. 멤버가이 시간을 어떻게 마무리하는지 확인해 보겠습니다.
총 근무 시간 = 9
휴식 시간에 1 시간, 회의에 1 시간, 이메일, 토론, 문제 해결 등에 1 시간을 뺀 값입니다.
따라서 실제 근무 시간 = 6.
스프린트 중 총 영업일 수 = 21 일.
사용 가능한 총 시간 수 = 21 * 6 = 126.
회원은 2 일 = 12 시간 동안 휴가를가집니다.
실제 시간 수 = 126 – 12 = 114 시간.
이는 멤버가이 스프린트에 대해 실제로 114 시간 동안 사용할 수 있음을 의미합니다. 따라서 그는 총 114 시간에 도달하는 방식으로 개별 스프린트 작업을 세분화합니다.
5 단계 : 5 일일6 월에 전체 스크럼 팀이 '계획 회의'를 위해 만납니다.
- 제품 백 로그에서 사용자 스토리에 대한 최종 판정이 완료되고 스토리가 Sprint 백 로그로 이동됩니다.
- 각 스토리에 대해 각 팀원은 식별 된 작업을 선언합니다. 필요한 경우 해당 작업에 대해 토론하고 크기를 조정하거나 크기를 조정할 수 있습니다 (피보나치 시리즈를 기억하십시오 !!).
- 스크럼 마스터 또는 팀은 도구의 각 스토리에 대한 시간과 함께 개별 작업을 입력합니다.
- 모든 스토리가 완료되면 스크럼 마스터는 초기 Velocity를 기록하고 공식적으로 Sprint를 시작합니다.
6 단계 : Sprint가 시작되면 할당 된 작업에 따라 각 팀원이 해당 작업을 시작합니다.
7 단계 : 팀은 매일 15 분 동안 회의를 갖고 3 가지 사항을 논의합니다.
- 그들은 어제 무엇을 했습니까?
- 그들은 오늘 무엇을 할 계획입니까?
- 장애 (로드 블록)가 있습니까?
8 단계 : 스크럼 마스터는 'Burn down chart'의 도움으로 매일 진행 상황을 추적합니다.
9 단계 : 장애가있는 경우 스크럼 마스터가이를 해결하기 위해 후속 조치를 취합니다.
단계 # 10 : 켜짐 4일7 월, 팀은 검토 회의를 위해 다시 만납니다. 멤버가 제품 소유자에게 구현 된 사용자 스토리를 보여줍니다.
11 단계 : 5에일7 월, 팀은 회고전을 위해 다시 만납니다.
- 무엇이 잘 되었습니까?
- 잘되지 않은 것은 무엇입니까?
- 액션 아이템.
12 단계 : 6에일7 월, 팀은 다음 스프린트를위한 사전 계획 회의를 위해 다시 만나고주기는 계속됩니다.
SCRUM 활동 도구
스크럼 활동을 추적하는 데 광범위하게 사용할 수있는 몇 가지 도구가 있습니다.
그중 일부는 다음과 같습니다.
다음 튜토리얼에서는 효과적인 Agile Teams를 추진하는 개념 인 Agile Manifesto에 대해 설명 할 것입니다.
저자 정보 : 이 시리즈는 다음 STH 팀 구성원이 작성했습니다. Shruti Shrivastava – BFSI, 전자 상거래 및 B2B 도메인에서 9 년의 경험을 가진 전문 스크럼 마스터. Shruti는 자동화 테스트 및 주요 스크럼 팀의 전문가입니다.Anshul Kumar Srivastava – BFSI 및 통신 부문에서 7 년의 경험을 가진 결과 지향적 제품 관리 전문가이자 애자일 실무자입니다.