프로젝트는 수요를 핵심으로 해야 한다. 프로젝트가 성공할 수 있는지, 수요에 대한 정확한 파악은 성공 요인의 60% 를 차지해야 한다. 다시 성공한 시스템 아키텍처 설계 및 팀 관리, 요구 사항이 빗나가면 그 반대다. Eas 프로젝트의 특수성으로 인해 프로젝트 개발 과정에서 고객과의 효과적이고 빠른 커뮤니케이션 채널을 구축하는 것이 프로젝트 성공의 열쇠입니다.
수요는 반드시 고객의 확인을 받아야 한다. 요구 사항 조사 및 분석을 통해 얻은 사용자 요구 사항 및 소프트웨어 요구 사항 설명서는 고객이 서명해야 합니다. 확인이 필요한 내용에는 프로젝트 요구 사항의 목표, 범위 및 기능 포인트 (사용 사례) 가 포함됩니다. Eas 프로젝트의 선행 단계에서 수요에 대한 중시가 부족하여 수요에 대한 이해에 약간의 편차가 발생하여 프로젝트의 진행에 영향을 미쳤다. 다행히 제때에 바로잡았으니 프로젝트 관리부의 도움으로 모든 수요는 고객 또는 고객 대표의 서명을 받아 확인되었다. (윌리엄 셰익스피어, 프로젝트 관리, 프로젝트 관리, 프로젝트 관리, 프로젝트 관리, 프로젝트 관리, 프로젝트 관리, 프로젝트 관리, 프로젝트 관리) 이렇게 하면 프로젝트가 고객의 검수를 받을 때 충분한 보장을 받을 수 있다.
이 프로젝트는 전담 수요 분석가를 만들어야 한다. 회사에는 전문적인 수요 분석가가 없다는 것은 인력 배치의 큰 폐단이다. (소프트웨어 오픈 작업의 세분화, 첫 번째 단계는 전문 시스템 분석가 또는 수요 분석가가 있어야 한다는 것입니다. ) eas 프로젝트 개발 과정에서 이 문제의 심각성을 충분히 인식하고 있습니다. 수요가 끊임없이 변화하고 있으며, 고객이 서명을 미루는 것은 전문적인 경험 있는 수요 분석가가 없기 때문입니다. 일반 개발자는 수요를 조사하고 요구 사항 사양 설명서를 작성할 때 항상 편차나 오해가 발생합니다. 소프트웨어 요구 사항 분석은 중요하고 책임있는 기술입니다. 전문 교육을 받지 않은 수요 분석가는 대개 프로젝트에 숨겨진 위험을 초래할 수 있습니다.
프로젝트는 각 모듈에 대한 수요 인터페이스를 지정해야 합니다. 그래야만 프로젝트 팀이 적시에 고객과 소통하고 고객의 요구와 피드백에 신속하게 대응할 수 있습니다. Eas 프로젝트의 초기 개발에서 수요 인터페이스가 적시에 구축되어 수요 변경이 프로젝트에 미치는 위험을 어느 정도 피했습니다. 확립 된 수요 인터페이스 직원은 체계적인 교육을 받지 않았으며, 수요 조사 및 고객과의 의사 소통 과정에서 업무 성과는 만족스럽지 않다고 말할 수 있습니다.
수요 조사 기록 및 수요 추적 테이블 유지 관리에주의하십시오. 이 일은 충분히 잘하지 못했다. 수요 조사관이 전문적이지 않기 때문에 프로젝트 관리자와 수요 분석 책임자는 이 과정에 대해 충분한 주의를 기울이지 않고, 이 과정을 모니터링할 좋은 도구나 프로세스를 가지고 있지 않기 때문에 수요 조사 기록은 더 큰 역할을 하지 못했다. (윌리엄 셰익스피어, 윈스턴, 수요 분석, 수요 분석, 수요 분석, 수요 조사, 수요 조사, 수요 조사, 수요 조사) 또한 수요 추적도 중요합니다. 결국 어떤 프로젝트의 수요도 고정적이지 않고, 수요는 언제든지 변경될 수 있으며, 개발자가 달성한 수요도 고객의 요구에서 벗어날 수 있습니다.
유지 관리 수요 매트릭스에 주의하십시오. 프로젝트 관리자는 이러한 컨텐츠에 대한 충분한 관심과 이해가 부족하고 프로젝트 개발 프로세스 시스템에는 좋은 수요 매트릭스 문서 템플릿이 부족합니다. 그러나 프로젝트 중반과 후반에 프로젝트는 eas 프로젝트 요구 사항의 기능 목록을 적시에 작성하고 제공 버전과 연계하여 고객과 협의하여 수요 이탈의 위험을 피했습니다. (수요 추적, 모든 원시 수요는 시종일관 있다. 최초 수요->; 사용자 요구 사항-> 제품 요구 사항->; 소프트웨어 요구 사항->; 디자인->; 테스트 및 일련의 추적. 수요 추적의 목적 중 하나는 모든 수요가 달성되었는지 확인하는 것이고, 더 많은 것은 변경 영향 분석이다.)
수요 변화를 통제하다. 건설은행의 역할을 중시하고 수요 변화에 대한 대응 메커니즘을 세우다. Eas 프로젝트 팀은 수요 변화에 대한 대응이 적시에 이루어지지 않아 프로젝트 관리자와 프로젝트 관리 팀이 책임을 져야 합니다. (영역 제어 내용 영역 관리에서 변경 관리는 구성 관리의 중요한 부분입니다. 수요는 반드시 통제해야 한다. 그렇지 않으면 계획이 자주 조정되고 혼란스러울 수 있다.)
디자인
건축 설계를 중시하다. Eas 프로젝트의 성공은 어느 정도 우수한 프레임워크 개발 팀에서 비롯되었으며, 프로젝트 초기부터 전체 시스템의 아키텍처를 기본적으로 파악했습니다. 약간의 변화가 있었지만 핵심 구조는 크게 변하지 않았다. 따라서 Dell 은 개발 효율성을 크게 향상시키고 프레임워크의 중복 코드를 피할 수 있는 안정적이고 간단한 시스템 프레임워크를 구축했습니다. (소프트웨어 개발의 두 번째 중요한 분업은 전문 아키텍처 디자이너가 있는 것이 가장 좋다. 아키텍처 설계와 전체 설계는 1-2 명이 완성해야 한다. 개념의 높은 무결성과 설계의 일관성을 보장한다) [1][2][3][4]
디자인에 대한 선택을 잘하다. 프로젝트 개발의 세 가지 요소는 비용, 품질 및 진도입니다. 품질 보장을 전제로, eas 프로젝트 팀은 특히 진도를 고려할 때 시스템의 확장성을 희생하는 기술에 지나치게 중점을 두지 않습니다. 이는 시스템의 사후 유지 관리에 약간의 위험을 초래하지만, 프로젝트의 진도를 효과적으로 보장할 수 있다. Eas 의 초기 아키텍처 설계부터 castle 과 AOP 를 도입하여 ORM 및 교차 절단 관심 지점 (예: 로그, 예외, 권한, 트랜잭션 등) 의 구현을 단순화하려고 했습니다. 또한 wcf 를 사용하여 SOA 를 사용하여 느슨하게 결합된 서비스 지향 어플리케이션을 구축하고자 합니다. 그러나 고객의 요구가 변화함에 따라, 우리는 기술적 어려움을 극복하고 castle 과 AOP 를 꾸준히 사용하면서 wcf 를 채택하겠다는 생각을 과감히 포기했고, 이를 위해 프레임워크 개발팀을 설립했다. 그것은 우리가 기술의 선택에 올바른 결정을 내린 것으로 밝혀졌습니다.
Ui 프로토 타입 디자인에 중점을 둡니다. 시스템의 프로토 타입 설계 및 수요 분석은 서로를 보완합니다. 좋은 프로토타입 버전을 고객에게 제공할 경우 고객은 시스템 구현을 더 잘 이해하고 커뮤니케이션의 효율성과 정확성을 높일 수 있습니다. Eas 프로젝트에서는 처음부터 프로토타입 설계 팀을 구성했으며 요구 사항 분석 단계에서 프로토타입 설계를 시작했습니다. 이러한 접근 방식은 고객 커뮤니케이션, 수요 확인, ui 설계에 큰 역할을 합니다. 하지만 이 점에서 전문 ui 디자이너가 부족해 이 작품에는 여전히 큰 결함이 있으며, 심지어 ui 의 디자인까지 반복 버전 제공에 큰 장애가 되고 있다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 예술명언) 프로젝트 후반에 ui 에 대한 버그가 가장 많았다. 따라서 유사한 웹 응용 프로그램을 개발할 때 가능한 한 빨리 ui 설계 사양을 설정하여 모든 ui 설계를 제한해야 한다고 생각합니다. 동시에 전문 ui 디자이너를 양성하여 프로토타입 설계를 시작할 때 가능한 한 빨리 ui 상호 작용 디자인을 완성해야 한다. 또한 요구 사항 단계에서 요구 사항 분석가와 코딩 단계에서 개발자와 협력하는 전담 ui 디자인 팀을 구성해야 합니다. (프로토타입 설계는 사전 사용자 수요 마이닝을 강화하고 사후 수요 변화를 줄이는 중요한 수단입니다. 전문 ui 디자이너가 필요하지 않아도 수요 분석가가 할 수 있습니다. ) 을 참조하십시오
실험
테스트 멤버는 요구 사항을 이해해야 합니다. 요구 사항을 이해하지 못하면 테스터는 올바른 테스트 케이스를 작성할 수 없습니다. 또한 테스트 과정에서 요구 사항을 오해하여 잘못된 버그 에스컬레이션을 초래하여 개발자의 생산성에 영향을 줄 수 있습니다. 개발자와 테스터의 협력을 강화하다. 개발자는 테스터가 제출한 버그에 즉시 응답해야 합니다. 테스터도 개발자가 만든 버그 수정을 추적해야 합니다. (테스터는 자신과 수요 분석가의 차이점을 인식해야 합니다. 테스터는 수요 분석가처럼 개발 업무를 분석할 필요는 없지만 수요 분석가처럼 분석된 수요와 업무에 익숙해야 합니다. ) 을 참조하십시오
테스트 초기에 테스트 원칙을 결정하고 버그의 심각도를 분류해야 합니다. 또한 버그 수정의 우선 순위를 결정해야 합니다.
진행 제어
좋은 프로젝트 계획은 프로젝트 진도에 큰 편차가 생기지 않도록 하기 위한 전제 조건이다. 전체 프로젝트 계획은 프로젝트 규모, 회원 및 기술적 난이도에 따라 고려해야 합니다. 프로젝트의 기한이 이미 확정되면, 반드시 몇 가지 방법을 채택하여 프로젝트 계획의 완성을 보장해야 한다. 첫 번째는 프로젝트에 적합한 소프트웨어 개발 라이프 사이클을 선택하는 것입니다. 일반적으로 폭포식 개발은 추천하지 않습니다. 가장 좋은 방법은 RUP 또는 민첩한 개발을 한 다음 프로토타입법과 결합하여 프로젝트 계획을 세우는 것이다. 이렇게 하면 수요 변화로 인한 위험을 피할 수 있다.
둘째, 매일 프로젝트 진행 상황을 추적해야 한다. 아침, 주간, 프로젝트 일간지, 프로젝트 주간지를 통해 프로젝트의 진행 상황을 알 수 있습니다. 또한 각 팀에 진행 추적자를 지정하여 각 팀 책임자의 일일 보고서를 기준으로 실제 진행 상황이 계획에서 벗어나는지 여부를 결정해야 합니다.
프로젝트 진행 편차를 처리하는 방법을 개발할 필요가 있다. 프로젝트 진행에 편차가 생기면 적절한 오류를 취하여 문제를 해결해야 한다. 또는 초과 근무, 인력 증가, 프로젝트 진도 신청 등을 통해 제때에 대응할 수 있습니다.
제때에 프로젝트 구성원에게 프로젝트 진행 상황을 보고하다. 모든 프로젝트 멤버가 프로젝트의 현재 상황을 알 수 있도록 해야 각 구성원의 스트레스를 늘리고 긴장을 풀지 않을 수 있다. 동시에 모든 멤버들이 목표를 가질 수 있게 하고, 어쩔 수 없이 할 수 있게 할 수 있다. (윌리엄 셰익스피어, 템페스트, 희망명언)
프로젝트 계획을 세울 때 단계 심사와 동료 심사 시기를 반드시 고려해야 한다. 이것은 eas 프로젝트에서 충분히 잘하지 못했다. 그 이유는 프로젝트 자체의 일정이 빡빡하기 때문이다. 프로젝트 진행 추적 테이블 및 프로젝트 진행 편차 추적 테이블을 유지 관리합니다. 프로젝트 관리 부서와 QA 가 적시에 프로젝트 진도를 파악할 수 있도록 하여 프로젝트 진도 관리에 유리하다.
변경 관리
변화에는 수요 변화와 인력 변화가 포함됩니다. 통제가 잘 되지 않으면 둘 다 프로젝트의 진도에 재앙적인 결과를 가져올 것이다. 요구 사항 변경은 이전 섹션에서 설명했습니다. eas 프로젝트에서 발견된 인력 변경 상황도 심각하기 때문에 인력 변경 관리에 대해 중점적으로 설명합니다.
사람이 프로젝트에 들어가면, 보통 프로젝트에 좋은 영향을 미친다. 그러나 신입 회원을 팀에 더 빨리 통합하는 방법도 주의해야 한다. 전반적으로, 만약 새로운 회원이 가입해야 한다면, 가장 좋은 변화 시기는 프로젝트 초반이다. 프로젝트 중후반에 새 멤버를 추가하면, 프로젝트에 재앙적인 결과를 의미할 수밖에 없다. 새로 가입한 멤버들은 프로젝트에 익숙하지 않아 좋은 영향이 제한적이다. 신입 회원과 옛 회원의 협력 관계가 잘 처리되지 않으면 부정적인 영향을 미칠 수 있다.
인원의 철수는 왕왕 통제할 수 없고, 프로젝트에 미치는 영향은 헤아릴 수 없다. 이러한 영향을 최소화하려면 프로젝트를 시작할 때 코딩 사양을 설정해야 합니다. 또한 문서의 유지 관리 및 업데이트에도 주의해야 합니다. 인원이 이직할 때는 반드시 인계작업을 잘 해야 한다. 이와 같은 변화에 대해 합리적인 평가를 하고, 프로젝트 관리부에 제때 보고하고, 제때에 고객과 소통해야 한다. 프로젝트 진행에 심각한 영향을 미칠 경우 가능한 한 고객의 이해를 얻어 프로젝트 연장을 신청해야 합니다.
위험 관리
처음부터 프로젝트 과정에서 발생할 수 있는 모든 위험을 고려하는 것은 비현실적이다. 그러나 특히 프로젝트 계획을 수립하고 팀을 만들 때는 위험 관리를 고려해야 합니다. 수요 위험, 진행 위험, 품질 위험, 기술 위험 등 많은 위험이 있습니다. 완전한 위험 관리 방안을 마련해야 하고, 일단 위험이 발생하면 제때에 대응해야 하며, 조직 관계자들이 해결해야 한다. 우리는 어떤 작은 위험도 무시할 수 없다, 그렇지 않으면 작은 위험은 결국 큰 화를 초래할 것이다. 프로젝트 관리자와 시스템 설계자는 위험에 대한 파악을 확인해야 합니다.
멤버 관리
단결하지 않는 프로젝트 팀은 프로젝트의 성공을 보장할 수 없다. 프로젝트 관리자와 프로젝트 책임자는 팀 구성원을 관리할 때 항상 구성원의 상황에 주의를 기울여야 하며, 작업 중인 갈등과 마찰에도 불구하고 팀 정신을 최대한 관철할 수 있도록 해야 합니다.
프로젝트 구성원의 사기를 지속적으로 보장하는 것이 중요하다. 프로젝트가 단계적인 진전을 이룰 때마다 모든 멤버들에게 알려야 성공에 대한 자신감을 얻을 수 있다. 프로젝트 개발 과정은 일과 휴식의 결합에 주의해야 한다. 맹목적으로 야근을 강요하면 프로젝트 구성원의 업무 효율만 떨어질 수밖에 없다. 프로젝트 과정에서 일부 활동이 제대로 진행될 수 있다면 팀 구성원은 프로젝트 팀의 집단 분위기를 느낄 수 있을 것이다. 단계 구현의 중요한 순간에 프로젝트 관리자는 텍스트와 언어를 통해 프로젝트 팀 구성원을 격려하는 데 주의를 기울여야 합니다. 프로젝트 매니저의 자신감도 구성원의 사기를 보장하는 열쇠다.
팀 구성원의 심리상태와 근무상태를 반드시 알아야 한다. 프로젝트 구성원의 전력은 개인의 능력 발휘뿐만 아니라 좋은 지도자도 중요하다. 따라서 전체 프로젝트 팀 구성원의 업무 진행 상황을 파악할 수 있는 적절한 프로젝트 책임자를 선택할 필요가 있다. 또한 각 구성원의 역량을 이해하여 적절한 역할과 직책을 배정해야 합니다.
개발 팀, 테스트 팀 및 프로젝트 관리 팀 간의 협력을 중요시합니다. 프로젝트 팀은 전체이며, 각 멤버는 서로 다른 역할을 가지고 있지만, 모든 사람은 팀의 중요한 멤버입니다.
저자: 장의는 다년간의 소프트웨어 개발 및 설계 경험을 가지고 있습니다. 그는 두 번이나 마이크로소프트의 가장 가치 있는 전문가 (MVP) 로 선정되었다. 그의 작품/번역에는 소프트웨어 설계의 요점과 모델, wcf 서비스 프로그래밍이 포함됩니다. 장의는 c#, ASP, wcf 등의 기술에 익숙하며 객체 지향 관련 기술에 정통하다. 현재 주로 SOA 기업 정보화 솔루션의 설계와 연구, 민첩한 방법의 보급과 실천에 종사하고 있습니다. 장의는 거리 아굴락당의 창시자이다.