실패하는 거대 프로젝트
OS/2
- IBM사가 개발한 것으로 실험적인 요소가 많이 들어갔으며 규모가 너무 컸다
Multics(Bell LAB 제작)
- Time-sharing OS
- 다수의 유저가 동시에 작업이 가능하다.
- 각각의 유저는 서로 다른 작업을 동시에 하는 것이 가능하다.
- Multics의 실패사례를 바탕으로 만들어진 것이 UNIX
실패한 프로젝트로부터 교훈을 얻을 수 있다.
기본 용어
WBS(Work Break-down structure)
- 프로젝트의 추진 목표를 통제 가능한 수준으로 분류한 작업 목록
주공정(critical task)
- 일정을 가능한 빨리 또는 제 때에 마치기 위해서 통제해야 하는 작업
작업량
- 하나의 작업에 투입되는 인적 자원의 시간적 총 투입량
간트 차트(Gantt chart)
- 프로젝트 일정 관리를 위한 바형태의 도구로서, 각 업무별로 일정의 시작과 끝을 그래픽으로 표시하여 전체 일정을 한 눈에 볼 수 있도록 한 차트
- Agile 방법과는 맞지 않으면 규모가 큰 프로젝트에서 주로 사용된다.
- 국공립 과제를 수주하거나 소프트웨어를 관리하는 업무를 맡는다면 사용된다.
Man-month
- 한 달 동안 한사람이 할 수 있는 작업량(1 M/M)
- 한 사람이 1년 동안 할 수 있는 작업량 (12 M/Ms)
- 정부의 소프트웨어 과제는 M/M으로 단가를 책정한다.
Man-month 신화
- 사람을 추가할수록 소프트웨어 개발을 더 늦게 만든다.
- 교육 시간, 상호 소통 시간 등 시간의 낭비가 심하다
- 특별한 지식이나 기술이 필요 없고, 누가 하든 똑 같은 일을 해야한다면 M/M방식이 적절
- 소프트웨어 작업은 복잡하기 때문에 명확하게 구분되지 않는다
- 소프트웨어 개발에 특히 Agile방식은 의사소통이 중요하며, 매일매일 일이 바뀌기 때문에 간트 차트와 같은 것으로 표현하기 힘들다.
- 작업과 인력의 연결도 힘들며 인력마다 할 수 있는 능력치가 다르다.
No sliver bullet / No Swiss army knife
- 소프트웨어에는 만병통치약이 없다.
- 상황에 맞춰서 도구나 개발 방법론 등을 재조정해야 한다.
- 오픈 소스를 가져올 때 조차 in housing/customizing이 필요하다
The second system effect
- 초기 소프트웨어에서 발생한 아쉬움을 두번째 소프트웨어에 over-engineering하게 되면서 느려지고 경쟁력이 떨어지게 된다.
Bug
- Bug는 없애는 것이 목적이 아닌, 일정 수준 이하로 유지하도록 노력해야 된다.
Progress tracking
- 조금씩의 지연이 전체적으로 큰 지연이 될 수 있다.
- 주기적으로 Small individual milestone을 충족함으로써 각 단계에 필요한 관리를 달성한다
Conceptual integrity (조직 문화, 개발 철학)
- 무엇을 더하고 뺄 것인지에 대한 고민
- 제일 좋은 시스템은 유저가 사용하기 쉽도록 구조가 단순하고 명확한 시스템이다.
- 구조가 복잡해지면 많은 feature들이 배울 시간이 부족하기 때문에 사용되지 않는다.
- 유저의 입장에서 어떤 기능을 사용하고 어떤 출력을 받아야 하는지에 대한 기준을 세워야 하며 간단한 구조를 위해 의도적으로 적은 feature를 삽입할 수도 있다.
- 이를 구현하기 위해서는 조직에 방향성, 철학을 제시해야하며 이것에 부합하지 않는다면 아무리 좋은 것이라도 거절될 수 있어야 한다.
- 조직의 철학을 구성원 모두가 동일하게 가지는 것이 중요하다.
Manual
- 소프트웨어를 시작하는 시점에서 상세한 규격, 기능에 대한 설명, 사용자에게 제공할 UI/UX에 대한 설명 등에 대하여 자세하게 내부/외부적인 부분에서 규격을 작성해야 한다.
The pilot system
- 만들어진 시스템의 주요한 기능에 대해서만 구현한 테스트해볼 pilot system을 만들어 테스트한 뒤 테스트가 끝난 뒤 폐기하고 고객에게 제공하지 않는다.
Formal documents
- 프로젝트의 목적, 성취 방법, 소요되는 경비, 데드라인 등에 대해 기술한 정형적인 문서가 필요하다.
- 신입사원이 와도 문서를 제공함으로써 기본적인 이해와 개념을 터득할 수 있게 한다.
Project estimation
- 일의 난이도, 복잡도 등을 이해한 상태에서 일정을 정해야 한다.
- 비기술적, 영양가 없는 미팅 등도 충분한 숙고 끝에 최대한 줄이고 그에 맞는 일정을 도출
Communication
- 필수적으로 커뮤니케이션을 원활하게 해야 하며, 토의되야 할 것이 있으면 추측이나 예측보다는 직접적인 커뮤니케이션이 필요하다.
- 불투명한 과정을 줄임으로써 불필요한 지연과 오류를 줄인다.
The surgical team
- 한 사람이 주도적으로 일을 진행해 나가는 외과 수술팀처럼 능력 좋은 개발자가 팀에 미치는 영향을 거대하며 팀에 능력 있는 개발자가 있는 것이 매우 좋은 영향을 미친다.
Code Freeze and system versioning
- 시스템은 충분한 사용이 이루어지고 유저가 충분히 경험해보면서 만들어진 통찰력을 통해 수정을 진행할 수 있다. 통찰력을 기반으로 한 수정 요구 사항을 지속적으로 충족시켜야 하며, 더 이상 수정이 허용되는 시점이 오면, 더 이상의 수정이 필요 없다는 의미의 code freezing을 선언하며, 버전 넘버를 기재한 후 버전을 저장한다.
- 중간 단계에서 versioning을 필수적으로 해야 하며, 의미 있는 단계에서 code freezing을 통해 버전을 저장하고 관리하는 작업을 해야 한다.
Specialized tools
- 훌륭한 도구는 생산성, 개발 기간, 성능을 향상시키는 것에 유효하다.
- 팀이 하는 프로젝트에 특화된 도구를 만드는 것이 유효하다.
- 경력이 높은 개발자들이 주로 도구를 만드는 작업에 투입된다.
- 수작업으로 불편한 작업을 자동화하는 작업을 지칭한다.
Lowering software development costs
- Water-fall 관점에서는, 소프트웨어 구조가 완성되었을 때 개발자를 구하는 것이 개발 비용을 줄일 수 있는 방법이 된다.
- 소프트웨어를 만드는 것보다 off-the-shelf 소프트웨어를 구매하는 것이 유효할 수도 있다.
- 최근의 관점에서는 오픈 소스를 찾는 것이 유효하다.
KHU, SWCON