기본 콘텐츠로 건너뛰기

murianwind의 트위터 - 2010년 01월 11일

  • [테스팅 히치하이커를 위한 안내서] murianwind의 트위터 - 2010년 01월 10일 http://goo.gl/fb/dmIW - 0:7 #
  • TOC 포럼 (1월14일,목) 정기 오프 모임 안 내 http://bit.ly/91Bf19 다음 주 목요일 제가 TOC 포럼에서 발표 합니다. 관심 있으신 분들은 많이 참석해 주세요. - 10:50 #
  • VoIP on Web2.0 : 트위터가 지진발생을 실시간으로 알려준다 http://mushman.co.kr/2691284 - 10:53 #
  • 벗님의 작은 다락방 : 농담도 통하지 않는 사회 http://daeil.textcube.com/1561 - 10:54 #
  • 스마트폰의 데이터 요금 절약 구세주, 오페라 미니 http://bit.ly/4Kslyk - 10:57 #
  • The Art of Compromise: Scrum and Project Governance http://bit.ly/5HlP0r - 10:58 #
  • 사랑의 헌혈, 그 진실과 오해 A to Z http://bit.ly/92AUek 제 부인도 헌혈하면 에이즈 걸린다면서 헌혈을 하지 않는데, 제가 알기로 한번 사용된 주사 바늘이 재사용되는 경우는 없습니다. - 11:15 #
  • 한국에서도 아이폰으로 바코드 찍어서 최저가 검색하기 - 지름도우미 with RedLaser http://bit.ly/7VhWVF - 11:20 #
  • 온라인 게임 현금거래, 무죄?! http://bit.ly/5B8WJ9 - 11:26 #
  • 아바타.. 다다음주 수요일까지 왕십리 아이맥스 전석 매진이군요..ㅡㅡ 헐.. 아내라도 보여줘볼까? 했더니.. 예매 오픈되는 순간이 지옥일거 같은.... - 11:35 #
  • 우리는 더 나은 개선을 위해 경쟁사의 제품을 사용해 봐야 한다고 말한다. 물로 일부 도움은 될 수 있을지 모르지만 경쟁사 제품의 임팩트가 너무 강할 경우 경쟁사의 제품은 일종의 선입견을 형성하고 나의 제품은 아류작으로 전락해버릴 수도 있다. - 11:43 #
  • 무엇인가를 뛰어 넘어 더 나은 것을 개발한다는 것은 매우 어렵다. 새로운 것을 만든다는 것은 그 자체가 리스크이다. 대부분의 회사는 그러한 리스크를 짊어질 각오를 하지 못한다. 그것은 사이버네틱 시스템의 복잡계와 맞물린다. - 11:44 #
  • 어제 CH CGV에서 아바타 촬영 비화에 대한 프로그램을 봤는데.. 아~~~ 라는 소리만... 정말 그 기술적인 혁명을 이룬 과정에 할말이.. - 11:48 #
  • 전국 모든 수유실 정보를 망라한 아이폰 어플을 개발해 보고 싶은 욕심은 있지만 정보와 개발 능력의 부재.. 올해 최고의 화도는 스마트 폰을 이용한 지리정보 시스템 어플리케이션이 될 것 같은... - 11:54 #
  • 오즈 서비스를 바라보면서 한가지 불만은 기존의 ez-i 단말기들은 완전히 서비스의 사각지대에 방치된체 버려져 있다는... - 11:55 #
  • 능력있는 개발자만 같이 해준다면 아이폰이나 안드로이드에 유용한 어플을 많이 개발해 보고 싶건만.. 누구 안계신가요? 기획과 테스트는 제가.. 개발만 같이 해주실만한... - 11:56 #
  • 필요는 발명의 어머니다.. - 11:56 #
  • 아이폰에서 무료로 배포되는 어플들은 개발자가 수익을 전혀 받지 못하는 것인가요? 그렇다면 무료로 배포되는 어플을 개발하는 개인 개발자들을 멀 먹구 사는거죠? 아이폰 어플은 그냥 부업인가? - 11:58 #
  • 공격적 스마트폰과 인상적인 태블릿.. RT @hongss: CES 2010 보면서 관심가는 한가지를 선택해주신다면?? http://bit.ly/8qdGNt - 11:59 #
  • 티핑 포인트를 읽고 느낀 것은 환경이 가장 중요한 것이다.. - 12:1 #
  • 내 회사의 제품을 흥행시키고 유행시키기 위해서 환경을 기다릴 것인가? 환경을 만들 것인가? 이것이 마케팅과 홍보의 기본이 아닐까? 라는 생각을 해본다.. - 12:2 #
  • 안된다 불가능하다 원래부터 그랬다와 같은 선입견을 가지고 있는 한 발전은 개뿔도 없다. 하지만 그러한 선입견을 넘어서는 것 자체가 리스크이기 때문에 누구도 가려하지 않는다. - 12:3 #
  • 몇일동안 블로그에 글을 올리지 않았더니 일일방문객이 한자리수로 떨어지기 일보직전이다. 봉인된 3편의 포스팅 중 어느거라도 먼저 풀어야 할텐데.. 요즘은 집에서도 아내 눈치 때문에 포스트 하기가 힘들다. ㅠㅠ - 12:52 #
  • 혹시 개인의 재미, 개인의 커리어 개발등의 명목으로 저와 함께 아이폰과 안드로이드 어플 개발을 함께 도모하실 개인 개발자분 계신가요? 모바일 어플리케이션 개인 개발자 연합을 구성해서 활동하는 것도 좋을 것 같다는.. - 12:53 #
  • 지리정보시스템과 증강현실을 결합해서 아이폰과 같은 모바일로 거리를 바라볼때 알바 구함 광고가 뜨는 어플을 만들면 어떨까? 잡코리아와 같은 곳에서 개발하면 좋을 것 같은.. - 12:57 #
  • 웹이 미칠듯한 기술 혁신의 속도전으로 빠르게 스탠드 얼론 어플리케이션의 영역을 침범하고 있지만 웹에 접속하기 위해 필요한 하드웨어의 제약은 어떻게 극복할 것인지.... - 12:58 #
  • 스마트폰에서 모바일 알라딘에서 카드 결제 체험기 http://bit.ly/4DLJWT - 14:5 #
  • 영유아정기검진 병원 검색을 하면서 나도 모르게 영유아정기점검이라고 치고 있다..ㅡㅡ 이것도 직업병인가? - 14:22 #
  • 영유아검진을 받기 위해 병원을 찾고 있는데 이것들이 배가 부른지.. 다들 시큰둥하니 올테면 오고 말라면 말라는 식이다. 아 짜증나.. 영유아 정기검진 잘해주는 병원 아시는 분 추천 좀 해주세요. 광진구 근방이면 좋겠습니다. - 14:24 #
  • 작년 한해는 어디를 파야할지 시추공 위치를 선정하는 한해였다면 올 한해는 시추공에서 경제성 있는 광구를 찾는 한해로 쓰고자 한다. 늦어도 내후년에는 광구에서 무엇인가를 시추하여 경제성을 이루었으면 한다. - 14:56 #
  • A자형 T자형 인간이 되자는 여러 이야기가 있다. 난 V자형인간이기를 원한다.. 깊이 파기 위해서는 입구가 그만큼 넓어야만 한다. 깊이와 입구의 너비는 비례한다. 전문가가 되기 위해서는 그만큼 더 넓은 영역을 알아야 할 필요가 있다고 본다. - 14:57 #
  • 웹미나!!! RT @AdobeCL: 오늘은 55분에게 행운을 드립니다. 얼른 응모&RT! 크리에이티브프리덤에서 진행되는 CS4 실시간 온라인 세미나로 웹+세미나의 합성어인 이 용어는 무엇? <힌트> http://bit.ly/8eVudk - 16:8 #
  • I love you, forever. :: Apple Computer가 이제는 자동차에 손댄다!? http://grinn.tistory.com/6 - 16:33 #
  • @acoralreef @toice 등기부등본에 채무관계와 저당권설정등을 반드시 보셔야 하구요 수도, 전기 등을 공용으로 사용하는지도 확인하셔야 합니다. 집주인의 주민등록증과 등기부등본의 주인이 일치하는지도 보셔야 하구요. - 16:35 #
  • @acoralreef @toice 집 전체의 수도관을 열어서 수압이 일정한지도 확인하시고요. 집 구석등에 곰팡이등이 피어있는지도 보셔야 합니다. 보일러 가동도 확인해야 하구요. 집주인이 모든 수리등을 해준다는 등의 요구사항도 계약서에 기입하시고요 - 16:37 #
  • @HRG 트레일러가 일종의 메이븐의 역할을 한다면 영화를 본 사람들이 세일즈맨의 역할은 한다고 생각합니다. 트레일러가 아무리 훌륭해도 초반 효과이상의 효과는 없다고 봅니다. - 16:38 #
  • 거세지는 LTE 바람...'위기의 와이브로' http://bit.ly/4tajiz - 17:30 #
  • [테스팅 히치하이커를 위한 안내서] 씽크 & 블링크 그리고 제약이론 http://goo.gl/fb/pdvc - 22:50 #

