본문 바로가기

프로젝트

샘플만 보여주세요. 소프트웨어 개발에서 가장 어려운 것이 "요구사항분석"이라고 여러 차례 언급한 바가 있습니다. 요구사항을 분석하여 "스펙"으로 만들어서 적어 놓은 문서를 "SRS"라고 합니다. 그런데 SRS는 샘플이나 Template을 보고 잘 적는 것은 거의 불가능합니다. 개발자들은 원래 샘플 소스코드를 보고 많은 것들을 배워왔기 때문에 스펙도 샘플을 보면 잘 적을 수 있을 것 같은 착각을 하는 경우가 흔합니다. 샘플 소스코드가 도움이 되는 이유는 개발자들인 소스코드에 대해서는 이미 상당한 지식과 경험이 있기 때문입니다. 샘플만 보고 잘하려고 하는 것은 피아노를 잘 치고 싶다고 유명 피아니스트가 친 것을 몇 번 보고 피아노를 잘 치려 하는 것과 비슷합니다. 심지어는 지금 듣고 있는 피아노 연주가 잘 하는 것인지 못하는 .. 더보기
프로젝트는 연습이 아니다. 필자는 수많은 소프트웨어를 개발해왔고, 주위에서 여러 프로젝트를 봐왔습니다. 그러면서 성공한 프로젝트와 실패한 프로젝트도 많이 봐 오면서 그 차이에 대해서도 많이 생각해 왔습니다. 물론, 성공한 프로젝트는 모두들 알고 있는 요소들이 있습니다. 상세하고 꼼꼼한 일정관리, 꾸준한 리스크관리, 인력관리, 품질관리 등등 이미 알려진 것들입니다. 비단 S/W 프로젝트가 아니더라도, 빌딩을 만들 때도 당연히 필요한 프로젝트 관리의 요소들입니다. 그런데, 유독 소프트웨어 개발 프로젝트에서 종종 벌어지는 현상이 있습니다. 이것이 프로젝트에 큰 리스크가 되고 프로젝트를 실패하게 만드는 원인이 되기도 합니다. 이것은 바로 "프로젝트를 연습처럼 생각한다"는 겁니다. 연구, 공부처럼 생각합니다. "요즘 Python이 인기인데.. 더보기
그냥 쓸 수 있겠네요. 소프트웨어를 개발하면서 가장 어려운 일은 고객의 요구사항을 파악하는 일이라고 알려져입니다. 고전적인 Waterfall 방식부터 Agile까지 요구사항에 대해서 다양한 방법으로 상당히 신경을 쓰고 있습니다. 특히나 우리나라에서는 고객이 요구사항을 잘 가르쳐 주지 않습니다. 물론 자신의 요구사항을 완벽하게 자세히 알고 말해주는 고객은 전세계 어디서도 찾아보기 어려운 것이 사실입니다. 정도의 차이가 있을 뿐이죠. 그만큼 요구사항 파악은 어려운 일입니다. 우리나라에서 요구사항 파악 시 고객이 이렇게 얘기하는 경우가 흔합니다. "자세한 요구사항은 나중에 알려줄 테니 일단 구현을 시작해주세요." 그래서 일단 제품을 다 만들어 놓고 고객에게 시연을 하면 그 때서야 고객이 "여기는 이렇게 고쳐달라", "이 기능을 넣어.. 더보기
하루 8시간 일하시나요? 하루에 8시간 일하시나요? 그렇다고 프로젝트 일정을 예측할 때 하루 8시간 일을 하는 것으로 계산하십니까? 그러면 프로젝트 일정을 지키기 어려울 것입니다. 보통 아무리 집중해서 일을 한다고 해도 하루에 80% 일하기 어렵습니다. 나머지 20%의 시간은 회의를 하고, 커피도 마시고, Email도 봐야 합니다. 또 2개의 프로젝트에 4시간씩 할당이 되어 있어도, 업무 전환 비용(Context switching cost)를 무시할 수 없습니다. 물론 프로젝트 일정은 프로젝트 관리자 혼자서 마음대로 정할 수가 없습니다. 실제 업무를 담당할 담당자들의 도움을 받아서 일정을 산정하게 됩니다. 이때 담당자들이 산정한 일정을 그대로 받아들이나요? 아니면 스스로의 버퍼를 따로 두시나요? 저는 하루의 업무시간을 보통 8시.. 더보기
오늘도 밤을 세워야 하는 개발자 (야근 탈출) 옛날부터 내려오는 경영자들이 믿고 있는 미신이 있습니다. "개발자의 Output은 근무시간의 양에 비례한다." 말은 아니라고 하면서도 밤에 사무실이 텅 비어 있으면 개발자들이 군기가 빠졌다고 생각하고 주말에 누가 나와서 일하나 확인하러 가끔 사무실에 들르는 사람들이 경영자입니다. 실제로 근무시간에 성과가 비례하는 개발자들이 있다면 공장에서 벽돌 찍어내는 것과 다를 바가 없겠지요. 이 미신은 믿기 싫지만 자꾸 저절로 손이 가는 새우깡처럼 믿게 되고, 회사 조직에서 위로 올라갈수록 더 맹신하게 되나 봅니다. 이러한 이유로 어쩔 수 없이 또는 습관적으로 야근을 하는 개발자가 있다면 십중팔구 미혼이거나 결혼을 했어도 아이가 없겠죠. 이런 정상적이지 않은 생활을 하며 10, 20, 30년간 소프트웨어 엔지니어 일.. 더보기
코더(Coder)의 비애 블로그에서 설계에 대한 몇몇 글들을 의견을 적어보려고 합니다. 안녕하세요. Ray입니다. 써니님이 지금 하시는 일을 코딩이라고 만 얘기할 수는 없는것 같습니다. 분석, 설계도 다 하고 계시는데, 문서화가 안되어 있거나 부족할 수는 있어도 분석, 설계는 하고 있는 거죠. 적은 인원이나 소규모 프로젝트에서는 설계가 별로 이슈가 되고 있지 않습니다. 이런 상황에서 인도에 외주를 줄만큼 설계를 하는것도 낭비죠. 하지만, 내가 설계를 해서 다른 사람이 내 설계서를 보고 약간만 물어보면서 구현(코딩)을 할 수 있느냐를 따져보면 설계 이슈는 전면으로 부각됩니다. 실제로 제대로 설계를 해서 산출물을 만들어 외부에 코딩(구현) 외주를 줄 수 있는 사람은 많지 않습니다. 하지만 이런 구현 외주는 미국과 인도에서는 흔한 일.. 더보기
SRS(Software Requirements Specification)의 중요성 본 블로그에서 소프트웨어 개발, 소프트웨어 공학에 대한 여러 주제에 대해서 다루겠지만, 특히 나는 요구사항 특히 SRS에 대해서 많이 다루려고 합니다. "소프트웨어개발의모든것"이라는 책에서도 요구사항에 대해서 가장 중요하게 다루고 있지만 지면의 한계와 다양한 독자층의 눈높이를 맞추기 위해서 욕심보다는 많이 설명하지 못하는 측면이 있습니다. 그래서 소프트웨어 개발단계에서 가장 중요한 "요구사항"에 대해서 천천히 여러분들과 의견을 주고 받으면서 심도있게 다뤄볼까 합니다. 제가 세상의 모든 경우의 요구사항 분석 기술 및 경험이 있는 것이 아니니 여러분들과 토론을 하면서 또 많이 배울 것을 기대하고 있습니다. 먼저 제가 책에서 요구사항에 대해서 설명한 내용을 앞부분을 약간 소개할까 합니다. 요구사항 분석 소프트.. 더보기
Expect Unexpected 제가 구독하는 블로그에 좋은 글이 있어서 번역해서 소개를 합니다. 예상치 않은 것을 예상하라. 프로젝트관리의 오래된 규칙: 항상 예상치 못한 일이 일어난다. 프로젝트관리자라면 예상치 못한 것을 예상하고 가능한 많은 준비를 해야 한다. 실제로, 잘 준비된 프로젝트 관리자는 예상치못한 일이 일어 났을 때에 대비하여 단지 B플랜(백업플랜)을 가지고만 있는 것이 아니라 B플랜을 실행할 능력을 가지고 있다. 리스크관리는 예측할 수 있는 이슈를 다루는 것이고 바라건데 모든 프로젝트관리자의 기본이다. 하지만 몇가지는 절대로 예상할 수 없다. 이것이 좋은 프로젝트관리자와 위대한 프로젝트관리자를 구분하는 것이다. 예상치 못한 일을 예상하는 능력과 이를 처리할 수 있는 능력이다. 그리고 당신은 예상할 수 없는 상황을 어떻.. 더보기
소프트웨어 프로젝트는 누가 진행하는가? http://skcho.com/58 난 자율따위는 믿지 않는다. 긁적 2008/11/12 13:17 안녕하세요. 조성경님. Ray라고 합니다. 블로그에 쓰신 글을 보고 동감을 하면서 제 의견을 몇자 덧붙여 봅니다. 소프트웨어 프로젝트를 진행하기 위해서는 여러 전문가가 필요하죠. 프로젝트관리자도 전문가여야 하고, 개발자들도 소프트웨어 전문가여야 하고, 분석/설계/테스트/빌드/UI/Techpub 등 많은 전문가가 있어야 하죠. 물론 프로젝트 규모에 따라서 혼자서 이 모든 일을 다하는 경우도 있고, 수백명이 각각의 업무를 나눠서 하는 경우도 있습니다. 확실한 것은 혼자서 뚝딱뚝딱 만드는 것과는 다르다는 것이죠. 그런데, 우리는 전문적이지 못한 사람들이 모여서 프로젝트를 진행하는 경우를 허다하게 봅니다. 그런 .. 더보기