Project Management
man-month: 한달에 투입되는 사람수(소프트웨어를 개발할 때 얼마나 많은 사람이 투입되어야 하는가), 정량적 수치
1 man-month: 한 사람이 한달동안 풀로 들어가는 것
12 M/Ms = 12명이 1달 = 1명이 12달?에 대한 문제 발생 -> 문제가 없는 논리이지만 소프트웨어에서는 안 통한다.
늦어진 소프트웨어 프로젝트에 사람을 추가하는 것은 더 늦게 끝나게 한다.
책(직접 겪었던 프로젝트 관리 실패담들을 모은 책)에서 강조한 것
man-month
Second system effect
prototyping
이전처럼 소프트웨어를 관리하는 것은 실패
-> man-month쓰기 부적절, 변수가 많음. 환상이다.
길어지는 이유
1.새로운 사람 뽑으면 교육하는데 오래 걸림
(애자일로 training 시간이 더 오래 걸리게 됨. 문서 수가 적으므로)
Man-month의 문제점: SW개발에서 서로 다른 팀끼리의 소통이 필수적이지만 사람이 늘어나면 소통이 길어질 수밖에 없다.
케이스 바이 케이스(no silver bullet)
한가지 방법이 모든 문제에 적용되지는 않는다.
!!!!!!!경험이 레퍼런스가 될 수 있으나 다른 문제의 솔루션이 될 수 없음!!!!!!!!!!!!!
이렇게 해결 가능한 완전 재사용가능한 프로그램은 없음
Second-system Effect
첫번째 시스템에서 느꼈던 아쉬운 점, 못 만든 기능들을 다 넣을려고, 만들려고 한다. 따라서 반드시 필요한 개선점이 들어가야 하는 것이다. 오버하는 것은 지양해야 한다.
Over-engineering
개발자들의 문제를 관리자들이 이해해야함 그리하지 못함
!!!!!!!!!!!!! Second-system에는 반드시 필요한 것들만 추가 개선!!!!!!!!!!!!!
Irreducible number of errors
버그가 없는 프로그램은 존재하기 힘들다. 따라서 작은 버그는 두고 큰 버그들을 해결해야 한다. 정성, 정량적으로 버그의 level을 나눠서 사소한 버그들은 두고, 큰 버그들을 다뤄야 한다.
Progress tracking
수면 위에 드러나지 않은 문제들로 전체적인 시간 delay가 있을 수 있다.
소프트웨어 개발이 어떻게 1년이나 늦어지는 거지? 하루에 한 시간씩 늦어지면 그럴 수도 있지.
애자일: 데일리 스크럼등으로 자주 대화하는 이유가 이러한 문제들을 파악하고 해결함
즉 각자 알아서 하라고 내버려두는 것이 아니라 소통을 통해 문제들 파악하게 하는 것
Conceptual integrity
소프트웨어를 만들 때 소프트웨어가 가져야 할 철학, 일관성
Waterfall 방식인 것 같음.
시스템 아키텍쳐: 시스템을 설계(기술적인 부분)
프로젝트 매니저: 프로젝트를 관리, 행정을 한다.
하나의 시스템 설계팀이 철학, 일관성에 따라 결정한다. Ex) 스티브 잡스, 다이슨
하나의 설계팀에서
SW의 전체적인 구조 설계와 철학, 일관성을 고려한 결정을하고 계획함
추가적인 기능등도 일관성 측면에서 판단하고 추가 또는 배제함
The Manual(개발과 관련됨, 시스템 아키텍쳐가 쓰는 것)
설계자가 매뉴얼 정의 -> 맞춰서 개발
The pilot system(권장 사항) = Prototype(주요 기능을 구현해보고 확인하고 나서 버린다.)
첫번째로 만든 시스템은 대부분 시행착오를 겪고 잘못된 설계 하에 채워질 수 있으니 상용화 하지 말고 버려라.
프로그램에서 검증해야할 중요한 것들 중심으로 먼저 만들어보기
Formal documents(project manager)
Product Manager(PM): 관리쪽(개발X)
이들이 만드는 문서에는
프로젝트의 목적, 누가 만드는지, 언제 만들어질 건지, 비용 등
포함됨 (개발관련 X)
project estimation:
공식적인 개발과 관련된 일정을 누가 얼마에 하는지 등을 계산(행정)
어떤 SW를 파는 것은 만드는 것과 다른 얘기
상용화 하기 위한 준비기간이 매우 김
waterfall일때 전체 기간의 30퍼센트만 개발 기간이 주어짐
Communication
큰 문제 피하기위함
탑다운일 때, 내가 결정하는 것이 아닌 물어봐야함(전체철학에 맞는지)
업무의 경우 이메일로(주장 및 근거, 책임...)
통화, 대화로 하지 않는다
The surgical team
파일럿 팀: 유능한 사람들이 먼저 개발하고
그 뒤에 대체 인력 투입
개발자의 능력은 동일하지 않다.
Code freeze and system versioning: 코드를 얼린다=개발을 종료한다.
오류가 있어도 code freeze 했으면 손을 데지 않아야 한다. 완벽할 수는 없다.
요구 사항을 더이상 받지 않고 개발 종류 선언
완벽한 SW가 아닐 수 있으나 괜찮음 원래 그럼
Specialized tools
개발 도구를 직접 개발한다. 반복적인 일을 도구로 만든다. Ex) 업무 자동화.
Ex) projectlibre
Lower software development costs
소프트웨어 개발 비용을 낮추는 것이다. 어떤 조직에서는 개발하는 사람이 항상 필요하지는 않다.
코딩이 필요한 시간에만 개발자를 고용하라
요구사항을 만족하는 오픈소스나 상용 제품이 있다면 그것을 그냥 쓰는 것도 나쁘지 않다.