Software Engineering – Project planning

Project planning(PL팀이 따로 있거나 개발자 자체적으로 계획을 수립하고 가격을 책정할 수 있다)

1. 구현할 기능을 세부적으로 분할한다.
2. 각각의 부분을 각각의 프로젝트 팀에게 할당한다.
3. 발생 가능한 문제점들에 대하여 예측한다.
4. 예측된 문제에 대하여 대비한다.

Project plan의 사용

• 프로젝트 팀과 고객에게 일이 어떻게 완수될 것인지와 프로젝트의 가격 등에 관해 대화를 나누는 수단으로써 사용된다.
• 프로젝트의 단계를 평가하는 척도로 사용할 수 있다.

Project stages

Proposal stage

• 제공/개발하고자 하는 소프트웨어에 소요되는 시간과 비용, 인력 등을 고객에게 설명하며 그에 따라 도출된 가격에 대해 설명 및 협상한다.

Project startup phase

• 누가 프로젝트에 참여하며 어떤 일을 담당할지에 대한 계획을 수립한다.
• 프로젝트를 분할하여 점진적으로 어떤 기능을 구현할지에 대한 계획을 수립한다.
• 인력, 예산 등과 같은 resource를 어떻게 배분할지에 대한 계획을 수립한다.

Periodically throughout the project

• 일이 진행됨에 따라 얻어진 경험과 정보를 바탕으로 계획을 수정한다.
• 예측 변수, 돌발 변수 등에 적절히 대응해야 한다.

Proposal planning

• 고객이 제시한 구체적인 요구 사항, 최대 가격, 최대 기간 등을 고려해서 계획을 수립하게 된다.
• 이 단계의 목적은 고객에게 가격 설정에 사용되는 정보를 제공하는 것이다.
• 가격은 주로 경쟁 방식으로 설정되며, 적은 돈의 차이로 프로젝트를 못할 수도 있다.
• agile에서는 집단 내부에서 proposal 단계를 진행할 때는 돈을 목적으로 진행하기 보다는 인력에게의 의존도가 높아지기 때문에, 어떻게 인적/물적 자원을 활용하고 배치할 것인지에 대한 계획을 수립하는 동일한 단계가 있다.
• 프로젝트의 가격은 개발 비용, 인건비, 운영비, 하드웨어 가격, 소프트웨어 가격 등이 포함된다.

Project startup planning

• 제안이 낙찰 받으면 고객으로부터 더 자세한 요구 사항을 전해 받으며, 요구사항을 조정할 수도 있다.
  • 디자인이나 구현 정보에 관해서는 알지 못한다.
• 가지고 있는 인적, 물적 자원을 어떻게 할당할지에 대한 구체적인 계획을 수립한다.
• 프로젝트 모니터링에 대한 방법도 이 단계에서 수립한다.
• Agile 방식에서도 사용되는 방식이다.

Development planning

• 계획은 주기적으로 수행되어야 한다.
• Plan-based의 경우에는 milestone마다 일이 제대로 수행되었는지 확인하여야 하며, agile에서는 각 sprint가 끝날 때마다 확인해야 한다.
• 프로젝트 스케줄, 비용 평가, 위험 평가는 주기적으로 수정되며 관리되어야 한다.

Software pricing

• 인력, 하드웨어, 소프트웨어, 재정비 비용, 훈련비, 사무용품 사용비 등을 모두 고려한다.
• 개발비용과 고객에게 청구할 수 있는 비용은 단순한 관계식이 없다.
• 조직의 영향, 경제적, 정치적인 영향, 비즈니스 환경 등이 가격 청구에 영향을 줄 수 있다.

가격에 영향을 줄 수 있는 요인

Contractual terms

• 개발자가 코드에 대한 소유권을 가지고 다른 프로젝트에 재사용하는 등의 추가적인 계약 조건에 의해 가격은 더 싸질 수 있다.

Cost estimate uncertainty

• 가격 책정에 대해 서툴거나 risk를 제대로 고려하지 못하는 경우 가격은 올라갈 수도, 내려갈 수도 있다.
• 고객의 입장에서 싸게 낙찰받았다고 해도, 그것은 개발사에 영향을 줄 수 있기 때문에 적정선을 찾아야 한다.

Financial health

• 개발사가 경제적으로 어려워 가격을 낮출 수도, 높일 수도 있다.

Market opportunity

• 새로운 시장에 진입하고자 하는 회사는 첫번째 계약이 있어야 후속 계약을 진행할 수 있기 때문에 낮은 가격을 제시할 수 있다.
• 이익을 없애거나 적자를 감수하고 가격을 제시할 수 있기 때문에 실력 있는 개발자를 투입하지 않을 수도 있다.

