XP 대 전통적인 좋은 프로젝트 관리 [닫기]

https://stackoverflow.com/questions/1228066

22-07-2019
|

문제

저는 IT 업계에 몸담은 지 10년이 되었지만 "전통적으로" 관리되는 프로젝트 팀(잘 관리되는 팀과 제대로 관리되지 않는 팀 모두)에서 일했습니다.

저는 "새로운" 스크럼 또는 XP 유형의 프로젝트 관리에 대해 들어본 적이 있고 이에 참여하고 싶었지만(S/W 사람들로서 우리는 항상 새로운 것을 좋아합니다) 기회를 얻지 못했습니다.

내 질문은 이것입니다. "새로운" 방식으로 전환한 경험은 무엇입니까? 그것이 훨씬 더 좋았나요, 나빴나요, 아니면 전혀 다르지 않았나요?XP 개발 방식을 사용할 때 프로젝트 성공률이 향상되었습니까? 아니면 잘 관리되는 기존 프로젝트와 동일합니까?

이것은 정치적인 질문이 아니라 새로운 세계로 이동했거나 적어도 한 번 이상 경험한 경험일 뿐입니다.

미리 감사드립니다

해결책

XP에 대해 들어 본 적이 있기 전에, 나는 초기 직장에서 정말 좋은 관리자 (Mike)를 가졌습니다. 그는 엔지니어를 관리하는 데 익숙해졌으며 소프트웨어 관리로 전환했습니다. 몇 가지 나쁜 일을 경험 한 후 나는 그와 함께 일하기 전과 후에 가지고있는 그의 스타일과 전형적인 프로젝트 관리를 되돌아 보았습니다.

적어도 하루에 한 번 모든 사람을 만났지만 우리에게 일할 공간을주었습니다.
두 개의 열이있는 화이트 보드를 사용했고, 일하는 사람들과 그들이 일하는 것은 그 보드를보고 무언가가 끝났거나 완료되었는지 확인할 수 있습니다.
모두가 교차 훈련을했습니다. 나는 RC와 CV를 배웠고 거기에서 파일을 사용하는 방법
작업이 완료되면 생산적인 "포스트 모르텀"을 실행했습니다. 그는 "X 만 있으면 도움이 되었습니까?"와 같은 질문을 할 것입니다. 또는 "다음에 우리는 노력할 수 있습니까 ..."
모든 사람들이 짧은 작업을 계속하고 우리의 시간을 관리 했으므로 항상 무언가를 작업했지만 많은 물건이 쌓여 있지 않았습니다.

Mike는 종이에 모든 것을했습니다. 그는 노트와 색인 카드를 그와 함께 보관할 것입니다. 그는 경영진이 요청한 모든 것이 종종 메모 카드에 작성된 관리 가능한 작업으로 전환 될 것이라고 주장했다. 그는 명확하게 설명 할 수 없거나 명확한 목표를 가질 수없는 일을하는 사람이있는 사람을 거부했습니다. 그는 VPS에게 "당신은 무엇을 더 빨리 의미합니까?" "보고서는 어떤 종류의 메트릭을 보여주고 있습니까?" "왜 이것이 우선 순위가되어야합니까?" 그는해야 할 일과 "완료"의 의미를 기록하는 데 거의 무한한 인내심을 가지고있는 것처럼 보였다.

XP 책을 처음 읽었을 때, 나는 "Mike가 일하는 방식"으로 얼마나 친숙한 지 놀랐습니다.

Agile은 일련의 모범 사례를 구현하고 환경에서 작동하는 방식을 평가하는 것 같습니다. 그들이 작동하지 않으면 변경하십시오. 그들이 일할 때, 그들에게 고수하십시오.

전통적인 프로젝트 관리의 실제 문제는 종종 존재하지 않는 것이 아니라 실제로 존재하지 않는다는 것입니다. 나는 얼마나 많은 상점이 RUP 또는 코드를 완성하거나 민첩하게 사용한다고 주장하는지에 놀랐으며 실제로 프로젝트 관리로 인식 할 수있는 것은 없다. 물론 회의가 있습니다. 그리고 사람들은 프로젝트 관리자라고 불렀습니다. 그러나 "Project X에서 수행 된 작업"또는 "Project Y에서해야 할 일"과 같은 간단한 질문을하지만 아무도 답이 없습니다. 그들은 이메일을 발굴하거나 코믹하게 부정확 한 MS 프로젝트 파일을 가리켜 야합니다.

