생산성을 높이고 고통을 덜면서 스크럼을 사용하는 방법

소프트웨어 개발을 다루는 것은 가장 깨끗하고 쉬운 일이 아닙니다. 여기에는 기술적인 문제와 비기술적인 문제 등 수많은 문제가 포함됩니다. 기술적 측면은 확실히 훨씬 더 복잡하고 어려운 기술이 필요하지만 동시에 올바른 전술과 도구를 사용하여 어떤 방식으로든 관리할 수 있습니다. 반면에 비기술적인 세계는 훨씬 더 많은 자유도를 가지고 있습니다. 그것은 인간의 본성과 마찬가지로 가변성과 예측 불가능성을 가지고 있습니다.

다른 제품 제조 프로세스와 마찬가지로 소프트웨어 개발 초기부터 수많은 모범 사례가 마련되고 테스트되었습니다. 민첩한 방법론은 주로 요구 사항의 극심한 가변성과 최종 제품 제공을 위한 가장 중요한 목표에 대한 집중 부족에 대처하는 일련의 다양한 방법입니다.

때로는 그러한 방법론이 원래 목적을 넘어서 최종 결과가 이상적이지는 않습니다. 스크럼은 이러한 방법론 중 하나입니다. 프레임워크로 더 설명됩니다. 이는 기본 원칙, 규칙, 이벤트 및 역할 세트를 기반으로 합니다. 우리는 이 글에서 이 프레임워크가 어떻게 판단력과 유연성을 가지고 사용될 수 있는지 논의하고 이상적이지 않을 수 있는 일부 엄격한 해석을 피할 수 있습니다.

스크럼에 대한 간략한 소개

애자일 방법론은 소위 "애자일 선언문"에 정의된 다음과 같은 일반 원칙을 기반으로 합니다.

• "프로세스와 도구를 통한 개인과 상호 작용"
• "포괄적인 문서를 통해 작동하는 소프트웨어"
• "계약 협상을 통한 고객 협업"
• "계획에 따라 변화에 대응"

(출처: 애자일 선언문 )

애자일 선언문에 따르면 위의 설명에서 오른쪽 항목이 중요하지만 왼쪽 항목이 더 중요합니다.

개발 프로세스의 관점에서 볼 때 민첩한 방법론은 모두 고전적인 폭포수 모델 대신 반복적이고 점진적인 프로세스를 의미합니다. 전체 개발은 여러 증분 단계로 구성되며 각 단계는 전체를 특징짓는 동일한 단계로 구성됩니다. 폭포수 프로젝트: 요구 사항, 분석, 디자인 및 코딩을 수집합니다. 즉, 각 단계는 전체 개발의 증분을 나타내며 그 자체로 전체 프로젝트로 볼 수 있습니다.

스크럼 방법론은 위의 원칙에 대한 특별한 편향으로 볼 수 있습니다. 스크럼은 팀이 자체 프로세스를 사용하여 특정 소프트웨어 제품을 개발할 수 있는 프레임워크입니다. 기본적으로 Roles , Events 및 Artifacts 가 특징입니다.

역할은 다음과 같습니다:

• 팀 : 분석가, 개발자, 테스터 및 일반적으로 프로젝트에 관련된 모든 종류의 전문가가 포함될 수 있습니다. 스크럼 계획 세션의 경계 내에서 자체 구성 방식으로 작동해야 합니다.

• 스크럼 마스터 : 모든 스크럼 프로세스를 조정하고 회의를 조직하는 등의 작업을 수행합니다.

• 제품 소유자 : 제품에 대한 책임을 지는 사람입니다. 그는 필요한 모든 기능이 명확하게 표현된 소위 제품 백로그를 관리합니다. 팀과 논의하고 도움을 받을 수 있지만 책임은 전적으로 본인에게 있습니다.

  
  

이벤트는 다음과 같습니다:

• 스프린트 : 반복 개발의 단일 증분을 나타냅니다. 보통 2주에서 한 달 정도 지속됩니다.

