저는 IT 업계에서 10 년째 근무했지만 "전통적으로"관리되는 프로젝트 팀 (잘 관리되거나 잘못 관리되는 프로젝트 팀)에서 일했습니다.XP와 전통적인 좋은 프로젝트 관리
"새로운"스크럼이나 XP 형식의 프로젝트 관리에 대해 들어 본 적이 있고 (내가 추측 한 것과 같은 새로운 것을 좋아하는 사람들처럼) 하나의 일부가되기를 갈망하지만 기회가 없습니다.
내 질문은 - "새로운"방식으로 옮긴 경험이 무엇입니까? - 현저하게 좋았던 것이 든 더 나빴습니까? XP 개발 방식을 사용할 때 프로젝트 성공률 향상이 있었거나 잘 관리 된 전통적인 프로젝트와 동일합니까?
이것은 정치적인 질문이 아니라 새로운 세계로 이전하거나 적어도 한 번 이상 경험 한 경험 일뿐입니다.
미리 감사드립니다.
필자는 XP에 대해 들어 본 적이 없기 때문에, 내가 가진 초기 직업에서 정말 좋은 관리자 (마이크)를 가졌습니다. 그는 엔지니어를 관리하고 소프트웨어 관리로 전환하는 데 익숙했습니다. 몇 가지 좋지 않은 경험을 한 후에 나는 그와 함께 일하기 전과 후에 전형적인 프로젝트 관리 대 그의 스타일을 되돌아 보았습니다.
마이크했던 모든 것을 쌓여 없었 종이에. 그는 노트북과 색인 카드를 보관할 것입니다. 그는 경영진이 그에게 물어 본 모든 것이 메모 카드로 작성되는 관리 가능한 업무로 전환되어야한다고 주장했다. 그는 누구도 명확하게 설명 할 수 없거나 명확한 목적으로 작업하지 못하게했습니다. 부사장에게 "무엇이 더 빠르다는 뜻입니까?"라고 물었습니다. "어떤 종류의 측정 항목이 보고서에 표시 되나요?" "이것이 우선 순위가되어야하는 이유는 무엇입니까?"그는해야 할 일과 끝난 것을 쓸 때 무한한 인내심을 가지고있는 것 같았습니다.
XP 서적을 처음 읽었을 때 나는"마이크의 일하는 방식이 얼마나 익숙했는지에 놀랐습니다.
그것은 민첩한 그냥 모범 사례의 집합을 구현하고 사용자 환경에서 작동하는 방식 평가에 대한 것 같다 그들이 일을 할 때 ". 그들이 작동하지 않는 경우, 그것들을 변경합니다. 그들에게 충실.
저는 전통적인 프로젝트 관리의 실제 문제는 실제로 존재하지 않는다는 것보다 더 자주 발생한다고 생각합니다. 나는 많은 상점들이 RUP 나 코드 컴플리트 또는 애자일을 사용한다고 주장하고 놀랍습니다. 프로젝트 관리. 물론 회의가 있습니다. 사람들은 프로젝트 관리자라고 불렀습니다. 그러나 "프로젝트 X에서 수행 된 작업"또는 "프로젝트 Y에서 수행 할 작업"과 같은 간단한 질문을하고 아무도 대답을하지 마십시오. 전자 메일을 통해 파고 들거나 코믹하게 부정확 한 MS 프로젝트 파일을 지적해야합니다.
다이어트를한다고 주장하는 사람이 먹는 음식이나 운동 방법에 관한 질문에 답할 수없는 경우; 그들이 정말로 다이어트 중이라는 것을 받아 들일 수 있습니까? XP & (주)
개발자의이동하면 오래된 수하물을 가져갑니다. 이전에 가지고 있던 프로젝트 관리 나쁜 관행이 여전히 남아 있다는 것을 의미합니다.
그러나 나는 우리와 고객 사이의 고리를 폐쇄하기 시작했을 때 크게 개선되었다고 말할 것입니다. 고객과의보다 많은 피드백과 프로토 타이핑은 고객의 "내가 원한 것이 아닙니다."라고 말하는 순간이 훨씬 적습니다.
저는 몇 달 전에 스크럼을 시작한 팀에 속해 있습니다. 우리는 일을 빨리 끝내고 낭비가 훨씬 적습니다 (스크랩 된 프로젝트). 우리 팀 (4 명의 개발자)의 관찰.
내가 직장에서 전 (약간 수정) 스크럼을 사용하고 여기에 내 생각이다했습니다 작업에 진전을 동기 부여를 제공
내 자신의 경험을 Echos –
나는 애자일/XP 관행에 대한 전반적인 움직임이 매우 긍정적이며, 여러면에서 프로젝트/개발 프로세스에로드 품질을 앞세운 것으로 나타났습니다. 당신은 몇 가지 제안 ... 정말 성공을보고 구매-의 관리에서와 팀에서해야합니다 :
을 강제 할 수는 없지만 나는 또한 어떤 가치 전통적인 접근 방식이하는 일들.
두 가지가 혼합되어있어 둘 다 작동 할 수 있습니다. 이는 내 팀에 가장 적합한 것으로 나타났습니다. 나는 점진적 개발을 구현했으며 실제로 우리를 돕습니다. 반복 개발은 조금 더 어려워서 우리는 아직 작업 중입니다. 그러나 우리는 다양한 구성원을 보유하고 있으며 많은 이해 관계자 (및 PM)는 전통적인 인공물과 이정표를 선호합니다. 그래서 우리는 올바른 균형을 유지해야합니다.
나는 또한 방법론보다 더 중요한 것은 그것을 구현하는 사람들이라는 것을 발견했다. 좋은 사람은 방법론에 관계없이 좋은 일을하고 일을 처리하는 방법을 찾지 만 확실히 방법론이 효율성 (및 사기)에 영향을 미칠 수 있습니다. 그러나 제대로 정렬되지 않은 리소스는 최상의 방법론을 사용하여 열악한 결과를 제공 할 수있는 방법을 찾을 수 있습니다.
, 큰 교훈은 짧은 출시주기이며,보다 진화 적 접근 - 의미에서 요구 사항의 변화는 어떤 프로젝트의 자연스러운 한 부분으로 받아 들여진다. 또한 고객은 솔루션을 제안하지만 디자이너와 개발자는 문제를 이해해야합니다. 관리자를위한
수업 : 개발자는 주어진 주제에 대한 10 개 이상의 생산성 차이를 만들 수 있습니다 exchangable 사양 - 투 - 코드 컨버터, 개인의 강점과 약점이 아니다. 지식과 경험은 팀에서 가장 가치있는 기술이며 개발자는 각 oterh를 가르 칠 수 있습니다. 관리자는 을 이해하여 개발자가 원하는 결과를 얻기 위해 어떤 작업을 수행 할 필요가 없습니다.
XP & 주식은 일반적으로 회사 변경을 에 문제가 이러한 솔루션을 혼합한다. 운명적이고, 지연되고, 탈선 된 프로젝트를 혼자서 저장하는 영웅적인 XP 컨설턴트는 개발과 관리 사이의 완충 장치 역할을합니다. 그러나 무엇을 배울지를 바라 보는 경우, 이러한 측면을 분리해야합니다.
내가 최근에 배운 것은 특성상 결함이 아니며 사양 변경시 하늘이 떨어지지 않는다는 것입니다. 디자인 오류는 여전히 가장 비싸지 만 완벽한 "단일"디자인은 없다는 것을 알게되었습니다. 우리가 옳은 것을 얻는 대신에, 많은 세부 사항들 중 아무 것도 잘못되는 것을 막을 수있는 보호 장치를 구현할 필요가 있습니다. 우리는 "옳은 것"과 "잘못이 아닌 것"사이의 여유를 우리의 이익에 사용하는 법을 배웠습니다.
이것은 멋진 답변이지만 모든 사람들이 개발/디자인 방법론에 대한 혼란스러운 프로젝트 관리라고 생각합니다.
필자의 경험에 비추어 볼 때, 일반적으로 프로젝트가 현재 6 개월 이상 실행되는 프로젝트의 기간 동안 요구 사항이 변경되지 않을 수 있으므로 기존 방식에 비해 스크럼을 선호합니다. 1 년이 넘었습니다.
프로젝트 관리가없고 모든 사람이 "작동하도록"스크램블하는 경우도있을 수 있으므로 공식적인 구조 만 있으면 아무 것도 좋지 않습니다.팀이 얼마나 잘 어울리는 지에 대한 질문에는 무언가가 있습니다. 자존심은 다른 사람의 코드가 아니라 코드의 코드처럼 드물게 나타나며, 그룹의 종류가 있습니다. 각 사람이 자신의 의견을 갖고있는 동안 아무도 생각하지 않습니다. 다른 사람들이 그런 식으로 행동하게 만듭니다.
때때로 내가 사용 해본 일부 스크럼과 애자일 방식은 큰 폭포 대신 급류처럼 끝나는 것처럼 보입니다. 제가 말하고자하는 것은 분석 및 설계 - 구현 - 테스트 - 배포 요구 사항을 수집하고 업데이트 된 요구 사항을 수집하는 사이클이 반복되어 반복적으로 반복되어 최종 결과물이 프로젝트 스폰서가 결코 바꿀 수없는 매우 상세한 요구 사항을 제시 할 수 없다면
커뮤니티 위키가되어야합니다. –
당신이 말하는 "전통 좋은 관리"가 무엇인지에 대해 너무 명확하지 않습니다. 나는 각각 다른 정의를 가진 많은 관리자들과 함께 해왔다. – monksy