태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

넣는 것 보다 빼는 것이 더 어렵다.

2013/05/14 23:29 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다.


성공하는 회사들의 초기 제품은 간략하고 핵심적인 기능으로 사용자들의 요구를 만족시켰다. 하지만 시간이 흐를 수록 경쟁상대가 많아지고 선두를 유지하거나 따라잡기 위해서 제품은 기능은 경쟁 제품들의 모든 기능을 다 포함하기 시작하곤 한다.


고객이 많아질수록 고객들의 요구사항도 다양해지고 하나의 고객도 놓치기 싫어서 가능하면 모든 요구사항을 신제품에 다 우겨 넣으려곤 하다.


이렇게 온갖 기능이 다 포함된 제품을 우리는 "Kitchen Sink"라고 한다. 설거지통에 닦아야 할 그릇들이 잔뜩 쌓여 있는 모습을 상상해보라.


기본적으로 영업은 한명의 고객도 놓치기 싫어서 무조건 고객의 요구사항을 다 들어달라고 요청을 한다.


이것을 조정해서 새로운 제품의 전략을 수립하는 부서는 마케팅부서이다. 하지만 내 경험에 의하면 우리나라의 많은 소프트웨어 회사들은 마케팅보다 영업에 가깝다. 소프트웨어 제품 전략에서 중요한 것은 많은 기능을 넣는 것보다 얼마나 적은 기능으로 최대한의 고객을 만족시키느냐이다. 경쟁제품을 모두 조사해서 슈퍼세트의 제품을 기획하는 일은 쉽다. 어려운 일은 기능을 빼는 것이다.


기능을 빼는 과정에서 기존의 고객을 잃을 수도 있다. 하지만 이것이 두려워서 "Kitchen Sink" Software를 만든다면 더 큰 것을 잃을 수도 있다. 


하지만 많은 사람들이 기능을 빼는데는 익숙하지 않다. 영업, 마케팅은 물론이고 마음씨 좋은 개발자들이 기능을 빼는 것을 주저하기도 한다. 그러면 제품의 아키텍처는 점점 복잡해지고 회생 불가능한 상태가 되곤한다.


스펙을 적을 때도 지원할 기능 외에 뺄 기능도 잘 기술해야 한다. 스펙에 지원하지 않을 기능을 적는 것은 지원할 기능을 적는것보다 더 중요할 때가 많다. 물론 모든 미지원 기능을 적는 것이 아니고 기존에 있던 기능을 빼거나 누구나 능히 포함될 것으로 생각하는 기능을 뺄때는 꼼꼼히 적어줘야 한다.


그래서 마케팅팀의 역할이 더욱 중요하다고 할 수 있다.


1%의 사용자도 쓰지 않는 수많은 기능을 개발하느라고 개발 비용은 훨씬 많이 들어가고 프로젝트가 망가져가는 것을 흔히 볼 수 있다. 중요한 것은 넣은 것이 아니고 빼는 것이다.


image by Kingfox





저작자 표시 비영리 변경 금지

전규현 프로젝트/요구사항분석

Trackback Address: http://allofsoftware.net/trackback/310 관련글 쓰기
  1. 저는 하위버전 호환성을 유지하는 것이 매우 중요하다고 생각합니다.

    고객사에서 제품을 상위버전으로 업그레이드 했을 때 서비스가 안되는 부분이 생긴다면 이는 재앙에 가깝습니다.

    조엘이 쓴 책에서도 MS 가 하위버전 호환을 유지하기 위해 얼마나 노력을 많이 했는지 언급되었던 것으로 기억합니다.

    새버전 출시 시 마케팅 자료나 영업자료에서 그 기능을 삭제하는 것은 가능하지만 제품에서 물리적으로 삭제가 되는 것은 아니라고 생각합니다.

  2. 공감합니다.

    소프트웨어 업그레이드 시 하위호환을 유지하기 위해서 많은 노력을 들이게 됩니다. 정말 잘 설계를 해서 꾸준히 하위 호환성을 유지하기도 하고 Migration 기능을 제공하기도 합니다.

    여기서 지적하는 것은 기존의 기능을 무작성 빼자는 것이 아니고 전략적인 생각없이 경쟁 회사들의 기능과 특정 고객이 원하는 기능을 잔뜩 포함해서 키친씽크를 만들지 말자는 얘기입니다.

    하위호환성을 유지하면서도 기존 기능을 없애거나 새로운 형태로 진화시키는 일은 종종 있습니다. 결국 기획팀에서 전략을 제대로 수립해야 겠죠.