• 스프린트 계획 : 2주 스프린트의 경우 최대 4시간, 한 달 스프린트의 경우 최대 8시간 동안 진행되는 회의입니다. 스크럼 마스터가 구성하고 일정을 정하며 팀과 제품 소유자를 포함합니다. 이 회의에서는 현재 스프린트에서 개발될 제품 백로그 의 여러 기능이 선택, 평가 및 논의됩니다. 기능은 우선순위에 따라 선택됩니다.

• 일일 스크럼 회의 : 15분 이하의 일일 회의입니다. 스크럼 마스터가 일정을 정합니다. 이러한 회의에서 각 팀원은 현재 작업을 수행하기 위해 수행한 작업, 발생한 문제 및 발생할 수 있는 어려움을 극복하는 방법을 설명합니다. 스크럼 마스터는 이러한 회의의 일정과 조정 및 올바른 실행을 관리합니다.

• The Sprint Review : 이번 봄학기 말에 열리는 회의입니다. 2주 스프린트의 경우 2시간, 1개월 스프린트의 경우 4시간이 소요됩니다. 스크럼 마스터가 구성하며 참가자는 스크럼 팀, 스크럼 마스터, 제품 소유자 및 제품 소유자의 결정에 따라 필요한 모든 이해 관계자입니다. 현재 증분에 대해 논의합니다. 무엇이 잘됐는지, 무엇이 잘못되었는지 간략하게 설명하고, 마지막에 필요한 경우 제품 백로그를 업데이트합니다.

• 스프린트 회고전 : 2주 스프린트의 경우 1시간, 1개월 스프린트의 경우 2시간 회의입니다. 이는 스프린트 검토 직후와 다음 스프린트 계획 전에 발생합니다. 이 회의에서는 지난 반복의 경험을 바탕으로 최종 제품의 품질을 개선하고 추가하기 위한 모든 조치에 대해 논의하고 다음 스프린트를 계획합니다.

  
  

유물은 다음과 같습니다

• 제품 백로그 : 제품의 모든 요구 사항을 포함하는 진화하는 문서입니다. 각 항목은 사용자 스토리라고 하며 설명, 주문, 견적, 가치와 같은 속성을 갖습니다. 순서가 높은 항목일수록 더 명확하고 상세합니다.
• 스프린트 백로그 : 필요한 계획과 결합된 다음 스프린트를 위해 선택된 제품 백로그 항목을 포함합니다.
• 사용자 스토리 : 위에서 말했듯이 사용자 스토리는 제품 백로그의 항목입니다. 사용자 스토리는 다음과 같은 일반적인 텍스트 구조를 따릅니다. " <종류 OS 사용자> 로서 나는 <일부 작업을 수행> 하여 <목표를 달성할 수 있습니다>. 또한 각각 다음과 같은 여러 가지 허용 기준이 있어야 합니다. 다음 스키마: <일부 전제조건>이 주어지면 <사용자가 어떤 작업을 수행할 때 > Then <일부 시스템 상태 변경이 발생합니다>.
• 번다운 차트(Burn-Down Chart) : 가로축은 시간을 나타내고, 세로축은 시간의 각 단계마다 수행해야 할 남은 작업량을 나타내는 차트입니다. 작업량은 소위 스토리 포인트 로 측정할 수 있습니다. 스토리포인트는 기술, 복잡성, 도구 등 개발 작업에 영향을 미칠 수 있는 모든 변수를 고려하는 작업 측정 단위입니다.
• Increment : 지금까지의 총 증분입니다. 즉, 지금까지 완료된 제품 백로그 항목과 지난 반복에서 이미 완료된 다른 모든 항목의 합계입니다.

스크럼을 어떤 형태의 교리와 혼동하지 마십시오

위에 나열된 항목을 전문가 그룹이 운영할 수 있는 기반으로 간주할 수 있습니다. 유용한 도구로 보일 수 있지만 실제로 프로젝트에서 결속력, 상호 소통 및 효율성을 가져오는 것은 바로 사람 자신입니다. 사실, 이러한 모든 처방을 엄격히 준수하고 스크럼 마스터의 모든 헌신에도 불구하고 프로젝트는 혼란에 빠져 비참하게 실패할 수 있습니다.

