[%] 애자일 스크럼이 안좋은 패러다임임??

[익명(14.37)]

이유가 머임?

[익명(118.235)]

좆소들이 잘못된 애자일로 땔감들을 괴롭힘 - dc App

[fender(mysticfall)]

참고로 패러다임은 방법론하고는 좀 다르다. 애자일 방법론은 장점도 많아서 널리 사용되는데, 환경에 따라서 오용될 가능성도 많고 잘 안 맞는 부분도 있어서 비판도 자주 받는 편이긴 함. 대표적으로, 윗 덧글에서 언급한 것 처럼 애자일을 개발자 쪼는 도구로 쓰는 경우가 있는데, 그건 잘못된 도입 사례이지만 은근히 흔하기도 해.

[익명(106.250)]

애초에 잘못된게 아니라 IT쟁이들이 착각하고 있는것임. 원류 지식으로 파고 들어가면 toyoda style + kanban의 일본식 TPM시스템 이론+kaizen이론이 미국에서 연구되어 U.S stylized 된 CI(continuous improvement)라는 경영관리 사고방식일 뿐임. IT로 이 방식이 넘어오면서 몇몇 기술쟁이들이 이걸 무슨 테크닉인것 처럼 포장하면서 방법론화 됨

[익명(59.12)]

잘알고있노.. 기계과나 생산관리하는 사람한텐 매우 익숙한 이론이지 그냥 사람쥐어짜느넉임

[익명(106.250)]

여어 펜더 간만~

[익명(106.250)]

여튼 실증적으로 토요다방식 성공한 나라는 일본이랑 미국의 극히 몇몇 기업 밖에 없음. 저 이론철학은 배경에 인간을 깔고 있기에 안될 놈들이 사는 나라의 인간들이 적용하려면 그냥 안되는 것 뿐임.ㅋㅋㅋㅋ

[black7375(220.70)]

???: 식스시그마 도입하자!!

[익명(211.36)]

식스시그마 블랙벨트 진짜 진짜 젤 싫다

[익명(211.36)]

주짓수를 그렇게 열심히 했으면 몸이라도 좋아지지 시발넘들

[익명(106.250)]

애자일이 잘되는 회사 = 그냥 일잘하고 공부잘하고 자체개선 잘하는 애들이 많이 포진된 회사일 뿐임 ㅠㅠㅠㅠ 그런회사는 사실 애자일 말고 waterfall로 해도 잘함.ㅋㅋㅋㅋㅋㅋ 이상 경영관리쪽 연구하는 사람만이 알고있는 불편한 진실임.ㅋㅋㅋ

[익명(118.235)]

요컨데 애자일 찬양하는 좆소pm들을 묶어놓고 존나게 때려야 한다는거군 - dc App

[익명(106.250)]

빙고. 줘패야 말을 듣는다. 빙고빙고빙고

[fender(mysticfall)]

스크럼의 경우, 개인적으로 느끼는 불만은 개발 리더의 역할에 대한 명확한 정의가 없다는 거다. 대표적인 게 스토리 포인트나 우선 순위에 대한 부분인데, 일반적인 해석은 그건 비즈니스 요구 조건의 복잡도 같은 걸 근거로 산출하거든. Product Owner도 기본적으로는 고객의 요구 조건을 바탕으로 스크럼을 운영하는 사람이지 기술 전문가는 아니니까. 근데 현실적으로 프로젝트를 하다보면 꼭 비즈니스적인 텀으로 설명할 수 없는 기술적인 작업들이 나오기 마련인데, 그런 걸 일반적 스토리와 묶어서 포인트 할당하고 우선 순위를 조율하는 과정이나 책임 소재가 불분명한 것 같다. 그게 다 스파이크 같은 개념으로 커버 되는 것도 아니니까.

[익명(106.250)]

