소프트웨어 개발 과정을 이해 관계자에게 어떻게 제시 하시겠습니까?

우리는 bugzilla를 사용하여 버그 및 기능 요청을 추적하고 개발자가 기능 코딩을 마치면 별도의 릴리스 정보를 작성해야합니다. 구식, 알아

위의 배열에서 우리가 가진 한 가지 문제는 이미 판매하고있는 소프트웨어에 적합하지만 새로운 소프트웨어 개발 프로젝트의 진행 상황을 추적 할 때는 전혀 쓸모가 없다는 것입니다. 그 이유는 새로운 소프트웨어를 개발할 때 bugzilla를 사용하여 기능을 추적 할 수 없거나 오히려 기능을 추적 할 수 없기 때문입니다. 소프트웨어 응용 프로그램에는 코딩 할 기능이 너무 많으며 버그질라에 넣는 느낌이 들지 않았지만 우리가 할지라도 어떤 기능이 어떤 기능에 의존하는지 알 수 없었습니다. 배송 날짜를 정확하게 예측하십시오).

그런 다음 이해 관계자는 개발 진행 상황 (또는 부족)에 대해 걱정하고 팀 리더 (진정한)의 평가에 대한 문을 두드리기 시작합니다. 새 신청서가 얼마나 완성되지 않았는지 알 수 있습니다.

소프트웨어 개발 과정을 이해 관계자에게 어떻게 제시 하시겠습니까?

민첩한 방식으로 수행 : 조기 시연 및 자주 시연.

실제로 그것을 사용하여 진보의 느낌을주는 내장 느낌을 능가하는 것은 없습니다.

면책 조항 : 나는 전에 Bugzilla를 사용한 적이 없으므로 프로젝트 관리 기능이 확실하지 않습니다 ( Bugzilla : Bugzilla를 사용한 프로젝트 관리가 좋아 보이지만).

이 문제는 훈련이 부족한 결과처럼 들립니다. 프로젝트 관리 소프트웨어를 사용 하여 시간과 노력 을 계획하고 책임 을 져야 합니다. 모든 프로젝트 관리 소프트웨어 ( Jira and Redmine 에 깊은 인상을 받았습니다 )에는 작업을 한 수준으로 분할하여 각 작업에 대해 정확한 (~ 시간) 예상치를 제공 할 수있는 기능이 있습니다.

거기에서 징계를 받고 업무 세부 사항을 작성 하는 경우입니다. 이것은 프로젝트 진행 상황에 대한 즉각적인 평가를 제공하는 간트 차트 (Redmine) 또는 프로젝트 번 다운 차트 (Jira)의 형태로 개요를 제공합니다.

하루가 끝나면 단순히 시간 추정 (정확성을 최대화하기 위해 작업을 분류하여 수행)을 제공 한 다음 개발이 시작될 때 진행률을 초기 (또는 수정 된) 추정치와 비교합니다.

프로젝트 관리가 엄청나게 고급 스럽거나 정교한 도구가 필요하지는 않으며 KISS는 전담 프로젝트 관리자가없는 경우 나쁜 관리가 아닙니다. 새 소프트웨어를 개발하는 경우 최소한 일종의 사양 또는 기능 목록이 있어야합니다. 예상 시간, 예상 시작 날짜, 예상 배달 날짜, 작업 시간 및 상태 표시기 (완료, 진행 중, 시작되지 않음)와 함께 스프레드 시트에 항목을 분류하여 덤프하십시오. 그런 다음 수 제조 (예 : 총 예상 시간 대 완료된 항목에 대한 추정 시간 수에 따라 % 완료로) 느낌이 프로젝트 진행 상황을 표시하는 적절한 어떤 통계 생성합니다. 밝은 색상으로 몇 가지 그래프를 생성하면 모든 사람이 행복합니다.

소규모 팀에게는 많은 PPM 소프트웨어가 과도하게 사용되어 여러 프로젝트, 리소스 할당, QC 항목 등을 추적 할 수 있습니다. 실제로 필요한 경우 상태 보고서를 작성하는 것만으로도 스프레드 시트가 제대로 작동합니다. "127 개의 기능 중 92 개를 완료했으며, 일정보다 2 주 앞서 코딩 및 테스트를 완료 할 것으로 예상됩니다." 모두 박수.