3 Classic Mistakes #1128
Description
제 3 장 전형적인 실수
전형적인 소프트웨어 프로젝트에서 실수를 통해 배울 기회는 보통 사람들이 일생동안 경험하는 횟수보다 많다.
3.1 사례 연구를 통해 본 전형적인 실수
사례 연구 3-1. 전형적인 실수
기가-쿼터라는 12개월 프로젝트를 기획
하지만 경영진에서 6개월로 단축시키고 통신 기능을 추가할 것을 지시
테스트 기간을 고려해 개발 기간은 4개월이었지만
원래 단축했던 6개월은 테스트팀에 넘기지 못하고 초과했고
초기에 계획했던 기간은 12개월도 넘어 15개월이 걸린 프로젝트였음
3.2 실수가 개발 일정에 미치는 영향
현대적인 프로그래밍 기법 사용에 대해 연구원들의 연구 결과는 다음과 같다.
낮은 성능은 낮은 생산성, 높은 성능은 높은 생산성의 범주에 들어간다.
하지만 높은 생산성을 예상한 프로젝트가 실제로 생산성이 낮은 사실이 드러난다.
현대적인 프로그래밍 기법을 적극 사용한다 해도 거기서 얻은 생산성을 상쇄하는 실수를 저지를 수 있다.
쾌속 개발을 고려할 때 느린 개발의 근본 원인을 제거하면 될 거라 생각할 수 있지만
문제는 그런 근본 원인은 없고, 그걸 찾기 위한 노력은 더 쓸모 없다는 것이다.
사람들이 뛰어난 업적을 세워 출세하지 못하는 이유는 너무 많아서 열거하지 못할 뿐이다.
소프트웨어 개발은 함정이 많다. 어느 함정에 얼마나 빠지느냐가 소프트웨어를 빨리 혹은 느리게 개발할 수 있는지를 결정한다.
느린 개발을 하려면 진짜 큰 실수 하나만 저지르면 된다.
쾌속 개발을 이루려면 큰 실수 모두 피해야 한다.
3.3 전형적인 실수 목록
많은 사람들이 잘못될 거라 예상하면서도 비효율적인 개발법을 선택했다.
이걸 전형적인 실수라 부르는 데 나름의 매력이 있어서 그렇다.
일정 초과? 인력 더 투입
일정 단축? 계획을 더 빽빽하게
팀워크가 깨뜨리는 개발자? 프로젝트 끝나면 해고
프로젝트 빨리 끝내야 함? 개발자 더 투입해서 빨리 일 시켜
이런 결정을 내리는 데는 나름의 이유가 있다.
그리고 자주 잘못된 결정을 내리는 이유 중 일부가 바로 전형적인 실수에서 오는 매력 때문이다.
실수를 너무 자주 저질러서 이제는 그 결과를 쉽게 예측할 수 있다.
그래서 이런 전형적인 실수를 저지르면 바라는 성과는 거의 얻을 수 없다.
이제 전형적인 실수 36개를 소개하는데
이 실수들의 공통 분모를 피한다고 해서 쾌속 개발이 된다는 보장은 없지만 피하지 않으면 속도가 분명 느려지는 건 사실이다.
사람
- 동기 저하. 생산성과 품질에 무엇보다 큰 영향을 미치는 요인으로 동기를 꼽는다(Boehm 1981)
- 저급 인력. 팀원 개발 능력이나 팀워크는 동기 다음으로 생산성 향상에 큰 영향을 미친다(Boehm 1981, Lakhanpal 1993)
- 문제 인물 방치. 제럴드 와인버그가 1971년에 Psychology of Computer Programming을 출판한 이후 이 문제가 널리 알려졌다. 문제 팀원 조치를 하지 않는 태도는 큰 문제다(Larson and LaFasto 1989)
- 영웅적 행동. 영웅심이 이로울 수 있다 생각해 프로젝트에서 영웅적 행동을 강조한다 (Bach 1995) 하지만 이런 분위기는 해가 된다. 꾸준하고 일관성 있는 진행과 실질적인 진척 보고 보다는 '할 수 있다'식의 태도를 더 중시하면 그렇다. 그러면 잘못된 상황을 개선할 기회를 놓친다. 그리고 피해가 생길 때 까지 조치를 취할 필요가 있다는 사실도 깨닫지 못하는 경우도 있다. 톰 드마르코가 말했듯이 '할 수 있다'식 태도는 사소한 실수를 진짜 재앙으로 이끈다 (DeMarco 1995)
- 프로젝트 후반에 인력 추가. 인력 추가는 새 인력으로 인한 생산성 증가가 아니라 기존 팀원의 생산성 저하를 유발한다. 프레드 브룩스는 프로젝트 후반의 인력 추가를 불에 기름을 붓는 행위에 비유했다(Brooks 1975)
- 시끄럽고 붐비는 사무실. 개발자 대부분(60%)은 더 조용하고 사적인 공간을 원한다(DeMarco and Lister 1987). 시끄럽고 붐비는 업무환경은 개발 기간을 늘인다.
- 개발자와 고객 사이 마찰. 개발자와 고객 사이 마찰은 의사소통 단절을 일으킨다. 이는 요구사항 이해 부족과 사용자 인터페이스 디자인의 품질 저하로 이어진다. 고객과 개발자 사이의 마찰이 너무 심해지면 양쪽 모두가 프로젝트 취소를 고려하게 된다(Jones 1994).
- 비현실적인 기대. 비현실적인 기대는 그 자체가 일정을 늘이지는 않지만 개발 기간이 너무 길다는 인상을 주는 데 기여한다. 스탠디쉬 그룹의 조사는 사내 비즈니스 소프트웨어 프로젝트에 성공하기 위해 필요한 5개 요인 중 하나로 비현실적인 기대를 꼽았다(Standish Group 1994)
- 효과적인 프로젝트 후원 부족. 경영진이 프로젝트를 효과적으로 후원하지 못한다면 다른 고위 간부가 비현실적인 기간을 강요하거나 프로젝트를 멋대로 변경할 수 있다. 롭 톰세트는 후원이 부족하면 프로젝트는 실패한다고 주장한다. (Thomsett 1995)
- 관련자 참여 부족. 경영진 후원자, 팀장, 팀원, 영업부, 최종 사용자, 고객, 그외 이해관계자 모두 프로젝트에 적극적으로 관여해야 한다. 관련자들이 참여해 친밀한 협력을 해야 하고 이를 통해 각 노력을 정확히 조율해야 쾌속 개발을 할 수 있다.
- 사용자 참여 부족. 스탠다쉬 그룹 조사에서 프로젝트가 성공하는 가장 큰 이유가 사용자 참여라고 밝혔다. (Standish Group 1994)
- 실속보다 정치. 래리 콘스탄틴은 각기 다른 정치적 성향을 가진 네 팀에 대한 연구를 보고했다. (Constantine 1995a). 정치가, 연구원, 고립주의자, 종합인. 정치가와 종합인은 초기에 대표의 신뢰를 받지만 시간이 지나면 정치가팀은 제일 하위로 떨어졌다. 정치를 결과보다 우선시하는 태도는 속력 중심 개발에 치명적이다.
- 막연한 기대. 예) 일정에 맞게 프로제트를 끝낼 수 있다고 믿지 않았지만, 열심히 하고 운도 따르면 할 수 있을지도 모릅니다.
공정
- 지나치게 낙관적인 일정. 프로젝트 범위를 과소 평가하게 되고, 효과적으로 계획을 세울 수 없으며 요구사항 분석이나 설계와 같은 결정적인 초기 개발 활동을 생략하게 된다.
- 불충분한 위험 관리. 하나만 잘못되어도 프로젝트는 쾌속 개발에서 느린 개발로 바뀐다. 위험 관리 실패가 바로 전형적인 실수가 된다.
- 하청업체 실패. 때때로 하청업체는 늦거나 승인하기 어려울 만큼 품질이 낮거나 명세서와는 다른 제품을 납품한다(Bohem 1989).
- 불충분한 계획수립. 쾌속 개발은 계획없이 이룰 수 없다.
- 압력에 따른 계획수립 포기. 대안을 수립하지 못하고 '짜보고 고치기' 상황으로 가는 게 문제다. 그렇게 마감을 놓치고 계획을 포기하는 게 전형적인 실수이다.
- 애매한 시작으로 낭비한 시간. 프로젝트를 시작하기 직전 승인이나 예산 수립에 보내는 시간을 말한다. 몇 달을 허비한 후 갑자기 타이트한 일정으로 작업하는 일이 흔하다. 개발 일정을 줄이려는 노력 보다 애매한 시작에서 시간을 절약하는 방법이 훨씬 쉽다.
- 건너 뛴 초기 활동. 요구사항 분석, 아키텍처 설계, 시스템 설계는 직접 코드를 작성하지 않으므로 건너 뛰게 된느 쉬운 표적이 된다. 이는 '바로 구현하기'라고 하는 실수이며 결과가 너무 뻔하다. 초기 활동을 건너 뛴 프로젝트는 제대로 단계를 거친 것보다 10배에서 100배나 많은 비용을 치른다(Fagan 1976, Boehm and Papaccio 1988). 처음에 5시간이 없어 제대로 못하는데, 나중에 바로 잡는 데 쓸 50시간이 나올리 없다.
- 불충분한 설계. 설계는 품질보다 편의를 위해서 강조하는 활동이다. 시스템을 완성하기 전에 시간이 들더라도 설계 주기를 여러 번 반복해야 한다.
- 부족한 품질 보증. 프로젝트 초기에 품질보증 활동을 하루 아끼면 나중에 더 큰 대가를 치루게 된다(Jones 1994).
- 불충분한 관리 감독. 프로젝트를 계획대로 진행하려면 우선 계획대로 진행하는지를 판단할 수 있어야 한다.
- 너무 이르거나 지나치게 잦은 통합. 촉박한 프로젝트는 통합을 조기에 서두르는 경향이 있다. 원한다고 바로 통합할 수 없기 때문에 어떤 쾌속 개발 프로젝트는 성공하기 까지 여러번 시도한다. 이런 시도는 제품에 이롭지 않으며 시간을 낭비하고 일정을 늘일 뿐이다.
- 세부업무 누락. 지난 프로젝트 기록을 잘 보관하지 않으면 눈에 안 띄는 업무를 잊어버린다. 누락한 업무는 개발 일정은 20~30% 까지 늘인다 (van Genuchten 1991)
- 나중에 따라잡을 계획. 절대 그런 일은 일어나지 않는다. 개발을 하면서 개발 소요 시간에 대해 많이 구체적으로 알게 되므로 일정을 재조정할 때 이런 지식을 반영해야 한다. 다른 실수는 제품을 변경할 때다. 개발중인 제품을 변경한다면 걸리는 시간도 변하게 된다.
- 미친듯이 구현하기 개발. 이는 짜보고 고치기 전략과 무리한 일정의 합작에 불과하며 이 조합은 절대 성공하지 못한다. 잘못된 두 전략을 합해 옳은 전략을 만들어 낼 수 없다.
제품
- 요구사항 치장. 실제 필요한 내용보다 더 많은 요구사항을 늘어 놓고, 성능을 필요 이상 강조해 일정을 늘인다. 복잡한 기능은 일정을 에측 불가능하게 늘일 뿐이다.
- 기능 변형. 평균적으로 프로젝트 요구사항은 한 생명주기 동안 약 25% 정도 변한다(Jones 1994).
- 개발자 치장. 요구사항이 아닌 기능을 설계, 구현, 테스트, 문서화를 하는 건 일정을 시연시킬 뿐이다.
- 조삼모사식 협상. 관리자가 일정 지연을 승인해 완전히 다른 업무를 추가하는 식이다. 관리자가 일정 지연을 승인한다는 건 일정에 문제가 있었다는 사실을 간접적으로 인정하는 꼴이다. 일정을 조절해도 그 사람이 다시 일정을 망친다.
- 연구중심 개발. 세이모어 크레이는 실패할 위험이 크기 때문에 한 번에 두 영역을 초과해서 공학적 한계를 뛰어넘는 시도를 하지 않는다고 했다(Gilb 1988). 새로운 알고리즘이나 전산학 한계에 도전한다면 인건 소프트웨어 개발이 아닌 소프트웨어 연구가 된다. 연구 일정은 이론상으로도 예측 가능하지 않다. 기술 수준을 향상하는 일정에 빨리 달성할 수 있다는 기대는 하면 안된다.
기술
- 특효약 증후군. 새 개발법, 새 기술, 특정 프로세스 등 한 가지에 집착해 일정 문제가 해결되기를 바란다면 반드시 실망하게 된다(Jones 1994).
- 새로운 도구나 방법에 대한 과대평가. 새로운 방법으로 얻는 이익은 그것을 배우는 학습 과정으로 부분적으로 상쇄되며, 새로운 방법을 최대한 활용할 만큼 익히는 데도 시간이 든다. 극적인 이익을 얻기 보다는 몇 퍼센트 정도로 천천히 꾸준히 향상될 뿐이다.
- 프로젝트 도중에 도구 변경. 학습 기간, 재업무 새로운 도구 사용에 따른 필연적인 실수 따위가 이득을 생쇄시킨다.
- 자동화된 소스코드 관리 부족. 평균적으로 소스코드를 매달 10% 정도 변경하는데 수작업으로 이를 따라잡을 수 없다(Jones 1994).
3.4 길리건 섬에서 탈출하기
시애틀 대학교 데이비드 움프레스는 전형적인 실수를 피하려는 회사를 지켜보는 것은 길리건 섬 재방송을 보는 것과 같다 고 했다.
에피소드 초반에 길리건, 스키퍼, 교수 중 한 명이 섬에서 벗어날 터무니없는 계획을 세우는데 에피소드가 진행되면서 잘못된 게 드러난다.
에피소드가 끝나면 섬에 발이 묶인 제자리 상태인걸 알아챈다.
자신만의 실수 목록
회사 내 다른 프로젝트의 사후분석을 장려하고 그들의 실수를 교훈으로 삼아라.
다른 사람들이 같은 실수를 피하고 교훈으로 삼을 수 있도록 실수 목록을 적극적으로 공개하라.