수동 소득 아이디어 2023
Scrum과 같은 민첩한 방법은 수년 동안 소프트웨어 개발의 사실상의 표준이었습니다. 그 이유는 소프트웨어 개발의 복잡한 특성 때문입니다. 디지털 제품 개발의 세계는 너무 빠르게 변화하여 개발 프로젝트 동안 모든 수준에서 예측하지 못한 변화에 지속적으로 직면하게 됩니다. 이는 폭포수에 제대로 반영되지 않은 사실입니다.
그럼에도 불구하고 때때로 폭포는 들판을 치우고 싶지 않은 것처럼 보입니다. 다음과 같은 점에서 애자일 방법의 대표로 Scrum을 사용합니다. digital.ai의 연구에 따르면 스크럼은 여전히 가장 인기 있는 애자일 접근 방식입니다. 응답자의 66%는 스크럼이 가장 일반적으로 사용되는 프레임워크라고 밝혔습니다. 이제 폭포수가 스크럼에 침투한 실제 사례를 살펴보겠습니다. 그래서: 폭포를 쫓지 마세요.
미니 폭포
우선: 완벽한 워터폴에서 스크럼으로 전환하려는 경우 이는 확실히 올바른 방향으로 나아가는 단계입니다. 아마도 가장 일반적인 이 반패턴은 일반적으로 폭포수 단계가 이제 2주로 압축되고 처음부터 반복해서 시작되는 방식으로 구현됩니다. “좋은” 점은 이제 스프린트가 끝날 때 작동하는 소프트웨어를 생성하려고 시도한다는 것입니다. 가장 일반적인 증상은 더 이상 테스트를 따라갈 수 없기 때문에 스프린트가 끝날 때 엄청난 스트레스를 받는 것입니다. 완료의 정의에 따라 여기에서 증분이 완료되는 경우는 드뭅니다.
실제로 미니 폭포에서 작업하는 경우 스프린트 계획에서 계획한 후 구현한 백로그 항목에 대한 작업 진행 제한이 제안됩니다.
워터 스크럼 사례
엄밀히 말하면 Scrum은 기존 폭포수에 내장되어 있습니다. 따라서 원래의 폭포수 단계는 남아 있지만 이제 2주 단위로 나뉩니다. 소수의 분석 스프린트 다음에 디자인 스프린트, 코딩 스프린트, 마지막으로 테스트 및 통합 스프린트가 이어집니다. 이것은 프로젝트 제어를 더 쉽게 만들 수 있기 때문에 확실히 폭포수에 대한 보강이지만 핵심은 여전히 여기에서 고전적이며 소프트웨어 개발의 복잡성은 어떤 식으로든 매핑되지 않습니다.
역할이 분리된 스크럼
Scrum에서 성공하려면 이상적인 구현 팀이 Scrum에서 교차 기능을 수행해야 합니다. 역사적인 이유로 그렇지 않고 팀 조직이 소프트웨어의 기술 구성 요소에 따라 나뉘는 경우 자체적으로 제품 기능을 완전히 구현할 수 없는 스크럼 팀이 많다고 합니다. 이로 인해 프로젝트 관리 및 통합 노력이 엄청나게 증가합니다. 이 반패턴의 전형적인 증상은 프로젝트 관리자 역할, 즉 구성 요소 팀을 조정하는 역할이 여전히 필요하다는 것입니다.
“클릭커”
일반적으로 사내 스크럼에 대해 생각하는 것만으로도 테스트를 자동화할 때가 되었음을 깨닫기에 충분합니다. 테스트 자동화는 매우 복잡한 환경에서도 오늘날 거의 문제가 되지 않지만 여전히 기능을 수동으로 테스트하는 데 전담하는 조직을 찾을 수 있습니다.
그러나 수동 테스트의 테스트 결과는 테스트가 실행된 후 작성된 코드의 첫 줄부터 유효하지 않기 때문에 이러한 테스트를 반복해서 실행해야 합니다. 그리고 지금까지 개발된 모든 기능에 대해(키워드: 회귀 테스트). 테스트 자동화가 없으면 테스터가 현재 있는 것을 테스트하는 데 전체 스프린트보다 더 오래 걸릴 것입니다. 이에 대한 솔루션은 분명히 테스트 자동화입니다. 다행스럽게도 이를 구현하기에 충분한 코드 검토 도구가 있습니다. 증상을 퇴치하는 것은 차례로 “폭포로 돌아가는 것, 즉 테스트를 뒤로 미루는 것”이 될 것이며 모든 관련 결과가 초래될 것입니다.
“나중에 통합하는 사람이 더 빠르고 더 오래”
지속적인 통합은 개발된 코드를 하나의 큰 전체로 지속적으로(하루에 여러 번!) 통합하는 것을 의미합니다. 스크럼 용어로는 증분입니다. 모든 테스트의 실행을 포함하여 완전 자동화된 피드백 시스템은 증분 상태에 대한 정보를 하루에 여러 번 제공합니다. 그리고 오류가 발생하면 신속하게 개발자의 손끝을 두드려줍니다. 너무 빨리 개발자가 오류의 원인을 정확히 파악하여 제거해야 합니다.
불행하게도, 개발할 때, 즉 자신의 “브랜치”에서 고립된 상태로 들어가는 것이 때때로 더 편안하게 느껴질 수 있습니다. 일부 분기 개념이 유효한 만큼, 분기의 수명에 따라 이후의 통합 노력이 증가하므로 통합 노력은 아마도 스프린트가 끝날 때까지 미루어질 수 있습니다. 그러나 실제로는 더 이상 수정할 시간이 없습니다.
변경 요청이 있는 스크럼
이 변형은 일반적으로 초기 요구 사항 및 기능 사양과 쌍을 이룹니다. 따라서 폭포수로 시작하지만 구현이 시작될 때 스크럼으로 전환하려고 합니다. 그러나 이러한 문서가 계약에 따라 정의되면 Scrum 구현 시작부터 민첩성에 대한 가능성이 사라집니다. 변화하는 요구 사항이나 새로운 통찰력에 더 이상 대응할 수 없기 때문입니다. 결국 계획을 실행해야 합니다. 변경을 위해서는 이제 계약상 정의된 변경 요청 절차가 필요하며 폭포수는 손짓합니다.
고정 스크럼
“그 날짜까지 이 기능은 이 가격으로 구현되어야 합니다. 그 프레임워크 내에서 원하는 만큼 민첩하게 대응할 수 있습니다.” 이 세 가지 요소가 고정되면 얼마나 민첩할 수 있습니까? 여기에는 여유가 거의 없으며, 소프트웨어 개발 또는 소프트웨어 현대화에서 민첩한 접근 방식의 이점이 여기에서 실현되지 않기 때문에 몇 번의 스프린트 후 실망감도 똑같이 높을 것입니다.
이 경우 제품 투자에 대한 고정 예산을 정의하고 이 예산으로 최대한 많은 비즈니스 가치를 생성하도록 제품 소유자를 지정하는 것이 좋습니다. 불필요하게 비싸지 않고 백로그에서 영리하게 우선 순위를 지정하면 불필요한 기능을 쉽게 합리화할 수 있습니다.