댓글

이 블로그의 인기 게시물

프로젝트의 3요소 - Project Management

프로젝트는 예산, 일정, 품질 3가지 요소로 이루어진다고 볼 수 있다. 물론 위 3가지 요소 외에도 개발 범위, 팀워크, 자원 조달 등 여러가지 요소들도 고려해 볼 수 있지만, 가장 중요한 요소를 꼽는다면 예산, 일정, 품질일 것이다. 위에서 말한 여러가지 요소들은 프로젝트를 계획하여 완료하는 순간까지 복합적으로 작용해서 프로젝트의 성과를 제한하게 된다. 위의 요소들을 잘 통제한다면 성공적인 프로젝트가 되는 것이고 그렇지 못한다면 실패하거나 사라지게 될 것이다. 프로젝트 관리란 그런 면에서 제한된 자원을 가지고 목적한 바를 제한된 기간내에 최소의 비용으로 완수할 수 있도록 하는 것으로 정의할 수 있을 것이다. 이것을 도식화 한다면 아래와 같은 그림으로 표현할 수 있을 것이다. 위의 그림에 보는 것처럼 일정과 품질, 예산은 우리의 프로젝트가 목적하는 바를 달성하도록 하기 위해 상호 연관되어 작용하게 된다. 우리가 접하게 되는 많은 방법론들의 가정에는 위의 요소들을 어떻게 관리할 것인가에 대한 기본적인 가정들이 설정되어 있다. 조직에서 어떤 특정한 방법론을 도입한다는 것은 그런 가정에 동의하는 것이고 그러한 철학을 받아들인다는 것이기 때문에, 방법론을 채택하기 전에 조직의 근본 문제와 문화에 대해 점검해 볼 필요가 있다. 그리고 위의 요소들 외에 고려해 볼 사항은 위의 요소들은 변동성과 불확실성을 내포하고 있다는 것이다. 특히 비용과 예산, 목적은 프로젝트를 진행하면서 가변할 가능성이 매우 큰 요소들이다. 대부분의 방법론은 이러한 변동성에 대한 안전장치들을 가정해서 세워져 있다. 변동성의 측면에서 위의 요소들을 다시 살펴본다면 아래와 같이 가정할 수 있다. 위의 그림을 일부 해석해 본다면 일정이 늘어난다면 비용은 늘어나게 된다. 범위가 변경되어도 비용은 늘어나게 된다. 범위와 일정은 상호 의존적이 된다. 만약 위 3가지 요소의 변동성을 통제하지 못하게 된다면 프로젝트는

