스크럼이 무엇인지에 대한 논쟁에서, 나는 아마도 민첩한 것을 완전히 오해했을 것입니다. 스크럼 (애자일 프로세스로 간주 됨)은 TDD, 페어 프로그래밍, CI, 리팩토링 및 기타 개발자 중심 기술과 관련이없는 기능 및 스프린트 및 역할 및 항목 관리에 관한 것입니다. 지금까지)는 민첩성의 핵심입니다. 지금 나는 어려움에 직면하고 있습니다!
1) 스크럼은 개발자가 민첩한 관행을 수행하는지 여부에 관계가 없습니까?
2) 자동화 된 테스트를 사용하지 않는 팀에서 Scrum을 구현할 수 있습니까? 리팩토링을 수행하지 않거나 애자일 프로그래밍 방식을 준수하지 않습니까?
답변:
스크럼이 애자일과 같다고 생각하는 것은 흔한 실수입니다.
민첩한 것은 민첩한 선언 의 네 가지 원칙을 따릅니다 . 스크럼은 이러한 원칙과 일치하는 프로젝트 관리 프로세스이지만 그 자체로는 애자일이 아닙니다. XP (TDD, 페어 프로그래밍)는 개발 프로세스이며 이러한 원칙과 일관성이 있고 스크럼과도 일치하지만 민첩하지 않습니다. 지속적인 통합, 지속적인 제공, DevOps는 모두 애자일 원칙과 일치합니다.
가장 먼저 원칙을 따르십시오. 이러한 모든 버즈 프레이즈는 사람들이 원칙을 따르도록 성공적으로 돕는 방법론 일뿐입니다. 그러나 "민첩함"의 주요 부분은 애자일의 원칙을 따르지 않는 프로세스를 마음대로 조정할 수 있다는 것입니다.
스크럼은 개발자가 민첩한 관행을 수행하는지 여부에 관계가 있습니까?
스크럼은 팀의 민첩성을 권장하는 일련의 지침입니다.
자동화 된 테스트를 사용하지 않는 팀에서 Scrum을 구현할 수 있습니까? 리팩토링을 수행하지 않거나 애자일 프로그래밍 방식을 준수하지 않습니까?
모든 스프린트가 끝날 때마다 작동하는 제품이 있어야하기 때문에 매우 어렵습니다. 작동하는지 확인하기 위해 완전한 수동 회귀 테스트를 수행해야하는 경우에는 불가능할 수 있습니다.
알리스 테어 콕번 (민첩한 운동의 창시자 중 하나)라고 이 크리스탈 클리어 (자신의 애자일 방법론의 한면)에 대해 :
Crystal Clear는 다음 단어로 레벨 3 리스너에게 설명 할 수 있습니다.
“워크 스테이션과 화이트 보드가있는 방에 4-6 명을두고 사용자에게 접근합니다. 1 ~ 2 개월마다 실행되고 테스트 된 소프트웨어를 사용자에게 제공하고 그렇지 않은 경우에는 그대로 두십시오.”
이는 자신이 무엇을하고 있는지 알고 신뢰할 수있는 숙련 된 개발 직원을위한 민첩성의 정의입니다. 그래서 당신이 의미 하는가 가 CI 및 TDD와 페어 프로그래밍 및 다른 모든 유행 물건을 사용할 수 있나요? 간단히 말해서 ... 아니요.
애자일은 일련의 프로세스를 따르는 것이 아니라 효과적입니다. 그것이 당신에게 의미하는 것은 팀과 그것이 어떻게 작동하는지, 당신이 유용하다고 생각하는 것에 달려 있습니다. TDD가 작업 코드를 생성하는 데 도움이되지 않으면 웹에서 소리를 덜내는 조명을 듣지 마십시오. 페어 프로그래밍이 팀이 집중하고 일을 처리하는 데 실제로 도움이된다면 시간 낭비를 말하는 사람을 무시하고 학교 운동 일에 3 다리 경주처럼 팀을 구성하십시오.
나는 몇 년 전에 민첩하게 행동했지만, 우리는 민첩하게 행동하고 있다는 사실조차 몰랐습니다. 매월 제품을 반복해서 제공하고 버그를 수정하고 정기적으로 새로운 기능을 추가했습니다. 우리는 그러한 것들이 발명되지 않았고 리팩토링 책이 쓰여지지 않았기 때문에 단위 테스트를 전혀하지 않았습니다. 따라서 그렇습니다. 소위 민첩한 관행없이 민첩하게 수행 할 수 있습니다.
Alistair는 또한 Kent Beck에 대해 다음과 같이 말합니다.
XP와 Software Engineering Institute의“Capability Maturity Model”의 5 가지 수준에 대해 물었고 XP의 3 가지 성숙도 수준으로 대답했습니다.
작성된대로 모든 것을하십시오.
그런 다음 규칙의 변형을 실험 해보십시오.
결국 XP를하고 있는지 아닌지를 신경 쓰지 마십시오.
결국, XP를하고 있는지 아닌지를 걱정하지 마십시오 . 이 함정 에 빠지지 않도록 상기시켜주는 현명한 단어입니다 .
개발 또는 관리에 민첩합니까?
애자일 (Agile)은 유연성과 빠른 단계 변화 시장 요구 사항 또는 이른바 가속화 된 배달 을 충족시키는 소프트웨어 개발 사례 입니다. 큰 그림에서 작업은 작은 평화로 작업을 분할하고 2-4주의 빠른 반복으로 기능을 제공함으로써 변화하는 고객의 복잡한 요구 사항을 충족시키는 유연한 접근 방식에 관한 것입니다.
그러나 이러한 유연성을 충족시키기 위해 개발 팀은 민첩한 프로그래밍 방법 을 연습해야합니다 .
애자일 소프트웨어 개발 에 관한 위키의 설명 :
민첩한 소프트웨어 개발은 반복적이고 점진적인 개발을 기반으로하는 소프트웨어 개발 방법 그룹으로, 요구 사항과 솔루션은 자체 구성, 부서 간 팀 간의 협업을 통해 발전합니다. 적응 형 계획, 진화 적 개발 및 전달, 시간에 따라 반복되는 반복 접근 방식을 촉진하고 변화에 대한 신속하고 유연한 대응을 장려합니다. 개발주기 내내 예상되는 상호 작용을 촉진하는 개념적 프레임 워크입니다.
1) 아니요 !!!! Scrum은 민첩합니다. 즉 민첩한 개발 관행 (TDD, 페어 프로그래밍, CI, 리팩토링 등)이 Scrum 프로젝트의 모든 측면에서 매우 중요합니다. 이러한 관행을 사용하지 않으면 팀의 운영 률을 파악하고, 작업을 추정하고, 적절한 스프린트 크기를 설정하는 것이 훨씬 어려울 것입니다.
2) 예. 민첩한 관행을 준수하지 않는 팀에서 Scrum을 구현할 수 있지만 실제로 팀의 잠재력을 제한한다고 생각합니다. Scrum / Agile이 성공적인 이유 중 대부분은 애자일 개발 방식을 통해 얻을 수있는 성능과 품질 향상으로, 스프린트마다 완벽한 기능을 제공하는 데 핵심적인 역할을합니다.
만약 당신 그룹의 다른 누군가가 애자일 개발 관행이 시간 낭비라고 확신 시키려고한다면, 왜 이러한 관행이 항상 스크럼과 애자일 전체에 스트레스를 받는지 강조하기 위해 시간을 투자해야한다고 생각합니다. 그들은 실제로 차이를 만듭니다.