10점 근처만 되도 우리나라 여건에서 훌륭합니다. 미국에서는 one-man company를 해도 각 기능을 구분해서 일을 합니다. 그러면서 필요한 문서도 다 만들죠. 그렇게 하는 것이 주먹구구보다 더 효율적이고 나중에 회사가 점점 커져도 일을 나줘 줄 수 있습니다. 그런데, 우리나라는 그렇게 할 수 있는 훈련이 거의 안되어 있어서 회사가 크나, 작으나 주먹구구이고 큰 회사들은 외국에서 방법론을 들여와서 기계적으로 따라하다가 더 비효율적으로 되곤하지요. 갈길은 멉니다. - -;
소프트웨어공학을 소프트웨어 개발에 적용하는 이유는 빠른 시간안에 적은 비용으로 소프트웨어를 만들이 위함입니다. 위 항목들은 그중에서 기초적이고 중요한 지표들을 모아 놓은 것입니다.
각 항목들은 보기에는 그리 어렵게 보이지 않을지 몰라도 하나하나 내포되어 있는 것들은 대단히 큰 것들입니다. 즉 하나하나 지키는 회사와 지키지 않는 회사의 차이는 엄청납니다.
실제로 20점이 나오는 회사는 어떤지 말씀을 드리죠. 이 평가 항목은 소프트웨어 회사의 모든 역량을 체크하지는 않습니다. 가장 기초적인 역량 및 다른 역량들을 미루어 짐작할 수 있는 것들입니다. 글로벌 소프트웨어 회사들은 모두 20점이 나온다고 할 수 있습니다. 또, 20점이 나온다고 무조건 성공하는 것도 아닙니다. 소프트웨어를 제대로 만들 수 있는 기초적인 역량을 갖췄다는 의미입니다. 다른 회사들과의 경쟁에서 우위에 서기 위해서는 이 20가지 이외에 필요한 것이 훨씬 많습니다.
하지만 제가 접한 거의 모든 소프트웨어 회사들은 20점 만점에 10점 미만이었고, 이정도의 기초되 되지 않고서는 글로벌 경쟁은 꿈도 꾸지 못하는 겁니다. 일단 이 평가에서 20점에 이르게 되면 기초를 갖춘 것이고, 이때부터 해야 할 것도 많습니다.
좋은글 잘 읽었습니다. 계산해보니 17점 나오네요. 그런데 형상관리나 이슈관리 시스템은 꼭 하나만 써야 하나요? 지금은 하나만 쓰고 있지만 전엔 CVS 형상관리도구나 지라, 버그질라, 멘티스 등의 이슈관리 시스템을 CI도구로는 컨티넘이나 허드슨을 사용했으나 지금은 SVN으로 통합되었고 자체개발한 이슈관리 시스템을, CI도구는 컨티넘과 허드슨을 사용하고 있습니다. "꼭 하나"여야만 하는 이유가 있을까요?
사실 통합빌드(CI)를 위한 기술은 CI도구와 더불어 maven, ant등의 기술이 혼용될수 있고 이때 소스코드 백업을 위해 Git + SVN 등 여러 도구를 혼합할 수 있는데 "꼭 하나"하는지에 대해서 궁금해지네요. 물론 아무생각없이 백화점식 도구를 사용하면 안되지만 목적이 명확해서 도구를 혼용한다면 하나보다 더 효율적이지 않을까 하는 생각도 해봅니다.
안녕하세요. 임병인님 17점이면 엄청난 점수인데요. 제가 지금까지 만나본 회사중에서 최고점입니다. ^^ 특별한 이유가 없다면 하나만 쓰는 것이 정답입니다. 자세한 이유는 제가 쓴 책을 보시기 바랍니다. :) 그리고 자체개발한 이슈관리시스템은 -1점으로 계산 해주세요. ^^ 그 이유도 책에 있습니다. 어쨋든 대단히 좋은 개발문화를 가지고 계신 것 같습니다.
빌드를 위해서 maven, nexus, ant등을 혼용해서 쓰는 것은 하나를 쓰는 겁니다. 각각의 목적이 다르죠. 그리고 빌드는 한 회사에서도 여러가지 방법을 사용합니다.
저같은 경우 혼자서 개발을 해도 20점 가까이 나옵니다. 실제로 1,2명이 시작하는 실리콘밸리 스타트업(벤처기업)들도 거의 20점이 나옵니다. 그렇게 해야 개발이 더 빨리 되고 잘되기 때문입니다.
그만큼 기본적인 문화와 저변의 차이가 큽니다.
소규모팀이라도 거의 20점이 나와야 정상적이고 효율적으로 개발이 되는 겁니다. 그럼에도 불구하고 소규모팀에서는 부족한 것이 많아도 개발이 문제없이 되는 것처럼 보이는 것은 소규모이기 때문이지 문제가 없는 것이 아닙니다. 비효율적인 부분이 차지하는 비율이 그렇게 크지 않기 때문입니다. 하지만 조직이 조금만 커지면 금방 문제가 급속하게 커집니다.
10년 가까이 된 작은 게임 회사에 있습니다. 2점 나오네요. 개발 단계에 있는 게임인데 경영진이 생각하는 서비스 시기보다 이미 1년 이상은 늦어지고 있는 것 같아요. 여러가지 원인이 있겠지만 큼직하게 생각나는 것은 팀간에 분단(?)과 서로에 대한 평가에 있어서 배타적인 것. 특정 개발자에 의해 의사 결정이 좌지우지 되는 것. 노력한만큼 돌아오는 댓가가 없다는 것. 오랜 기간 회사가 운영 되다보니 초기 멤버들에 우물안 생각과 행동, 그리고 그러한 것을 타파하려는 의지가 없어보이는 경영진 등이 아닐까 생각됩니다.
이곳에 입사한지 1년을 넘기고 있는데 올해 한해를 더 두고보고 이직을 심각히 고려해봐야 할 것 같습니다. 그렇다고 더 좋은 회사로 갈 수 있는 것도 아니고... 이직 보다는 차라리 해외로 나가는 것에 좋겠다는 생각을 더 많이 하게 됩니다. 물론, 해외로 나간다고 모든 문제가 해결되는 것은 아니겠죠. 언어, 인맥, 학연 등등 아무것도 없는 해외에서 혼자 처음부터 시작해야 하니까요. 그만큼 시간과 노력, 고통이 따르겠지만 제가 경험한(경력 7년차) 한국 게임 회사 현실이 바뀌길 기다리기 보다 해외에서 제 살길을 모색하는 것이 더 빠를 것 같다는 생각이 듭니다.
물론, 개발자로써 제 자신에 대한 반성도 늘 하고 있답니다. 하지만, 반성하고 노력해서 더 개선 시키려 해도 회사가 혼자 어떻게 될 수 있는 개체(?)가 아니다 보니 부디쳐 싸우기 보다 편한 길을 찾아 피해가게 되는 것 같습니다. 그리고 그 결론이 해외인 것 같기도 하구요...
지금 겪고 계신 상황이 우리나라의 다른 대부분의 SW회사의 상황과 크게 다르지는 않습니다. 개발자에게 좋은 회사들도 있지만 많지는 않습니다.
특히나 게임회사는 아주 독특합니다. 게임은 SW 역량보다도 기획역량이 더 중요한 위치를 차지하기 때문이기도 하고 체계적인 개발과는 좀더 거리가 먼것이 현실입니다.
해외로 나간다는 것은 좋은 생각이나 언어와 문화의 걸림돌이 있습니다. 영어를 아주 잘하거나 외국의 개발문화에 아주 익숙해야 합니다. 우리나라에서 7년정도 고생을 했으면 우리나라 개발문화에 익숙해서 해외에서는 적응이 어려울지도 모릅니다. 해외라도 게임회사라면 좀더 적응하기 쉬울 수도 있겠습니다.
우선 게임업계에 계속 있을지를 결정하셔야 하고 다음에 국내에 계속 있을지도 결정하셔야 겠네요. 결정은 본인의 몫이니 잘 결정하기 바랍니다.
2번 빼고 19점인가요? 대단하십니다. ^^ 돈없는 회사는 다 잘해서 20점 나오기 어려운데 여건이 좋으신가 보네요.
2번에 대해서 설명하면 다음과 같습니다. 개발문서에는 여러가지가 있고 Baseline에 들어가는 문서가 있고 Baseline에 들어가지 않는 문서가 있습니다. 여러 문서중에서 Baseline에 들어가는 문서는 많지 않습니다. Baseline에 들어가는 문서는 소스코드와 한쌍으로서 같이 업데이트가 되어야 하는 문서들입니다. 스펙(SRS), 설계서 등이 그 예입니다. 제가 쓴 책에 자세히 설명이 되어 있습니다. 나머지 문서들은 해당 문서를 만들기 위한 Temporary 문서이거나 다른 용도로 사용하는 문서들입니다. 예를들어 기획서, 개발계획서, 테스트 계획서 등은 Baseline에 들어가지 않습니다.
Baseline에 들어가는 문서는 소스코드관리시스템에 들어가서 소스코드와 같이 Baseline을 생성해야 합니다. 그래야 해당 Baseline의 프로그램, 소스코드, 문서가 다 짝을 이루고 그래야 제대로된 형상관리가 됩니다.
십 수년 전에 개발자로 일하던 회사의 점수를 내 보니 12 점 나왔습니다. 일정과 리스크 관리는 PM이 했을 텐데 전 그런 문서를 본 적이 없어서 점수를 먹이지 않았습니다. 의료용 제품을 만들어서 FDA 개발 권장 사항을 따르던 회사였습니다. 실리콘 밸리에 있었는데요... 지금은 M&A되어 없어졌지요... 감사합니다. 옛날 기억이 소록소록 나네요...
좋은 글 잘 읽었습니다.
답글삭제어휴~ 이번에도 10점아래로 점수가 나오네요..
여러 모로 의미있는 테스트라고 생각합니다.
한가지 한국 소프트웨어업계에서 부족한 점이 인력구조인것 같습니다.
대부분의 소프트웨어 개발에 정확한 역활분배가 이루어지지 않고 있습니다.
거의 모든 개발자는 슈퍼 개발자라고만 생각하는 경향이 있습니다.
개인적으로는 "스티브 맥코넬"이 "프로페셔널 소프트웨어 개발"이란 책에서 이야기했듯이 소프트웨어 개발 부분에서도 전문화가 이루어져야 한다고 생각합니다.
전문적인 UI 개발자, 전문적인 업무로직 개발자, 전문적인 테스터, 전문적인 형상관리자, 전문적인 아키텍트, 전문적인 네트워크 관리자 등등..
이런 조건들이 갖추어 진다면 대부분의 회사들이 10점에서 15점은 충분히 넘을 수 있다고 생각합니다.
다만 아직 우리나라 소프트웨어 기업에서 이렇게 전문성 있는 인재를 채용하거나 육성하기에는 우리나라의 소프트웨어 시장규모나 기업의 여건이 녹녹하지 않은 것 같습니다.
어서 빨리 이러한 여건이 충분히 갖추어진 환경이 제공되어 만드신 "소프트웨어 회사의 개발 역량 평가표"에 20점 만점을 받는 기업들이 많아지길 기원합니다.
아무쪼록 오늘도 좋은 하루 보내시구요~ 늘 행복하시길 기원드립니다. ;-)
10점 근처만 되도 우리나라 여건에서 훌륭합니다.
답글삭제미국에서는 one-man company를 해도 각 기능을 구분해서 일을 합니다. 그러면서 필요한 문서도 다 만들죠. 그렇게 하는 것이 주먹구구보다 더 효율적이고 나중에 회사가 점점 커져도 일을 나줘 줄 수 있습니다. 그런데, 우리나라는 그렇게 할 수 있는 훈련이 거의 안되어 있어서 회사가 크나, 작으나 주먹구구이고 큰 회사들은 외국에서 방법론을 들여와서 기계적으로 따라하다가 더 비효율적으로 되곤하지요.
갈길은 멉니다. - -;
안녕하세요~
답글삭제제가 책을 완전히 소화 하지 못해서 생기는 의문일까요?
위에 평가 항목에 대해서 모두 지키면 곧 20점이면 정말로 프로젝트 수행 시 문제가 없나요?
현재 20점이 나오는것은 아니지만, 위 항목들을 다 지킨다고 했을때 결과가 궁금 합니다.
안녕하세요. ^^
답글삭제소프트웨어공학을 소프트웨어 개발에 적용하는 이유는 빠른 시간안에 적은 비용으로 소프트웨어를 만들이 위함입니다. 위 항목들은 그중에서 기초적이고 중요한 지표들을 모아 놓은 것입니다.
각 항목들은 보기에는 그리 어렵게 보이지 않을지 몰라도 하나하나 내포되어 있는 것들은 대단히 큰 것들입니다. 즉 하나하나 지키는 회사와 지키지 않는 회사의 차이는 엄청납니다.
실제로 20점이 나오는 회사는 어떤지 말씀을 드리죠. 이 평가 항목은 소프트웨어 회사의 모든 역량을 체크하지는 않습니다. 가장 기초적인 역량 및 다른 역량들을 미루어 짐작할 수 있는 것들입니다. 글로벌 소프트웨어 회사들은 모두 20점이 나온다고 할 수 있습니다. 또, 20점이 나온다고 무조건 성공하는 것도 아닙니다. 소프트웨어를 제대로 만들 수 있는 기초적인 역량을 갖췄다는 의미입니다. 다른 회사들과의 경쟁에서 우위에 서기 위해서는 이 20가지 이외에 필요한 것이 훨씬 많습니다.
하지만 제가 접한 거의 모든 소프트웨어 회사들은 20점 만점에 10점 미만이었고, 이정도의 기초되 되지 않고서는 글로벌 경쟁은 꿈도 꾸지 못하는 겁니다. 일단 이 평가에서 20점에 이르게 되면 기초를 갖춘 것이고, 이때부터 해야 할 것도 많습니다.
소프트웨어 회사의 개발 역량 평가표 -All of Software- - 조엘 테스트와 비슷하며 20점 만점의 테스트
답글삭제와우,, 글 잙읽었습니다. 저는 계산을 하여 보니 3점이 나오는군요. ㅎㅎㅎㅎㅎㅎㅎ ㅠㅠ
답글삭제안녕하세요. chan님
답글삭제변화가 필요한 상황이네요. ^^
좋은글 잘 읽었습니다.
답글삭제계산해보니 17점 나오네요.
그런데 형상관리나 이슈관리 시스템은 꼭 하나만 써야 하나요?
지금은 하나만 쓰고 있지만 전엔 CVS 형상관리도구나
지라, 버그질라, 멘티스 등의 이슈관리 시스템을 CI도구로는 컨티넘이나 허드슨을 사용했으나
지금은 SVN으로 통합되었고 자체개발한 이슈관리 시스템을,
CI도구는 컨티넘과 허드슨을 사용하고 있습니다.
"꼭 하나"여야만 하는 이유가 있을까요?
사실 통합빌드(CI)를 위한 기술은 CI도구와 더불어 maven, ant등의 기술이 혼용될수 있고
이때 소스코드 백업을 위해 Git + SVN 등 여러 도구를 혼합할 수 있는데 "꼭 하나"하는지에
대해서 궁금해지네요. 물론 아무생각없이 백화점식 도구를 사용하면 안되지만
목적이 명확해서 도구를 혼용한다면 하나보다 더 효율적이지 않을까 하는 생각도 해봅니다.
안녕하세요. 임병인님
답글삭제17점이면 엄청난 점수인데요. 제가 지금까지 만나본 회사중에서 최고점입니다. ^^
특별한 이유가 없다면 하나만 쓰는 것이 정답입니다. 자세한 이유는 제가 쓴 책을 보시기 바랍니다. :)
그리고 자체개발한 이슈관리시스템은 -1점으로 계산 해주세요. ^^ 그 이유도 책에 있습니다.
어쨋든 대단히 좋은 개발문화를 가지고 계신 것 같습니다.
빌드를 위해서 maven, nexus, ant등을 혼용해서 쓰는 것은 하나를 쓰는 겁니다. 각각의 목적이 다르죠. 그리고 빌드는 한 회사에서도 여러가지 방법을 사용합니다.
Git+SVN도 목적을 달리는 하는 것이기 때문에 목적에 맞게 쓰면 됩니다.
전규현님,
답글삭제위의 글 잘 읽었습니다.
저는 현재 sw 솔루션 개발 회사에 근무중인데요...
sw 제품을 개발하는데 있어서 표준 프로세스를 구축하고자 합니다.
하여, sw 개발 프로세스에 관한 컨설팅을 받으려면 어느 회사에 알아 보면 좋을지
혹시 답변 가능하시면 부탁 좀 드립니다.
감사합니다..
안녕하세요.
답글삭제제가 하는 일이 컨설팅이고 SW 개발 프로세스 컨설팅도 한분야입니다.
관심이 있으시면 [email protected]으로 메일 주세요.
감사합니다.
안녕하세요. 전 요즘은 모바일웹을 만들고 있습니다.
답글삭제큰 규모는 아니고요.
빌드나 소스관리, 버그관리 시스템에 대한 용어를 거의 사용하고 있지 않아서
체크문항에 체크된 것이 6개네요.
하지만, 왠지 10점미만에 대한 내용이 좋지 않아서 기분이 썩 좋지는 않네요.
소규모 팀운영에는 10점 미만이라도 문제가 없을듯 한데,
전사적 차원에서 보면 문제가 되겠다는 생각입니다.
암튼 많은 생각을 하게 하는 질문이네요.
언제나 좋은 글 감사히 보고 있습니다.
수고하시고, 건강하세요 ~
안녕하세요. 김흥완님
답글삭제저같은 경우 혼자서 개발을 해도 20점 가까이 나옵니다. 실제로 1,2명이 시작하는 실리콘밸리 스타트업(벤처기업)들도 거의 20점이 나옵니다. 그렇게 해야 개발이 더 빨리 되고 잘되기 때문입니다.
그만큼 기본적인 문화와 저변의 차이가 큽니다.
소규모팀이라도 거의 20점이 나와야 정상적이고 효율적으로 개발이 되는 겁니다. 그럼에도 불구하고 소규모팀에서는 부족한 것이 많아도 개발이 문제없이 되는 것처럼 보이는 것은 소규모이기 때문이지 문제가 없는 것이 아닙니다. 비효율적인 부분이 차지하는 비율이 그렇게 크지 않기 때문입니다. 하지만 조직이 조금만 커지면 금방 문제가 급속하게 커집니다.
당장이라도 필요한 것들을 하나씩 갖춰나가시기를 바랍니다.
감사합니다.
좋은 말씀 감사합니다. 지금 확인했네요.
답글삭제새글이 올라와서요~ ㅎㅎㅎ
그리고, 김홍완 입니다.
오늘도 수고하시고요~
10년 가까이 된 작은 게임 회사에 있습니다. 2점 나오네요.
답글삭제개발 단계에 있는 게임인데 경영진이 생각하는 서비스 시기보다 이미 1년 이상은 늦어지고 있는 것 같아요. 여러가지 원인이 있겠지만 큼직하게 생각나는 것은 팀간에 분단(?)과 서로에 대한 평가에 있어서 배타적인 것. 특정 개발자에 의해 의사 결정이 좌지우지 되는 것. 노력한만큼 돌아오는 댓가가 없다는 것. 오랜 기간 회사가 운영 되다보니 초기 멤버들에 우물안 생각과 행동, 그리고 그러한 것을 타파하려는 의지가 없어보이는 경영진 등이 아닐까 생각됩니다.
이곳에 입사한지 1년을 넘기고 있는데 올해 한해를 더 두고보고 이직을 심각히 고려해봐야 할 것 같습니다. 그렇다고 더 좋은 회사로 갈 수 있는 것도 아니고... 이직 보다는 차라리 해외로 나가는 것에 좋겠다는 생각을 더 많이 하게 됩니다. 물론, 해외로 나간다고 모든 문제가 해결되는 것은 아니겠죠. 언어, 인맥, 학연 등등 아무것도 없는 해외에서 혼자 처음부터 시작해야 하니까요. 그만큼 시간과 노력, 고통이 따르겠지만 제가 경험한(경력 7년차) 한국 게임 회사 현실이 바뀌길 기다리기 보다 해외에서 제 살길을 모색하는 것이 더 빠를 것 같다는 생각이 듭니다.
물론, 개발자로써 제 자신에 대한 반성도 늘 하고 있답니다. 하지만, 반성하고 노력해서 더 개선 시키려 해도 회사가 혼자 어떻게 될 수 있는 개체(?)가 아니다 보니 부디쳐 싸우기 보다 편한 길을 찾아 피해가게 되는 것 같습니다. 그리고 그 결론이 해외인 것 같기도 하구요...
제 생각이 틀리다면 '전규현'님에 따끔한 질타 부탁드립니다.
안녕하세요.
답글삭제지금 겪고 계신 상황이 우리나라의 다른 대부분의 SW회사의 상황과 크게 다르지는 않습니다. 개발자에게 좋은 회사들도 있지만 많지는 않습니다.
특히나 게임회사는 아주 독특합니다. 게임은 SW 역량보다도 기획역량이 더 중요한 위치를 차지하기 때문이기도 하고 체계적인 개발과는 좀더 거리가 먼것이 현실입니다.
해외로 나간다는 것은 좋은 생각이나 언어와 문화의 걸림돌이 있습니다. 영어를 아주 잘하거나 외국의 개발문화에 아주 익숙해야 합니다. 우리나라에서 7년정도 고생을 했으면 우리나라 개발문화에 익숙해서 해외에서는 적응이 어려울지도 모릅니다. 해외라도 게임회사라면 좀더 적응하기 쉬울 수도 있겠습니다.
우선 게임업계에 계속 있을지를 결정하셔야 하고 다음에 국내에 계속 있을지도 결정하셔야 겠네요. 결정은 본인의 몫이니 잘 결정하기 바랍니다.
19점이 나오네요. 2번의 경우는 모든 개발문서가 정말로 소스코드관리시스템에 저장되어야 하는지는 좀 의문스럽습니다. 개발문서나 시나리오, 와이어프레임 기타 등등은 Jira라든가 Wiki, 혹은 팀 내 공유폴더 등의 형태로 관리될 수 있다고 생각합니다.
답글삭제우울한딱따구리님 안녕하세요.
답글삭제2번 빼고 19점인가요? 대단하십니다. ^^ 돈없는 회사는 다 잘해서 20점 나오기 어려운데 여건이 좋으신가 보네요.
2번에 대해서 설명하면 다음과 같습니다.
개발문서에는 여러가지가 있고 Baseline에 들어가는 문서가 있고 Baseline에 들어가지 않는 문서가 있습니다.
여러 문서중에서 Baseline에 들어가는 문서는 많지 않습니다. Baseline에 들어가는 문서는 소스코드와 한쌍으로서 같이 업데이트가 되어야 하는 문서들입니다.
스펙(SRS), 설계서 등이 그 예입니다. 제가 쓴 책에 자세히 설명이 되어 있습니다.
나머지 문서들은 해당 문서를 만들기 위한 Temporary 문서이거나 다른 용도로 사용하는 문서들입니다.
예를들어 기획서, 개발계획서, 테스트 계획서 등은 Baseline에 들어가지 않습니다.
Baseline에 들어가는 문서는 소스코드관리시스템에 들어가서 소스코드와 같이 Baseline을 생성해야 합니다. 그래야 해당 Baseline의 프로그램, 소스코드, 문서가 다 짝을 이루고 그래야 제대로된 형상관리가 됩니다.
소규모일본회사에서 근무하는 1인입니다. 한국회사실정과는 다르지만 체크해본결과
답글삭제11점정도 나오네요. 기본적인 시스템은 갖추어져있고 그것을 따르지만 좀더 구체화된
시스템이 정석화되어 있지않습니다.
제대로 된 시스템만 도입된다면 따르는것은 시간문제인것같습니다.(일본인특성상.)
소프트웨어 개발 팀의 역량을 개발자 역량에 대한 척도없이도 개량화 할 수 있다고 믿는 것이 놀랍군요!!!
답글삭제미국 소프트웨어 엔지니어로 근무중입니다. 17점 나오네요
답글삭제십 수년 전에 개발자로 일하던 회사의 점수를 내 보니 12 점 나왔습니다. 일정과 리스크 관리는 PM이 했을 텐데 전 그런 문서를 본 적이 없어서 점수를 먹이지 않았습니다. 의료용 제품을 만들어서 FDA 개발 권장 사항을 따르던 회사였습니다. 실리콘 밸리에 있었는데요... 지금은 M&A되어 없어졌지요... 감사합니다. 옛날 기억이 소록소록 나네요...
답글삭제