Day_01. Chp-1생존을 위한 사고방식

Chp-1 생존을 위한 사고방식


생존을 위한 사고방식이 필요한 이유
=대규모 Project 의 절반이 통제가 불가능해 취소되고 있음
=제품의 완성 전에 일정, 예산을 초과한다는 통계치가 존재할 만큼 중요함


S/W 생존을 위한 방법
=문명화된 방식을 사용하라
==모든 당사자들의 권리를 존중하라(고객, 개발팀)
===고객 – 합리적으로 프로젝트를 변경하게 해주어야함
===개발팀 – 할당된 기간 등이 충분히 있는지


S/W 생존의 욕구
=프로젝트가 취소되지 않고 팀도 해체되지 않고 만족스러운 작업 환경을 가진다


생존의 Test
=간단한 설문조사등을 통해 Project 의 건강 상태를 평가할 수 있다


생존 Test 의 5가지 영역
=요구사항 / 계획 / 프로젝트 통제 / 리스크 관리 / 인력


영역별 특징

요구사항	실제 사용자(End-user)와 project초기에 면담을 가졌는가
계획	일정과 예산 추정치는 최근 업데이트 됫나 단계별 구현과 납품의 계획이 있는가 시스템 Test와 코드리뷰의 품질 보증 계획이 있는가 프로젝트 계획에 휴일,병가,교육의 기간이 들어가 있는가 자원의 할당은 100%가 안되게 지정되어 있는가
프로젝트 통제	PM 이 프로젝트에 열중할수 있는 환경인가 프로젝트 이해관계자(Stack holder – 개발자,테스터,사용자,스폰서) 의 마일스톤을 알수있나 오류추적 S/W 소스코드 통제 S/W등 기초적 자동화 도구가 있는가 (Excel 은 자동화 도구라고 보기 어려움)
인력	요구된 과업을 수행할 인력은 충분한가
	***계획부분의 점수가 낮은데 통제점수가 좋을수 없음***

프로세스 상류(Up-stream)활동
=개발자들이 쓸데없는 곳에 시간을 사용하지 않도록 만든다는 뜻
=개발자들의 시간을 절약해 주는 것이 중요하다


Process 특징
=생존이 목표라면 Process 에 중점을 두고 업무를 진행해야 한다
=Process가 좋은곳에는 에러를 못찾는 확률이 적음
=큰 노력을 하지않아도 Process 수준이 높으면 에러가 잘나옴
=Process가 부실하면 부단히 노력해야 평균적 에러를 검출한다


생존에 필요한 프로세스 구성요소
=모든 요구사항에 대한 문서화
=요구사항의 변경 통제를 위한 절차를 적용하라
=요구사항 설계, 소스코드에 대해서는 테크니컬 리뷰를 필히 진행해야 한다


Process의 긍정적 효과
=시행착오의 감소
=시간이 지난뒤에는 몸에 체득되어 자동적으로 수행함


Process 특징
=상류 – 분석/설계 과정 = Technical Review
=상류는 code가 없고 개념이 많이 등장하기 때문에 Technical Review 를 진행한다
=하류 – 구현/Test
=실체 확인을 위한 Demo – 가장 강력한 Process 통제 방법


좋은 Process 의 특징
=초기에 문제를 제거한다
=단계내 봉쇄를 통해 Technical debt를 예방한다
=결함이 생긴 후 바로 처리하여 결함을 발견하고 수정한다

 

상류		하류
분석	설계	구현	Test
Technical Review		Demo
전체 Project 에서 80%		전체 Project 에서 80%