[공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다.

2013/03/14 19:05 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





소프트웨어를 개발하는데 있어서 가장 어려운 것을 하나 꼽으라면 "요구사항분석"입니다.

소프트웨어를 개발하는데 있어서 가장 중요한 것을 하나 꼽으라도 "요구사항분석"을 선택합니다


하지만 우리나라에서 "요구사항분석" 역량을 제대로 갖춘 개발자를 만나보는 것은 매우 어렵습니다. "요구사항분석"은 교과서를 통해서 배울 수 없고 실전을 통해서 익혀야 하는데 우리나라는 자수성가한 개발자들로부터 시작되고 이어져 왔기 때문에 이를 가르쳐 줄 수가 없었습니다. 대기업에서는 대규모 방법론이나 비싼 툴을 사용하여 "요구사항분석"을 해보려고 하는데 아무리 비싼 골프채가 있어도 골프를 잘치는 것은 딴 얘기이듯이 툴이 이것을 해결해주지는 않습니다.


결국은 요구사항분석의 핵심을 꺠닫고 꾸준히 현실 프로젝트에서 경험을 쌓아가는 것이 유일한 방법입니다. 그래서 그 실전적인 방법을 공유하고자 세미나를 개최합니다. 많은 성원 부탁합니다. 


시간과 장소는 아래 URL 참조하세요. 


http://projectresearch.co.kr/2013/03/11/대한민국-개발자들이여-깨어나라-올바른-sw-개발-방법/


참석하실 분들 댓글 달아주시고, 여기(http://onoffmix.com/event/13214)로 신청하시면 됩니다.




image by naotakem

저작자 표시 비영리 변경 금지

전규현 프로젝트/요구사항분석

Trackback Address: http://allofsoftware.net/trackback/309 관련글 쓰기
  1. 꼭 회사차원의 컨설팅을 받아보고 싶었는데
    개인적인 교육수강기회가 생겨서 너무 좋습니다.
    다음날 교육도 맘에 들더군요..
    신청해버리고 말았습니다... ㅎㅎㅎ

  2. 안녕하세요.
    꼭 듣고 싶은 세미나인데 정원이 차서 참가가 힘드네요 ㅠ
    온오프믹스쪽에 문의해보니 그 쪽에선 결제대행만 하기 때문에 인원 조정은 주최자에게 직접 문의해야 한다고 하시더군요.
    서서 들어도 좋으니 인원을 늘려 주실 수는 없는지 문의드립니다.

  3. 안녕하세요.
    세미나 장소의 공간이 한계가 있고 대기가 40명이 넘어서 인원을 늘려서 해결이 어려울 것 같습니다. 다음 기회에 참여을 하시면 어떨까요?

  4. Blog Icon
    권인호

    네.. 어쩔 수 없지요.
    꼭 가까운 시일 내에 다음 기회가 있기를 희망합니다.
    답변 감사드립니다.

  5. 세미나 잘 들었습니다.
    高僧을 모시고 禪問答 하는 시간 같았습니다.
    어떠한 질문에도 거침없이 답변을 쏟아내시는 모습이 인상적이었고요.
    저도 열심히 SRS의 道 를 닦아서 解脫 에 이르러 보겠습니다.

투명한 개발 문화의 효과

2013/03/05 22:42 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



흔히 투명한 개발이 효율적이고 좋다고 한다. 그 진정한 의미를 알아보자.


투명한 개발이란 개발에 관련된 거의 모든 정보와 지식이 공유되는 것을 말하지만 추가로 내가 강조하고 싶은 것이 따로 있다.


거의 모든 결정의 과정 및 결과가 공개되고 기록되는 것이다. 이것의 효과는 꽤 대단한다. 이슈관리시스템을 이용하여 모든 정보를 공개하는 것도 좋은 방법이다. 결정해야 할 이슈들을 공개하고 결정 과정이 공개되면 근거가 부족한 일방적인 주장을 하기가 어려워진다.


일방적인 주장이라고 하면 특정부서의 입장만 밀어붙이거나 윗사람이라고 해서 일방적으로 우기는 것을 예로 들 수 있다. 영업의 입장, 회사의 비전, 개발 비용등 여러가지를 고려해야 할 결정에 영업의 입장대로만 주장하여 그렇게 결정되면 장기적으로 회사에 손해가 될 수 있다.


또, 2주는 더 걸릴 일을 추가해 놓고 일정을 전혀 손댈 수 없다고 주장을 한다면 그러한 주장이 공개된다면 상황이 좀 달라질 수도 있다. 무조건 우기기보다는 합리적인 해결책을 찾는 시늉이라도 하게 될 가능성이 높다. 그런 상황에도 독선적인 결정을 하고 그런 과정이 모든 직원들에게 공개가 되고 그런 일이 반복된다면 그런 주장을 하는 사람의 능력을 의심하게 될 것이다.


물론 이런 변화는 하루 아침에 일어나지도 않고 모든 정보가 투명하게 시스템에 기록되는 일이 쉽게 이루어지지는 않는다. 수평적인 구조와 성숙한 개발문화를 가지고 있다면 자연스로운 일이지만 그렇지 않은 조직에서의 변화는 쉽지 않고 오래 걸리는 일이다.


이럴 때는 개발팀이 주도하여 개발과정이 투명하게 공개되도록 유도를 하는 것이 좋다. 개발팀 스스로가 최대한 이슈를 등록하고 사소한 요청이나 결정사항도 이슈관리시스템을 통하고 타부서의 사용률이 저조하면 도와줘서라도 타부서 사람들도 점차 끌어들이는 것이 좋다. 경영진의 후원도 필요하지만 개발팀 스스로도 많은 노력을 해야 한다. 


우리가 흔히 모여서 회의를 통해 논의하고 결정하는 것 중 상당수는 시스템을 통해서 가능하다. 사람들이 물리적으로 모이는 것은 매우 많은 비용을 지불해야 한다. 가능하면 시스템을 이용하는 습관을 들이면 좋다. 또한 모여서 결정한 것도 시스템에 등록을 하면 좋다. 이때 최종 결정 사항외에도 그 과정과 누가 무슨 주장을 했는지 핵심적인 것을 요약해서 기록을 해주면 좋다. 이런 것이 일상화 될 때까지는 신경을 써서 노력해보자.


정보와 지식, 의논 내용 등을 기록으로 남기는 것이 습관이 들지 않으면 상당한 부담인 것이 사실이다. 하지만 모두가 어느정도 몸에 벤다면 오히려 더 시간을 절약해주고 효과적이라는 것을 알게 될 것이다.


내가 오늘 주장하거나 결정한 것이 내일 아침에 신문에 나도 나는 떳떳한가? 대부분의 정보가 공개되면 이와 비슷한 효과가 있어서 일방적인 주장이 좀 줄어 들 수 있다. 또한 한번 기록으로 남은 것은 추후 되돌아 봤을 때 언제 잘못된 결정을 했는지도 잘 알 수 있다. 말로해서 사라지거나 메일에 묻혀서 찾기 어려운 것은 그런 역할을 할 수 없다. 물론 모든 것을 기록으로 남기는 것은 불가능하지만 해보면 어디까지 남겨야 하는지 저절로 알게 된다. 걱정할 필요가 없다.


투명한 개발을 꺼려하는 개발팀도 많은 것을 알고 있다. 스펙의 많은 부분이 개발자들 머리속에 있고 뭘하나 알려고 해도 개발자에게 물어봐야 하고 온갖 정보를 숨겨서 개발자가 쥐고 있으면 그것이 곧 파워라고 생각하는 경우도 있다. 물론 단기적으로 맞는 말일 수 있으나 장기적으로는 개발자에게 오히려 손해인 경우가 많다. 회사 차원에서는 장/단기적으로 모두 손해다.


보통 개발팀은 여러가지 불합리한 것들 때문에 고생을 한다. 일방적인 요구사항 추가/변경이나 그럼에도 불구하고 무리한 일정에 많이 시달리곤 한다. 투명한 개발은 여러가지 효과가 있지만 개발팀이 조금더 합리적으로 일할 수 있게 하는 효과도 있다.


스펙을 작성하고 Wiki를 통해서 정보를 공유하는 것외에 모든 결정과정을 투명하게 공개하는 것을 통해서 좀더 효율적인 개발 문화에 한발짝 다가가보자.



image by max_thinks_sees  



저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/308 관련글 쓰기
  1. 의미있는 글.. 잘 읽었습니다

  2. 전 개인 프로젝트나 아르바이트 일을 할때도
    항상 이슈트래커를 사용합니다.
    Ruby 기반의 redmine인데 오픈소스여서 활용도가 높습니다.

소프트웨어공학은 실전이다.

2013/03/04 13:01 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




이 전글에 댓글을 달려다가 좀더 정리를 해야 할 것 같아서 본글로 올린다.


2013/02/27 - [프로젝트/품질관리] - 거의 다 만들었어요.


알파, 베타의 정의를 가지고 이렇게 강하게 주장하는 경우는 처음봐서 약간 당황스러웠다. 독자들은 알아서 판단하겠지만 혼란이 있을 수도 있어서 다시 한번 내 의견을 밝힌다.


나는 20년간 한국, 미국, 대기업, 벤처기업을 다 경험하고 이론과 실전을 다 경험하고 온 국민이 쓰는 소프트웨어 개발에도 다수 참여하고 수많은 소프트웨어 프로젝트를 성공시켰고 여러 소프트웨어의 회사의 역량 개선을 시키고 있고 이런 경험을 책(소프트웨어 개발의 모든 것)으로 쓰고 블로그를 통해서 공유하고 있다. 


소프트웨어 공학은 실전이다. 이론적으로 먼저 정립된 것이 아니라 실전적인 발전을 거듭해오다가 이론적인 정리가 된 것이다. 따라서 보편적인 이론과 원리가 있고 주장이 있으며 회사마다 그 응용이 있다. 물론 모든 회사의 응용이 효율적인 것은 아니다. 대부분의 우리나라 소프트웨어 회사들의 응용이 비 효율적인 이유는 그 원리를 모르고 응용만 해왔거나 스스로 방법을 생각해 냈기 때문에 한계가 있는 경우가 많다.


세상에는 수만가지 종류의 소프트웨어가 있고 그에 알맞는 라이프사이클도 약간씩 다르다. 다른 것이 잘못된 것은 아니다. 따라서 하나의 프로세스나 이론만 들이대고 이대로 따라하면 모든 소프트웨어에 알맞다고 주장하는 것은 틀릴 가능성이 매우 높다. 


이론서를 보거나 Wikipedia를 보더라도 "generally"라는 용어를 주로 사용하는 이유가 그것이다. 


알파, 베타라는 용어도 최초에 한사람이 이를 정의하고 모든 사람들이 이것을 따르라고 한 것이 아니다. IBM에서 최초로 A, B버전을 사용하였고 수많은 회사가 이런 용어를 따라했으며 Microsoft가 이후에 많은 영향을 미쳤으며 수많은 회사들이 이와 유사한 용어를 따라서 써오다보니 어느 정도 정립이 되었을 뿐이다. 각 회사의 프로세스 정의서에 알파, 베타에 대한 정의가 서로 다르며 이것이 틀린 것은 아니다.


제가 컨설팅했던 수많은 회사에서도 알파, 베타 버전의 용어가 비슷은 하지만 미묘하게 약간씩은 다르다. 회사마다 천차만별로 다른 것이 아니고 핵심적인 것은 비슷하지만 약간씩 다른 것이다. 이것이 틀린 것은 아니다. 회사마다 소프트웨어의 성격에 따라서 강조해야 하는 것이 다르고 프로세스가 다르다. 그렇다고 회사에서 개인마다 다르게 사용해서는 안된다. 회사내에서는 동일한 절차와 정의를 사용해야 한다. 회사마다 코딩컨벤션이 다른 것도 그 하나이다.


회사를 옮기면 그 회사의 조직, 프로세스, 규칙을 익혀야 한다. 대부분의 회사가 비슷한 프로세스와 정의를 사용하기 때문에 이를 익히는데 며칠도 걸리지 않는다. 대부분은 그냥 적응한다.


회사마다 다른 극단적인 예를 들면 5년이 걸리는 화상탐사선을 개발할 때와 간단한 Web application은 알파, 베타, RC를 다루는 방법이 다르다. 화성탐사선은 스펙이 완벽하게 정해지고 수정되는 법이 없고 스펙이 바뀐다면 엄청난 크로스체크와 절차가 필요하다. 하지만 간단한 Web application은 많이 다를 것이다.


모든 것은 어떻게 하면 소프트웨어를 가장 효율적으로 개발하느냐에 집중되어 있다. 소프트웨어의 성격에 따라서 회사의 조직, 프로세스, 시스템, 문화등이 비슷은 하지만 조금씩 달라진다. 어떻게 하면 효율적으로 개발할지 고민을 하다보니 여러 라이프사이클이 나오고 방법론도 매우 많다. 그 중에서 개발하는 소프트웨어에 가장 알맞는 방법을 선택해야 한다. 여기서 한가지만 옳다고 주장하는 것도 잘못된 것이지만 비효율적인 방법을 선택하는 것도 안좋다.


우리가 주의할 것은 하나의 경험이나 학습으로 세상의 모든 진리로 착각하면 안되겠다는 것이다. 그래서 나도 글을 쓸때 항상 조심하는 편이다. 또한 다른 사람의견에 빈정대거나 공격하지 않고 건설적인 토론을 하려고 노력한다. 하지만 대중을 상대로 하는 일이라 힘들때가 많다. 교양있는 여러분의 많은 경험을 같이 나누고 싶다.



image by  Israel Defense Forces


 





저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/307 관련글 쓰기

거의 다 만들었어요.

2013/02/27 23:49 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





"거의 다 만들어서 2주후에 개발이 끝나요"


이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다.

개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다.


하지만 이런 대화는 여러 오해를 양산한다.


영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아 있다는 것도 알기도 한다. 하지만 정확하게 언제 고객이 쓸 수 있는 제품이 나오는지는 알 수가 없다.


그래서 우리는 좀더 전문적으로 제대로된 용어를 사용해서 커뮤니케이션을 할 필요가 있다.


우선 개발 단계별로 정확한 용어를 사용하는 것이 필요하다.


"개발"이라는 말은 너무나 모호하다. 사실 스펙을 쓰는 일부터 유지보수 까지 모두 개발이다.

그래서 분석/설계/구현/테스트 등 단계별로 세분화된 단어를 쓰는 것이 좋다.


따라서 "개발이 끝나요"보다는 "구현이 끝나요"가 좋다.


그 다음에는 개발팀에서 만들어내는 버전이 어느 정도 수준인지 표현할 필요가 있다. 내부 테스트를 진행할 수 있는 수준인지 필드테스트를 할 수 있는 수준인지 알려줘야 한다.


일반적으로 이런 수준을 표시하는 용어는 많이들 들어봤겠지만, 알파/베타/RC 등이 있다.


알파버전이란 모든 기능의 구현이 완료되었고 버그는 많지만 Show stopper가 없는 수준을 말한다. 주변에서 "개발이 다 됐어요"라고 말할 때도 자세히 살펴보면 알파 수준도 안되는 경우 많다. 기능이 99% 완료 되었으면 알파가 아닌 것이다. 예를 들어 설치 프로그램은 아직 개발을 안했다던지 간단한 기능의 일부가 미 구현상태면 알파가 아닌 것이다. 


따라서, 미국이나 인도나 어디에서도 알파버전이라고 하면 이 수준으로 이해를 하면 된다. 


그리고 알파버전 테스트에서 발견된 버그를 대폭 수정해서 버그를 많이 줄인 버전을 베타버전이라고 한다. 베타버전은 내부테스트를 하기도 하고 고객을 대상으로 외부 테스트를 하기도 한다. 베타버전은 버그는 있지만 꽤 쓸만한 버전이다.


RC버전은 Release Candidate의 약자로 테스트를 해보고 출시를 결정할 후보 버전이다. 따라서 대부분의 경우 아주 안정적이다. 출시가 결정되면 바로 고객이 사용하는 버전이다. 물론 버그가 없는 것은 아니지만 충분히 안정적이다.


따라서 알파/베타/RC등의 용어를 적절하게 사용해서 개발팀에서 만들어낸 버전이 정확하게 어느 정도 수준인지 전달을 해야 한다.


"2주후에 개발이 끝나요"보다는 "2주후에 알파버전 구현이 끝나요"가 좋다.


좀더 자세히 말하면 "2주후 금요일 오후3시 정각에 알파버전 소스코드 프리즈가 있습니다."라고 하면 좀더 정확한 의미가 전달된다.

개발자들은 3시까지 모든 소스코드를 Commit해야 하고,

빌드팀은 3시가되면 소스코드를 내려받아서 빌드를 하고

테스트팀은 3시쯤 되면 알파테스트를 시작할 준비를 하고 기다리고 있을 것이다.


관리자나 경영자는 당연히 테스트 일정을 알고 있고 언제 출시 예정인지 알고 있다.

이슈관리시스템을 보고 있으면 거의 실시간으로 발견되는 버그와 고쳐지는 버그의 현황을 볼 수 있다. 


하지만 아직도 대부분의 개발 현장에서는 이런식으로 커뮤니케이션이 이루어지지 않고 있는 것이 현실이다. 


알파/베타 등의 용어를 들어봤거나 사용하고 있어도 그 의미를 정확하게 사용하지 않고 있는 경우가 많고 개발자와 영어/관리자/경영자가 그 의미를 똑같이 공유하고 있는 않다. 서로 다르게 생각하고 있으면 커뮤니케이션에 문제가 자주 생긴다.


세계적으로 표준으로 사용하는 용어들이니 표준에 맞게 사용하고 모든 직원이 똑같이 공유를 해야 한다.


그래야 좀더 합리적인 일정으로 개발이 진행된다. 



저작자 표시 비영리 변경 금지

'프로젝트 > 품질관리' 카테고리의 다른 글

QA팀이 필요없다고?  (2) 2013/08/22
거의 다 만들었어요.  (8) 2013/02/27
고쳤으니 테스트 해주세요.  (4) 2013/02/18
우리는 개발자가 테스트해요.  (8) 2009/01/28

전규현 프로젝트/품질관리

Trackback Address: http://allofsoftware.net/trackback/306 관련글 쓰기
  1. Blog Icon
    염구나

    저부터라도 오늘부터 이런 세부적이고 명확한 커뮤니케이션을 해야겠군요. 좋은 글 감사합니다.

  2. 글의 취지는 공감하나, 글에서 쓰신 알파, 베타, RC의 정의도 올바르지 않아 보입니다.

    알파버전은 모든 기능의 구현이 완료된 것이 아니라, feature freeze를 하기 위한 테스트 버전입니다. 즉, 알파 버전 가지고 테스트를 한 후에야 feature freeze가 된다는 겁니다. 상황에 따라 crash가 있을 수도 있고, data loss도 있습니다.
    베타버전은 알파버전을 통한 테스트 후 feature freeze가 되고, feature complete을 한 후 수행하는 테스트입니다. 베타 테스트의 목적은 주로 feature들에 대한 usability 테스트입니다. 그래서 사용자의 피드백에 따라 반영하는 과정을 베타1, 베타2, .. 등 여러 번 거치기도 합니다.
    RC 버전은 Unknown Major Bug가 없는 상태(그에 따라 Known Bug는 있을 수 있음)이며, RC 버전을 통한 테스트를 거쳐 Code Complete을 하는 것을 목표로 합니다. RC1, RC2 등 여러개가 나오는 경우가 있는데, 베타와는 다르게 말 그대로 별도의 후보 Set을 말합니다. 숫자가 높다고 더 좋은 것도 아닌거죠. 이 경우 Known Major Bug를 workaround하기 위한 경우들이 대부분입니다. 회피할 버그의 종류나 workaround 방법이 달라지니 후보 set이 여러개 나오는 거죠.

    위키피디아에 있는 정의라도 잘 읽어보셨으면 합니다.
    http://en.wikipedia.org/wiki/Software_release_life_cycle

  3. 안녕하세요. 안재우님

    의견 감사합니다. 이런 정의를 모르고 썼겠습니까? ^^ 쉽게 풀어서 설명한 것이지요.
    제 책에서는 자세히 설명이 되어 있으니 참고를 하세요.
    릴리즈사이클에 대한 정의도 일반적으로 이렇게 정의를 하지만 회사마다 약간씩 다르기도 하고 실제 프로젝트에서는 이보다 훨씬 복잡한 상황들이 벌어지죠. 알파버전 이후에 기능을 추가하는 경우고 심심치 않게 발생합니다. 원칙에는 어긋나보이지만 그런 경우 회사마다 대처하는 방법이 다르죠. 백과사전에는 모든 답이 있지만 실제 경험을 해보지 않은 사람들은 백과사전을 보고 따라 할 수 있는 것은 아니죠. 그런 맥락으로 대부분의 독자의 눈높이에 맞추고 있다고 생각하시면 되겠습니다.

    대부분의 회사가 이런 단계별 테스트를 하지도 않고 있기 때문에 왜 복잡하게 설명하지 않고 일관된 커뮤니케이션 한 주제에 대해서만 간단하게 설명하고 있는지 이해를 하실 수 있을 겁니다.

  4. 알파버전에는 crash가 있을 수는 있지만 Show stopper가 있어서는 안되는데 그 정의는 빠져있군요. :)

  5. 글쎄요, 쉽게 풀어서 설명하는 것과 각 단계를 구분하는 핵심이 설명되지 않은 것은 좀 다르다고 봅니다. 대부분의 사람들이 알파, 베타, RC 간의 차이가 그냥 버그가 더 적고 안정화되는 것이라고만 알고 있습니다. 그러다 보니, 개발팀에서 제멋대로 갖다 붙이는 경우가 많습니다. 하지만 알파/베타/RC라는 명칭은 원래 개발팀에서 임의로 붙일 수 있는 것이 아니지요.

    항상 베타가 알파보다 버그가 적지도 않습니다. 물론 알파 테스트를 거쳤기에 적을 수도 있지요. 하지만 Feature 변동이 있기에 베타가 오히려 버그가 더 많을 수도 있습니다. 그리고 Known Bug가 아닌 항목들이 베타에서 등장하기도 하지요.

    그리고, 답글을 주신 내용을 보면 이상한 항목이 있는데요,
    '알파 버전 이후에 기능을 추가하는 경우는 심심치 않게 발생합니다. 원칙에는 어긋나 보이지만'이라고 하셨는데, 원칙에 어긋나지 않습니다. 알파 버전의 '개발'이 아닌 '테스트' 이후에야 Feature Freeze가 일어날 수 있으니까요. 테스트도 안해보고 사용자의 피드백도 들은 적이 없는데, 알파 버전이 모든 기능 구현이 완료된 버전이 될 수 없지 않을까요?

    백과사전, 이론, 원칙대로 현실에 모두 반영할 수 없는 것은 맞는데, 이론과 원칙을 잘못 알고 있으면서 현실만을 얘기하는 것도 위험하지요.
    예를 들어, 어떤 프로젝트의 개발팀장이 이 글을 읽고 알파 버전에선 기능 구현이 이미 끝나서 버그 고치는거 빼고 일체 기능 추가나 변경은 못한다라고 주장하면 어떻게 될까요? 사실 알파 단계에서 이렇게 한다는 건 고객의 피드백을 별 그다지 들을 생각이 없는 경우입니다. 프로젝트는 일정 내에 끝낼 수 있을지 몰라도, 고객에게 좋은 평가를 듣거나 시장에서 크게 성공할 가능성이 거의 없다고 봐야죠.

  6. 안녕하세요. 안재우님

    제가 원래 이런 토론을 아주 좋아하지만 이상하게 말꼬리를 잡고 늘어지는 형태로 얘기를 하시는 것 같아서 조심하게 되는군요. "원칙에 어긋나 보이지만"이란 말도 과도하게 해석해서 부풀리는 것 같습니다. 또, 첫번째 댓글에 약간 빈정대는 투가 있기는 하지만 그대로 이해하겠습니다.

    기본적으로 안재우님의 주장은 다 공감합니다. 친절하게 쓰셨으면 더욱 공감했을 겁니다. ^^ 제 독자들도 이런 말꼬리에 회사에서 억지 주장을 하지 않을 거라고 믿고 있습니다. 많은 독자들은 제가 쓴 "소프트웨어 개발의 모든 것"을 읽었거나 오랫동안 블로그를 구독하고 있어서 말꼬리 하나하나 보다는 전체적인 맥락에 공감을 합니다.

    소프트웨어 개발의 큰 원리는 같으나 회사마다 다른 것들도 많아서 하나의 주장만 맞다고 하면 문제가 되는 경우가 있습니다.

    알파버전에 관한 것도 큰 맥락은 같으나 용어와 정책들도 서로 다릅니다. 헌법은 아니죠. Feature freeze라고 하는 곳도 있고, 알파버전에 Spec을 close하는 회사도 있습니다. 고객의 피드백을 알파 이후에 하는 회사도 있고 개발단계에서 Mock up을 가지고 미리 하는 회사도 있습니다. 사실 현실에서는 이보다 100배 더 복잡합니다. 이런 것에 대한 원리를 설명한 글은 안재우님의 참고로 들으신 Wikipedia글이 더 잘 대표를 한 것 같습니다. 그렇다고 제가 항상 Wikipedia를 배낄 필요는 없다고 생각합니다. 20년부터 알파, 베타를 비롯해서 소프트웨어 공학을 사용했고, 미국 실리콘밸래의 회사와도 같은 방식으로 일을 했고 이론과 경험은 충분하다고 생각합니다.

    건설적인 주장과 토론은 환영합니다. 가끔 이런 반응에 대한 우려로 글을 쓸 때도 좀더 신중하게 정리를 해서 쓰고 싶기는 하지만 저도 시간이 그렇게 많은 편이 아니라서 후다닥 글을 쓰는 형태를 바꾸기는 어렵겠네요. ^^

    아무튼 적극적인 반응 감사합니다.

  7. 베타단계에서 사용자의 피드백을 받아서 베타1, 베타2 등을 만들어 내는 것은 안재우님의 경험을 말씀하신 것이 아닌가 생각합니다.
    그럼 베타단계에서 사용자의 의견에 따라서 스펙이 바뀐다는 얘기인데 어쩔 수 없이 그렇게 해야 하는 소프트웨어도 있기는 하지만 스펙을 베타단계에서 바꾸는 것은 많은 비용을 지불해야 하기 때문에 애초에 스펙단계부터 변경을 최소화하기 위해서 잘 작성하는 것이 일반적이라고 볼 수 있습니다.

    소프트웨어 개발 방법론(or 라이프사이클)에는 여러가지가 있기 때문에 베타테스트에서 사용자의 피드백을 반영해서 계속 바꾼다는 것이 틀렸다고 말하고 싶지는 않습니다.

    우리나라의 많은 회사들이 그런 식으로 소프트웨어를 개발하고 있고 그럼으로 인해서 많은 비용을 지불하고 있습니다. 우리나라에서는 흔히 고객은 실제 동작하는 소프트웨어를 보여주기 전에는 피드백을 줄 수 없다고 합니다. 많은 비효율이 여기서 출발합니다.

    제가 많은 대기업, 중견기업를 포함해서 중소소프트웨어 회사에서 요구공학을 가르치고 스펙 작성을 도와줬는데 제대로 스펙을 작성할 수 있는 엔지니어는 2~3%도 안되는 것이 현실이죠. 그래서 이같은 현상이 어쩔 수 없이 벌어집니다. 스펙을 제대로 작성하면 이후 발생하는 변경이 최소화되죠. 방법론에 따라서 스펙 작성방법이 다르기 때문에 꼭 어떻게 작성해야 한다고 주장하지는 않습니다. 하지만 스펙 작성 역량도 없이 이런 저런 방법론만 주장하는 사람들도 많기는 합니다.

    아무는 저는 소프트웨어를 보여주기 전에 스펙단계에서 고객의 요구사항을 충분히 반영할 수 있도록 교육을 하고 있습니다.

    RC 버전은 Unknown Major Bug가 없는 상태라는 것은 발견하지 못한 Major bug가 없다는 얘기인데 이것은 불가능한 것 같습니다. Unknown한 것은 있는지 없는지는 알 방법이 없습니다. 또한 RC는 후보군이기 때문에 Major Bug가 있을 수 있는데 회사에 따라서는 Major bug가 있으면 Release가 허용이 안되는 회사도 있습니다. 또한 한국에서는 많은 회사들이 Critical,Major,Minor,Trivial,Showstopper 등 버그의 숫자만 보고 결정하는 프로세스를 만들려고 하는데 버그의 숫자만 가지고는 판단하기 어렵기 때문에 Go-live회의를 통해서 Release여부를 결정합니다. 실패시 RC2를 만들어 내기도 합니다.

    저는 소프트웨어 공학은 실전이라고 생각합니다. 이론을 잘아는 소프트웨어 공학 교수님들이 소프트웨어는 제대로 개발을 못하는 이유입니다. 따라서 저는 다른사람들의 실전적인 방법에 대해서 비난을 하지는 않습니다. 단지 컨설턴트로서 좀더 좋은 방향으로 개선을 해줍니다. 그렇다고 제가 소프트웨어 공학 이론을 모르는 것은 아니죠. 처음부터 이론을 먼저 공부한 것은 아니고 20년 실전을 해오다 보니 이론을 접할 기회가 많아서 익히게 된 것이죠. 그렇게 쌓이면 원리를 깨우쳐서 이론에서 주장하는 문구 하나하나에 집착하지 않은 상태가 됩니다. 저는 몇몇 분야에서는 원리를 깨우친 상태라고 할 수 있습니다. 그래도 여러 회사의 상황들은 제게 많은 도움이 됩니다.

    앞으로 건설적인 토론이 계속 되면 좋겠습니다.

  8. 안녕하세요. 처음 댓글에서 밝혔듯이 저는 기본적인 글의 취지 자체에는 공감하고 있습니다. 다만 Consensus를 형성하기 위한 전제가 되는 '용어의 정확한 의미를 이해하고 사용'이라는 측면에서의 문제를 지적한 것입니다. 예로 드신 용어가 보편적인 정의와 일치하는 것이라면 제가 애초에 댓글을 달 이유도 없었겠지요.
    계속 말씀하시는 것은 용어에 대한 정의가 '상황에 따라 다르다', '회사에 따라 다르다'라는 건 결국 '개인에 따라서도 달라질 수도 있다'라는 건데, 원 글의 취지와 모순되어 보인다는 생각이 듭니다. 하지만 엄밀히 말하면 정의가 다른게 아니라, 해석과 적용이 다른 것일뿐이 겠지요.

    토론의 정의는 '각각 다른 의견을 말하면서 논하는 것'인데, 의견이 같아 공감하는 부분은 이미 얘기했고, 다른 의견에 대해 논하는 것을 원치 않으신듯 하니 저 역시 더 이상 토론을 진행할 것이 없을 것 같습니다. 그에 따라 '원래 정의가 뭐라고 되어 있든, 최소한 조직 내에서는 동일한 것으로만 맞추면 된다' 정도가 원래 글의 취지였다고 이해하도록 하겠습니다. 그럼 이만..

고쳤으니 테스트 해주세요.

2013/02/18 10:13 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





여기 두가지 테스트 방법이 있다. 우리 회사는 어떤 방법을 사용하고 있나 생각해보자.


첫째, 테스트 도중에 버그를 고쳐서 좀더 안정된 버전을 테스트팀에 계속 전달하는 방식이다.

테스트 한사이클을 도는데 2주일이 걸린다고 생각해보자. 테스트 기간내내 테스트 팀은 버그를 지속적으로 발견하여 보고를 할 것이다. 개발팀은 동시에 버그를 수정한다. 그리고 다음날 개발팀은 테스트팀이 보고한 버그를 많이 수정한 새버전을 테스트팀에 전달한다. 


테스트 팀은 새버전을 가지고 어제 테스트한 시점의 다음 단계부터 또 테스트를 진행한다. 이렇게 테스트 기간 내내 여러번 새버전을 받는다.


두번째 방법은 다음과 같다. 테스트가 2주가 걸리면 2주 동안 테스트 팀은 새버전을 절대로 받지 않고 한 버전을 가지고 테스트를 완전히 종료한다. 개발팀은 버그를 계속 고치지만 새 버전을 테스트 팀에 전달하지 않는다.


어느 방법이 더 효율적으로 보이는가? 많은 회사들이 첫번째 방법을 사용하고 있다. 믿기 어렵겠지만 사실이다. 첫번째 방법은 큰 문제가 있다. 테스트 기간 도중에 테스트 팀이 새로운 버전을 받으면 이전에 테스트 한 내용이 무효가 된다. 여기서는 그걸 무시하고 계속 테스트를 했기 때문에 테스트가 끝나도 끝난 것이 아니다.


그럼에도 첫번째 방법을 사용하는 이유는 있다. 도저히 테스트 할 수 없을 만큼 불안정한 제품을 테스트 해달라고 전달한 경우이다. 그래서 테스트 팀과 적당히 테스트를 하면서 차츰 안정화를 시켜가는 것이다. 이런 품질의 제품은 테스트를 할 필요가 없다. 이 경우는 테스트 팀을 개발팀의 딱까리로 생각하는 것이다. 


원래 테스트를 진행할 수 없을 정도의 제품을 테스트팀이 받으면 테스트를 중단하고 개발팀으로 다시 돌려보내야 한다.


이렇게 비효율적인 테스트가 우리 주변에서 흔히 벌어지는 이유의 원인 따지고 들어가면 앞단계인 분석과 설계가 엉망이거나 없기 때문인 경우가 많다. 


제품의 품질을 유지하기 위해서는 분석/설계도 중요하고 전문적인 테스트를 해야 한다. 대충 개발하고 테스트팀이 개발팀을 도와주는 형태로는 평생 주먹구구식 개발에서 못벗어나고 비용과 시간도 많이 들뿐만 아니라 개발팀은 잦은 야근에서 벗어나기도 어렵다.


앞으로 테스트에 관한 얘기를 좀더 쉽게 풀어서 써보도록 하겠다.


image by cseward

저작자 표시 비영리 변경 금지

'프로젝트 > 품질관리' 카테고리의 다른 글

QA팀이 필요없다고?  (2) 2013/08/22
거의 다 만들었어요.  (8) 2013/02/27
고쳤으니 테스트 해주세요.  (4) 2013/02/18
우리는 개발자가 테스트해요.  (8) 2009/01/28

전규현 프로젝트/품질관리

Trackback Address: http://allofsoftware.net/trackback/305 관련글 쓰기
  1. 아직 댓글이 없네요.
    일등...

    테스트에 대한 글들을 많이 기다리고 있겠습니다.

  2. 안녕하세요, 자주 블로그글을 유용히 읽고 있는 독자중에 하나입니다.
    개발자가 만든 코드의 테스트를 결국 누가 하는가인것 같습니다만,
    [우리는 개발자가 테스트해요..] 라는 글과 상충되는 느낌을 받았습니다.
    개발자가 유닛테스트를 자동화해서 거치더라도 결국엔 누군가는 사람이 테스트를 해봐야 할텐데요,
    그것이 테스트부서나 팀내 테스트인원이 아니면 누가 해야할련지요?
    (결국 팀내 테스트인원이라면 팀내 테스트인원은 개발자의 딱까리(본문의 표현;;)가 될것같습니다.. ㅠ)

  3. 안녕하세요. 저도 기억이 잘 안나서 옛날 글을 읽어봤는데 어느 부분이 상충되는지 발견을 못했습니다. 좀더 자세히 찝어주시면 제가 아는한 자세히 설명드리겠습니다.
    과거의 글은 테스트팀이 없어서 발생하는 문제를 지적했고, 이 글은 테스트 프로세스 중 문제가 되는 경우를 설명했습니다.
    질문하신 내용의 요지는 테스트인원을 어디에 두느냐인 것 같습니다.
    여러 경우를 많이 봤지만 테스트인원이 개발팀내에서 개발팀장의 지휘를 받는 경우를 종종 봤습니다. 항상 그런 것은 아니지만 개발자의 딱까리가 되는 경우가 많더군요.
    그래서 테스트팀은 별도의 팀이나 부서로 두는 경우가 많습니다. 물론 순수 SW인가? HW에 탑재하는 Firmware인가에 따라서 약간씩은 효율적인 테스트 조직이 다르기 때문에 상황에 따라서 잘 판단해야하지만 테스트팀은 전문성을 발휘할 수 있도록 조직적인 배치를 하는 것이 좋습니다.

  4. 관계자들이 깊이있게 곱씹을만한 글이네요.
    저도 예전에 테스트 업무만 맡은 적이 있어서요.
    그때도 QA부서가 제품의 출시 권한이 있어야 한다는 화두가 있었지만 실제적인 권한은 미미했지요.
    저도 개발자이지만 아직 기본적인 문제에서도 버그가 발생하는 것에 부끄러움을 느끼지 못하는 개발자들이 있었죠. 자기 프로그램은 자기 얼굴과도 같다고 생각합니다.

인해전술이 오히려 프로젝트를 망친다.

2013/02/11 23:31 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed


일정이 촉박하다고 프로젝트를 빨리 끝내고 싶은 마음에 프로젝트 초기부터 대거 인력을 투입하면 오히려 프로젝트를 망칠 가능성이 더 높아진다.


프로젝트 초기에 분석/설계 단계에는 그렇게 많은 인력이 필요하지 않다.


많은 인력을 분석도 안된 프로젝트에 투입을 하면 놀 수 없는 개발자들이 인터페이스도 정의가 안된 모듈이나 라이브러리를 만들기 시작한다. 이것들 중 대부분은 나중에 다시 만들어야 하고, 이것들을 버리기 아까워서 어떻게든 활용하려고 버티다보면 소프트웨어의 아키텍처가 점점 이상하게 된다.


많은 인력이 투입되는 단계는 구현단계이며 핵심 구현 인력들이 분석/설계 단계에 리뷰어로 참석할 수는 있다.  일정이 촉박하면 분석/설계를 최대한 빨리 끝내고 할일의 범위와 아키텍처를 명확히 한 후에 인력을 투입해야 한다.


필요한 라이브러리를 개발하지 말고 상용라이브러리를 구매하는 것도 일정을 단축하는데 도움이 된다.


가장 안좋은 방법이 프로젝트 초기에 시장통처럼 개발자를 잔뜩 투입하는 것이다. 소프트웨어 개발을 잘 모르는 경영자들이 이런 실수를 종종 하곤 한다.


우리 주변에서 1년짜리 프로젝트인데 10명의 개발자가 투입되면 10명이 12달동안 계속 같이 일하는 경우를 흔히 볼 수 있다. 이렇게 일정 투입 계획이나 현황만 보아도 개발이 얼마나 주먹구구식으로 진행되고 있는지 알 수 있다. 10명의 개발자가 투입되는 프로젝트도 초기 2,3개월 또는 3,4개월동안은 분석/설계를 담당하는 1,2명만 필요하다. 이 프로젝트에서 분석/설계를 담당한 엔지니어는 많은 개발자가 투입되는 구현기간에 같이 구현에 참여할 수도 있고 다른 프로젝트에서 또다시 분석이나 설계를 담당할 수 있다.


이렇게 인력이 효율적으로 순환이 되면 훨씬 적은 인력과 비용으로 많은 프로젝트를 효과적으로 진행할 수 있게 된다.


인해전술로 많은 인력을 투입하는 방법은 해당 프로젝트를 망치는 방법일 뿐만아니라 회사 전체적으로 효율적인 인력운영을 할 수 없게 만든다. 


image by   Boston Public Library



저작자 표시 비영리 변경 금지

전규현 프로젝트/일정

Trackback Address: http://allofsoftware.net/trackback/304 관련글 쓰기

1:10:100 rule

2013/02/05 22:00 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 "1:10:100 rule"이다.


성숙한 개발문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 대부분의 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다.


소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다.


그 1:10:100 rule을 설명한 그래프가 아래에 있다.



요구사항이 스펙을 작성하면서 바뀌면 "1"이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 "368"배의 비용이 들어간다.

요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 시간이 흐를수록 비용은 기하급수로 증가를 한다.


따라서 기획이 제대로 되어야 하고 분석 설계가 적절하게 잘되어야 하며 한창 개발중에 기획이 바뀌거나 요구사항이 바뀌면 그 수정 비용은 엄청나다는 것을 알야 한다.


말은 쉽지만 이를 진정으로 꺠닫고 실천하는 회사나 개발자를 만나는 것은 쉬운 일이 아니다. 


사실 개발자들은 기획에서 정확한 요구사항을 주지 않는 다거나 나중에 요구사항을 바꾼다고 불평이 많다. 하지만 많은 경우 불평은 하지만 그것을 현실로 받아들이고 스스로 이를 개선하려는 노력은 별로 하지 않는다. 오히려 상황이 그러니 분석, 설계를 제대로 하지 않고 대충 개발하다가 나중에 바꿔달라고 하면 또 대충 받아들여서 개발하고 이런 악순환을 반복하곤 한다.


이런 것을 극복하기 위해서 여러 방법론이 나오기도 하고 최근에는 Agile이 각광을 받고 있지만, 이런 방법론이나 기법으로는 이를 해결할 수는 없다. 정공법외에는 방법이 없다. 기획을 제대로 하고 분석 설계를 효율적이고 적절하게 하는 것이다. 또한 그 과정에서 모든 관련자가 책임을 지고 검토를 해서 문제가 없게 해야 하면 나중에 딴소리를 하거나 바꿔달라고 하면 안된다. 정말 중요한 변경 요청이 아니면 다음 버전으로 미루는 것이 좋은 전략이다.


전 임직원이 1:10:100 rule을 진정으로 깨닫고 있다면 글로벌 소프트웨어 회사가 될 수 있는 잠재력이 충분히 있다고 할 수 있다.


image by Pokey's Dad







저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/303 관련글 쓰기

티끌모아 태산 (개발 시간 절약하기)

2013/01/30 21:12 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




성숙된 개발문화를 가지고 있는 회사는 개발 절차가 아주 효율적으로 진행된다.


하지만 그렇지 않은 회사들은 불필요하게 낭비하는 시간이 아주 많다. 10초에서 몇십분까지 자잘한 시간을 낭비해서 이것들을 합치면 어마어마한 시간이 낭비된다.


시간을 꼭 사용해야 할 중요한 곳에는 아끼지 말고 시간을 써야 한다. 하지만 자동화를 하거나 시스템이 커버를 할 수 있는데 사람이 반복적으로 하고 있거나 과도한 안전장치를 갖춘 프로세스로 인해서 비효율적으로 시간을 낭비하는 경우가 정말로 많다.


10초, 1분이라고 별것 아닐 것 같은 시간이 모이면 생산성은 10%, 20%, 50% 떨어지게 된다.


소프트웨어 개발은 워낙 복잡하기 때문에 이렇게 10초, 1분씩 낭비되는 시간을 최대한 제거해 나가면서 개발을 지속적으로 효율적으로 발전시켜나가는 노력이 필요하다.


회사마다 여건이 조금씩 다르지만 몇가지 예를 들어보겠다.


10초라도 낭비하면 아까운 시간들이다.


  • 빌드가 완전 자동화가 되어 있지 않아서 소스코드를 빌드할 때마다 약간이나마 중간에 수작업이 들어가는 시간 - 빌드는 완전 자동화를 구현해야 한다. 당연히 Command line으로 빌드가 되어야 하고 한번의 Enter로 최종 설치본까지 생성이 되어야 한다.
  • 이슈(버그)관리시스템을 잘 관리해보고자 너무 많은 커스텀필드를 넣어서 이슈(버그)를 등록할 때마다 몇초씩 더 걸리는 시간 - 적당한 커스트마이징은 필요하지만 과도함은 삼가해야 한다.
  • 이슈관리시스템이 있는데 보고나 관리를 위해서 별도의 자료를 만드는 시간 - 이슈관리시스템을 이용하면 원하는 View로 원하는 정보를 실시간으로 볼 수 있다. 관리자도 보고를 기다리지말고 직접 이슈관리시스템을 봐야 한다.
  • 여러벌의 Branch에 같이 존재하는 버그를 동시에 고치기 위해서 수작업을 할 때 - SCM의 Merge기능을 믿지 못하거나 기능을 활용할 줄 몰라서 수동으로 Merge를 하는 행위는 정말 시간 낭비이다. 제대로만 사용한다면 SCM의 Merge기능은 막강하고 99.9% 믿을만하다. 수작업이 아니고 최종적인 확인 정도만 해도 되는 경우가 대부분이다.
  • 개발자들의 주간 보고서 작성하기 - 이부분은 약간 논란의 이슈가 있다. 정말 간단한 주간보고서는 큰 무리가 없지만 부담스러울 정도의 주간보고서는 개발자들이 작성하지 않는 것이 좋다. 개발자들의 업무 기록은 이슈관리시스템 등에 다 남아 있다. 관리자는 개발자를 괴롭히지 말고 스스로 시스템을 보면 된다. 물론 기반시스템들이 잘 구축되어 있어야 한다.

이 외에도 코딩시 일반 업무시 절약할 수 있는 시간음 무궁무진하다. 이런 시간을 꾸준히 찾아서 제거해 나가는 노력이 필요하다.

image by  Big Swede Guy




저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/302 관련글 쓰기
  1. Blog Icon
    이정훈

    좋은글 항상 고맙습니다. 글을 읽으면서, 이제까지 운좋게 아무문제 없이 개발해 왔었구나하고 안도하며 반성합니다.

  2. 좋은 글에 영향은 많이 받았습니다. 빌드 완전 자동화를 사내에서 추진 중에 있고, 덧붙여 어떻게 하면 빌드 속도를 빠르게 할 수 있을지 고민 중입니다.

재택근무가 가능한가?

2013/01/22 11:06 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





우리 주변에는 비효율적인 개발 환경을 가지고 있는 회사들이 매우 많다. 상상외로 많다. 


스스로의 회사는 어떤가 생각해 보자. 나름대로 효율적인 개발문화를 가지려고 많은 노력을 해왔을 것이다. 그래서 과연 우리회사가 제대로 효율적인 개발문화와 환경을 가지고 있는지 궁금할 것이다.


이렇게 비교를 해보자. 당장 우리 회사의 개발자들이 모두 재택근무를 하면 어떻게 될까? 그리고 일주일에 딱 하루만 회사에 나와서 필요한 회의를 한다면...


대부분은 그렇게 해서는 회사가 돌아가지 않을 것이라고 생각할 것이다. 


그렇다면 아직 먼 것이다. 소프트웨어 회사가 효율적인 프로세스와 시스템을 갖추고 개발 역량과 성숙한 개발문화를 갖추고 있다면 얼굴보고 해야 할 일이 그렇게 많지가 않다. 일주일에 몇시간이면 충분하다.


일단 회의가 너무 많은가? 회의는 정말 비효율적이다. 꼭 필요한 회의가 아니면 대부분의 회의는 시간을 비효율적으로 사용하며 많은 인원의 시간을 한꺼번에 소비한다. 대분은 시스템으로 커버가 가능하다.


개발할 때마다 얼굴을 보고 설명을 해줘야 하는가? 주먹구구식 개발의 대표적인 현상이다. 효율적으로 작성된 SRS가 있다면 설명해줘야 하는 시간은 수십분의 일로 줄어든다. 줄어들어야 제대로 작성된 SRS이다.


수시로 물어봐야 해서 항상 자리에 붙어 있어야 하는가? 성숙한 개발 환경에서는 프로세스, 시스템, 문서등이 이를 대신한다. 


실제 이런 경험이 있는 않은 경우라면 즉, 기존의 적당한 주먹구구와 공력에 의해 개발을 했거나 비효율적인 프로세스를 적용해서 나쁜 기억만 가지고 있는 경우라면 이렇게 개발하는 것이 더 비효율적인 것이 아니냐고 반문을 하곤한다. 그렇게 하려면 문서를 너무 많이 적어야 하는 것이 아닌가? 프로세스나 시스템이 오히려 더 거추장스러운 것이 아닌가? 의문을 품을 수 있다.


책이나 인터넷을 보고 프로세스를 따라한 부작용이기도 하다. 태권도장에 가서 직접 태권도를 배우면 금방 되는 것이 책을 보고 배우면 대부분은 제대로 배우지 못하고 효율적이지 못한 것과 비슷하다.


프로세스, 시스템, 문서 모든 것은 개발을 빠르고 효율적으로 하기 위해서 존재하는 것이고 그보다 더 이상 이하여서도 안된다. 이는 제대로된 경험으로만 터득이 가능하다. 따라서 경험자나 전문가의 가이드가 필요한 것이다.


나름대로 개발 환경을 개선하기 위해서 열심히 노력한 경우라도 재택근무가 가능한 수준이 아니라면 아직 갈 길이 멀다는 것을 명심하자.


이제 효율적인 개발에 한발을 내딪였을 뿐이다.


image by  edgeplot

저작자 표시 비영리 변경 금지

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/301 관련글 쓰기
  1. 회의라는 것을 4시간 30분 하다보니 뼈저리게 느껴져요. 헤헤헤 T_T

개발 경쟁력과 실속없는 화려한 보고서

몇 년 전 C사에서 있었던 일이다. C사가 그동안 진행했던 프로젝트를 경영진에게 보고하기 위해서 직원들이 보고서를 만들 때였다. 그런데 직원들 보고서가 최소 1주일 전에 완성 되어야 한다는 것이다. 경영진이 보고서를 매우 까..

한국에는 가짜 CTO가 많다

소프트웨어 회사에서 가장 중요한 한 사람을 꼽으라고 하면 단연 CTO다. 회사 전체 기술의 총 책임자이며 기술 비전과 로드맵을 이끄는 핵심이다. 회사 비즈니스 전략을 기술에 녹여내는 중추 역할을 한다. 회사 기술을 속속들이..

SW개발, 착한 리더보다 독한 리더가 낫다

몇년전 A사에서 이슈관리 시스템 도입에 대해서 경영자와 의논한 적이 있다. A사는 이슈관리시스템을 사용하고 있지 않았고 버그만 엑셀 파일로 관리하고 있었다. 이슈관리시스템이 꼭 필요한 상황이었고 당장이라도 도입해야 했었다...

개발자에게 재택 근무가 필요한 이유

과거 서울 남부의 경기도에서 소프트웨어 개발자를 채용할 때였다. 서울에서 별로 멀리 떨어져 있지 않은 경기도에 있는 곳인데도 많은 지원자들이 거리상의 문제로 지원을 포기 했고, 특히 서울 북부에 사는 사람들은 인터뷰 시에도..

SW업계에는 망치를 만드는 사람이 많다

누군가 빌딩을 만드는데 망치도 못도 다 만들어 쓴다고 하면 어떤 생각이 드는가? 빌딩을 만드는 사람은 망치와 못은 사다가 쓰는 것이 훨씬 낫다는 것을 누구나 알고 있다. 하지만 소프트웨어 업계에서는 망치와 못을 직접 만들어서..

평등한 토론이 SW혁신 만든다

소프트웨어에서 창의적인 혁신은 천재 한 사람의 머리에서 나오는 것이 아니다. 여러 직원들의 격 없는 평등한 토론에서 탄생하는 것이다. 이런 토론 문화 없이 혁신적인 소프트웨어가 탄생하기는 어렵다. 이는 비단 소프트웨어만의 문..

할아버지 개발자를 만나고 싶다

외국 소프트웨어 회사에서는 할아버지 개발자들을 종종 볼 수 있다. 현재도 프로그래밍을 하고 있는 진짜 개발자들이다. 우리나라가 개발자들은 이런 할아버지 개발자를 만나보거나 이야기를 전해 들으면 많이 부러워한다. 대부분의 개발..

똑똑한 개발자를 찾기 위한 인터뷰 전략

나는 오랫동안 많은 개발자 인터뷰에 참석했다. 여러 소프트웨어 회사에서 개발자 인터뷰를 어떻게 진행하는지 들을 수 있는 기회가 있었고 회사의 관계자 대신 면접관으로서 기술 인터뷰를 진행한 경험도 많다. 그래서 소프트웨어 업계..

美 SW 힘은 평등한 호칭 문화에서 생겼다

필자는 지금까지 소프트웨어 조직에는 수평적이고 자율적인 문화가 필요하다고 했다. 하지만 수직적이고 상명하복 식 조직문화를 없애고 평등한 토론에서 오는 창의적이고 효율적인 개발문화를 만들고 싶어도 넘기 힘든 큰 장애물이 있다...

여자 개발자가 희망이다

소프트웨어 회사를 포함해서 많은 기업들이 개발자가 부족하다고 아우성이다. 이렇게 개발자가 부족하게 된 이유는 열악한 개발 환경에 따른 뛰어난 개발자들의 이탈과 저급개발자 양산 등 여러 환경, 정책적인 문제가 있지만 여자 개발..