내 인생 첫 차량 구매 후기 - 쉐보레 스파크

다사다난한 2011이 끝나고.. 2012년이 밝았군요.. 머.. 저는 언제나처럼 설날을 기준으로 하기 때문에 별다르게 주변 분들에게 새해 인사를 하거나 그러지는 않았습니다만.. TV고 어디고 간에 새해가 밝았다 하니 그런가 합니다.. 저는 어제 저녁 아내님이 2도 화상을 입으시는 바람에 송구영신 예배나 새해 맞이 예배는 가지도 못했고.. 그냥 한해의 액땜을 제대로 했구나 하고 있습니다. 오늘은 출장 가기 전에 체력 비축하고 있습니다... 아.. 그냥 방에서 뒹굴거리고 있습니다.. 간만에 좀 뒹굴거리는것 같네요.. 어쨌든 새해 첫날 먼가 참신한 글을 써보고 싶었지만.. 소재가 그렇게 뉴턴의 사과처럼 머리로 떨어져주는건 아니니.. 지난 해 진행했던 카드 소팅 결과는 참여하신 분들이나 기다려주시는 분들에게는 죄송하지만 조금만 더 기다려주시면 고맙겠습니다. 그래서 오늘의 소재는 써야지.. 써야지.. 하면서 차일 피일 미루던 제 인생 첫 차량 구매 후기를 올려보겠습니다. 제가 운전을 잘 하거나 차량에 대해 잘 알고 있는 것이 아니기 때문에 그냥 참고만 하시면 되겠습니다. 우선 제가 차량을 구매하게 된 동기는 .. 그렇습니다.. 애들 때문입니다. 자녀가 둘이 되니.. 엄마, 아빠의 팔뚝 힘으로는 더 이상 외출이 힘들어졌습니다. 그래서 차를 구매해야겠다고 무리를 하게 되었습니다만.. 역시 언제나 부족한 것은 총알이죠.. 그래서 당연히 경차로 알아보게 되었습니다. 하지만 아시다시피 우리 나라에 경차는 딱 두가지입니다.(지금은 레이라고 새로 나와서 세가지가 되었지만.. 제가 차를 구매할때는 두 종류였습니다.) 선택이라고 할것도 없죠.. 현대 차는 고객을 개새끼로 아는 현대의 투철한 정신에 절대 사고 싶지 않았고.. 쉐보레는 옛날 대우 생각을 하면 이것도 역시 사고 싶지 않았지만.. 여기 저기 얘기를 들어보니 쉐보레로 변하면서 차 좋아졌다.. 쉐비케어가 진리다.. 라는 얘기에.. 그냥 스파크 구매로 결정했습니다

