애자일 경험담 9

Developer 2009/12/09 15:47
오랜만에 애자일 관련 포스팅을 남기는 기념으로 기존의 정보공학 방법론에서의 문제점을 까보기로 하자.
정보공학방법론 다른말로 Water fall 방법론(폭포수모델)의 성공확률을 보면 1990년 중반 겨우 16% 였다.
이것이 2000년대 중반 30%까지 상승한다.
상승요인을 Chaos report에서는 애자일 방법론의 적용이라 명시한바가 있다.
왜 그럴까?

이유는 간단하다. Water Fall 방법론은 요구사항의 변화를 수용하지 않는다.
처음 Fix된 요건은 최종 Release할때까지 변경될수가 없고 변경에는 엄청난 비용이 지불된다. 그나마 이것도 개발팀이 정말 Perfact하게 일했을때이다.
다시말해 Water Fall 방법론은 3가지 변수를 가진다.
첫째, 요구사항의 변경이 없을것
--> 비즈니스가 변화하기전에 최대한 개발을 빨리 끝내던가 정말 수십년째 루틴하게 돌아가던 업무를 IT화 할때 본 조건을 충족시킬수 있다.
둘째, 이해관계자의 숫자가 매우 적을때
--> 1사람을 만족시키는 것이 2사람을 만족시키는 것보다 2배가 아닌 몇배는 더 쉽다
셋째, 개발팀이 기술적 Challange를 받지 않을때
--> 아주 간단해서 평범한 개발자라면 도저히 에러를 일이키지 않거나 에러를 금방 잡을 수 있을때 만족한다.

종합하면 Water Fall 모델은 "최단시간에 한방에 고객 1~2명을 대상으로 개발할때 성공률이 보장된다"

더 재미 있는것은 Water Fall 모델에서 주장하는 ERD를 보면 현재의 OOP와는 개념이 안맞다.
특히 SI업은 Database 응용 개발 사업이라 볼 수 있는데 가장 중요한 ERD를 어떻게 설계하는지 한번보자.

고객: 저희는 대출업무 시스템을 만들고 싶습니다.
개발자: 대출하려면 어떤 일들이 일어나고 있나요?
고객: 대출고객이 책일 대출신청대로 가져오면 대출담당자가 책에 있는 고유번호 읽어 기록하고 대출대장에 기록합니다.
개발자:그때 기록되는 데이터가 어떤것입니까?
고객: 책고유번호, 책이름, 고객번호, 대출일, 대출반납일 입니다.
여기서 개발자는 바로 ERD라는 것을 그린다.

[Book Table] ----- [Rent Table] ----- [Customer Table]
BkSeq                    RtSeq                    CuSeq
BkName                  BkSeq                   CuName
                             CuSeq
                             RtData

이게 당연하다고 생각하는가?
실상은 이건 잘못되어도 한참 잘못되었다.
원래의 정보공학방법론에서는 CRUD라는 것을 그리도록 하게 되어 있다.
사용자 삽입 이미지
엔티티를 도출하기전에 단위프로세스와 엔티티의 연관을 Create, Read, Update, Delete로 구분하여 최종 ERD라는 것을 그린다.

그런데 멋도 모르는 개발자들이 스스로 정보공학 방법론을 준수하지도 못하면서 정보공학최고 이러고 있는 것이다. 얼마나 한심한 노릇인가?

정확히 다시 말해 기존의 정보공학방법론에서 계약이후에 요구하는 개발 산출물은 다음과 같다.

1. 과업내역서 (고객사 작성)
2. 사업수행계획서/WBS (개발팀이 과업내역서 참조후 작성)
3. 관리관련 (테일러링내역서, 보안계획, Risk관리계획, 교육계획 등등등)
4. 요구사항관련 (요구사항 정의서, 요구사항 명세서 등등)
5. 설계관련 (CRUD, ERD, DFD, DB명세서, 기능정의서, 기능명세서, 인터페이스정의서, 인터페이스정의서, 테이블정의서, 테이블명세서, 기능정의서, 기능명세서, 형상관리정의서, 형상관리명세서 등등등등등)
6. 구현후 테스트관련 (단위테스트정의서, 단위테스트결과서, 통합테스트정의서, 통합테스트결과서, 성능시험계획서, 성능시험결과서, 인수시험계획서, 인수시험결과서 등등등)
7. 교육 (교육교재, 교육결과서)
8. 보고서 (일간, 주간, 월간, 이슈 보고서 등)

다쓰기고 벅찬 산출물을 다 만들겠다고 하는것도 웃기다.
할려면 제대로 하던가?
아니면 혁신을 이루어 좀더 인간적인 업무 환경을 만들던가?
이도 저도 아닌 것때문에 오늘도 좌절하는 개발자는 반드시 존재할 것이다.

마지막으로 카네기 멜론 대학 컴퓨터공학과 교수였고 IBM 연구원이었다가 현재는 구글 연구소 부사장으로 근무한 알프레드 스펙터(Alfred Spector)가 1986년에 다리건축과 소프트웨어 개발을 비교한 말이 떠오른다.

"다리 건축은 계획된 기간에 끝나고, 계획된 예산으로 마무리 되며, 무너지지 않고 성공적으로 완료가 된다. 하지만 소프트웨어 개발은 계획된 기간에 끝나지도 않으며, 계획된 예산에 마무리 되지도 못한다. 또한 성공적으로 완료되지 못하고 실패한다. 또 다른 차이점은 만약 다리가 무너지면 조사하고, 왜 다리가 무너졌는지 그 이유를 찾아내서 재발을 방지하려고 노력하지만 소프트웨어 프로젝트의 실패는 감추어지고, 무시되며, 합리화 된다는 점이다. 그래서 우리는 실패하더라도, 그 원인에 대해 찾고 배우지 않기 때문에 또 다시 실패하게 된다."

이 말에서 우리는 무엇을 찾아야 하는가?
2009/12/09 15:47 2009/12/09 15:47

트랙백 주소 :: 이 글에는 트랙백을 보낼 수 없습니다