Requirements volatility

• 요구사항이 변경될 때 더 많은 금액을 청구하는 조건으로 낮은 가격을 제시한다.

Pricing strategies

Under pricing

• 가격을 잘못 책정한 경우
• 새로운 시장에 진입하여 기회를 노리는 경우

Increased pricing

• 예측되지 않은 위험이나 요구사항 변경 등에 가격을 올리는 경우

Pricing to win

• 고객이 믿고 지불할 수 있는 가격을 책정해야 한다.
• 추후에 발생할 수 있는 추가 비용에 대해서도 충분히 고민해야 한다.
  • PL팀이 있는 이유

Plan-driven development

• 큰 규모의 프로젝트에 사용되는 전통적인 개발 방법
• 어떤 일을 할지 / 누가 할지 / 스케줄 / 최종 결과물 등에 대하여 기록한다.
• 매니저/PL팀(이)가 전담하여 계획을 통하여 의사결정을 하고 진행 단계를 평가한다.

Pros

• 인적, 물적, 정치적 등에 대한 고민을 초기 단계에 함으로써 많은 문제를 해결할 수 있다.

Cons

• 빠르게 시장에 반응해야 하는 소프트웨어 분야에 맞지 않다.

Project plans

• 소개 > 프로젝트 조직 > 위험 분석 > HW/SW 자원 요구사항 > 일의 세분화 > 프로젝트 스케줄(선후 관계, 의존 관계 등) > 모니터링 및 보고

The planning process

• 반복적으로 수행되는 단계이면 꼭 수행하여야 하는 단계이다.
• 요구사항, 스케줄, 위험 등이 변경될 때 마다 주기적으로 계획을 수정해야 한다.
• 비즈니스 목표도 수정하는 것도 유용한 작업이다.
  

Planning assumptions

• 계획을 긍정적으로가 아닌 현실적으로 수립해야 한다.
• 예측 가능한, 예측 하지 못한 모든 문제를 고려의 대상으로 넣어야 한다.
• Delivery 스케줄이 수정되면 관련된 사람들과 투명하게 논의해야 한다.

Risk mitigation

• 최대한 예측해서 위험을 피해야 하며, 계획을 수정하기도 하며 고객과 투명하게 이야기하여야 한다.

Project scheduling

• Project scheduling는 분할한 일을 어떻게 조직할 것인지와 언제 실행할 것인지에 대하여 결정
• 누가 어떤 일을 맡을 것인지, 언제까지 할 것인지에 대하여 식별하고, 일을 마치기 위해 필요한 HW/SW자원, 필요한 디스크 공간, 특정 하드웨어가 필요한 시간, 팀 구성원의 여가비 등을 모두 평가한다.
• 누가 맡을 것인지에 대해 구성원을 잘 안다면 구체적인 사람을 기재할 것이고, 잘 모른다면 학력이나 직책 등을 기재한다.

Project scheduling activities

• 프로젝트를 각각의 일을 완료할 수 있는 일과 시간, 필요 자원 등으로 세분화한다.
• 의존 관계, 상관 관계 등을 고려하여 최적의 스케줄로 조직한다.
• 의존성(선후 관계)을 줄임으로써 Task waiting 시간을 최소화 해야 한다.
• 프로젝트 매니저의 직관력과 경험에 의존한다.
  

Scheduling problems

• 문제의 난이도나 개발 비용의 측정이 힘들다
• 생산성은 개발자의 수에 비례하지 않는다.
• 커뮤니케이션에 대한 문제로 늦은 문제에 추가 인력을 투입하는 것은 더 늦게 만든다.
• 돌발 상황이 항상 발생한다. 문제가 발생하면 관련자와 투명하게 이야기하여야 한다.

Schedule presentation

• 엑셀, 간트 차트와 같은 그래픽의 형태로 스케줄을 설명한다.
• 세분화한 작업에 대해 설명한다. 작업을 세분화할 때는 각각 2~4주 정도의 시간이 적절하다.
• Calendar-based로, 스케줄을 설명할 때는 y축을 시간으로 두는 것이 좋다.
• Activity networks : 그래픽으로 설명하면서 일의 상관관계를 설명한다.
  

Project activities

• 스케줄의 결과물에 필요 시간과 인력, 마감날짜와 최종 도출 결과물에 대하여 설명한다.

Milestones and deliverables

Milestone

• 특정 작업이 완료되었는지 점검하는 날짜
• 프로젝트의 진행 상황을 평가할 수 있는 척도로 사용된다.

Deliverables

• 고객에게 전달될 수 있는 작업의 결과물

Agile planning stages

Release planning

• 최종적인 sprint 후의 출시될 결과물에 대한 계획을 수립한다.
• 최종적인 결과물의 기능들을 나열하는 작업

