나는 자바 세계에서 Death March 프로젝트를 작업 해왔다. 처음에는 관리가 좋지 않고 다루기 힘들고 복잡한 기술 덕분에 처음부터 실패 할 프로젝트들이다. 보통 여러 시스템에 걸쳐 있으며 종종 폭포수 접근법에 묶여있다.Rails/Django 프로젝트가 Death March이 될 수 있습니까?
Rails와 Django는 신속한 변경에 신속하게 대응할 수있는 방향으로 애자일 개발 기술로 선전되었습니다.
대형 엔터프라이즈 시스템의 Death March 시나리오에 영향을받지 않는다는 뜻입니까? 아니면 Rails/Django 프로젝트에 여전히 복잡한 정도의 공간이 남아있어서 자바 프로젝트처럼 제어 할 수 없습니까?
물론입니다. 나는 죽음의 행진이 된 여러 장고 프로젝트에 대한 개인적인 경험을 가지고있다.
세계에서 모든 민첩한 개발 기술을 보유 할 수 있지만 회사가 민첩한 개념을 완전히 포용하지 못하면 죽음을 피하는 데 도움이되지 않습니다. 경영진이 특정 날짜에 제품을 제공 할 것을 요구하고 특정 기능 세트를 포함하는 경우 프레임 워크를 사용하면 도움이되지 않습니다. 사용자는 만족할 때까지 가능한 한 빨리 작업을 진행해야합니다. 그것이 죽음 행진을 의미한다면, 죽음은 행진입니다.
사망 행진은 사용하는 언어에 상관없이 가능한 나쁜 관리 및 계획 기능입니다.
+1 언어는 죽음 행진과 관련이 없습니다. Toyotas 또는 BMW를 수리 할 때 정비사가 초과 근무를 더 자주해야하는지 묻는 것과 같습니다. 사장님이 초과 근무를하는 경우에 따라 다릅니다. –
정직하게 말하면, 제대로 관리되지 않은 것이면 개발 프로세스를 쉽게하기위한 프레임 워크의 편의성이 있어도 실패 할 가능성이 있습니다. 그것들은 틀림없이 프레임 워크를 사용하기 때문에 죽음의 행진 시나리오에 면역되지 않습니다. 사용 된 기술이 의도 한대로 사용되지 않아 많은 프로젝트가 실패한 것을 보았습니다.
그것은, 요구되는 질문처럼 보인다 기술이 인간의 어리 석음을 해결할 수 있는지 여부입니다 ...
글쎄, 내가 아는 한, 아직 치료법이 없다. 당신이 링크 된 페이지에서
: 일정에 비현실적인 또는 지나치게 낙관적 기대
"
... 결과는 범위, 또는 둘 모두를 특징으로, 종종 해당 문서의 부족, 또는 을 포함 관련 교육의 어떤 종류 ... 종종 죽음의 행진 충분히에 "던져 시도 (에 의해 특히 지독한 시간, 주말, 또는 일을 팀 구성원을 요청하여 바로 프로젝트의 과정에 필사적 인 시도를 포함 할 것이다) 기관 문제에 "..."
마음에 온다, 당신이 언급 한 바와 같이 몇 가지 방법은, 죽음의 행진 (폭포 인에 더 민감한 것을 나에게 보인다는), 그것은 어떤 방법처럼 보인다 충분한 나쁜 관리가 하나가 될 수 있습니다.
예. 예를 들어 경영진이 그렇게 말하기 때문에 스프린트가 1 년이면 스크럼이란 무엇인가? – AlbertoPL
기술이 사용되면 왜 관리가 얼마나 나쁜지와 관련이 있습니까? 이것은 나에게 심각하게 어리석은 질문처럼 보입니다. 기술로 인해 빈약 한 관리가 어려울 것이라 생각되면 사용하려는 기술을 선택하기 전에 다른 문제를 해결해야합니다.
특정 기술이 민첩하다는 것에 대해 이야기하는 것이 좋습니다.하지만 실제로는 잘못된 것 같습니다. 나는 애자일 사고 방식을 진정으로 이해하지만, Rails 나 Django를 선택했던 팀보다는 Fortran에서 프로그래밍 된 팀 (관리 및 사용자 포함)과 협력하기를 원할 것입니다. 왜냐하면 멋지게 들렸으므로 스팸으로부터 스크럼을 알 수 없었기 때문입니다. (Fortran 애호가에게는 의도하지 않음)
10 년 전 StackOverflow가 존재하는 경우, 이것은 속임수 일 뿐이며, 자바가 C++에서 경험했던 죽음의 행진에 면역이되어 있는지 묻는 프로그래머 일 것입니다. . –