사람이 다이어트 중이라고 주장하고 자신이 먹는 음식이나 운동 방법에 대한 질문에 대답 할 수 없다면; 그들이 실제로 다이어트를하고 있다는 것을 받아들이시겠습니까?

다른 팁

갈 때 오래된 짐을 가지고 가세요.이는 이전에 가졌던 프로젝트 관리 나쁜 관행이 여전히 남아 있다는 것을 의미합니다.

그러나 우리와 고객 사이의 고리가 닫히기 시작하면서 상황이 크게 개선되었다고 말씀드리고 싶습니다.고객과의 피드백과 프로토타입이 더 많고 빈번해지면 고객이 "이건 내가 원한 게 아니야"라고 말하는 순간이 훨씬 줄어듭니다.

직장에서 직장에서 (약간 수정 된) 스크럼을 사용했는데 여기에 내 생각이 있습니다.

일일 회의와 번 다운은 작업을 진행할 동기를 제공했습니다.
우리 관리자는 연못을 가로 질러 동료들과 대화하고 "이것이 우리가 이번 달에 일하는 것"을 보여줄 수 있습니다.
당신은 어떤 작업을 수행 해야하는지 정확히 알고 있었고, 완료하는 데 필요한 시간을 이미 추정했습니다.
우선 순위가 변경되면 (새로운 작업, 중요한 버그가 추가됨) 스프린트에 추가하거나 단순히 백 로그로 밀어 넣는 잘 정의 된 프로세스가있었습니다.

이것들은 사랑스러운 답변이지만, 개발/디자인 방법론으로 모든 사람의 혼란스러운 프로젝트 관리를 생각합니다.

나는 몇 달 전에 Scrum을 시작한 팀에 있고 우리는 더 빨리 일을하고 훨씬 적은 "폐기물"(폐기 된 프로젝트)으로 일을 끝내는 것 같습니다. 소규모 팀 (4 개의 개발자)의 관찰.

Agile/XP 관행으로의 전반적인 이동이 매우 긍정적 인 것을 발견했습니다. 여러 가지면에서 프로젝트/개발 프로세스에 품질을로드합니다. 성공을보기 위해 경영진과 팀의 바이 인이 필요합니다 ... 몇 가지 제안 :

소규모 프로젝트 (2-3 명)와의 변화를 시험
현재 팀이 가장 개선 할 수있는 영역을 이해하고 (품질, 생산성, 시장 투 마켓?) 몇 가지 민첩한/xp/scrum (무엇이) 프로세스를 통합하십시오 ... 동시에 그것들을 모두 통합하지 마십시오. 변경 전에 어떤 프로세스가 어떤 문제를 해결하는지 이해합니다.
가능하다면 - 변경하고자하는 영역을 추적하고 동시에 실행되는 다른 프로젝트와 비교할 수 있습니다 (무언가를 개선하는 데 중점을 두는 것만으로도 개선하기에 충분합니다. 이에 대한 연구/용어가 있지만 그것이 무엇인지 잊어 버립니다. )
때로는 새로운 프로세스를 시작할 때 성능이 떨어질 것입니다. 이것은 학습 곡선의 일부입니다.
오늘 좋은 변화가 내일 좋은 변화로 남아 있다고 가정하지 마십시오. 항상 프로젝트 영역을 검토하고 언제든지 프로세스를 변경할 준비가되어 있습니다.
리팩토링 코드와 마찬가지로 변경 사항은 영원히 좋은 상태로 남아 있습니다. 프로세스를 리팩토링하십시오.
팀과 경영진으로부터 구매를 받도록하면 성공할 수 없습니다.

나는 민첩한 접근 방식이하는 일 중 일부를 좋아하지만 전통적인 접근 방식이하는 일 중 일부를 소중히 여깁니다.

