일정에 늦었을 때 해야 할 일

아. 먼가 기술적인 내용이..
포스팅이 안되고 있다 -ㅅ-..

기술적인 내용은 사이트 개발 들어가면서 포스팅 해 봅시다..
그럼 시작!

일반적인 프로젝트는 거의 100% 계획된 일정을 넘긴다. 여러분이 일정을 넘겼을 때, 시간의 양을 늘리는 것이 반드시 필요하다. 그런 경우에는 그렇게 하고, 만약 그렇게 할 수 없다면 다음과 같은 다른 해결책을 시도해 볼 수 있다.

일정에 맞출 수 있다는 희망을 가져라.
 - 희망적인 낙관론은 프로젝트가 일정을 넘겼을 때 보이는 일반적인 반응이다. 전형적인 합리화는 다음과 같다. "요구 사항이 우리가 예상했던 것보다 조금 더 오랜 시간이 걸렸지만, 더 이상 변하기 않기 때문에 나중에 시간을 절약할 수 있을 것이다. 그리고 코드 작성과 테스트 시에 부족한 부분을 보충할 것이다." 하지만 이런 경우는 좀처럼 일어나지 않는다. 300개의 소프트웨어 프로젝트를 대상으로 한 조사에서는 일정을 늦추거나 초과하는 것이 일반적으로 프로젝트의 마무리 단계에서 증가한다는 결론을 내렸다. 프로젝트는 나중에 잃어버린 시간을 보충하지 않는다. 결국 더욱 늦춰질 뿐이다.

팀을 확장하라
 - Fred Brooks의 법치에 따르면, 늦어진 소프트웨어 프로젝트에 사람을 추가하는 것은 프로젝트의 일정을 더 늦춘다고 한다(Brooks 1995). 이는 마치 불난 데 기름을 붓는 것과 같다. Brooks의 설명은 설득력이 있다. 새로운 사람은 무언가를 생산할 수 있기 전에 프로젝트에 익숙해주기 위한 시간이 필요하기 때문이다. 그들의 훈련은 이미 훈련은 받은 사람들의 시간을 빼앗게 된다. 그리고 단순히 사람의 수를 늘리는 것은 프로젝트의 복잡성과 의사 소통의 양을 증가 시킨다. Brooks는 한 여성이 9개월만에 한 아이를 낳을 수 있다고 해서 9명의 여성이 한 달에 한 아이를 낳을 수 있는 것은 아니라는 사실을 지적하였다.
  당연히 여러분은 Brook의 법칙에 있는 경고를 훨씬 자주 주의해야 한다. 프로젝트에 사람을 투입하면, 그들이 프로젝트를 제 시간에 완성시킬 것이라고 기대하기 쉽다. 하지만 경영진들은 소프트웨어 개발이 금속 박판에 못을 박는 일과는 다르다는 것을 이해할 필요가 있다. 더 많은 사람들이 작업을 한다고 해서 반드시 더 많은 작업이 수행된다는 것을 의미하지는 않는다.
  하지만 늦어진 프로젝트에 사람을 추가하는 것이 프로젝트를 더 늦춘다는 단순한 문장은, 어떤 환경에서는 새로운 사람을 추가하여 프로젝트의 속도를 높일 수 있는 가능성을 있다는 사실을 감추고 있다. Brooks가 그의 관점에서 지적했듯이, 독립적으로 나누어져서 수행될 수 없는 소프트웨어 프로젝트에 새로운 사람을 추가하는 것은 도움이 안 된다. 하지만 만약 프로젝트의 작업이 나뉠 수 있다면, 프로젝트의 일정이 늦어졌다고 하더라도 프로젝트를 나누어 서로 다른 사람들에게 일을 할당할 수 있다. 다른 연구자들은 프로젝트의 일정을 늦추지 않고 늦어진 프로젝트에 사람을 추가할 수 있는 환경을 공식적으로 규명하였다.

프로젝트의 범위를 축소하라
 - 프로젝트의 범위를 축소하는 가장 강력한 기법이 종종 간과된다. 만약 어떤 기능을 제거하면, 설계와 코드 작성, 디버깅, 테스트, 그리고 해당 기능에 대한 문서를 제거할 수 있다. 또한, 다른 기능에 대한 해당 기능의 인터페이스도 제거할 수 있다.
  여러분이 제품을 초기에 계획할 때, 제품의 능력을 "반드시 갖추어야 할 것", "가지면 좋은 것", 그리고 "선택적인 것"으로 분류한다. 만약 일정이 늦어지게 되면, "선택적인 것"과 "가지면 좋은 것"에 대한 우선순위를 매겨서 가장 덜 중요한 것을 뺀다.
  어떠한 기능을 완전히 제거할 수 없다면, 같은 기능을 수행하는 보다 값싼 버전을 제공할 수 있다. 아마도 일정에 맞추기는 했지만 성능을 위해서 최적화는 되지 않는 버전을 제공할 것이다. 그리고 최소한의 중요한 기능만이 미숙하게 구현된 버전을 제공할 것이다.
  또한, 느린 버전을 제공하는 것이 훨씬 쉽기 때문에 속도에 대한 요구 사항을 무시하기로 결정할 것이다. 그리고 메모리 집약적인 버전을 제공하는 것이 쉽기 때문에 공간에 대한 요구 사항도 무시할 것이다.
  최소한의 중요한 기능에 대한 개발 시간을 재측정하라. 어떤 기능을 두 시간이나 이틀, 또는 2주 내에 제공할 수 있는가? 이틀 버전 대신 2주 버전, 또는 두 시간 버전 대신 이틀 버전을 작성하여 얻는 것이 무엇인가?