이는 사람들이 규칙, 방법론, 프레임워크를 인간을 올바른 길로 이끄는 일종의 신성한 엔진과 혼동하는 경우가 많기 때문입니다. 이는 일반적인 심리적 결함입니다. 매우 중요한 고려사항은 현실은 이론과 다르며 매우 복잡하고 야생적인 동물이라는 점이다. 규칙과 패턴 목록으로 그것을 길들일 수 있다고 생각한다면 실패할 운명입니다.

스크럼의 실제 목적은 개발 과정에서 "배경 소음"의 양을 최소화하고 가장 중요한 것에 대한 집중도를 높이는 것입니다. 올바른 유연성과 겸손함을 가지고 사용한다면 그렇게 하는 데 효과적일 수 있습니다.

다음 섹션에서는 스크럼의 세계로 여행을 떠난 실제 사용 사례를 설명합니다. 저를 포함한 경험이 부족한 사람들이 처음으로 애자일 원칙을 일관된 방식으로 받아들이려는 의지를 가진 여정이었습니다. 이전에 제가 작업했던 많은 프로젝트는 반복적인 방식으로 만들어졌지만 실제 애자일 프레임워크에 대한 전체 의식이 없었습니다.

실제 사용 사례

여기서는 스크럼 프레임워크를 엄격하게 채택하지 않은 실제 사용 사례에 대해 이야기합니다. 이 프로젝트는 조직 표본 수집부터 조직 슬라이드의 최종 배포까지 다양한 단계에서 처리하는 등 해부 병리학 실험실과 관련된 모든 활동을 추적하는 것을 목표로 하는 소프트웨어 시스템에 관한 것이었습니다. 또한 시스템은 특정 소프트웨어 드라이버를 통해 외부 자동화 기계와 특정 단계에서 통합될 예정이었습니다.

저는 소프트웨어 설계자로서 이 프로젝트에 참여했습니다. 주요 문제의 윤곽을 잡고 기본 아키텍처 청사진을 고안하기 위해 프로젝트 관리자와 협력해야 했습니다. 애자일 원칙을 극단적으로 따른다면 아키텍처를 미리 생각하는 것은 최선이 아닙니다. 아키텍처 설계도 반복 시나리오에서 볼 수 있습니다. 하지만 대부분의 상황에서는 여전히 시작할 기반이 필요하며 관련된 모든 이해관계자와 이에 대해 논의해야 합니다.

나는 관점, 관점 , 관점을 기반 으로 한 구조화된 접근 방식으로 맥락을 명확하게 분리하려고 노력하는 예비 건축 연구에 접근했습니다. 문제를 명확하게 분리하고 특정 유형의 이해관계자에 따라 토론을 맞춤화하려면 이러한 접근 방식을 따르는 것이 중요합니다.

논의된 아키텍처의 일부는 실제로 개발 단계와 그 구성이었습니다. 회사 자체는 아직 애자일 방법론을 채택하지 않았습니다. 그럼에도 불구하고 우리는 관리자 및 관련된 다른 사람들과 합의하여 이러한 격차를 메우고 싶었고 스크럼 방법론 프레임워크에서 영감을 얻기로 결정했습니다.

우리는 스크럼에 대한 교육을 전혀 받지 않았지만 스크럼의 기본 사항은 모두 알고 있었습니다. 방법론적, 기술적 측면 모두에서 우리가 프로젝트에 대해 염두에 둔 주요 지침은 다음과 같습니다.

• 반복적 접근 방식에서 부분 및 전체 목표에 집중하기 위해 따라야 할 기본 관행 세트입니다(최종 결정의 스크럼).
• 자동화 도구로 활동/소스를 추적합니다.
• 단위 및 통합 테스트와 결합된 동작 중심 개발 접근 방식입니다.

스크럼 관행