둘 다 작동 할 수 있습니다. 두 사람의 혼합이 가능한 것과 마찬가지로, 지금 제가 팀에 가장 적합한 것입니다. 나는 점진적인 개발을 구현했으며 실제로 우리를 도와줍니다. 반복적 인 발전은 조금 더 어렵고 우리는 여전히 그 일을하고 있습니다. 그러나 우리는 다양한 구성 요소를 가지고 있으며 많은 이해 관계자 (및 PMS)는 전통적인 유물과 이정표를 선호합니다. 그래서 우리는 올바른 균형을 계속 찾아야합니다.

또한 방법론보다 더 중요한 것은 사람들이 그것을 구현하는 것임을 발견했습니다. 좋은 사람들은 방법론에 관계없이 좋은 일을하고 일을 할 수있는 방법을 찾지만, 방법론은 효율성 (및 사기 :))에 영향을 줄 수 있습니다. 그러나 정렬되지 않은 자원은 가장 좋은 방법론을 사용하고 결과가 좋지 않은 결과를 찾을 수 있습니다.

개발자를 위해 XP & Co.의 위대한 교훈은 릴리스주기가 짧고보다 진화적인 접근법입니다. 요구 사항 변경은 모든 프로젝트의 자연스러운 부분으로 받아 들여집니다. 또한 고객은 솔루션을 제안하지만 디자이너와 개발자는 문제를 이해해야합니다.

관리자를위한 교훈 : 개발자는 사양-코드-컨버터를 교환 할 수 없으며, 개별 강점과 약점은 주어진 주제에 대해 생산성 차이를 10 개 이상 만들 수 있습니다. 지식과 경험은 팀에서 가장 귀중한 기술이며 개발자는 각 오테르를 가르 칠 수 있습니다. 관리자는 필요하지 않습니다 이해하다 원하는 결과를 시행하기 위해 개발자가하는 일.

XP & Co.는 일반적으로 문제와 문제를 해결하는 것입니다. 회사를 변경하십시오. 영웅적인 XP 컨설턴트는 운명, 지연 및 탈선 된 프로젝트를 단독으로 저장하면 개발과 관리 사이의 버퍼 역할을합니다. 그러나 무엇을 배워야하는지보고 있다면 이러한 측면을 분리해야합니다.

최근 몇 년 동안 배운 것은 버그가 성격 결함이 아니며 사양이 변할 때 하늘이 떨어지지 않는다는 것입니다. 디자인 오류는 여전히 가장 비싸지 만 단일 "완벽한"디자인이 없다는 것을 배웠습니다. 한 가지를 올바르게 얻는 대신 우리는 많은 세부 사항이 잘못되지 않는 보호 조치를 구현해야합니다. 그리고 나는 "오른쪽"과 "잘못되지 않은"사이의 여유를 우리의 유리하게 사용하는 법을 배웠습니다.

내 경험은 전통적인 접근 방식보다 스크럼을 사용하는 것을 선호한다는 것이 었습니다. 자주 발생하지 않았기 때문에 일반적으로 프로젝트의 길이에 대한 요구 사항이 변하지 않을 수 있다는 것이 일반적으로 프로젝트가 1 년이 넘는 현재 프로젝트에 대해 최소 6 개월 동안 실행되는 것처럼 보입니다. .

프로젝트 관리가없는 경우도있을 수 있으며 모든 사람이 "작동"하기 위해 스크램블하기 때문에 공식적인 구조를 갖는 것은 아무것도 좋지 않습니다. 팀이 얼마나 잘 모이고 자아가 누군가의 코드가 아니라 팀의 코드로 나타나지 않는지에 대한 질문에 무언가가 있습니다. 다른 사람들이 그런 식으로 사물을 보게하려고합니다.

때때로 내가 사용한 일부 스크럼과 민첩한 접근 방식은 큰 폭포 대신 급류처럼되는 것 같습니다. 내 말은 수집 요구 사항의주기 - 분석 및 설계 - 구현 - 테스트 - 배포 및 업데이트 된 요구 사항을 반복하여 반복적으로 반복되는 것 같습니다. 결국 나오는 것은 프로젝트 스폰서가 결코 변경되지 않을 매우 상세한 요구 사항을 제공 할 수 없다면 프로젝트.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow