소프트웨어 개발 썸네일형 리스트형 레퍼런스 있어요? 컨설팅을 하다보면 종종 듣는 질문이 레퍼런스 있냐는 말입니다. 또 이걸 시행하면 시행전보다 몇%의 생산성의 향상을 가져오는지 수치로 알려달라고 하는 사람들도 있습니다. 히딩크가 한국에서 와서 기초 체력훈련에 집중할 때 반대 했던 많은 사람들처럼 소프트웨어를 개발하기에는 너무나 기초가 취약한 수많은 기업에서 아주 기초적인 것들을 도입할 때도 종종 이런 말을 듣게 됩니다. 레퍼런스는 Global 소프트웨어 회사 전부이고, 생산성 향상을 논할 수 없을 만큼 기초적인 것이다라고 말을 해야 하지만, 그렇게 얘기를 하면 기분이 나쁠 수 있으므로 애둘러서 말해야 합니다. 아직도 국내 소프트웨어 개발 환경 및 역량 수준이 Global 수준과 너무나 큰 차이가 나는 것이 현실입니다. 레퍼런스를 따질 때가 아니고 기초부터.. 더보기 악순환 vs. 선순환 지난번 글 (이 바닥을 못 벗어 난다.)의 추가 글입니다. 회사가 Risk가 큼에도 불구하고 Domain 지식이 점점 더 매달릴 수 밖에 없는 이유와 선순환을 하려면 어떻게 해야 하는지 좀더 현실감 있는 예를 보여주려고 합니다. 회사마다 상황이 모두 다르기 때문에 각자의 상황과 1:1로 다 일치하지는 않지만 참고하실 수는 있을 겁니다. 그럼 악순환과 선순환에 대해서 알아보죠. Domain 지식에 점점 매달리게 되는 악순환의 고리 주먹구구식 개발 개발자에 의존한 코딩 중심의 개발 주도 없거나 빈약한 개발 프로세스 및 개발 문서 회사의 지식은 개발자 머리 속에 보관 개발자 간 지식의 공유가 어려움 후배 개발자들에게 지식 전달이 잘 안됨 프로젝트가 커질수록 협업이 점점 어려워짐 점점 더 경험 많은 개발자에 의.. 더보기 나는 혼자가 아니다. 지금 내가 생각하고 행동하는 것은 나 스스로의 힘이 아닙니다. 과거의 수많은 대가들이 이룩해 놓은 지식, 경험과 지혜를 간접적으로 배우면서 자라온 내가 있고 그 바탕 위에 내가 존재 합니다. 이런 성현들의 지식이 없다면 지금의 내가 존재 할 수 있을까요? 원시인과 별 차이 없는 내가 있겠죠. 소프트웨어를 개발하다 보면 수많은 문제에 부딪히는데 그 대부분은 이미 과거에 소프트웨어 개발의 대가들이 다 겪은 후에 그 해결책을 다 만들어 좋은 것들입니다. 그렇지 않고 소프트웨어 역사상 처음 발생하는 이슈는 거의 없습니다. 그런데 많은 개발자들의 개발 행태를 보면 마치 최초의 선구자 같이 행동을 합니다. 과거에서 배우지 않고 자신의 지식과 경험 테두리 안에서 별 희안한 방법들을 생각해 냅니다. 피아노를 배우려고 .. 더보기 거만한 속빈 강정 소프트웨어 개발 경험도 개발자가 미국 실리콘밸리의 소프트웨어 회사에 입사해서 5년이면 배울 수 있는 것(소프트웨어를 개발하는 방법)을 우리나라에서는 10년, 20년 아니 30년을 소프트웨어만 개발해도 배우지 못합니다. 오히려 이런 경험 많은 고참 개발자들은 배울 수 있는 기회가 눈앞에 와도 배울 수가 없게 됩니다. 책을 하나 봐도 대부분 아는 내용이라고 저자를 평가 절하하지만 아는 수준이라는 것이 용어 한번 들어보고 샘플 좀 사용해 본 정도인 경우가 대부분입니다. 예를 들어 소스코드관리시스템에 대한 내용을 봐도 내가 대형SI회사에서 10년 넘게 개발을 했는데, 이런 것을 모를까봐?라고 생각하지만 고작 소스코드 백업 받듯이 저장하고 태깅 좀 한 정도 가지고 소스코드 관리를 제대로 하고 있다고 착각합니다. .. 더보기 다 만들었어요. 이제 테스트만 하면 되요. 소프트웨어를 개발하는 회사에서는 자주 듣는 말입니다. 그런데, 이 테스트가 언제 끝날지 모르는 경우가 많습니다. 소프트웨어 개발 컨설팅을 하면서 정말 놀란 것 중의 하나가 대부분의 회사가 릴리즈 시 "알파", "베타", "RC", "GA", "FCS"와 같은 단계를 거치지 않는 다는 것이었습니다. 대부분이 알파수준의 소프트웨어를 만들어서 만족스러울 때까지 테스트와 수정을 동시에 병행한다는 것이었습니다. 이는 큰 회사나 작은 회사나 별 차이가 없었습니다. 개발을 단계적으로 진행하지 않는 회사는 업무와 일정에 대한 정교한 구분 없이 일을 진행하다가 적당한 시점에서 한번의 테스트를 통해 제품을 완성하려고 합니다. 이를 빅뱅(Big bang) 테스트라 하는데 이 방법이 운 좋게 개발 기간을 단축시켜 줄지도 모른.. 더보기 소프트웨어 공학이 왜 필요하지? 복잡하기만 한데... 소프트웨어 공학 블로그를 운영하고 있으면서도 전면에는 소프트웨어 공학이라는 말을 사용하고 있지 않습니다. 그 이유는 소프트웨어 공학은 막연하고 왠지 모르게 문서도 많이 만들어야 할 거 같고, 절차도 엄격히 따라야 할 것 같아서 부담스러운 느낌을 줄 수 있기 때문입니다. 이것이 다 소프트웨어 공학에 대한 오해에서 비롯된 것 같습니다. 이미 유행이 한번 쓸고 지나간 CMMI나 외국의 유명한 방법론들을 도입했다가 실패한 경험과 소문들 때문일 겁니다. Naver 백과사전에서 소프트웨어 공학을 찾아봤습니다. 다음과 같이 설명되어 있더군요. 요약 컴퓨터 소프트웨어의 계획·개발·검사·보수·관리 등을 위한 기술과 그것을 연구하는 분야이다. 소프트웨어의 규모가 커지고 복잡해짐에 따라 공학적인 접근으로 구조화 프로그래밍을.. 더보기 효과적인 버그 처리 방법 HannaKim님의 이 버그를 누구에게 넘겨 줄 것인가? 라는 글에 대한 의견을 적어보려고 합니다. 의견이라기 보다는 주욱 해오던 방법입니다. 너무 당연한 얘기일수도 있습니다. 개발자에게 버그를 할당하여 처리하는 방법은 여러가지 형태가 있습니다. 주먹구구식으로 개발자에게 직접 버그가 보고되고 처리되는 형태부터 철저한 Workflow를 따라서 관리자가 담당개발자를 할당해서 처리하는 방법까지 다양합니다. 여기서는 자질구레한 기타 방법은 제외하고 정상적으로 Bug Tracking System를 사용하면서 체계적으로 버그를 관리하고 해결하는 방법 내로 국한을 해서 설명하도록 하겠습니다. 다른 방법을 사용하고 있다면 심각성을 깨달으시고 빨리 방법을 고치셔야죠. 개발팀의 규모나 프로젝트의 종류는 천차만별입니다. 기.. 더보기 오늘도 밤을 세워야 하는 개발자 (야근 탈출) 옛날부터 내려오는 경영자들이 믿고 있는 미신이 있습니다. "개발자의 Output은 근무시간의 양에 비례한다." 말은 아니라고 하면서도 밤에 사무실이 텅 비어 있으면 개발자들이 군기가 빠졌다고 생각하고 주말에 누가 나와서 일하나 확인하러 가끔 사무실에 들르는 사람들이 경영자입니다. 실제로 근무시간에 성과가 비례하는 개발자들이 있다면 공장에서 벽돌 찍어내는 것과 다를 바가 없겠지요. 이 미신은 믿기 싫지만 자꾸 저절로 손이 가는 새우깡처럼 믿게 되고, 회사 조직에서 위로 올라갈수록 더 맹신하게 되나 봅니다. 이러한 이유로 어쩔 수 없이 또는 습관적으로 야근을 하는 개발자가 있다면 십중팔구 미혼이거나 결혼을 했어도 아이가 없겠죠. 이런 정상적이지 않은 생활을 하며 10, 20, 30년간 소프트웨어 엔지니어 일.. 더보기 고객중심의 서비스 마인드가 소프트웨어 산업을 망친다. 부제 : Global mind를 가져라. 우리나라의 Customer Service(A/S) 정신은 정말로 환타스틱합니다. TV가 고장나서 전화하면 수리기사가 바로 달려와서 고쳐주고 갑니다. 핸드폰이 고장나서 서비스센터에 가면 바로 고쳐줍니다. 뭐든지 바로바로 해결이 되죠. 하지만 미국에서는 좀 다릅니다. 노트북이 고장나면 바로 해결이 안됩니다. 서비스센터에 맡겨도 서비스센터는 단순히 포장만해서 수리공장으로 보내는 경우가 대부분이고 오래 걸리면 한달이 걸리기도 하고 재수 좋으면 그보다는 빨리 받아 볼 수 있죠. 미국은 땅덩어리가 워낙 커서 가 도시마다 전문서비스기사를 둘 수도 없습니다. 부른다고 쪼르륵 달려갈 수도 없습니다. 비행기타고 몇시간 날아가서 차 랜트해서 또 한참 가야지만 고객을 만날 수 있거든요.. 더보기 소프트웨어 회사의 개발 역량 평가표 아래 평가표는 소프트웨어 개발 회사나 개발팀이 얼마나 역량을 갖추고 있는지 평가하는 표입니다. 아래 각 문항에서 "예"(1점)에 해당하면 Checkbox를 체크하시면 됩니다. 1.전사적으로 소스코드관리시스템을 딱 하나만 사용하고 있다. 2.모든 소스코드 및 개발문서는 소스코드관리시스템에 저장되어 있다. 3.각 마일스톤마다 Baseline을 설정하고 있다. 4.소스코드관리시스템에 체크인 시 메시지를 작성하는 규칙을 가지고 있고, 모든 개발자가 이를 지키고 있다. 5.모든 소스코드는 리뷰를 하고 있다. 6.자동으로 일일빌드를 하고 있다. 7.전사적으로 버그관리시스템을 딱 하나만 사용하고 있다. 8.모든 버그를 버그관리시스템에 등록하고 있으며 다른 곳에 별도로 관리하지 않는다. 9.모든 직원이 버그관리시스템에.. 더보기 이전 1 2 다음