견고한 방법론적 프레임워크를 시행해야 한다는 필요성에 동기를 부여받았지만 심층적인 기술이 부족했기 때문에 우리는 너무 멀리 가지 않고 스크럼의 몇 가지 주요 규칙을 채택하기로 결정했습니다. 우선 우리는 반복적인 접근 방식이 정말 중요하다고 생각했습니다. 스크럼은 반복 작업 단위로 간주할 수 있는 소위 스프린트를 통해 이를 다룹니다. 각 스프린트 는 백로그에서 선택한 수의 기능을 다루며 특정 기간을 갖습니다.

우리는 스프린트 기간으로 2주를 선택했습니다. 실제 거래를 시작하기 전에 우리는 사전 작업과 조직 작업을 수행하기 위해 일주일이라는 일반적인 스프린트 숫자를 0으로 설정했습니다. 이 예비 스프린트에서 우리는 모든 기능을 우선순위별로 나열한 백로그의 초기 버전도 작성했습니다. 우리는 작업 노력을 평가하기 위해 특정 방법을 채택하지 않았으며 단지 팀 구성원 간의 일반적인 토론만 수용했습니다.

스크럼 규칙의 경우 각 스프린트가 시작될 때 이미 완료된 작업에 대해 논의하고, 발생한 모든 문제를 평가하고, 다음 스프린트 에서 구현할 기능을 선택합니다.

프로젝트 관리자는 도메인 전문가의 지원을 받아 제품 소유자 역할을 수행했습니다. 실제 제품 관리자가 참여하지 않았고 프로젝트 관리자 자신이 클라이언트의 요구 사항에 대한 모든 지식을 갖고 있었기 때문에 이는 특정 상황에서 의미가 있었습니다. 스크럼 마스터의 경우 한동안 그 일을 한 다음 우리 둘 다 완전히 훈련받지 않았더라도 다른 동료에게 그 역할을 넘깁니다.

우리 팀은 서로 다른 도시에서 일하는 사람들로 구성된 이질적인 팀이었습니다. 그래서 우리는 매일 같은 시간에 Skype 통화를 예약하여 가상 버전의 스탠드업 회의를 조직해야 했습니다. 회의 시간은 약 15분 정도였습니다. 팀원 중 일부는 이를 통제의 한 형태로 해석했기 때문에 어떤 형태로든 저항했습니다.

우리는 팀원들 간의 간단한 토론을 통해 주요 문제에 집중하고 의사소통을 강화하며 개선 방법을 찾고 모두가 작업을 더 쉽게 할 수 있도록 하는 일상 회의의 진정한 의미를 그들에게 알리는 데 시간을 보냈습니다. 한동안 그들은 시간 낭비이고 실제 업무에 방해가 된다고 계속 말했지만 결국 우리는 그들을 설득했습니다.

자동화 도구를 통한 활동/소스 추적

방법론 관행 외에도 다음과 같은 주요 문제를 해결하기 위한 도구도 필요했습니다.

• 코드 버전 관리, 변경 사항 추적, 팀 전체 공유.

• 활동 추적 및 버그 해결: 수행해야 할 작업, 할당된 작업, 상태 등을 추적합니다.

• 소스 코드 변경 사항을 활동과 일치시킵니다.

  
  

프로젝트의 정보 흐름은 방법론적 관행에만 의존하여 정보를 제어하기에는 너무 복잡합니다. 작업을 더 쉽게 하려면 견고한 도구 기반이 필요합니다. 자동화하는 작업이 많을수록 중요한 일에 더 집중하고 더 나은 제품을 생산할 수 있습니다.

코드 버전 관리를 위해 가장 자연스러운 선택인 Git을 사용했습니다. Git은 다양한 방식으로 사용될 수 있는데, 저희는 개인적으로 Gitflow를 워크플로우 패턴으로 채택했습니다.

활동을 추적하기 위해 우리는 프로젝트 관리를 목표로 하는 일반 플랫폼인 Redmine을 사용했습니다.

