본문 바로가기

프로젝트

고객이 요구사항을 너무 자주 바꿔요. 우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다. 예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행 일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리.. 더보기
왜 이리 버그가 많아요? 소프트웨어 릴리즈는 그 성격에 따라서 몇 가지 형태로 구분이 됩니다. 소프트웨어는 그 종류가 셀 수 없이 많아서 획일적으로 얘기할 수는 없어도, 릴리즈를 구분하여 부르는 것은 필요합니다. 릴리즈를 구분하다는 것은 현재 릴리즈가 어떠한 것이고, 그에 따라서 어떠한 프로세스를 따라야 하고, 어떠한 기대값을 가져야 하는지 그 이름만 들어도 알 수 있게 합니다. 하지만, 팩키지를 개발하는 소프트웨어 회사는 나름대로 릴리즈 구분에 익숙해져 있지만, SI회사, 게임회사, 포탈 등의 서비스 회사, 금융회사들은 릴리즈는 그냥 릴리즈라는 생각을 하고 합니다. 따라서 수많은 릴리즈를 함에도 불구하고 각 릴리즈를 부르는 버전도 없는 경우가 허다하고, 개발자가 임의대로 릴리즈를 하는 경우도 많습니다. 그럼 릴리즈를 어떻게 구.. 더보기
Track me, if you can "요구사항 추적"이라는 말을 들어 보셨을 겁니다. 요구사항, 기능, 컴포넌트(클래스), 파일, 함수들의 연관관계를 추적하여 특정 요구사항에 관련된 컴포넌트나 소스코드들을 추적하고, 거꾸로 함수가 바뀔 때 이 변경에 영향을 받는 요구사항을 알아낼 수 있습니다. 왠지 근사해 보입니다. 실제로 요구사항을 추적하려고 노력하는 회사를 종종 보게 됩니다. 하지만 요구사항을 추적할 필요도 없는 작은 소프트웨어이거나 엉터리로 하고 있는 경우가 대부분입니다. 아니 100%입니다. 요구사항 추적이라는 것이 말만 근사해 보이지, 대부분의 역량으로는 거의 불가능합니다. 또 요구사항 추적툴 없이 엑셀파일에 끄적거려서는 할 수 없는 일입니다. 요구사항 추적은 사람의 생명을 다루는 소프트웨어이거나 엄청난 비용과 테스트가 불가능한 .. 더보기
개발자들이 바글바글한 외딴섬에 떨어진다면 개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까? Language 기초를 다시 가르칠까요? UML을 가르칠까요? 문서 작성법을 훈련 시킬까요? 개발방법론을 가르칠까요? 팀워크를 키워줄까요? OOP를 가르칠까요? 어떻게 하시겠습니까? 나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement .. 더보기
커뮤니케이션 오류 소프트웨어 프로젝트를 진행하다 보면 수많은 커뮤니케이션의 오류를 발견하게 됩니다. 문서화 되지 않은 수많은 의견과 결정들에 대한 오해와 대화를 하면서 발생하는 표현의 오류는 한 두개가 아닙니다. 이는 비단 프로젝트에서 뿐만 아니라 일상생활에서도 벌어지는 현상이지만, 일상생활에서의 커뮤니케이션 오류는 그렇게 심각하지 않을 수 있지만, 프로젝트에서의 커뮤니케이션 오류는 심각한 손실을 초래하기 때문에 조심할 필요가 있습니다. 따라서 프로젝트를 진행하면서 오가는 대화나 기록은 명확해야 합니다. 미사여구보다는 직설적인 화법으로 핵심을 정확하게 말해야 합니다. 또 하나의 문장은 사실, 의견, 추축, 가정, 결정 또는 정보일 수 있습니다. 그런데, 현재 하고 있는 말이 사실인지 의견이지 명확하게 하지 않으면 수많은 .. 더보기
UML전문가가 설계전문가? 종종 "소프트웨어 설계를 잘 하려면 UML을 잘 알아야 합니까?"라는 질문을 받습니다. 사실 넘치는 기법들이 개발자들을 더 혼란스럽게 하는 것에 종종 화가 날 때가 있습니다. 기법은 기법일 뿐입니다. 내용은 아니죠. UML은 잘 정리된 모델링, 설계 기법이며 툴이고 많은 장점을 가지고 있다고 생각합니다. 그럼에도 불구하고 소프트웨어 설계라고 하고 UML을 떠올리는 것을 보면 UML이 본의 아니게 나쁜 일도 했다는 생각이 듭니다. 잘 된 설계는 형식에 구애 받지 않고, 소프트웨어를 구현하기 충분하게 소프트웨어 구조를 잘 설명한 것입니다. UML이 그 중의 하나가 될 수도 있고, 전통적인 Flowchart, DFD, 수도코드나 글로 설명할 수도 있습니다. 설계는 어떠한 다이어그램을 그리고 어떤 툴을 쓰냐에 .. 더보기
좋은 PM은 훌륭한 리스크 관리자 프로젝트에서 가장 중요한 활동 중에 하나가 리스크 관리입니다. 프로젝트 실패의 원인의 대부분이 리스크 관리를 하지 않거나 하더라도 부실하게 하는 데 있습니다. 성공하는 프로젝트관리자는 우수한 리스크 관리자입니다. 성공하는 프로젝트는 대부분 성공 가능한 범위 및 일정을 가지고 리스크를 잘 관리한 프로젝트입니다. 반면, 성공 가능한 범위 및 일정을 가지고 시작한 프로젝트라도 리스크 관리에 거의 신경을 쓰지 않으면 예상치 못한 돌발 변수에 프로젝트는 실패하기 쉽습니다. 프로젝트 리스크 관리를 하다 보면 소프트웨어 프로젝트는 정말 가시밭길을 걷고 있다는 생각이 듭니다. 웬만한 크기의 프로젝트에서 리스크 수십 개를 찾아내기란 그리 어렵지 않기 때문입니다. 하지만 미리 발견되고 관리되는 리스크들은 그 위험을 현저히.. 더보기
요구사항 분석의 출발점 소프트웨어 개발에 있어서 요구사항 분석이 가장 중요하다는 것은 앞에서도 이미 주지한 사실입니다. 2008/11/19 SRS(Software Requirements Specification)의 중요성 2009/02/04 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은? 요구사항 분석의 산출물은 SRS, 요구사항분석서 또는 다양한 방법론에 의해서 다른 문서들이 나올 수 있겠죠. 그럼 요구사항분석의 출발은 무엇일까요? 어떤 기능을 제공하기를 원하나 조사하는 것일까요? "왜 이 프로젝트를 하려고 하는가?"입니다. 프로젝트를 하는 목적과 목표를 알아야 모든 요구사항이 일관성을 갖게 됩니다. 이걸 누구나 다 알고 있다고요? 제 경험에 의하면 그렇지 않습니다. 프로젝트 구성원에게 각각 물어보면 프로젝트의 목적.. 더보기
우리는 개발자가 테스트해요. 주변의 소프트웨어 회사들을 보면 개발자가 테스트를 하는 회사를 정말로 많이 접하게 됩니다. 물론 개발자도 구현을 하면서 Unit테스트는 일상적으로 하지만, 제품의 기능이 정상적으로 동작하는지 확인하는 시스템 테스트도 개발자가 테스트하는 것을 보는 것은 그리 어려운 일이 아닙니다. 오히려 전문 테스트 인력이나 테스트팀이 있는 회사를 보는 것이 더 어렵습니다. 있다고 하더라도, 테스트팀이 전문적으로 테스트를 수행한다기 보다 개발자의 손을 좀 덜어주는 경우가 흔합니다. 이렇게 개발자가 테스트를 하는 이유는 다양하지만 다음과 같은 것들이 있습니다. 우리는 인력이 너무 적어서 테스터를 별도로 둘 수 없어요. 프로젝트 기간이 너무 짧아서 별도의 테스트 단계를 둬서 테스트를 할 수 없어요. 개발자만이 기능을 속속들이.. 더보기
프로젝트 시작부터 개발자가 바글바글 소프트웨어 개발 프로젝트가 시작되면 바로 개발팀이 구성되어서 개발자들이 바글바글 한가요? 그렇다면 뭔가 개발 체계에 잘못된 것이 없는지 검토를 해봐야 합니다. 개발을 단계(Stage)구분 없이 마구잡이로 하고 있지 않은지? 개발 업무(분석, 설계, 구현)의 구분 없이 섞여서 하고 있지 않은지? 개발자가 별도의 전문성 없이 모든 업무(분석, 설계, 구현, 빌드, 테스트)를 다 하고 있지 않은지? 프로젝트의 각 단계에 따라서 투입되는 인력이 달라집니다. 소프트웨어 개발 프로젝트에서 흔히 저지르는 실수 중 하나가 프로젝트가 시작되자마자 모든 프로젝트 인력을 한꺼번에 투입해 놓고 프로젝트 끝날 때까지 그 인원으로 계속 진행하는 경우입니다. 각 단계 별로 필요한 인력과 인원 수가 달라지는데 프로젝트 초기부터 많은.. 더보기

티스토리툴바