스크럼에서 그런 불만을 느낀다면 경영관리 이론 쪽의 품질분임조 활동이 어떻게 이루어지는지 좀 찾아보면 나름대로 불만의 원인을 알 수 있을 거라 생각함. 애초에 위에서 말한 애자일의 원류이론은 PM체제하에서 진행되는 이론이 아님. 다기능공 (IT에서는 이걸 데브옵스라고 하더라..ㅋㅋㅋ) 제도에서 단위생산성개념을 배제한 조직생산성 개념으로 만들어진 이론이라 프로젝트 리더가 있어야하는 IT기반 활동에서 충돌이 생길 수 밖에 없음.

[fender(mysticfall)]

니가 말한대로 스크럼/칸반 같은 건 원래 제조업 동네에서 출발한 방법론이니 IT에 적용하면서 충돌이 생기는 것이겠지. 근데 이 동네에서 유행한지 벌써 십 몇 년은 지났기 때문에 잘하는 동네는 어느 정도 노하우가 쌓이기도 했다고 본다.

[익명(106.250)]

으흠.. 근데 십몇년이나 지나서 노하우 어쩌고하기엔 좀 힘들다... 원류이론은 생긴지 70년도 지났어... 그런데 아직도 매년 매년 실증 검증하면서 성공적인 상황의 요소 검증이 일어나고 있고 저 오래된 구닥다리 이론이 세계적인 저널에서 계속 논의되고 있다는건 저게 방법론이라기 보단 그냥 약팔이 사상이란 반증이기도 하고..

[익명(106.250)]

이 양반아. 어쩌다가 우연히 온라인상에서 이렇게 조우라도 하면 인사하면서 손이라도 흔들어라.ㅋㅋㅋㅋ 사람 삐치게 위에서 인사한거 씹고 그랭 ㅋㅋㅋㅋㅋㅋ 여튼 잘자고~

[fender(mysticfall)]

씹으려고 한게 아니라 뭐라할지 애매해서, 누구인지 확신도 안들고... 말투 보면 짐작은 가는데 아이피를 다 외우진 않으니까 ㅎㅎ;

[익명(106.250)]

아 그리고 스크럼이랑 칸반.. 저거 "방법론" 아님(IT에서 경영관리론을 잘못 이해해서 method라고 원서에서 자주언급되는데 노노...) 그냥 셀프 모티베이션에 의한 정신개조사상임. 그걸 눈에 보이게 기록해서 갈구자는 것 뿐이고.ㅠ

[익명(106.250)]

나야 나 프갤에서 씐나게 자네와 함께 90년대 라떼얘기하던 ㅠㅠ 난 통피 고정이라구~

[fender(mysticfall)]

원류야 어떻든 현 시점에서 상당히 폭넓게 도입된 방법론인 건 사실이잖아. 이런 저런 설문 조사 결과를 봐도 그렇고, 프로젝트 관리 도구들 보면 칸반 보드 같은 건 거의 기본이 된 걸 봐도 그렇고. 여튼 반갑고 잘자라 ㅎㅎ

[fender(mysticfall)]

근데 애자일이 좋은 점도 많아. 잘 돌아가는 경우 주먹구구로 이 정도 기능이면 6개월이면 되겠네 하는 식으로 밀어부친다던지 하는 일이 적지. 물론 애자일이라고 프로젝트 데드라인이 없는 건 아니지만, 적어도 팀의 '속도'를 경험적으로 측정해서 보다 정확한 예측을 할 수 있고, 생각보다 진도가 늦는다면 어떤 일이 얼마나 쌓여있고 어디서 막혀있고 그런 것들이 투명하게 드러나니까, 무작정 열심히 안해서 그런다는 식의 해석도 피할 수 있다... 물론 이상적으론 말이지.

[익명(110.70)]

일정산출을 정량화할 수 있는 장점이 있어서 이거 몇일 걸리겠다 하는 예측이 가능한 짬이 쌓이긴 한데 개발자한테 과한 투명성을 강요한다는 주장도 있더라