세 번째 문제를 해결하기 위해 우리는 커밋 주석에 문제 식별 코드를 사용하여 Git 커밋이 특정 Redmine 티켓과 관련될 수 있는 방식으로 Git 저장소를 Redmine과 통합했습니다. 이런 식으로 우리는 활동과 Git 작업 단위 간의 완전한 매핑을 얻었습니다.

단위 및 통합 테스트와 결합된 행동 중심 개발 접근 방식

우리는 행동 중심 접근 방식을 기반으로 개발 프로세스를 구축하고자 했습니다. BDD는 Scrum 및 일반적으로 Agile 원칙, 특히 커뮤니케이션과 관련된 부분에 매우 적합합니다. 기술 지식이 없는 사람도 이해할 수 있는 형식으로 테스트 시나리오를 작성할 수 있으며 올바른 도구를 사용하면 현재 상태에 대한 시각적 보고서를 제공합니다. 제품의 논리적 경계를 그리고 그 경계 내에서 개발 작업을 강제합니다.

BDD 기능 테스트는 전체 테스트 도구의 외부 계층에 불과했습니다. 단위 테스트와 통합 테스트도 사용했습니다. 이러한 개발 환경의 복잡성에 압도당하지 않기 위해 우리는 올바른 도구와 자동화 기능을 사용해야 했습니다.

관련된 주요 기술은 다음과 같습니다.

• Cucumber : REST 서비스를 사용하여 Spring Boot 애플리케이션 에 통합됨

• 기타 테스트 도구: 통합 테스트를 지원하는 JUnit , Mockito 및 Spring Boot 라이브러리.

  
  

다음 정신 지도는 위에서 논의한 내용을 요약하여 보여줍니다.

고려사항

비록 가볍고 유연한 방식이라 할지라도 스크럼을 채택하는 것이 그만한 가치가 있었습니까? 대답은 '예'입니다. 하지만 분명히 하자면, 우리는 그것을 모든 문제에 대한 해결책으로 볼 수 없으며, 그 정신 자체를 이해하지 않고 채택한다면 심지어 해로울 수도 있습니다. 방법론의 본질은 사람들이 정보를 최대한 공유하고 헌신하면서 함께 일할 수 있도록 집단 정신 스키마를 제공하는 것이지만, 사람들이 실제 작업이 아닌 이국적인 의식의 규칙을 따르는 데 집중한다면 원래의 목적은 사라지게 됩니다.

스포츠 비유

스포츠 비유를 통해 위에서 말한 내용을 더 잘 이해할 수 있습니다. 모든 사람이 축구를 좋아하는 것은 아니지만 거의 모든 사람이 축구가 어떻게 진행되는지에 대해 최소한의 아이디어만 갖고 있습니다. 우선 집단게임이다. 두 팀이 골대 안으로 공을 전달하려고 경기장에서 서로 대결합니다. 이렇게 간단해 보이는 작업을 수행하려면 개인의 계획과 집단 전략 및 전술을 혼합해야 합니다. 이러한 전략과 전술은 코치가 미리 가르치며 운동 세션에 소요되는 전체 시간의 큰 부분을 차지합니다.

실제로 효과적이려면 위에서 설명한 축구 선수들이 따르는 집단 규칙이 아무런 노력 없이, 심지어 그것이 존재한다는 생각조차 하지 않고 실행되어야 합니다. 예를 들어 자동차를 운전하는 동작처럼 자동이어야 합니다. 이 목표를 달성하기 위한 기본 요구 사항은 챔피언십을 준비하는 데 필요한 제한된 시간 내에 모든 플레이어가 완전히 흡수할 수 있을 만큼 단순해야 한다는 것입니다.

실제 작업 대신 스크럼 의식을 따르는 데 집중한다면 결국 질서 대신 혼란을 가져오게 될 것입니다. 반면, 좀 더 실용적인 접근 방식을 따르고, 유연하게 대처하고, 특정 경험에서 작동하지 않는 모든 것을 제거한다면 최대한 활용할 수 있습니다. 일부 스크럼 접근 방식을 따르기가 어렵다면 연기하고 이후 단계에 도입하는 것을 고려해 볼 수도 있습니다.

