L05-Project Management (Ch22)

다루는 주제

• 위험 관리

• 인력 관리

• 팀워크

소프트웨어 프로젝트 관리

• 소프트웨어가 제 시간에 일정에 맞게 그리고 소프트웨어를 개발하고 조달하는(procuring) 조직의 요구사항에 따라(in accordance with) 제공되도록 하는 활동과 관련(Concerned)이 있다.

• 프로젝트 관리는 소프트웨어 개발이 항상 소프트웨어를 개발하는 조직이 설정한 예산(budget)과 일정 제약을 받기 때문에 필요하다.

성공 기준(criteria)

• 약속된(agreed) 시간에 고객에게 소프트웨어를 전달한다. -> 시간

• 전체(overall) 비용을 예산 내로 유지한다. -> 비용

• 고객의 기대(expectations)를 충족하는 소프트웨어를 제공한다. -> 기대

• 일관성 있고(coherent) 잘 기능하는 개발 팀을 유지한다. -> 일관성

→ SE만의 고유한 목표가 아니라 모든 엔지니어링 프로젝트에 해당된다!

SE 프로젝트의 고유한(Distinct) 특징

• 제품이 무형(intangible)이다. -> 바람(보이지 않음)

  • 소프트웨어는 보거나 만질 수 없다. 소프트웨어 프로젝트 관리자는 단순히 구축 중인(is being constructed) 결과물(artefact)을 보는 것으로 진행 상황을 파악할 수 없다.

• 많은 소프트웨어 프로젝트가 '일회성(one-off)' 프로젝트이다. -> 눈송이(형태와 구조가 다름)

  • 대규모 소프트웨어 프로젝트는 일반적으로 이전 프로젝트와 어떤 면에서 다르다. 많은 경험을 가진 관리자도 문제를 예측하기 (anticipate)어려울 수 있다.

• 소프트웨어 프로세스는 가변적(variable)이며 조직마다(organization specific) 다르다. -> 요리(다른 레시피)

  • 우리는 아직 특정 소프트웨어 프로세스가 개발 문제로 이어질 가능성이 있는 시기를 안정적으로(reliably) 예측(predict)할 수 없다.

프로젝트 관리에 영향을 미치는(influencing) 요소

• 회사 규모

• 소프트웨어 고객

• 소프트웨어 규모

• 소프트웨어 유형

• 조직 문화

• 소프트웨어 개발 프로세스

→ 이러한 요소들은 서로 다른 조직의 프로젝트 관리자가 매우(quite) 다른 방식으로 일할 수 있음을 의미한다.

보편적인 관리 활동

• 프로젝트 계획

  • 프로젝트 관리자는 프로젝트 개발 계획, 추정(estimating) 및 일정 관리와 사람들에게 작업 할당(assigning)을 담당한다.(be responsible)

  • Chapter 23에서 다룬다.

• 위험 관리

  • 프로젝트 관리자는 프로젝트에 영향을 미칠 수 있는 위험을 평가하고(assess), 이러한 위험을 모니터링하며, 문제가 발생했을(arise) 때 조치를 취한다.

• 인력 관리

  • 프로젝트 관리자는 팀에 적합한 사람을 선택하고 효과적인 팀 성과로 이어지는 업무 방식을 수립(establish)해야 한다.

• 보고(Reporting)

  • 프로젝트 관리자는 일반적으로(usually) 고객과 소프트웨어를 개발하는 회사의 관리자에게 프로젝트 진행 상황을 보고할 책임이 있다.(responsible)

• 제안서(Proposal) 작성 -> 매우 중요!

  • 소프트웨어 프로젝트의 첫 단계(stage)는 업무 수행 계약(contract)을 따내기 위한 제안서(proposal) 작성을 포함할 수 있다(may involve). 제안서는 프로젝트의 목표와 수행 방법을 설명한다.

위험 관리 (왜 중요한가?)

• 위험 관리는 위험을 식별하고 프로젝트에 미치는 영향을 최소화하기 위한 계획을 수립하는 것(drawing up plans)과 관련이 있다.(is concerned)

