GN⁺: Scrum이 당신을 스트레스 받게 하는 이유
(rethinkingsoftware.substack.com)- 오늘날의 프로그래밍은 90년대와 2000년대 초반보다 훨씬 더 스트레스가 많음
- 당시에는 마감일 근처에서만 일이 미쳤었고, 다른 때는 비교적 평온했음
- 최근 몇 십 년 동안 스트레스가 증가한 이유를 고민해 봤음
- 경쟁, 시장 변화, 엄격한 마감일 때문이 아니라, 스프린트 방식의 작업 때문임
1. 스프린트는 멈추지 않음
- 스프린트는 끝나지 않는 연속적인 마감일임
- 워터폴 방식은 실제 마감일과 이벤트에 맞춰져 있었음
- 스프린트는 인위적인 마감일로, 자연스러운 휴식 시간이 없음
- 단기 스트레스는 건강에 좋을 수 있지만, 장기 스트레스는 신체에 해로움
2. 스프린트는 자발적이지 않음
- 팀이 자발적으로 2주마다 코드를 배포하는 것과는 다름
- 스프린트의 모든 측면이 규정되어 있음
- 자율성은 작업 경험에 중요한 역할을 함
- 강제적인 작업은 스트레스와 불편함을 초래함
3. 스프린트는 중요한 지원 활동을 무시함
- 스프린트는 다음 작업을 준비할 시간을 제공하지 않음
- 작업을 수행하기 위해서는 준비 시간이 필요함
- 스프린트는 준비와 실행을 분리하려고 하지만, 이는 스트레스를 유발함
스크럼폴: 실제 (그리고 더 나쁜) 그림
- 대부분의 스크럼 구현은 워터폴과 스크럼의 혼합임
- 큰 마감일이 항상 배경에 존재함
- 큰 마감일이 다가오면 스크럼이 중단되고, 스트레스가 증가함
결론
- 스프린트에는 휴식이 없고, 자율성이 부족하며, 준비 시간이 부족함
- 개발자들은 자신의 작업과 프로세스를 통제할 수 있어야 함
- 이를 위해서는 윤리적인 조직을 구축하거나 프리랜서로 전환하는 등의 노력이 필요함
GN⁺의 정리
- 이 글은 스크럼 방식이 개발자에게 지속적인 스트레스를 주는 이유를 설명함
- 스프린트의 연속적인 마감일, 자율성 부족, 준비 시간 부족이 주요 원인임
- 개발자들이 자신의 작업 방식을 통제할 수 있도록 해야 함
- 유사한 기능을 가진 다른 프로젝트로는 Kanban 방식이 있음
현직 pm인데요.
-
잘 동작했다고 느꼈던 애자일/스크럼에서는 주요 스프린트가 끝나면 회고하고, 휴식하는 시간을 부여받았습니다. 개발팀도 기획팀도 다음 것을 준비하기 전에 쉴 수 있는 타이밍이 있었구요.
-
본문과 동일하게 동작하지 않는다고 느꼈던 방식에서는 워터폴로 내려오는 데드라인 아래에 제품팀 내부에서 스크럼 방식도 같이 동작시키면서 스트레스가 가중되었고, 데드라인 자체가 변경 불가였기 때문에 휴식/회고할 시간도 없이 매주 달리면서, 끝나지 않는 달리기같은 느낌이 있었어요.
- 애자일과 스크럼이 잘 동작하는 팀의 경우에는 미팅이 효율적이고, 미팅을 하지 않아도 기획<>개발이 일방적이지 않은 상호 존중, 소통, 안전한 팀이라는 분위기가 있었고요.
- 반대로 잘 동작하지 않는 팀은 늘 팀원들이 수동적, 강압적, 비난적 어조, 회의적인 분위기가 반복되었던 것 같습니다.
워터폴의 의도는 가능한 한 요구사항을 초기에 식별하고 설계-구현-테스트 작업 간의 의존성이 있으니 일을 순서대로 하자는 것, 그리고 애자일과 스프린트의 의도는 워터폴로 미리 설계하거나 구현하기에 너무 분량이 많은 일을 작게 쪼개서 해보자는 거라고 저는 이해하는 데요. 둘 다 장단점이 있고 교조적으로 방법론을 추구하기 보다는 상황에 맞게 필요한 것만 취사 선택만 해도 되지 않을까 싶네요. 글에서 주장하는 것과 같이 휴식도 있어야 하고 기술 검토나 프로토타입을 만드는 준비 시간도 있어야 할 거구요. 누가 작업의 순서를 결정하든 방해요소를 이해하고 실무의 흐름대로 우선순위를 결정하기만 하면 개발자 자율성의 유무도 상관이 있나 싶습니다
개발 경험은 전혀 없고 개발 방법론의 절차를 맹목적으로 적용하려는 매니저들이 외국에서 많이 양산돼서 외국 블로그에 이런 글들이 올라오는 걸까요? 마치 우리나라의 실무를 전혀 모르는 기획자와 개발자 사이의 갈등을 보는 듯 하네요
실무 흐름대로 우선순위를 제일 잘 결정할 수 있는것은 개발자 그 자신일 텐데요, 자율성을 뺏고 그걸 다른사람이 대행해 준다는 접근 자체가 오히려 실무와 팀 계획의 격리를 일으키는 원인이라 생각합니다.
매니징 자체도 하나의 전문분야라 한다면, 개발 경험이 없는 매니저라 할지라도 개발 리소스의 매니징이 잘 안되는 시점을 맞닥뜨리게 되었을 때 그 상황에 대한 해답은 매니저가 적응 혹은 대응해야 한다고 생각합니다. 그런데, 이 책임소재가 개별 기여자에게 전가되는것을 너무 많이 봤네요...
네 최종 책임은 매니저가 져야 하죠. 근데 현실은 그렇지 않나 봅니다. 마치 경영만 할 줄 아는 CEO가 회사의 업은 하나도 이해 못하고 종종 회사를 말아먹는 것처럼요
Hacker News 의견
-
Rich Hickey의 말을 인용하며, 프로그래머는 짧은 거리만 달리는 주자와 달리, 매 100야드마다 출발 신호를 쏘아 새로운 스프린트를 시작하는 방식으로 문제를 해결함
-
소프트웨어 프로세스를 싫어하게 되었음. 팀 규모를 적절하게 설정하고 개발자에게 목표를 달성할 수 있도록 권한을 부여하면, 관리의 생산성 흐름 없이도 잘 해낼 수 있음. Agile 등은 관리자가 자신의 급여를 정당화하기 위해 존재함
-
"스프린트가 자발적이지 않다"는 의미가 무엇인지 궁금함. 팀이 스프린트의 특성을 선택하며, 무작위로 할당되지 않음. 리더십, 팀원, 비팀 이해관계자 간의 협업임. 스크럼이 너무 경직된 이유를 설명해주길 바람
-
스크럼이 처음 나왔을 때부터 개발자가 계속 스프린트를 하는 것이 말이 안 된다고 생각했음. 스프린트는 짧고 빠르며, 그 후에는 휴식이 필요함. 모든 작업을 스프린트로 만드는 것은 미친 짓임
-
스크럼이 실제로는 더 나쁜 "스크럼폴"로 변하는 경우가 많음. 초기에는 원격 팀의 소통을 위해 스크럼을 사용했으나, 점차 마케팅 주도 목표와 스트레스가 많은 스프린트로 변함. 개발자 소진이 명확하게 드러남
-
2000년대 초반에는 프로젝트 매니저 없이 엔지니어 팀이 자체적으로 일했음. 소프트웨어가 지금처럼 상호 연결되지 않았고, 배포 주기도 길었음. 현재는 CI/CD와 지속적 배포로 인해 모든 것이 빠르게 진행됨. SCRUM이 스트레스를 줌
-
대부분의 대화는 "내 직장에서 스크럼이 X, Y, Z 때문에 별로임"과 "그건 이상적인 스크럼이 아님"으로 요약될 수 있음
-
40년 동안 소프트웨어를 개발해왔으며, 어떤 방법을 사용하든 작업을 나누고 목표 달성을 보여줘야 함. 작은 팀에서는 간단한 코드베이스로 Kanban이 충분할 수 있지만, 큰 팀이나 복잡한 솔루션에서는 보고가 필요함
-
Agile, Scrum, Standups 등을 사용하지 않음. 주 1회 회의를 통해 우선순위를 재설정하고, 티켓 시스템으로 진행 상황을 추적함. 개발자가 자율적으로 일할 수 있도록 함. 회의나 TPS 보고서보다 코딩에 더 많은 시간을 할애해야 함
-
8개의 회사에서 일해본 결과, Basecamp의 Shape Up 접근 방식이 가장 성공적이었음. "얼마나 많은 날"이 아닌 "얼마나 많은 시간을 투자할 것인지"를 묻는 것이 중요함. Shape Up은 6주 주기 사이에 쿨다운 시간을 제공하며, 일관되게 성공적인 제품을 제공함