|
오병곤 저자님의 책은 오랜만에 읽어본듯 하다. 대한민국 개발자 희망보고서 라는 책을 예전에 읽었었고.. 월화수목금금금 에 상당히 공감했었다. IT 의 힘든 상황에서 기술사 자격증을 땃다는 것에 놀랐고 참 대단함을 느꼈었다. 개인적으로는 아직도 그정도의 열정을 쏟지는 못하고 있는듯 하다. 이 책은 프로젝트를 성공적으로 마치기 위해서 실용적으로 어떻게 소프트웨어 개발을 진행할지에 대한 내용을 담고 있다. 넓게는 프로젝트 개발하면서 우리가 흔히 접하게 되는 개발단계의 단계별 과정을 다루면서 해당 단계의 문제점과 대안 그리고 우수사례를 다루고 있다. 간접적으로 프로젝트의 진행이 어떻게 이루어지는지 나 해당 과정에서 어떠한 문제가 발생을 하는지 그러한 문제가 발생하지 않기 위해서 어떠한 방법을 쓰고 어떠한 우수사례가 있는지를 접할 수 있어서 좋은 듯 하다. 그전에도 우리나라 특유의 빨리빨리 가 it 도 예외는 아니어서 외국보다 더 짧은기간에 개발을 했었지만 점점 경기가 안좋아져서 그런지 이제는 그 기간마저도 더 줄이고 개발자도 더 줄여서 개발을 진행하는 경우가 많다. 보통 프로젝트는 분석,설계,개발,단위테스트,통합테스트 등의 단계의 과정을 거치며 개발을 해나간다. 그런데 요새는 앞의 분석,설계을 없애거나 개발에 합치고 개발기간은 줄이고 단위테스트도 개발에 합쳐버리는 개발,통합테스트 의 과정으로 가는 경우도 많다. 더구나 개발자는 전보다 축소하고 기간도 축소를 해서 프로젝트를 한다. 예전에 3년정도의 기간을 잡고 하던 프로젝트를 요새는 1년을 넘기는 경우가 거의 없다. 개발자들은 기계가 아니다. 프로그램 개발은 기계적으로 키보드를 두드려서 완성하는것이 아닌데 기본적으로 무엇인가를 개발하기 위해서는 개발전에 어쩌면 개발보다 더 긴 시간을 생각을 하며 구상을 해야 한다. 하지만 현실은 그냥 자리에 앉아있는걸 더 중요하게 여기는 경우도 많다. 책에서 얘기하는 개발자들에게 생각할 시간이 필요하다는 말과 야근을 보여주기식 면책용의 방법으로 사용한다는 말에 공감한다. it 에는 많은 방법론이 나와있다. 해당 방법론들은 모든 프로젝트에 적합한것이 아니다. 내가 겪은 프로젝트들은 그때 트렌드에 따라 이 개발방법론을 쓰면 개발기간이 단축이 되고 비용도 단축시킬수 있다면서 무슨 마술인것마냥 쓰는 경우가 많다. 프로젝트마다의 상황에 맞추어 그에 맞는 적절한 개발방법론을 사용해야 한다는 말에 공감한다. 개발방법론이라는게 해당 프로젝트의 개발기간을 단축시키거나 비용을 단축시키기 위해서 사용하는건 아니라고 생각한다. 개발을 진행하면서 시행착오로 개발기간의 연장과 그에 따른 추가 비용 및 요구사항 변경들에 따른 추가리스크, 추후 유지관리 등에 대한 리스크를 최소하 하기 위한 것이라고 생각한다. 실제 그 프로젝트에 들어가는 실공수가 줄어드는 것은 아니라고 생각하는데.. 이상하게 이 방법론을 쓰면 실공수가 이렇게 줄어요.. 와 같은 식의 프로젝트를 많이 겪게 된다. 결국은 프로젝트를 성공시키기 위해서 개발자들은 월화수목금금금 상황을 계속 할 수 밖에 없게된다. 정작 그렇게 만든 관리자들은 책임을 안지는데 실제 개발하는 개발자들이 책임을 지는 상황이 항상 겪을때마다 답답함을 느끼게 된다. 속된말로 남이 싸놓은 똥을 왜 내가 치워야 하는건지... 책에서 얘기하는 고객의 인식의 변화는 많이 공감이 가면서 가장 우선적으로 변화되어야 할 부분이라고 생각한다. 눈으로 보이는 것은 쉽게 요구를 변경하지 않는다. 책에서는 찰흙을 예를 들었지만 만들어 이미 굳어버린 찰흙으로 다른걸 만들어 달라고 요구를 하진 않을것이다. 그런데 소프트웨어 개발에서는 고객이 아무때나 그냥 수정할 수 있다고 생각한다. 소프트웨에의 개발도 찰흙처럼 굳으면 다시 변형하기가 힘들다는 인식을 가지는게 참 중요하다고 생각한다. 시스템 오픈이 내일인데. 오늘 요구사항을 변경하면서 수정해달라는 경우도 허다하다. 갑질 이라는 단어가 요새 많이 사용되는데 기존에 작성한 요구사항정의서 든 해당 요구에 대해서 이렇게 협의했다는 사인을 했든 분명 이렇게 해달라고 하지 않았냐는 회의록 녹취 든.. 소용이 없다. 고객의 입장은 그렇다. 우리가 필요하다는데... 개발자가 안된다고 하면 관리자에게 얘기해서 통과시키기에.. 이러한 요구사항 변경에 대한 고객의 인식의 변화가 중요하다고 생각한다. 책에도 언급이 되었지만 짝프로그래밍은 항상 빠지지 않는 소재이긴 한데 개인적으로는 우리나라의 특성상 할수가 있을까 하는 생각을 아직도 가지고 있지만 그 비슷한 방식은 실무에서는 종종 하는 경우가 있다. 서로 다른 업무를 하고 있지만 두 개발자들의 유대관계가 좋은 경우 서로 같이 봐주면서 개발을 하는 경우도 있다. 해당 업무를 하고 있던 개발자는 계속 보고 있던 소스이기에 거기에 제한된 시야가 생기는 경우가 있다. 그럴때 그러한 제한된 시야를 가지지 않는 개발자가 같이 보게 될 경우 의외의 해결책이나 버그가 쉽게 발견되는 경우가 많다. 이러한 제한된 시야가 생기는 걸 없애기 위해서도 책에서 말하는 것처럼 개발자들에게 생각할 시간을 주는게 프로젝트의 리스크를 줄이는 좋은 방법이 아닐까 생각한다. 책에서 얘기하는 프로젝트의 공수산정도 많이 공감이 가는 내용이다. 프로젝트의 공수산정을 제대로 하는게 가장 첫번째 과제일 것이다. 책에서 얘기하는 것처럼 소프트웨어의 공수산정은 아무래도 제대로 하기가 힘들다. 실제 눈에 보이는 명확한 데이터가 없기 때문이다. 그러므로 어찌보면 좀더 철저하게 파악해야 하는 부분인데 문제는 재대로 공수산정이 안되는 경우도 많지만 더 큰 문제는 그렇게 제대로 산정이 안된 공수산정 조차 고객의 요구에 의해 심하게는 절반으로 줄인다는 것이다. 그 기간자체가 비용이므로 고객은 좀더 저렴한 비용으로 프로젝트를 하려고 한다. 그 이면에는 인력에 대한 저평가도 원인중 하나가 아닌가 싶다. 책을 읽으면서 개인적으로 경험했던 상황들에 대한 내용들이 많아 많이 공감을 하면서 읽었던듯 하다. 우리나라의 모든 IT 분야가 그런건 아니지만 개인적으로 겪었던 IT 프로젝트를 생각하다보니 답답해서 사설이 길었던듯 하다. IT 프로젝트에 대해서 발생하는 단계마다의 문제점과 그에 따른 우수사례 등을 간접적으로 접할 수 있어 IT 에 관심있는 분들이 읽으면 좋을듯 하다. 개인적으로는 관리자나 고객 처럼 실제 칼자루를 쥐고 있는 분들이 읽고 인식이 좀 많이 바뀌었으면 좋겠다는 생각을 한다. |
|
난 96년부터 IT 분야의 일을 시작해서 지금도 이쪽 일을 하고 있다. 햇수로 21년이 되는건가. 프로그래밍으로 시작해서 프로젝트 관리를 중간에 했고, 지금은 NIPA 품질관리 컨설팅 사업을 수행하고 있다. SW공학 및 품질 관리 컨설팅 일을 하고 있고, 나름 이쪽 지식 및 지혜를 정리하고픈 바램이 있던 차에 업계 선배분께서 먼저 길을 닦아 주셔서 반가운 마음으로 책을 읽게 되었다. 이 책 저자는 일단 기술사 자격을 가지고 있는 분이라서 그런지 여러 주제의 내용들이 서로 조화롭게, 개념있게 잘 정리되어 있다는 느낌을 받았다. 즉 지식적으로도, 통찰의 측면에서도 건질 내용이 참 많다. 인상적인 몇가지를 소개하자면, 먼저 책의 구성, 아니 구조이다. 크게 기술과 관리 및 지원으로 나누었고, 덧붙여 SW를 바라보는 기본적인 시선이 어때야 하는지로 전체 책의 구조를 잡았다. 물론 책의 핵심 컨텐츠는 기술이지만 개인적으로는 3부가 더 읽고 싶어 먼저 있었다. 기본 파트에서는 PDCA와 테크니컬 라이팅 내용이 좋았다. 주로 우리는 일을 할때 실행과 체크 일부를 하는데, 그게 아니라 계획과 개선의 중요성, 즉 시작과 끝을 강조하려는 저자의 통찰이 좋았다. 그리고 기술 문서를 작성하기 위한 팁들, 특히 제안을 많이 쓰는 나로서는 옆에 끼고 번번히 참조할 수 있는 제안서 작성 체크리스트가 생겨 좋았다. 참, 이 책의 부제 워딩에 포함된 베스트 프랙티스(우수사례)를 매 주제별로 하나씩 볼 수 있어 구체적인 사례의 풍부함을 녹여 낸 점도 잘 된 점이라 할 수 있다. 책 구성 면에서 하나 더 언급하자면 전체 40개의 얘기 실타래를 책 제일 뒤에 60개의 실천법으로 정리해 두었다. 책 말미에 책 내용에 대한 나침반의 역할을 톡톡히 할 수 있다고 본다. 두번째로 기술 파트에서 좋았던 내용을 말하자면 먼저 생명주기란 주제를 아주 깔끔하게 잘 정돈해 준 점, 그리고 요구사항, 설계, 구현, 테스트, 통합이라는 기술 영역의 핵심 주제에 대해 꼭 기억하면 좋을 주제들을 참 엄선했고 설명 자료도 피와 살이 되는 중요한 점을 잘 추렸다. 마지막으로 관리 및 지원 영역이다. 이 책의 전반적인 느낌이기도 하지만 현장에서 많은 고민을 통해 나온 통찰이 곳곳에 배어 있고 그 심오함을 설명하는 데 있어 소소한 이야기가 잘 배치되어 있다. "개발자 채용과 경력 개발"에서 짐 굿나이트의 경영 철학을 언급하고 있는데 참 적절한 내용이 해당 주제와 잘 버무려졌다고 본다. 그리고 내가 주로 하고 있는 업무인 품질관리에 대한 주제를 다룬 "통찰력을 제공하는 품질활동"에서는 QC, QA, QI, QM이 아주 명쾌하게 개념 정리되어 있음을 확인할 수 있다. 통상 두리뭉실하게 알고 있어 혼동이 되는 영역인데 참고하면 좋을 내용이다. 정리하자면, 이 책은 무한 경쟁 시대에 타임 푸어를 살고 있는 한국 IT의 현실 속에서 우수사례에 기반한 스마트한 일처리를 가이드하는 단비같은 책이다. IT는 지식산업인데 업계의 생리에 맞지 않는 옷을 우리는 많이도 껴 입고 있다. 먼저 이 길을 경험한 선배로서 후배에게 할 수 있는 최선은 자신의 통찰을 나눠주는 것이다. 사람은 다들 본전 심리가 있고, 경쟁이 만연한 한국 사회에서 자신의 소중한 자산을 아낌없이 내 놓기가 쉽지 않은데 이 책을 읽으면서 참 많은 지식과 통찰을 접하면서 저자의 진정성을 느낄 수 있어 감사했다. 이 책이 많은 후배 개발자의 손에 쥐어져서 SW업계에 맞는 지식과 지혜가 전파되어 이제는 우리 조국도 위대한 SW가 우후죽순처럼 만들어지길 기대해 본다. 꼼꼼히 읽었고, 일독을 권하고 싶은 책이다. |
|
올해로 개발자 15년차이며 프리랜서 8년차인 IT 개발자이다. 수많은 프로젝트를 경험해 봤지만 어떤 체계적인 방법론이 적용된 프로젝트는 거의 접해 보지 못했다. 업무량이나 일정 등을 대충 감으로 파악해서 진행하기 일쑤이다. 거기에 아직도 대부분의 프로젝트 현장은 스마트하게 일하기 보다는 '열심히 일하기'를 선호한다. 아마도 '스마트' 의 기준이나 척도를 제대로 측정할 수 있는 장치를 아직은 제대로 만들어 내고 있지 못한 게 아닐까 싶다. IT 현장 관리자들에게 이 책을 권하고 싶다. 이 책에 있는 내용들을 당장 현장에 적용을 할 수는 없을지라도 지속적으로 현장에서 일어나는 문제들을 점진적으로나마 개선할 수는 있을 것이다. |
|
컴퓨터 공학 또는 전산학을 전공한 개발자라면 학부 과정에서 소프트웨어 공학이라는 과목을 수강한 경험이 있을 것이다. 소프트웨어 공학은 소프트웨어 개발이 어떤 과정으로 진행되며 각 단계에서 해결해야 할 문제를 이해하고 전체 과정을 경험하는 과목이다. 과목의 특성상 수강생들은 학기 동안 1-2개의 팀 프로젝트를 진행한다. 그 과정에서 일의 양을 추정하는 경험, 팀원을 구성하고 역할을 분담하는 경험, 일을 관리하는 경험을 한다.
소프트웨어는 단순한 코딩만으로 완성되지 않는다. 소프트웨어는 다양한 이해관계자들의 상호작용을 통해 점진적으로 완성된다. 소프트웨어 개발 과정은 생명주기로 설명하기도 한다. 복작한 소프트웨어 개발 과정을 단순화해서 설명할 수 있기 때문이다. 하지만 소프트웨어 개발 과정은 살아있는 생명체처럼 역동적이고 다양한 변수가 존재한다. 관리해야 할 요소는 여기 저기 산적해 있고 복합적으로 상호작용을 하고 있는 경우가 많아 처음부터 체계적으로 관리하지 않으면 해결에 골머리를 앓기도 한다.
반면 많은 개발자들은 소프트웨어 개발을 쉽게 생각하는 경향이 있다. 소프트웨어 개발이라는 큰 그림을 보기 보다는 기술이라는 나무에 관심이 더 많고 집착하는 성향이 강하기 때문이다. 하지만 소프트웨어 개발의 목적은 고객의 문제 해결이라는 것을 명심한다면 기술 자체에 집중되어 있는 관심을 주변 환경으로 돌릴 필요도 있지 않을까 생각한다.
이런 생각을 설명하는데 도움이 될 책이 출간됐다. 바로 오병곤 작가님의 "실용주의 소프트웨어 개발" 이다. 책의 제목만 봤을 때는 소프트웨어 개발 방법론을 설명한 이론 서적이 아닌가 생각했다. 하지만 책을 읽고 난 후 내가 오해 했음을 인정했다. 작가님은 25년 IT 경력을 통해 축적한 경험과 지혜를 실무에서 활용할 수 있도록 구체적인 문제와 사례를 통해 설명하신다.
책은 크게 3장으로 구성되어 있다.
1장은 엔지니어링에 관한 내용이다. 소프트웨어 생명주기에서 각 단계마다 필요한 기술적인 내용을 설명하고 있다. 특히 소프트웨어 개발에서 가장 중요한 요구 사항 도출 및 명세서 작성, 요구 사항 관리에 대한 부분은 많은 분량을 할애하여 설명하고 있다.
2장은 개발 과정에서 발행할 수 있는 환경적인 요인을 어떻게 관리하고 운영할 것인지에 대한 이야기다. 엔지니어는 경험을 통해 성장한다. 기술적인 성장뿐만 아니라 개발 환경을 관리하고 운영하는 경험은 더 넒은 관점으로 소프트웨어 개발을 볼 수 있는 시야를 열어 줄 것이다. 관리의 경험이 부족한 개발자라도 작가님이 설명해 주시는 내용을 통해서 시야를 넓히는데 많은 도움을 얻을 수 있을 것이다.
3장은 일을 바라보는 관점과 태도에 대한 이야기다. "일에 대해 생각하는 과정이 있어야 어떤 일이든 일을 장악하고 경영할 수 있다"는 조언은 많은 생각을 하게 한다. 성장이 멈춘 것은 아닌지, 초심을 잃은 것은 아닌지, 나 자신을 돌아 보는 시간이었다.
저자의 25년 경험과 지혜의 액기스중에 액기스가 농축되어 있는 책이다. 책은 각 주제가 독립적으로 구성되어 있다. 자신의 가려운 부분을 긁어 줄 수 있는 주제를 선택해서 읽으면 된다는 말이다.
이책을 이렇게 추천하고 싶다. 3년 이하의 신입 사원이라면 3장부터 보고 조언해 주시는 내용을 실천해 보기를 강력히 추천한다. 1장과 2장은 소프트웨어 개발을 보는 시야를 넓힌다는 마음으로 가볍게 읽어 보기를 권한다. 경험이 없는 상태라면 무슨 내용인지 이해하는데 많은 어려움이 있을 수 있기 때문이다.(경력 10년차인 본인도 온전히 이해했다고 자신있게 말할 수 없다. ㅜㅜ)
5년 이상 10년 미만 경력의 개발자라면 자신이 처한 환경과 경험을 기반으로 비교 하면서 읽으면 많은 도움이 될 것 같다. 특히 도움이 됐던 부분은 재미있게도 3장이었다. 일의 가치를 다시 생각해 보고 어디를 향해 가야 할 것인지 생각해보는 계기를 마련해 주었기 때문이다.
프로젝트 기획, 팀 빌딩, 요구 사항 검토 및 분석, 구조 설계 및 구현, 개발 환경 구축, 테스트, 배포, 프로젝트 관리, 비즈니스 개발 등을 경험 했고 지금은 다시 개발을 하고 있다. 4-5년을 곁에서 조언해 주는 사람없이 경험을 통해 성장해야 했고 그 과정에서 다양한 시행 착오를 겪을 수 밖에 없었다. "실용주의 소프트웨어 개발"이란 책이 3-4년 만 일찍 출간 되었어도 많은 시행 착오를 줄일 수 있었을 텐데 하는 아쉬움이 남는 지점이다.
소프트웨어 개발이라는 큰 숲을 보기를 원하는 개발자, 현명한 시행 착오를 계획하려는 개발자에게 본 도서를 추천한다. |
|
대상 독자들에 대해 SI 프로젝트에 참여하고 있는 PM 혹은 PM이 되실 분, PM으로 커리어를 쌓아나가고자 하시는 분들에게는 “필수”라고 감히 말할 수 있을 것 같습니다.
책의 구성 이 책은 크게 3개의 장으로 나뉘어 있습니다.
저는 이 3개의 챕터를 다시 2개의 분류로 나눠보고 싶습니다. 1. 기술(Engineering) / 관리 및 지원(Management & Support)
2.기본(Fundamental)
책의 장점
기타 부연
마무리하며
|
1. 필자 소개이 글을 쓰는 저자는 IT 전문가로 성장하기 위해 꾸준히 노력하는 사람이다. 초등학교 때 하이텔, 나우누리, 에듀넷, 키텔(?) 등의 PC 통신을 통해 프로그래밍을 알게 되었다. 컴퓨터로 무언가를 만들고 고치는 것이 좋아서 대학교에서는 컴퓨터공학(Computer Engineering)을 전공했다. 국내와 해외에서 짧고 굵게 다양한 경험을 했으며 현재는 금융공기업에 재직중이다. 2. 어떻게 읽게 되었는가대학동기의 소개로 오병곤 대표님이 저술하신 ＜실용주의 소프트웨어 개발＞ 책이 출간 서평 이벤트를 한다는 것을 알게 되었다.
이벤트에 응모 후 당첨이 되어서 책을 수령하게 되었다. 2. 누구를 위한 책인가＜실용주의 소프트웨어 개발＞의 독자는 소프트웨어 개발을 똑똑하게 하고 싶은 프로젝트 관리자(Project Manager, PM), 소프트웨어 개발이라는 숲 속의 나뭇가지가 아니라 전체 그림을 보고 싶은 개발자(Engineer)이다. 개인적으로는 공공기관에서 외주를 통해 소프트웨어를 도입하려는 업무 담당자가 이 책을 읽었으면 한다. 공공기관의 IT 부서에서 근무를 하면 신규 SW도입 또는 유지보수 계약 등 관리적인 측면에서 일을 많이 하는데 이 책을 통해 여러 가지 도움이 되는 내용을 많이 얻을 수 있었기 때문이다. 3. 책 구성이 책은 아래의 세 가지 파트로 구성되어 있다.
각 파트는 현실, 우수사례, 산출물, 요약이라는 내용으로 이루어져있다. 각 파트 안의 주제가 적당한 분량으로 나누어져 있어 글이 잘 읽힌다. 4. 좋았던 점 세 가지＜실용주의 소프트웨어 개발＞에는 실무에 활용할 수 있는 훌륭한 내용이 많이 있다. 그 중에서 필자에게 와닿았던 좋았던 점 세 가지를 추려보았다. 첫째, 개발에 대한 이야기만 하지 않았다는 점이 책은 소프트웨어 개발을 다루지만 그렇다고 해서 소프트웨어 개발만 다루지는 않는다. 필자는 이 점이 가장 마음에 들었다. 특별히 들어가는 글인 ‘우리가 버려야 할 세 가지 관행에 대하여’는 큰 울림이 있었다. 여기서 말하는 세 가지 관행은 Word Hard, Work Fast, Work in The Same Way를 말한다. 대부분의 사람들이 자기보다 똑똑하지 않은 사람들이 만들어놓은 관행에 순응하며 산다. 이 글을 읽는 필자도 그러한 현실에 굴복하며 살 때가 많다. 이러한 사실이 참 안타깝다. Work Hard를 먼저 살펴보자. 경제협력개발기구(OECD) 자료에서 발간하는 ‘1인당 평균 실제 연간 근로시간’을 보면 2014년 기준으로 한국이 연간 2,124시간을 일을 한다. OECD 회원국 평균 근로시간이 연간 1,770시간이므로 한국인 노동자는 연간 354시간, 주당 평균 6.8시간을 더 일한다. 야근을 안하면 열심히 일하지 않는다고 생각하는 꼰대문화, 고객 또는 관리자에게 내가 열심히 일하고 있음을 보여주기 위한 불필요한 행동 등 한국의 평균 근로시간이 긴 데는 여러 가지 이유가 있다. 프랑스에서 일할 때 필자의 관리자는 나에게 이렇게 말했다.
대한민국은 과거의 성공방식이었던 Word Hard를 버리고 일의 양(Quantity)이 아니라 질(Quality)로 승부하는 Work Smart를 받아들여야 한다. Work Fast도 문제다. 소프트웨어 개발은 건물을 짓는 건설업과 다르다. 한국의 ‘빨리빨리’문화를 잘 적용하면 큰 경쟁력이 될 수 있다는 사실에는 공감하지만 무리한 속도전은 얻는 것보다 잃는 게 더 많다. 이에 대한 내용은 필자의 생각을 더 적기보다는 책을 인용함으로써 마치겠다.
Work in The Same Way는 다른 말로 매너리즘이라고 한다. 끝없는 야근을 종료하려면 지금 하는 일의 프로세스에 도전해야 하는데 대부분은 이러한 일을 하지 않는다. 순환보직을 하는 공공기관은 더 심한 것 같다. 힘들어도 어차피 2-3년 이면 다른 사람이 할 일이라는 생각에 개선할 생각을 하지 않는다. 개선을 하려면 힘이 드는데 그에 대한 적절한 보상이 없거나 미미할 때가 많기 때문이다. 하지만 환경만 탓할 수는 없지 않은가? 필자는 책을 읽으며 본인이 맡은 일에 대해서, 본인의 삶에 대해서 혁신할 수 있는 환경을 만들기로 결심했다. 어떻게(How)에 대해서는 더 생각해봐야겠지만 모든 변화는 확고한 결심에서 시작되니 곧 더 좋은 변화가 내 삶에 올 것임을 믿는다.
둘째, 소프트웨어 개발 및 관리에 대한 모범사례＜실용주의 소프트웨어 개발＞에는 소프트웨어 개발 및 관리에 대한 모범사례가 많이 수록되어 있다. 그리고 필요한 경우는 각 개발단계에서의 산출물의 목록과 템플릿도 제공한다. 예를 들어, 아래는 요구사항 종류에 대한 목록을 나열한 표이다.
필자는 현재 요구사항정의서를 작성중인데 요구사항 목록 뿐만 아니라 책 안에 있는 다양한 자료를 보면서 큰 도움을 받고 있다. 물론 기업에서 일을 잘하는 방법 중 하나는 기존의 잘 된 문서를 보면서 자신의 업무에 적용하는 것이다. 하지만, 거기에만 머무르면 앞에서 말했던 기존에 하던대로 업무를 하는 관행(Working in the same way)에 빠질 수 있다. 타 기관에서 작성한 문서, 소프트웨어 개발 도서 등 여러 가지 자료를 함께 참고하면서 이전보다 더 잘 일하면 더 좋지 않을까? 아키텍처 설계, 프로그램 명세서 작성, 테스트 설계, 대가 산정, 개발자 채용, 품질활동 등 공공기관 IT부서의 기획팀에서 일하면서 한 번쯤은 고민해봤을 내용에 대한 훌륭한 답변이 이 책 안에 가득하다. 우수한 조직은 비즈니스 목표 달성에 부합하는 측정활동을 수행한다. 아래 그림은 책 중간에 소개되었던 GQM(Goal, Question, Metric)이라는 도구인데 실무에 적용할 수 있는 훌륭한 내용이라 생각하여 이 포스트에도 추가했다. 올바른 목표와 질문을 하면 이에 대한 정량적인 데이터를 수집하여 올바른 의사결정을 하는 데 도움을 줄 수 있다.
셋째, 일의 기본에 대한 내용＜실용주의 소프트웨어 개발＞은 소프트웨어 기술과 관리 외에도 일의 기본(Fundamental)을 다룬다. 직장생활 2년 차인 필자에게 도움이 되는 내용이 많았다. 글을 읽으면서 그래도 나름대로 열심히 살고 있고, 꾸준히 발전하고 있다고 생각했는데 아니었다.
소프트웨어 개발을 주먹구구식으로 하는 것처럼 내 삶도 주먹구구식으로 살고 있는 것은 아닌가라는 생각에 부끄러웠다.
5. 아쉬웠던 점 두 가지이 책을 읽으면서 실무에 바로 적용할 수 있는 내용이 많았다. 개인적으로는 기술적인 부분보다는 관리적인 측면에서 큰 도움을 받을 수 있었다. 그렇다고 하더라도 이 세상에는 완벽한 책이 존재하지 않고, 한 사람을 안주하게 만드는 달콤한 칭찬보다는 계속 정진할 수 있도록 만드는 “배려깊은 말”이 중요하다고 생각하기에 감히 아쉬웠던 점을 적는다. 첫째, 각종 서식을 제공하지 않음＜실용주의 소프트웨어 개발＞에서 소개하는 여러 가지 서식을 파일로 공개하면 더 실용적인 책이 되었을 것 같다. 기본적인 서식 파일을 제공하면 책을 읽은 독자가 좀 더 쉽게 현실에서 배운 지식을 활용할 수 있지 않을까? 둘째, 여러 가지 관리업무 자체를 체계적으로 관리할 수 있는 방법의 상세설명 부재앞에서도 계속 언급했듯이 이 책에는 훌륭한 소프트웨어 관리기법을 소개한다. 하지만, 각 관리 방법을 적용하는 것은 가능하더라도 여러 가지 관리업무를 체계적으로 관리할 수 있는 방법에 대해서는 설명이 다소 부족한 것 같다. 물론 요구사항 및 결함관리를 위한 도구인 Redmine, 형상관리를 위한 Subversion, Git 등을 소개하고 있지만 단순한 언급에서 끝난다는 점이 아쉽다. 예를 들어 사용자의 요구사항은 발전해서 테스트 시나리오, 소스코드, 문서 등으로 발전한다. 요구사항은 역방향으로도 추적이 가능해야 한다. 알지만 이것을 어떻게 실천할 것인가? 특정 도구에 대한 설명이 어려웠다면 실무 경험이 풍부한 저자의 경험을 소개하는 것도 좋지 않았을까? 예를 들어, 파일의 이름은 이렇게 규칙을 정했고, 폴더 구조는 이렇게 만들어서 각 프로젝트를 관리했다는 식의 내용으로 말이다. 6. 총평소프트웨어 개발 전 과정을 이해하고 싶고 이전보다 좀 더 나안 관리자, 개발자가 되고 싶은 사람이 이 책을 읽는다면 분명히 얻어가는 게 있을 것이라 생각한다. 따라서 이 책은 돈과 시간을 들여 읽을만한 가치있는 책이다. 이 책의 구매는 아래 사이트에서 가능하다. |
|
이 책은 크게 3개의 장으로 구성되어 있다. 1장에서는 기술(Engineering) 관점에서 효율적이고 스마트하게 소프트웨어를 개발하고 프로젝트를 진행하기 위한 방법론, 전략, 아이디어, 제언 등을 다루고, 2장에서는 관리 및 지원(Management & Support)이라는 측면에서 대가산정 현실화 및 검증, 개발자 채용과 경력개발, 품질 관리, 프로젝트의 위함과 결함관리, 요구사항 변경에 대한 자세, 형상관리, 효율적 프로세스 개선 등에 대해 이야기 한다. 3장은 기본(Fundamental)이라는 주제로 일의 시작과 가치, 우선순위, 성장을 기록하기, 테크니컬 라이팅, 시간관리, 창의, 기술과 인문의 만남 등에 대해 다루는데 개발자 개인의 성장에 초점이 맞춰져 있다. "소프트웨어 개발에서 많이 쓰는 방법론은 '정보공학 방법론'도 아니고 '객체지향 방법론'도 아니다. 그것은 '일단 짜보고 고치기' 방법론이다. 이 방법론은 계획과 수립, 분석, 설계 과정을 등한시하고 오로지 프로그래밍만을 강조한다. 프로젝트에서 해야 할 일을 정의하고 계획을 수립하는 절차를 대충하고 진행한다. 고객의 요구사항을 정확히 파악하려는 노력을 게을리하고 이를 시스템에 구체적으로 반영하는 과정을 생략한다. 빨리 일정을 끝내려는 무리한 속성 과정이다. 일단 짜보고 고치기 방식은 기본적인 스프트웨어 개발 절차를 무시하고 우연에 맡기는 프로그래밍이다. 일에 대해 생각하지 않고 맹목적으로 일하는 방법론이 아직도 유요한 까닭은 이 방법이 가장 쉽기 때문이다. 머리를 쓰지 않으니 힘들 리가 있겠는가? 개발 조급증도 원인이다. 이 방법론이 부실과 재작업을 키운다."(p289) 내가 재직 중인 회사는 프로젝트 단위로 외주 개발을 하는 SI쪽이 아니고 회사 자체 서비스(포털사이트, 쇼핑몰, 모바일 애플리케이션)를 개발, 운영하고 있다. 체계적인 절차를 밟아 일을 진행하기 보단 같은 멤버로 10년 이상 손발을 맞춰온 구성원들의 팀웍과 경험, 누적되어 있는 사내 코드 레퍼런스, 라이브러리, 패턴 등에 따라 움직일 때가 많다. 이 책을 읽으며 적지 않은 문제의식과 인사이트를 얻을 수 있었다. [설계] 단계의 중요성과 비중에 대한 부분이 가장 크게 와 닿았다. 수개월에서 반년 이상 소요되는 비교적 규모가 큰 프로젝트와 한달 또는 일주일 내외의 작은 단위 개발, 운영 업무를 지난 십수년 진행해오면서 이 책에서처럼 정밀하고 체계적으로 요구사항을 도출하여 꼼꼼히 설계하는 과정을 거치진 못했다. 언제나 기간에 대한 압박은 존재하고 경험과 센스에 의존해 설계 후 개발에 착수하고 런칭 과정에서 여러 번의 수정과 피드백을 거치고 런칭 이후에도 지속적으로 개선, 안정화 작업을 진행한다. 일정 수립 단계에서 설계 과정의 비중을 높이고 완성도 있는 설계 절차를 확실히 거친 후에 실제 개발에 들어간다면 분명 시행착오를 줄이며 결과적으로는 완성도와 전체 일정의 단축이라는 두 마리 토끼를 잡을 수 있을 것 같다. 사실 그게 만만한 일은 아니다. 개발팀 뿐 아니라 기획팀, 디자인팀, 일정에 대한 의사결정권자까지 모두 설계 단계의 중요성과 어려움에 대한 이해와 그 '비용'을 기꺼이 들일 수 있는 의지가 필요하기 때문이다. 이 책을 개발팀원을 비롯해 회사 동료들과 함께 읽어보자고 제안할 생각이다. 생각해보니 오병곤 저자의 전작 '대한민국 개발자 희망보고서'란 책도 10여년 전에 팀 필독서로 정해서 함께 있고 느낀 점을 나눈 적이 있었다. 산적한 개발 이슈와 실무적인 내용을 주제로 자주 미팅을 하지만 어떻게 효율적으로 개발을 해나갈 것인가, 업무와 개발을 스마트하게 처리하기 위해 우리가 어떻게 변화해야할 것인가에 대한 고민과 노력은 부족했다. 나 개인의 영역에서도 그렇고 회사적으로도 부족했다고 본다. 개발팀원, 타부서 팀장들과 함께 읽고 토론하고 개선된 방법론을 적용해보고 사후 리뷰하는 과정을 가질 수 있도록 내가 좀 주도적으로 나서보려 한다. 이 책이 좋은 지침서, 나침반 역할을 할 수 있을 것이라 기대한다. 나에게 고객이라고 한다면 내가 개발한 웹사이트와 모바일 애플리케이션의 이용자(User)일 것 같기만 실상 함께 기능 개선에 대해 상의하고 협업하는 기획자나 디자이너도 주요한 고객이다. 기획자, 디자이너와의 관계와 관련해서는 오래전부터 프로그래머에겐 중요한 주제였다. 이 책을 읽으면서 다시 한 번 나의 '고객'에 대해 생각해볼 수 있었다. 기획자들이 아무리 길게 회의를 하고 기획서, 스토리보드를 만들어와도 개발자가 움직이지 않으면 그들의 기획이 구체화될 수 없는 게 당연하고 그 사실로 인해 개발자는 갑의 위치에서 이야기할 수 있는 일종의 권력 같은 게 있을 때가 있다. 프로젝트의 완성도, 결과물의 품질을 위해 최선을 다해 노력하는 개발자라면 열린 마음과 서비스 정신(?) 역시 필요하다는 10년전에도 했던 생각을 다시 한 번 했다. 저자는 '현장의 작은 조각 경험과 체험들을 묶고 연결하여 범용적 이론으로 체계화 할 수 있어야 그 분야의 전문가라고 불릴 수 있다'고 강조한다. 이 책이야말로 오병곤 저자가 25년간 IT와 인문학의 중간에서 IT 기획, 비즈니스 솔루션 개발, 경영과 프로세스 혁신 컨설팅, 조직원 교육 등에 통해 경험한 노하우와 시행착오를 녹여낸, 한국적 현실에 맞는 소프트웨어 개발 방법론이다. PM 역할을 하는 리더와 팀원들이 함께 읽고 나누며 이 책에서 제안하는 방법론을 자신의 조직에 맞게 간단한 것부터 적용해본다면 기존보다 향상된 개발 퍼포먼스를 얻을 수 있을 것이다. IT, 개발 파트에 종사하는 사람이라면 꼭 읽어봐야할 좋은 책이라고 생각하며 일독을 권한다. |
|
저자를 생각할 때 나는 그의 책 『대한민국 개발자 희망보고서』가 먼저 떠오른다. 이 책은 쉽게 변하지 않는 IT 환경에서 고민하는 수많은 개발자들의 심금을 울렸으며 나도 그 중 한 명 이라는 점을 우선 서두에 밝혀두고 싶다. 이 책이 나온 지 정확히 10년만인 올해 오병곤 작가의 기술서 『실용주의 소프트웨어 개발』이 출간되었다. 그의 책을 기다려 온 독자 중 한 사람으로서 유독 외국서적에 의존적인 IT업계에 우리나라에도 이런 책이 나왔다는 점에서 뿌듯한 마음을 금할 길 없다. |