방법론과 라이프 사이클의 실제 사례

Question

올바른 라이프 사이클과 방법론을 선택하는 것은 그렇게 많은 방법론이 없었던 때와 마찬가지로 쉽지 않습니다. 요즘에는 새로운 방법론이 매일 등장합니다.

나는 대부분의 프로젝트가 일정 수준의 진화를 필요로하고 각 프로젝트가 나머지 프로젝트와 다르다는 것을 발견했다. 그렇게하면 극단적 인 프로그래밍이 15 명의 직원을 둔 특정 회사의 프로젝트에서 작동하지만 100 명의 직원 회사와는 제대로 작동하지 않거나 특정 프로젝트 유형 (예 : 실시간 응용 프로그램, 과학 응용 프로그램 등)에서는 작동하지 않습니다. .

대부분 프로젝트 유형, 프로젝트 크기 (작업하는 사람의 수), 프로젝트 시간 (실제 또는 계획), 프로젝트 수명주기 및 방법론 등을 설명하는 경험 목록을 갖고 싶습니다. 프로젝트가 성공 또는 실패했습니다. 다른 모든 데이터는 감사 할 것입니다. 충분한 데이터가 있으면 패턴을 찾을 수있을 것 같습니다. 물론, 의견을 환영합니다.

• PS : PT, 매우 큰 : 매우 긴, LC : 증분 - CMMI, PR : 성공
• PS : PT, 매우 큰 : 매우 긴, LC : 폭포 - CMMI, PR : 성공

편집 : 나는 모든 대답의 통계로 "요약"을 구성 할 것입니다.

Answer 1

내 개인적인 경험 :

• 프로젝트 크기 : 매우 큰 (150 + 명)
• 프로젝트 시간 : 매우 긴 (육년)
• 사업 소득 (추정) : 40 만 $ (군대 지불 중)
• 프로젝트주기 : 증분 lyfetime. 주요 이정표는 모두 입니다.
• 프로젝트 구조 : (시스템 부서, 개발 부서 등)에서 전통적이지 않으므로 좋습니다. 나중에 기반으로하는 프로세스 ( 프로세스는 요구 사항, 디자인, 구현, 테스트, 피드백, 메트릭)의 흐름을 확립합니다.
• 프로젝트 결과 : 성공 (지금까지) 여기

Answer 2

당신이 이동 :

• 프로젝트 크기 : 코드의 약 1 만 라인, 30명
• 프로젝트 시간 : 구년
• 을 프로젝트 라이프 사이클 : 고객의 큰 요구 사항으로 인해 오래된 폭포, QA 팀에 배달 시간이 비 춥니 다. 대형 고객에 대한 고객의 약속이있을 때 민첩하기가 매우 어렵습니다.
• 프로젝트 구조 : 부서 단위로 조직되어 있지만 CMMI를 사용하여 동기화 상태를 유지합니다. 당사는 이해 관계자, 작업 제품, 편차 절차 등을 보유하고 있습니다.
• 프로젝트 결과 : 우리가 정말 CMMI의 구현을 개선했습니다와 때마다 시간에

-C를 우리의 지난 몇 자료를 전달했다.