QA 부서는 필요한 것인가?

많은 프로젝트 관리 방법론과 조직론에서 항상 얘기하는 것이 QA 부서를 독립적으로 두는것에 대해 강조하는 편이다. 테스트 역시 테스트 조직을 별도로 두는 것에 대해 강조하는 편이다. 이러한 QA 부서 또는 테스트만을 전담하는 조직이 꼭 별도로 존재해야 하는 것일까? 테스트의 경우에는 개발자와 다른 시각을 가진 사람들의 테스트의 필요성을 강조하기 위해서 테스트 조직을 별도로 두는 것을 강조하는 편이다. 만약 테스터가 개발이나 영업, 운영과 같은 조직의 하부 조직이 되다 보면 정치적인 독립성에 따라 자신만의 독립적인 시각이나 의견을 피력하기 힘든 점이 있기 때문이다. QA 부서는 어떨까? 여기서 먼저 생각해 볼 것이 있다. 그것은 QA 부서가 과연 무슨 일을 하는 부서인가? 하는 문제이다. 여러분의 회사에서 QA 부서는 과연 어떤 일을 하는가? 여러분은 QA 부서에 대해 얼마나 호감을 가지고 있는가? 펼쳐두기.. 회사마다 회사의 정책이나 전략에 따라 QA 부서의 역할은 매우 판이하다. 그리고 그 역할에 따라 회사 내에 QA 부서의 호감도도 매우 달라지는 편이다. 만약 여러분이 QA 부서에 대한 호감도가 낮다면 아래와 같은 문제가 있는 것은 아닌지 한번 고민해 보시고 댓글이나 트랙백등으로 의견을 주셨으면 하는 바람이다. 먼저 일반적으로 QA 부서가 하는 일은 제품의 품질을 측정하고 제품의 품질을 향상시킬 수 있는 모든 활동을 계획하고 제어하는 일을 한다. 그런데 문제는 소프트웨어의 품질이 문제가 된다. 먼저 공장과 같은 하드웨어를 제조하는 회사의 경우에는 품질 부서가 독립적으로 존재한다. 이 품질 부서에서 제품의 품질을 측정하고 제품의 품질을 개선하기 위해 집중하는 곳은 하드웨어 그 자체이다. 하드웨어는 각각의 부붐의 품질이 100인 제품이 모여서 하나의 제품을 구성하게 되었을 때 그 제품의 품질은 역시 100이다. 이것은 매우 명확한 사실이다. 소프트웨어를 만드는 회사의 조직과 관리 방법 역시 이러한 하드웨어를 만드는 회사의 조직과 관리 방법을