• 소프트웨어 위험 관리는 소프트웨어 개발의 내재된 불확실성(inherent uncertainties) 때문에 중요하다.

  • 이러한 불확실성(uncertainties)은 느슨하게(loosely) 정의된 요구사항, 고객 요구 변화로 인한 요구사항 변경, 소프트웨어 개발에 필요한 시간과 자원을 추정하는(estimating) 어려움, 그리고 개인(individual) 기술의 차이에서 비롯된다(stem from).

• 위험을 예상(anticipate)하고, 이러한 위험이 프로젝트, 제품 및 비즈니스에 미치는 영향을 이해하고, 이러한 위험을 피하기 위한 조치를 취해야 한다.

위험 분류(classification)

• 위험 분류에는 두 가지 차원(dimensions)이 있다

  • 위험 유형 (기술적, 조직적 등)

  • 위험의 영향을 받는 대상:

• 프로젝트 위험은 일정이나 자원에 영향을 미친다;

• 제품 위험은 개발 중인 소프트웨어의 품질이나 성능에 영향을 미친다;

• 비즈니스 위험은 소프트웨어를 개발하거나 조달하는 조직에 영향을 미친다

  • 새로운 계약(contract)을 따내는 것?

  • 예: 경쟁사(compertitior)가 새로운 프로젝트 도입

사례 예시: 프로젝트 팀원 상실(Losing)

어떤 종류의 위험이 발생할 수 있는가?

프로젝트, 제품 및 비즈니스 위험의 예

위엄 관리 프로세스 (1)

• 위험 식별(identification)

  • 프로젝트, 제품 및 비즈니스 리스크를 파악한다.

• 위험 분석(analysis)

  • 이러한 위험의 가능성(likeihood)과 결과(consequences)를 평가한다(assess).

• 위험 계획

  • 위험의 영향을 피하거나 최소화하기 위한 계획을 수립한다.

• 위험 모니터링

  • 프로젝트 전반에 걸쳐 위험을 모니터링한다.

위험 관리 프로세스 (2)

• 위험 식별(Risk identification) - 이 단계에서는 잠재적 위험 목록(List of potential risks)을 작성합니다.

• 위험 분석(Risk analysis) - 이 단계에서는 우선순위가 정해진 위험 목록(Prioritized risk list)을 만듭니다.

• 위험 계획(Risk planning) - 이 단계에서는 위험 회피 및 비상 계획(Risk avoidance and contingency plans)을 수립합니다.

• 위험 모니터링(Risk monitoring) - 이 단계에서는 위험 평가(Risk assessment)를 수행합니다.

위험 식별(identification)

• 팀 활동이거나 개별 프로젝트 관리자의 경험을 기반으로 할 수 있다.

• 프로젝트의 위험을 식별하기 위해 일반적인 위험 체크리스트를 사용할 수 있다

  • 기술 위험.

  • 조직적 위험.

  • 인력 위험.

  • 요구사항 위험.

  • 추정(Estimation) 위험.

다양한 위험 유형의 예

위험 유형가능한 위험

위험 분석

• 각 위험의 확률(probability)과 심각성(seriousness)을 평가한다.

• 확률은 매우 낮음, 낮음, 중간(moderate), 높음 또는 매우 높음일 수 있다.

• 위험 결과(consequences)는 치명적(catastrophic), 심각함(serious), 감내 가능함(tolerable) 또는 미미함(insignificant)일 수 있다.

위험 예시

위험 계획

• 각 위험을 고려하고, 해당 위험을 관리하기 위한 전략(strategy)을 개발한다.

• 회피(Avoidance) 전략

  • 위험이 발생할 가능성을 줄인다;

• 최소화(Minimization) 전략

  • 위험이 프로젝트나 제품에 미치는 영향을 줄인다;

• 비상(Contingency) 계획

  • 위험이 발생하면, 그 위험에 대처하기(deal) 위한 계획이다;

만약에 질문

