13. Project Planning & Management

agile말고 전통적 방식으로 개발하는 회사의 스타일을 알아보자. (간트차트, 워터폴 방식)

Man-Month

이 프로젝트에 사람을 얼마나 투입해야 하지? 
4명이요.
그냥 사람 4명??, 능력상관없이 4명??

Man-Month: 일을 한달동안 해서 끝내기 위해 필요한 사람 (ex. 12 M/M는 한달에 12명, 12달동안 1명필요)
=> 개발자마다 능력이 제각각인데 이렇게 계산해도 되는가?

The Mythical Man-Month
이 책은 소프트웨어개발에서 개념적 일관성이 왜 중요한지, 프로토타입(파일럿시스템)이 얼마나 중요한지, 사람을 많이 투입해도 진행이 더뎌지는 이유는 뭔지, 왜 여전히 만능도구는 없는지 등등 소프트웨어 개발에 관련한 고찰
소프트웨어 개발이 man-month로 측정한다는건 신화다.

No sliver bullet
한방의 비장의 무기는 없다. 도구나 개발방법론을 쓸때는 상황에 맞춰써야 한다.  뿐 만아니라 언어, 이것저것 다 상황에 맞춰야 된다.

The second-system effect
첫번째 시스템을 이러저러한 이유로 빨리 만들었을때 아쉬움이 많이 남을 것이다. 이걸 second-system에 다 넣는다면 over-engineering이 일어날 수 있다. 

Irreducible number of errors
소프트웨어 프로그램에 버그가 없을 수는 없다. 치명적인 버그가 아니라면 그냥 안고 가라. 오히려 자잘한 에러를 줄이려고 하면 치명적 에러를 낼 수 도 있다.

Progress tracking
하루하루 밀려서 마감기한을 1년을 넘기는 걸 막기위해 작은 이정표같은걸 만들어서 주기적으로 미팅을 가지면서 진행상황을 체크해

Conceptual integrity
사용자가 직관적으로 프로그램을 사용하기 위해서는 개념적으로 완벽해야 한다. 그러기 위해선 철학과 방향성을 통해 벗어나는 개발은 피해야 한다.

Manual
메뉴얼을 통해 사용자 측면과 개발자 측면에서 구체화를 해라

Pilot system
상용화 전에 시운전 해보는 프로그램이다. pilot system은 버려질 시스템이다. 모든 기능이 들어가지 않고 주요기능만 들어간다. pilot system을 먼저 만들어보고 상용 프로그램을 만들어봐라

Project estimation
프로젝트 난이도를 고민해봐야 한다. 이걸 이해하고 일정을 잡아야 한다. 

Communication
커뮤니케이션은 원활해야 한다. 보통 일적인 소통은 이메일을 확인해서 증거를 남겨라. 예측하고 추측하지 말고 모르면 물어보고 confirm받아라. 

surgical team
한명이 졸라 잘해면 팀 케미가 좋아진다. 

Code freeze and system versioning
코드를 얼릴께요 건들면 뒤집니다. 여러 검토를 하고 이제 코드 수정이 없다고 선언하는게 code freeze.
계속 개발하지 지겹게 개발하지말고 한번 멈춰라.
사용자 요구사항 계속 맞추다보면 개발이 끝나지 않는다. 어느 날짜에 시스템 변경을 멈추고 종결시켜야 한다. 모든 시스템 변경은 다음 버전까지 미뤄져야 한다. 

Lowering costs
우선 구조를 짠다음에 개발자를 고용하라
개발하지말고 원래 있던거 써