Iteration planning

• 2~4주 정도의 주기를 갖는 sprint마다 달성할 목표에 대한 계획을 수립한다.

Approaches to agile planning

• scrum에서는 개발해야할 backlog가 있을 때 daily review를 통하여 계획을 수립한다.

Extreme programming(XP)

• Agile의 전통적인 기법이며 user stories를 사용하여 계획을 수립한다.

Story-based planning

• 시스템이 구현해야 할 기능들을 포함하여 user stories를 구성하며 user stories가 완성되면 시스템이 완성되었다고 판단한다.
• 어떤 user stories를 먼저 구현할지, 구현하는데 얼마나 시간이 소요될지에 대하여 평가한다.
• 프로젝트 팀은 스토리를 읽고 스토리를 구현하는데 소요되는 시간 순대로 순위를 매긴다.
• 크기와 난이도를 고려하여 시간과 인력을 투입해야 할 척도인 effort points를 부여하여 정량적으로 표현한다. (주로 시간 값으로 환산한다)

Velocity

• 팀이 주어진 시간 안에 할 수 있는 능력
• velocity안에서 effort point가 있는 story를 처리해 나간다.
  

Release and iteration planning

Release planning

• 이번 release에 어떤 기능을 구현할지, 어떤 순서로 구현할지를 고려하여 순서를 매기고 stories선택하고 정제하는 과정을 가진다.
  각 stories마다 2~3주 정도의 시간을 가지고 반복적으로 수행한다.
  velocity안에서 effort points를 고려하여 구현할 수 있는 stories 수를 계획한다.

Task allocation

Task planning stage

• Story를 각각의 개발 task로 세분화한다.
• 각각의 task는 4~16시간이 할당된다.
• 각각의 task는 반복 작업을 통하여 2~3주의 시간 안에 완성된다.
• 분할된 task를 개발자에게 할당할 때 개발자에게 확인 받는 과정을 거친다.

장점

• 팀 전체가 task와 전체 일정 등에 대한 이해도가 높으며 공감대가 형성된다.
• Sign up 과정을 거치기 때문에 개발자가 책임감을 가질 수 있고, 적극적으로 개발에 참여할 의사를 표명할 수 있다.

Software delivery

• milestone까지 기능을 구현하지 못하면 날짜를 연장하는 것이 아닌 기능을 제거한다.
• 일정을 절대로 미루지 않는다.

Agile planning difficulties

• 고객의 의견을 적극 반영해야 하기 때문에 계획을 수립하기 어렵다.
• 고객이 우선 순위를 바꿀 수 있기 때문에 개발 순서나 일정 등이 수시로 변경될 수 있다.
• 고객이 agile방식에 친숙하지 않을 수 있다. 문서가 나오지 않아 불만이 나올 수 있다.

Agile planning applicability

• agile팀은 소규모의 팀에, self-motivating되고 서로 잘 아는 안정된 팀에서 적용될 수 있다.
• 규모가 큰 프로젝트에서나 지리적으로 떨어져 있는 경우, 팀원이 자주 바뀌는 경우 agile방식을 적용하기 어렵고 큰 틀에서 plan-based방식을 채택해야 한다.

Estimation techniques

Experience-based techniques

• 매니저가 이전의 프로젝트에서 한 경험을 바탕으로 평가한다.
• 대부분에서 사용된다.

Algorithmic cost modeling

• 제품의 특성을 평가한 것을 기반으로 프로젝트에 들여야 하는 노력을 계산하여 수식화 된 계산법을 사용한다.
• 사용하기 어렵다.

Experience-based approaches

• 프로젝트에 들인 노력과 과거의 프로젝트에 대한 경험에 기반하여 평가한다.
• 각각의 멤버 간의 토의를 통해 팀원이 들인 노력과 평가에 대한 정보를 공유하며, 서로의 경험을 공유하여 평가의 척도로 삼는다.

Problem with experience-based approaches

• 새로운 소프트웨어가 이전의 소프트웨어와 공통점을 가지지 않을 수 있다.
• 비슷한 프로젝트를 경험해본 개발자가 없다면 제대로 된 평가를 할 수 없다.

Algorithmic cost modelling

• 입력 값으로 code size를 자주 이용한다.
• 사용하기 복잡하고 어려우며, 고려되는 사항이 불확실하다.
• 복잡성 때문에 적은 수의 대기업이나 국방/항공 분야에서만 주로 사용된다.

Estimation accuracy

• 프로그래밍 언어, 구성요소와 시스템의 재사용 여부, 분산 시스템의 사용 여부 등에 의해 코드사이즈가 변하기 때문에 평가에 영향을 미친다.