ologist`s story :: SPSG에 요약글들

2007/02/10 15:16 Developer

SPSG에 요약글들

프로젝트 초기에 프로세스에 투자하면 후반에 많은 혜택을 가져온다

훌륭한 프로젝트 팀은 요구사항과 아키텍처를 주의 깊게 검토하여 상류쪽 문제를 정정할 수 있는 기회를 스스로 만들어낸다.

프로젝트 초반에는 '비용 및 일정 목표가 확실'하던가 아니면 '요구사항이 확실'하던가 둘 중의 하나다. 이 두 가지 모두 확실한 경우는 없다.

어떤 사람들은 불가능한 목표를 좋아한다. 그러나 개발자들이란 현실주의자자. 그렇기때문에 대부분은 불가능한 목표를 접하면 의욕을 잃고 만다.

관리자 업무 대부부은 한 가지 일에 오랜 시간을 집중해서는 곤란하다. 그러나 개발자 업무는 한 가지 일에 몇 시간씩 집중이 필요하다.

사용자를 프로젝트에 끝까지 참여시키는 것이 소프트웨어 프로젝트의 핵심 생존 기술이다.

소프트웨어가 실행되는 것보다 더 확실한 현황 보고서는 없다.

단계별 납품방식이 만병통치약은 아니다. 하지만 모든 것을 고려해 볼 때 추가 비용은 프로젝트 상태와 품질에 대한 가시성을 높이고 추정치의 정확도를 향상시키며,
리스크를 감소시키는 대가에 비하면 결코 비싸지 않다.

프로젝트가 잘 굴러가지 않는 이유는 많은 업무들 간 조율도 빈약하고 비효율적으로 수행하기 때문에, 많은 노력을 들이고도 결국 별 볼일 없는 결과를 내놓기 때문이다.

변경통제를 하면 모든 필수적인 변경이 가능하며 프로젝트 전반에 걸쳐 이런한 변경이 미치는 영향을 이해하게 된다.

성공적인 프로젝트에서는 팀원들이 자신의 과업에 대한 책임감도 크지만, 그들에게 영향을 주는 과업에 대한 책임 소재도 확실히 한다.

나름대로 독특한 방식으로 일을 하는 경우라도 체계적으로 변경을 통제할 수 있다. 그러나 이때에도 투명한 의사결정과 책임을 강조하는 절차에 따라 시행해야 한다.

비젼을 수립하는데 가장 중요한 것은 지나친 것은 부족함만 못하다는 메시지를 전달하는 것이다. 비전은 간단명료한 것이 좋다.

프로젝트에서 성공하려면 모든 계획 자료를 언제든지 검토할 수 있도록 공개해야 한다. 생산성 예측치, 일정, 일정 조정, 리스크, 업무분장, 기타 계획 등을 모두 공개해야 한다.

소프트웨어에서는 비밀이 없어야 한다. 좋은 일이건 나쁜 일이건 어떤한 것이라도 프로젝트 관계자 모두에게 알리는 것이 좋다.

우수한 조직은 적은 비용으로 큰 리스크를 줄이는 방안을 적극적으로 모색한다.

생산성이 뛰어난 프로그래머가 나타날 때까지 기다리는 것이 능력과 생산성이 떨어지는 프로그래머가 생산성을 갖출 때까지 기다리는 것보다 좋은 방법이다.

요구사하을 수집하는 데 가장 어려운 일은 사용자가 원하는 것을 '기록'하는 활동이 아니다. 그들 자신이 원하는 것이 무엇인지 알 수 있게 도와주는 하나의 탐험적이며 '개발' 차원의

활동이 필요하다.

사용자에게 '프로토타입은 그저 프로토타입일 뿐'이라는 것을 반드시 이해시켜야 한다.
사용자 인터페이스 프로토타입을 만들 때 직면할 수 있는 위험 요소중의 하나는 사용자들의 향후 프로젝트에 대한 기대치가 믿을 수 없을 정도로 높아질 수 있다는 것이다.

사용자 프로토타입을 실제 소프트웨어를 위한 기초로 사용해서는 안된다. 영화 세트장 무대를 진짜 집의 기초로 사용해서는 안 되는 것과 같은 이치이다.

신속하지만 얼룩이 남는 문제는 누군가 말했듯이 신속에서 오는 장점이 잊혀진 후에도 얼룩은 오랫동안 남는다는 것이다.

베타테스트를 효율적으로 수행하려면 많은 조정과 인력이 필요하다. 이런 자원을 조직 내부로 집중하면 더 효울적인 품질 관리를 수행할 수 있다.

아키텍처의 목표가 복잡함을 감소시키는 데 있다는 것을 인식하고 나면, 아키텍트가 소프트웨어 내에 어떤 것을 포함할지에 집중하는 만큼 어던 것을 제외시켜야 하는지에도
초점을 맞추어야 한다는 것이 명확해진다.

소프트웨어 프로젝트에 관해 나쁜 소식을 들어야 한다면, 프로젝트 비용에 미치는 상류/하류 효과때문에모드라도 되도록 조기에 듣는 것이 좋다.

최고는 우수의 적이다.

모든 프로젝트 이해 관계자들이 추정 절차에 동의하면, 불합리하게 결정된 예산이나 일정 등에 논쟁을 벌이지 않고 프로젝트에 투입될 자원이나 포함될 기능에 대해 합리적인 협상을 벌일 수 있다.

일정이 지연되는 위험을 최소화하려면 초과 근무에 의존하는 계획을 세우지 말고 프로젝트 초기에 더 많은 자원을 투입해야 한다.

모든 훌륭한 소프트웨어 프로젝트 계획 방식과 마찬가지로, 이 책의 방식도 프로젝트 전반에 걸쳐 실수가 발생할 수 있다는 사실에 바탕을 둔 것이다. 프로젝트의 성공 여부는 프로젝트 팀이 이런 실수를 빠르고 쉽게 찾아내어 수정하는지에 달려 있다.

품질 보증 작업을 프로젝트에 말기로 연기하면 개발자의 디버깅은 불량한 컴포넌트 서너 개의 상호작용을 점검하는 수준이 아니다.
그것은 불량한 컴포넌트 수백 혹은 수천개의 상호작용을 디버깅하는 것이다.

설계 형식성을 너무 많이 갖추는 것이 너무 적게 갖추는 것보다 돈을 버는 영리한 방법이다.

테크니컬 리뷰를 통해 비용을 높이면서도 신뢰성을 떨어뜨리는 기능을 찾아내어 제거할 수 있으므로 이득이 몇 배나 높아진다.

소프트웨어 구축 작업은 아주 세말한 수준에서 이루어져야 하며, 이런 수많은 결정들을 갱신하는 것은 전체 시스템을 다시 구현하는 것과 같다. 실제로 한번 잘못된 결정을 내리면 기회는 두 번 다시 오지 않는다.

소프트웨어 변경에 대한 압력이 높아질수록 이 변경 내용을 신중히 검토해야 하며 그렇지 않으면 프로젝트가 통제를 벗어나 버린다.

전형적인 프로젝트에선는 약 80퍼센트의 시간을 예기치 못한 재작업에 쓴다. 전략적이고 계획된 재작업을 수행해야 소프트웨어 품질을 획기적으로 높이고 프로젝트 전체의 생산성을 향상시킬 수 있다.

전체 프로젝트 팀은 각 단계를 종료할 때마다 소프트웨어를 릴리즈 가능한 상태로 만들어야 하며, 이것을 최우선으로 처리해야 한다.

프로젝트 초기에 프로젝트의 규모를 과소평가하거나 프로젝트 팀의 생산성을 과대평가하는 것은 잘못이 아니다. 문제는 프로젝트 후반기에도 이런 실수를 찾아내지도 수정하지도
못하는 것이다.

프로젝트 300개를 대상으로 수행되었던 1991년 연구 보고서에 의하면 초과된 시간을 만회한 프로젝트는 거의 없었다. 오히려 시간이 더 늘어나는 경향을 보였다.

프로젝트 관계자가 프로젝트를 시작할 때부터 재추정 계획을 이해하지 못한다면, 개발 팀의 재추정 작업을 실수로 간주할 것이다.

소프트웨어 프로젝트 관리의 가장 일반적인 문제점은 그렇게 해야만 하는 실제 이유도 없으면서 프로젝트 계획을 단념하는 것이다.

프로젝트 이력에 대한 결론을 사용하기 쉬운 형태로 변환하면, 소프트웨어 프로젝트 이력을 만들기 위해 개발팀이 쏟아넣은 시간과 노력의 가치가 극대화되고, 향후 프로젝트가 성공할 수 있는 든든한 초석이 된다.

팀에 해를 끼친 사람은 누구라도 성공한 것이 아니며, 팀을 도운 사람은 그 누구라도 실패한 것이 아니다.

소프트웨어 프로젝트 생존 전략