기본 콘텐츠로 건너뛰기

murianwind의 트위터 - 2010년 03월 17일

  • [테스팅 히치하이커를 위한 안내서] murianwind의 트위터 - 2010년 03월 16일 http://goo.gl/fb/UxfT - 0:25 #
  • Infographic of the Day: Comparing the 100 Largest Sites on the Internet http://bit.ly/aEbhkp - 0:32 #
  • 도시형 보건소는 선심성 공약이다 http://bit.ly/aFyk2k - 0:41 #
  • 김연아 충격 후 한국 배우려는 일본의 단상 http://bit.ly/dki7cD - 0:44 #
  • 아이폰끼리 살짝 부딪히면 돈이 송금된다 - Paypal 새기능 http://bit.ly/bjJc9Q - 0:52 #
  • Toyota's journey from Waterfall to Lean software development - Henrik Kniberg's blog http://goo.gl/ZuWK - 9:33 #
  • Agile Support with Kanban http://bit.ly/aBlAY5 - 9:35 #
  • The TDD Tetrahedron http://bit.ly/aVvQWt - 9:35 #
  • 얼마나 테스트하면 안심하고 잘 수 있을까? http://bit.ly/9OpeEs 저도 수년간 테스팅을 했고 수년간 고민했지만 아직도 테스팅이 끝나도 발을 뻗고 잠을 못잡니다. 정말 딜레마라는... - 9:42 #
  • Most Effective Team Structure http://bit.ly/defUcZ - 9:43 #
  • IE9, HTML5 속도 경쟁 불지피다! http://bit.ly/b2OnNq - 9:46 #
  • MIX10]표준으로 더 강력해진 IE9과 웹 플랫폼[4보 최종] http://bit.ly/97Rr9W - 9:48 #
  • 혁신을 위해서라면 모순을 극복하라 http://bit.ly/bdyIab 저는 모순을 극복하는 방법으로 제약이론과 사고프로세스를 IT에 접목하는 것을 연구하고 있습니다. - 9:50 #
  • 莫以其具 如何能 武之成者 : 흔해빠진 사랑이야기? 아니, SNS 이야 http://radiostar.textcube.com/177 - 9:51 #
  • @1serene 뒤에 저자 소개 보충하고 전체 레이아웃은 나중에 손보시는 거겠죠.. 좋은 아침입니다. ^^ - 9:58 #
  • LGT에는 구글 넥서스원 개통 못하는 건가요? ㅠㅠ - 10:1 #
  • @we_hear 저도 사내 연애이긴 했지만.. 정말 인간이 할 짓이 아니던데.. 행복하세요..^^ - 10:5 #
  • 전문가란 어떤 사람일까? 내가 생각하기에 무언가를 남들보다 잘하고 많이 안다고 전문가는 아닌 거 같다. 잘 아는 것을 넘어 새로운 것을 만들어 낼 수 있어야 전문가가 아닐까? 그런면에서 난 아직 한참 멀었다. - 10:11 #
  • 기존의 설계기법을 열심히 연습하는 단계라면 초보자, 설계기법을 자유자재로 구사하면 숙련공, 나만의 설계기법을 만들어 낼 수 있다면 전문가? 난 요즘 나만의 설계기법을 만들어 보기 위해 고군분투중이다. - 10:12 #
  • 나만의 무언가를 만든다는 것은 사실 불가능할지도 모른다. 이미 남들이 다 알고 있는 것인 경우가 많다. 문제는 차별화가 아닐까? 단 하나의 차별만으로도 사람들은 쉽게 다른 것으로 인식하기도 한다. - 10:14 #
  • @jakebaek 아주 기본적인 것은 제 블로그( http://bit.ly/pJt6z ) 에 소개되어 있고 조만간 스터디를 생각하고 있습니다. 스터디에 관심 있으시면 이곳으로 http://bit.ly/aE8iri - 10:16 #
  • @1serene 흠.. 우선은 글자가 너무 빽빽해서 읽기 힘듭니다. 표와 같은 것이 여러장 걸쳐 있어서 전체를 파악하기도 힘들고요. 책이 아닌 전자문서라는 것을 고려해서 디자인을 해주시면 좋을 것 같습니다. - 10:17 #
  • 난 참 이런저런 일은 잘도 벌린다. 하지만 거의 수습은 하지 못하고 대부분 다른 사람이 수습한다. 덕분에 무슨 평가만 들이닥치면 1년 내내 펑펑 논거나 다름없는 사태가 생긴다. 흑... 놀지는 않았는데... - 10:20 #
  • @1serene 논문처럼 2단 편집을 해보는 건 어떨까요? 먼가 아이디어가 필요해 보이는 듯... - 10:45 #
  • XML의 아버지 '팀 브레이'는 아이폰을 싫어해!? 진짜로! http://bit.ly/doIGFv - 10:47 #
  • Asking: Any plan for Korean(Hangul)? - Is there any plan to support Korean? As you know well Korean market is a ... http://gsfn.us/t/fnga - 10:50 #
  • Prezi 한글 지원을 위해 여러분의 도움이 필요합니다. http://gsfn.us/t/fnga 에 가셔서 미칠듯이 댓글과 함께 동의 표시를 해주세요. - 10:51 #
  • @youthinking @JieEun @taekie @Sandollcomm @enamu 메일 폼을 하나 만들어서 담당자에게 미칠듯이 하루에 한번씩 폰트와 함께 메일을 보내보죠.. 답장 주는 날까지.. - 10:51 #
  • @1serene 주변에 능력자도 많으시면서.. 허허허허허 - 11:2 #
  • @1serene 이참에 능력을 키워보시는 건.. 화이팅... - 11:10 #
  • 연산군도 못한 일, MB는 해낼까? http://bit.ly/dnuAFM - 12:29 #
  • 우리에게 가장 시급한 평생 교육은.. 한글... 우리 주변에는 한글을 제대로 읽을줄도 쓸줄도 이해할줄도 모르면서 어륀지라고 발음해야한다고 혓바닥을 낼름거리는 인간이 너무 많은 것 같다.. - 12:44 #
  • 아와 어는 다르거늘 어라 하여도 아라 했다고 우기고 계속 어라 말하면 후두려 까고 아라 했었다고 그렇게 고백했다고 말하고 모든걸 지 맘대로 해석하는 사람에게는 필히 우리말 교육 6개월만에 달인되기 과정에 보내버렸으면 좋겠다. - 12:46 #
  • 어떤 사람들은 주변에서 머라고 말하든 한가지로만 해석하는 특이한 논리 구조를 가진 사람들이 있다. 일명 불도저, 최씨 고집, 똥고집, 쇠심줄고집 등으로 표현되는 사람들은 이비인후과로 보내야 하는 걸까나? - 12:47 #
  • @HanBaDa_ @yooheeyeol 우리 주변에 화장실이 최소 1.8미터 이상 되는 집에 사는 사람이 누가 있을까요? 칫솔을 안방에 보관해야 하는 것일까요? - 12:47 #
  • @OEHAN 하지만 어떤 사람들은 그런 지식이 지금은 필요없다. 조금만 기다려 달라고 하시는 분들도 있죠. 테스팅에 있어서 가장 중요한 것이 무엇인지 전 요즘 고민입니다. - 12:48 #
  • 테스팅을 잘하기 위해서 가장 필요한 지식은 무엇일까요? 전 무엇인가를 만드는 과정을 완벽히 이해하는 것이 가장 먼저 필요한 것이 아닐까 생각합니다. 사용성을 하기 위해서는 심리학, 인지공학, 아키텍쳐 등에 대해 먼저 이해해야 하는거 아닐까요? - 12:49 #
  • @taekie @Sandollcomm @youthinking @JieEun @enamu 유료결재 후 한글 지원 요청이 먼저일까요? 한글지원해주면 돈내겠다가 맞는걸까요? - 12:51 #
  • @OEHAN 그게 좀 조심하셔야 하는것이 섣불리 달려들다가 전공지식 후려치기 한번 당하고 나면 오히려 더 무시당하는 경향이 있어서.. 대화의 노하우도 중요한 것 같습니다. - 12:53 #
  • @youthinking @mahabanya 방관자 효과 아닌가요? - 13:16 #
  • 국제적인 기업환경에서 가장 강력한 힘은 표준화다. 표준화의 근간은 오픈이다. 전세계 IT 기술을 이끄는 많은 기업은 각자의 플랫폼을 개방함으로써 표준을 이끌고 그 표준을 기반으로 세계를 지배한다. - 14:1 #
  • 우리의 기업들이 자사의 기술에 대해 폐쇄적인 입장을 견지하는 한 한국의 IT 기술은 아무리 좋은 기술이라고 해도 햇빛 한번 보지 못하고 사라질 수밖에 없다. 삼성의 8밀리 비디오 테이프가 그랬고, 와이브로가 그렇다. - 14:2 #
  • 트위터의 애니웨이가 무서운 이유는 바로 개방을 통해 SNS 플랫폼 자체를 트위터 플랫폼 자체로 디파토 표준을 이룰수만 있다면 페이스북도 구글도 무섭지 않을 것이기 때문이다. 페이스북도 구글도 같은 전략으로 각자의 세력을 넓히고 있다. 우리는? - 14:3 #
  • 표준화의 뒤에는 과학화가 뒷받침 되어주어야 하고 그 뒤에는 전문화된 분업화가 뒷받침되어주어야 한다. 하지만 우리는 소프트웨어 개발에서 인사, 재무, 관리, 테스팅 어느것 하나 과학적으로 전문화된 분야가 없이 모두 경력직으로만 뽑는다. - 14:4 #
  • 경력과 과학화는 아무런 관련이 없다고 봐도 무방하다. 과학화는 데이터에 기반해야하고 그 뒤에는 훈련된 사람이 있어야 하고 그 뒤에는 교육에 대한 꾸준한 투자가 있어야 한다. - 14:5 #
  • 하지만 난 아지까지 많은 기업에서 테스팅에 대하여 꾸준한 교육 투자를 하는 경우를 많이 보지 못했다. 즉, 우리 나라의 소프트웨어 산업이 선진국에 비해 20년 이상 뒤쳐진 이유와 국제적 경쟁력이 없는 이유는 자명한 일이다. - 14:6 #
  • 한국은 너무 결과만을 중요시한다. 결과를 중요시하다 보니 뱁새가 황새 쫓아가다 가랑지 찢어져 뒈지는 형국이다. 생산성 증대, 경영 혁신, 기술의 진보는 그렇게 한순간에 이루어지지 않는다. 모든 것은 절차가 필요하다. - 14:7 #
  • 절차에 대한 일말의 고민 없이 결론에 집착하게 된다면 가장 중요한 기초공사 부실로 겉으로 보기에는 멋져 보이지만 외부의 충격에 결코 버티지 못하는 모래성이나 다를바 없다. 지금이라도 우리는 과정을 중요시 할 필요가 있다. - 14:8 #
  • 외국의 선진 기술, 선진 기법도 좋지만 그러한 것이 완성될 수 있었던 토대부터 차근히 따라가지 못한다면 수천년이 지나도 우리는 선진국이 될 수 없다. 최신이 무조건 좋은 것은 아니다. 중요한 것은 자신의 분수와 주제에 맞게 최선을 다하는 것이다. - 14:9 #
  • 많은 중소기업들이 제대로 된 테스팅을 수행하지 못하는 것은 일부 대기업이나 선진 기업들에서나 가능한것만을 생각하기 때문이다. 그런건 나중에 생각하고 우선 가장 중요하고 시급한 것부터 차근 차근 해나갈 필요가 있다. - 14:10 #
  • 난 SW Testing Camp를 통해서 많은 사람들이 지금 당장 필요한 것들에 대해 많은 이야기를 나눌 수 있었으면 좋겠다. 테스트 자동화, 정책 및 전략, 프로세스, 표준 그런걸 다 떠나서 지금 당장 할 수 있는 것에 더 집중할 수 있었으면 한다. - 14:12 #
  • @Lidless_Eye 맨파워에 의지하는 구조를 회피하는 방법론도 있지만 맨파워를 극대화하기 위한 방법을 목표로하는 방법론들도 있습니다. - 14:27 #
  • @ejang 언제쯤부터 서비스를 시작하실 건가요? 기존 서비스가 중단되기 전에 갈아타야하는 건가요? 기존 서비스를 사용하던 사람들은 그냥 계속 사용하면 되는 것인가요? - 14:28 #
  • http://is.gd/aLtea <ISTQB Advanced & Expert Syllabus 번역 및 스터디> 모꼬지만들었습니다. 많은 관심부탁드려요. #ISTQB - 15:9 #
  • @ejang 음.. 기존 사용자들을 위해서 서비스 개시일이 기존 서비스의 종료 전으로 해주실수는 없나요? 다시 가입하는 것쯤이야 얼마든지 할 수 있지만 서비스가 단절되는건 좀 그런것 같습니다. 고려해 주시면 고맙겠습니다. - 15:19 #
  • 최근의 애플의 아이폰이나 아이패드를 보면서 과연 내가 멀티태스킹이 얼마나 필요할까? 고민해 보았는데..음.. 필요한것 같다는.. 뭐야.. 결론은 지름신을 물리치기 위한 마지막 발악이라는.. - 15:22 #
  • http://is.gd/aLtea ISTQB Advanced Level 과 Expert Level Syllabus 문서를 번역하고 스터디하실 분을 찾습니다. 선착순 6분 받겠습니다. 중도에 포기 없이 꾸준이 하실 수 있는 분을 찾습니다. #ISTQB - 15:23 #
  • @ejang 이장님 T2B 다음 버전 서비스 해주실 때 트위터의 리트윗 기능으로 트윗한 트윗들도 블로그로 가져올 수 있도록 손봐주실수 있으신가요? - 15:57 #
  • 조만간 전국에 대나무 꽃이 피는건 아닐지.. 흠... - 16:8 #
  • 사용성 테스트 결과를 어느 수준까지 써야 하는가? http://bit.ly/bt95Aj 저는 2.5정도의 수준이 딱 좋다고 생각합니다. 흠.. - 16:12 #
  • @aliceherstory 전 왜 안오는걸까요? ㅠㅠ - 16:51 #

댓글

이 블로그의 인기 게시물

프로젝트의 3요소 - Project Management

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

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

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

QA 부서는 필요한 것인가?

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