• 만약 여러 엔지니어가 동시에 아프다면 어떻게 될까?

• 만약 경기 침체(economic downturn)로 인해(leads to) 프로젝트 예산이 20% 삭감된다면 어떻게 될까?

• 만약 오픈 소스 소프트웨어의 성능이 부적절(inadequate)하고, 그 오픈 소스 소프트웨어에 대한 유일한 전문가가 떠난다면 어떻게 될까?

• 만약 소프트웨어 컴포넌트를 공급하고 유지 관리하는 회사가 도산한다면(goes out of business) 어떻게 될까?

• 만약 고객이 예상대로(as predicted) 수정된 요구사항을 전달하지 못한다면 어떻게 될까?

위험 관리를 돕는 전략(strategies)

위험 모니터링

• 확인된 각 위험을 정기적으로 평가하여 가능성이 감소하고 있는지 또는 증가하고 있는지 결정한다.

• 또한 위험의 영향이 변경되었는지 평가한다.

• 각 주요 위험은 관리 진행 회의에서 논의되어야 한다.

위험 지표 (해야함)

인력 관리

• 사람은 조직의 가장 중요한 자산(assets)이다.

• 관리자의 임무는 본질적으로 사람 지향적이다. 사람에 대한 이해가 없으면 관리는 성공하지 못할 것이다.

• 열악한(Poor) 인력 관리는 프로젝트 실패(failure)의 중요한 요인이다.

인력 관리 요소

• 일관성 (Consistency)

  • 모든 팀원은 편애나 차별 없이 비슷한 방식으로 대우받아야 한다.

• 존중

  • 서로 다른 팀원은 서로 다른 기술을 가지고 있으며 이러한 차이점을 존중해야 한다.

• 포용 (Inclusion)

  • 모든 팀원을 참여시키고(involve), 사람들의 의견이 고려되도록 한다.

• 정직 (Honesty)

  • 프로젝트에서 무엇이 잘 진행되고 있고 무엇이 잘못되고 있는지에 대해 항상 정직해야 한다.

사람 동기부여(Motivate)

• 가장 하단에는 생리적 욕구(Physiological needs) - 기본적인 생존을 위한 욕구로, 음식, 물, 수면, 공기 등의 기본적 신체 요구를 포함합니다.

• 두 번째 단계는 안전 욕구(Safety needs) - 물리적 안전, 경제적 안정, 건강과 복지 등 안정성과 보호에 관한 욕구입니다.

• 중간 단계는 사회적 욕구(Social needs) - 소속감, 사랑, 애정, 관계성에 대한 욕구를 나타냅니다.

• 네 번째 단계는 존중 욕구(Esteem needs) - 자존감, 인정, 성취, 타인으로부터의 존중에 대한 욕구입니다.

• 피라미드의 최상단에는 자아실현 욕구(Self-realization needs) - 개인의 잠재력을 최대한 발휘하고 성장하려는 욕구를 나타냅니다.

팀워크

• 대규모 팀은 일반적으로 여러 개의 소규모 그룹으로 나뉜다

• 소프트웨어 엔지니어링 그룹의 최적 규모는 4-6명이다. (12명을 초과하지 않는다)

• 소규모 그룹의 이점

  • 의사소통 문제를 최소화할 수 있다

응집력 있는(cohesive) 그룹

• 구성원들은 그룹이 개인보다(than individuals) 중요하다고 생각한다

  • 그룹에 충성적(Loyal)이다

• 이점

  • 그룹은 자체적인 품질 표준을 수립할 수 있다. (합의)

  • 개인은 서로 배우고 지원한다.

  • 지식이 공유된다.

  • 리팩토링과 지속적인 개선(improvement)이 장려된다(is encouraged).

그룹 구성원 선정

• 자신의 일에 잘 동기부여되어 있다!

• 기술적 지식과 능력?

• 성격?

• ...

그룹 의사소통

• 영향을 받는 요소

  • 그룹 크기/구조/구성(composition)

  • 물리적 환경

  • 이용 가능한 의사소통 채널