GN⁺: Agile과 Jira의 느리고 고통스런 죽음
(ehandbook.com)"Agile이 더 이상 Agile이 아니게 되었으니, 이제 Agile이 Jira를 가지고 함께 사라져야 할 때임"
- 소프트웨어 개발 주기는 점점 더 길어지고, 기술 팀은 점점 더 커지고, 개발 관리에는 점점 더 많은 앱이 필요하고, 실제로 코딩을 하는 사람은 점점 더 줄어들고, 점점 더 짧은 기간 동안, 지속적인 체크포인트 사이에 진척이 점점 더 줄어들고 있음
- 애자일은 어디서 부터 잘못 되었을까?
- 애자일은 기존의 문서 중심의 무거운 소프트웨어 개발 프로세스의 대안으로 2000년대 초반에 개발된 방법론임
- 그러나 현재는 애자일이 기존의 복잡한 프로젝트 관리 방법론으로 변질되고 있음
기술 비대화(Tech Bloat)가 주요 문제임
- 많은 사람들이 애자일을 포기하거나 포기하려는 주된 이유는 기술 비대화 때문임
- 기술 비대화는 모든 기술 회사의 적이며, 사내 또는 외주 개발팀이 있는 비기술 회사에도 위험함
- 기술 비대화는 기술 부채와는 다르지만, 기술 부채를 만들어냄
- 기술 비대화의 증상은 다음과 같음:
- 고객과 반복적으로 대화하지만 고객 행동에 대한 전문가가 되지 않음
- 마감일과 납품일을 끊임없이 평가하고 재평가함
- 모든 세부 사항이 문서화될 때까지 개발 프로세스를 시작하기를 극도로 꺼림
- 가장 위험한 작업이 아닌 가장 쉬운 작업부터 시작하려는 동기가 생김
기술 비대화의 혼란스러운 결과
- 문서화 증가
- 무엇을 왜 개발했는지 뿐만 아니라 "어떻게" 개발했는지도 추적하는 문서화가 프로세스에 스며듦
- 이 "어떻게"가 상태 업데이트의 초점이 되어 팀이 어떻게 일하고 있는지 끊임없이 재평가함
- 팀은 일을 하는 데 시간을 보내기보다 왜 일이 완료되지 않았는지 논의하는 데 더 많은 시간을 보냄
- 잦은 마감일 설정
- 더 잦은 검사점에서 더 많은 마감일이 설정되어 본질적으로 창의적인 프로세스의 모든 전환점에서 미시적 관리를 낳음
- 이는 품질 있는 소프트웨어 생산에 역행함. 모든 작업이 얼마나 잘 실행되었는지와 상관없이 정해진 기한에 전달되기 때문
- 재평가 과정의 끊임없는 의심
- 재평가 기간 동안 끊임없는 의심으로 인해 모범 사례가 선언되지 않고, 낭비가 제거되지 않으며, 규모의 경제가 인식되지 않게 됨
- 생산 과정의 미시적 관리
- 전체 기능의 30% 정도가 완성될 때쯤이면 더 이상 우선순위가 아니게 됨
- 조직은 로드맵이 여전히 성공적인 제품 구축을 정의하는지 여부와 관계없이 로드맵에 있는 것을 생산하는 죽음의 나선에 빠짐
- 최종 결과
- 제품은 다양하고 상충하는 고객 요구 사항의 무게에 시달림
- 기능은 종종 시장에 늦게 출시되고 시장에 가장 적합한 방식과 순서가 아닌 기술팀에 가장 적합한 방식과 순서로 제공됨
- 결국 영업/마케팅 팀은 자신들이 무엇을 판매하는지, 고객은 무엇을 구매하는지 모르기에 반발함
- 그러면 조직은 대대적인 정리에 나섬
세상은 더 많은 기능이 아닌 중요한 일을 더 잘하는 가벼운 소프트웨어가 필요함
- 이는 새로운 개념이 아니지만, 모든 방법론이 결국 멀어지는 개념임
- 사람들은 결국 토요타 방식이 토요타에 충분히 토요타스러운지 묻기 시작하고, 그것은 더 많은 일을 만드는 일이 됨
- 애자일은 이제 귀여운 이름과 더 짧은 회의, 더 많은 규칙을 가진 PMP가 되었음
- 문제는 애자일의 아이디어가 아니라 실행과 통제할 리더십의 부족임
- 효용성보다 마감일, 성장보다 삭감, 진보보다 절약에 초점을 맞춘 중간 관리층의 문제임
GN⁺의 의견
- 애자일은 원래의 의도와 달리 관료주의화되고 형식화되어 소프트웨어 개발을 더디게 만드는 요인이 되고 있음
- 기술 비대화는 애자일뿐만 아니라 모든 기술 조직에서 주의해야 할 위험 요소임
- 문서화, 마감일 설정, 미시적 관리 등이 오히려 품질과 속도를 떨어뜨릴 수 있음
- 애자일의 본질은 고객 중심, 협업, 유연성 등에 있으므로 형식에 얽매이기보다는 원칙을 되새길 필요가 있음
- 소프트웨어 개발에서 중요한 것은 더 많은 기능이 아니라 핵심 기능을 잘 구현하는 것임
- 조직 문화와 리더십이 애자일의 성패를 좌우하므로, 기술 관리자들은 이에 주의를 기울여야 함
- 애자일을 넘어 새로운 방법론을 모색할 때가 된 것 같음
애자일이냐 waterfall이냐의 문제 이전에 사람과 문화 등 환경이 그대로면 아무리 신박한 개발 방법론을 들이밀어봤자 K-OOO 화 되는길 밖에 없습니다
동의합니다. 잘못된 애자일을 하고 애자일이 틀렸다고 이야기하는 것들이 많아지고 있는 것 같아요.
한편으로 드는 생각은 등장한지 시간이 꽤 흘렀는데도 프랙티스를 잘 쌓는게 어렵다는건 피할 수 없는 것 같기도 해요.
애자일 선언에 참여한 uncle bob 도 이 문제를 일찍 이해하고 잘못된 애자일을 바로잡기 위해 2019년에 클린 애자일 책을 발간했는데, 아직도 이런 문제가 계속되네요. 개인적으로 애자일이 표준 가이드라인이 없고, "문화"라는 모호한 표현을 사용하고 있기 때문이라고 생각합니다. 구체적인 표준 가이드라인이 제시되었으면 좋겠네요
애자일이 문제가 아닙니다. 그걸 하는 사람이 문제죠. 무슨 방법론을 가지고 오던 결국은 그걸 하는 사람이 어떻게 하느냐 입니다. 저는 애자일은 방법론이 아닌 어떤 주기마다 제품을 성장시키는 정신에 가깝다고 생각합니다. 이걸 놓치고 맹목적으로 플래닝하고 회고하면 시간 낭비인것 같아요.
원문이 유료 아티클이라 끝까지 보지는 못했는데요, 번역된 표현을 좀더 다듬으면 좋을것 같습니다.
"Agile이 더 이상 Agile이 아니게 되었으니, 이제 Agile이 Jira를 가지고 함께 사라져야 할 때임"
=> "Agile이 being agile을 멈춰서, 이제 Agile이 Jira를 가지고 함께 사라져야 할 때임"
대문자 Agile과 소문자 agile을 구분해서 쓰는 개념이 있고요,
being agile과 doing agile이 서로 연결되어 있지만, 구분해서 생각합니다.
being agile by doing agile.
애자일 도입 이유가 중요하죠. 개발 잘되라고 도입하겠습니까? 난 니들 노는꼴을 못보겠다. 얼마나 열심히 하는지 내가 한번 볼께 . 이런 마인드로 도입하는거죠. 그러니 헬이 되겠죠.
???: 폭포수라도 다시 끌어올리는 방법이 있습니다. 있어야 합니다. 안그러면 우리가 원하는 서비스를 만들 수가 없어요. 그런 유연하지 못한 업체는 망해야 합니다. 반드시!
K 애자일은 재평가 없는데.!
고객 : 이 화면에 버튼이 여기가 좋겠네요
개발자 : (밤새야 되구나 신규건도 있는데)
고객 : 다른 화면에 버튼이 있어야 겠네요
개발자 : (누가 분신술을 써줘) 네 하핫..
고객 : 아직 안되었나요 일정상 다끝났어야되는거 아닌가요?
개발자 : (살려줘) 네..;;
Hacker News 의견
-
Agile의 문제점
- 한 회사의 엔지니어링 디렉터로서, 독립적인 Scrummaster 팀이 아침 스탠드업만 주관하고 나머지 시간에 무엇을 하는지 알 수 없었음
- Scrummaster 팀의 역할을 줄이고 팀을 자율적으로 운영하도록 하여 회사의 중심 팀으로 성장시킴
- Scrummaster 팀은 절반으로 줄어듦
-
Agile Manifesto의 원칙
- 개인과 상호작용을 프로세스와 도구보다 중시
- 포괄적인 문서보다 작동하는 소프트웨어를 중시
- 계약 협상보다 고객 협력을 중시
- 계획을 따르는 것보다 변화에 대응하는 것을 중시
-
Agile의 핵심
- Agile은 개발 속도를 빠르게 하는 것이 목적이 아님
- 불필요한 기능을 피하고 낭비를 줄이는 것이 중요함
- 작은 반복 작업을 통해 큰 디자인을 피하고 ROI가 낮은 기능을 방지함
- JIRA는 문제를 추적하는 시스템일 뿐, 배달 문제의 원인이 아님
-
Agile의 유연성
- Agile은 고정된 방법론이 아니며, 팀과 조직에 맞게 유연하게 운영되어야 함
- 프로젝트마다 이해관계자가 다를 수 있어 유연하게 대응해야 함
-
JIRA에 대한 의견
- JIRA는 문제와 프로젝트를 읽고, 댓글을 달고, 작업 완료 여부를 확인하는 데 유용함
- 대부분의 사람들이 JIRA를 싫어하는 이유는 조직이 스프린트와 포인트를 관리 도구로 사용하기 때문임
- JIRA는 단순한 작업 및 버그 추적 도구로서 괜찮음
- Agile과 JIRA는 별개이며, Agile 프로세스 자체에 대한 불만이 많음
-
Agile의 기원
- Agile은 웹 개발 컨설팅에서 나쁜 고객을 관리하기 위한 방어적 프로세스로 탄생함
- 모든 결정을 문서화하고, 확정된 타임라인을 피하며, 작업 산출물을 세세하게 생성하는 것이 중요함
- 이는 소프트웨어를 만드는 좋은 방법은 아니지만 일관된 방법임
- 대규모 비기술 기업에게 매력적이며, 기술이 아닌 다른 요소가 경쟁 우위인 경우 소프트웨어가 충분히 잘 작동하기만 하면 됨
-
Agile의 현재
- Agile은 죽어가는 것이 아니라 이미 승리한 상태임
- 반복적인 개발이 소프트웨어 개발의 기본이 됨
-
JIRA의 문제점
- JIRA는 Agile이 아니며, 불필요한 기능이 많은 소프트웨어임
- 보드와 알림만 필요하다면 잘못된 사용법임
-
Agile의 적용
- Agile의 원칙을 수백 개의 프로젝트에 적용하려고 노력함
- 고정된 범위, 예산, 타임라인을 가진 프로젝트에서 Agile을 운영하는 것이 어려움
- 프로젝트 목표와 측정 방법을 정의하면 우선순위 기능으로 범위를 조정할 수 있음
- 일부 프로젝트는 Agile 방법론을 사용하고, 다른 부분은 워터폴 방식으로 진행하여 혼합된 접근 방식을 사용함