관리자 관리

개념을 강조해 보겠습니다. 애자일 방법론과 특히 스크럼은 팀 구성원이 이를 기꺼이 채택하거나 적어도 그 장점을 알고 있는 경우에만 작동할 수 있습니다. 회사의 관리자가 일반적인 소란을 따라가며 외부 세계에 "보세요? 우리는 민첩합니다!"라고 알리기 위해 도입하는 경우에만 작동할 수 없습니다. 분명히 합시다. 목적이 단지 마케팅이라면 그러한 방법론을 따르는 척하는 것이 더 나을 것입니다. 홍보 목적으로만 부담을 내부 프로세스에 도입할 필요가 없습니다.

이야기의 교훈: 민첩한 방법론은 관리자가 강요하는 것이 아니라 관리자와 함께 엔지니어가 채택하는 경우에만 긍정적인 영향을 미칠 수 있습니다. 대부분의 관리자, 특히 기술적 배경이 없는 관리자는 방법론이 소프트웨어 프로젝트의 수명 주기에 어떤 영향을 미칠 수 있는지 전혀 모르는 반면, 엔지니어, 특히 수석 엔지니어는 그렇습니다. 수년간의 경험은 최고의 책과 최고의 강좌보다 낫습니다.

게다가 이탈리아 회사에서의 이상한 경험에 따르면 조직은 일종의 중세 유산에서 유래한 것처럼 보이는 문화에 의해 좌우되는 경우가 많습니다. 이러한 맥락에서 스크럼 마스터와 제품 소유자 역할도 운영 역할이 아닌 단순히 경력 경로에서 권위의 원천으로 볼 수 있습니다.

사실을 말하자면, 나는 최근 이 가혹한 현실을 실험해 보았습니다. 보통 이런 사람들은 방법론의 원리가 무엇인지 전혀 모르고, 이해도 안 되는 규칙으로 사람들을 계속 괴롭힙니다.

이런 끔찍한 환경에서 익스트림 프로그래밍과 스크럼은 의미 없는 제목일 뿐입니다. 이러한 맥락에서 관리자는 처리해야 할 엔트로피의 원천이며, 적절한 수준의 생산성에 도달하려면 팀이 자체 작업을 관리해야 하며 심지어 관리자도 관리하여 나쁜 영향을 줄여야 합니다. 이는 이 섹션의 제목인 "관리자 관리"를 설명합니다.

방법론, 테스트 관행, 추적 활동 및 관련 도구 간의 균형

이 기사에 설명된 사용 사례에서는 방법론뿐만 아니라 테스트 전략, 활동 추적 및 이를 지원하는 데 사용되는 도구에 대해서도 설명했습니다. 최고의 방법론 프레임워크는 소프트웨어 개발과 관련된 모든 복잡한 문제를 스스로 해결할 수 없습니다.

실제로 기능 테스트를 다루는 BDD는 개발 중인 소프트웨어 시스템의 논리에 대한 지식을 공유하는 매우 효과적인 방법입니다. 이는 모든 팀 구성원과 제품 소유자 사이에 강력한 유대감을 구축하고 프로젝트의 더 중요한 측면에 대한 집중력을 향상시킵니다. 따라서 이는 스크럼이 다루어야 하는 문제의 일부를 다루고 있습니다.

반면에 단위 및 통합 테스트는 소프트웨어 개발자의 내부 프로세스에 더 많이 관여하지만 간접적으로 변경 사항을 더 쉽게 처리하고 Scrum의 반복적 접근 방식과 잘 결합됩니다.

결론

소프트웨어 개발은 개발자 한 명이 처리하는 최소한의 프로젝트에서도 복잡한 문제입니다. 프로젝트에 팀을 구성해야 하는 경우 여러 가지 조직적 문제가 발생합니다. 민첩한 방법론은 이러한 문제를 해결하려는 시도이지만 무의미한 확대 형태를 피하고 소금 한 알만 취하는 경우에만 실제로 유용할 것입니다.