더 많은 취약점들이 보완되었다는 말이 브라우저의 안정성이 떨어진다는 식으로 받아들여지는 것에 대해서는 어떻게 생각하는가?

잘못된 논리라고 생각한다. 만약 문제를 해결하지 않는다면, 겉으로 보기에는 좋겠지만 내부적으로 그 문제가 해결되지 못한 체 남아있게 된다. 지금 현재 우리가 처해 있는 상황을 그대로 비춰볼 수 있는 좋은 영화가 있는데, 바로 ‘Les Repos’, 해석하면 ‘부패한 것들’이라는 영화다.

한 젊은 형사와 늙은 형사의 이야기인데, 젊은 형사가 늙은 형사에게 점점 부패하는 방법을 배우는 과정을 그린 영화이다. 영화에서 범인을 잡으면 젊은이는 그 범인을 항상 경찰서로 데리고 가려 한다.

하지만 그 순간 늙은 형사는 "아니야 그렇게 하지마. 만약 우리가 그를 경찰서로 넘기면 범죄율이 증가하고, 그렇게 되면 우리의 평판도 안 좋아질 수밖에 없어. 그냥 그 자에게 돈을 받고 풀어주면 돼. 그게 그 범인을 처벌하는 유일한 방법이야."라고 말한다.

이는 현재 우리의 상황을 너무나 잘 투영하고 있는 듯 하다. 옳은 일을 꿋꿋하게 하게 되면, 내 스스로에 대한 평판은 낮아질 수도 있지만 결국 사용자들은 더욱 안정된 보안 속에서 활동할 수 있게 된다. 여기서 가장 중요한 것은, 우리의 제품을 선택한 사용자가 안전해야 한다는 것이고 사람들은 우리가 그렇게 만들어주길 바라고 있다는 것이다.

모질라 커뮤니티에 참여하는 개발자들은 옳은 일을 해야 된다는 사실에 대해 상당한 공감대를 형성하고 있고, 우리는 함께 협력해서 일을 해야 하기 때문에 서로를 믿어야 한다는 사실도 서로 잘 알고 있다. 만약 커뮤니티에서 제품의 결점을 숨기기 시작하면, 전체의 동기부여 면에서나 커뮤니티의 사기 면에서 상당히 부정적인 영향을 미칠 것이 뻔하다. 하지만 우리는 우리 팀을 위해 일하는 것이 아니라, 항상 사용자들을 위해 일하는 것이라 생각하고 마음을 다지고 있다.

가장 최근의 예를 하나 들어보자. 10일 전 우리는 파이어폭스 2.0.0.10.를 출시했다. 그러나 두 시간 후 우리는 새롭게 출시된 버전에 꼭 수정해야 할 오류가 있다는 사실을 발견해냈다. 몇몇 웹사이트 기능이 제대로 작동하지 않은 것이다. 우리는 재빨리 목요일 저녁 2.0.0.11 버전을 재차 내놓기로 결정했다. 3일 반 만에 새로운 버전을 내놓은 것이다. 이는 상당히 큰 전환점이 됐다. 우리는 일주일에 두 번이나 업데이트 하라고 사용자들에게 부탁하는 것을 좋아하지는 않지만, 결함을 그대로 묻혀 두는 것이 더 싫었기 때문이다.

출처: http://www.zdnet.co.kr/news/network/security/0,39031117,39164051,00.htm





:


'서비스로서의 게임' 선언문
(Manifesto for Game-as-a-Service)



우리는 다음의 것들을 가치있게 여긴다:

개발자(developer)보다 사용자(user)
를,

제품(product)보다
체험(experience)을,

기능(feature)보다 혜택(benefit)을,

품질(quality)보다 만족(satisfaction)*을 더 중요시한다.


다시 말해서, 왼쪽에 있는 것들이 비록 가치있긴 하지만,

우리는 오른쪽에 있는 것들에 더 큰 가치를 둔다는 것이다.



* 품질(quality)이 '기능이 개발자가 의도한 바대로 작동하는가?'라면, 만족은 '혜택이 사용자의 기대를 충족시키는가?'를 의미한다.
:

현재 회사에서 Google Apps의 도입을 검토하고 있습니다.

사용자 삽입 이미지

혹시나 Google Apps의 우수 도입 사례나, MS Exchange Server와의 비교 자료가 있으시면 Trackback이나 답글로 알려주시길 부탁드립니다.


:

남기룡 님
께서 UnitTest++에서 빨간 막대가 녹색 막대로 변하는 순간의 희열감을 원하셨는데,

마침 쑥갓 님께서 UnitTest++용 GuiRunner를 만들어주셨네요:

사용자 삽입 이미지

사용법은 박일 님의 글을 참고하시기 바랍니다: http://parkpd.egloos.com/1668243


:

"애자일 게임 개발: 실천과 도입" in KGC 2007은 실수도 있었고, 의도하지 않은 방향으로 흘러간 점들도 있지만, 사람들의 관심을 불러일으키는 데에는 어느 정도 성공한 듯 합니다:

제 입장에서 오늘의 하이라이트는 바로 이 세션이었다고 저는 생각합니다. XP, SCRUM, TDD등을 실제로 게임 업계에서 적용해본 사례들을 여러 패널분들의 경험담을 통해 들을 수 있었고, 애자일 개발에 대한 패널들의 조언이나 생각들을 들어볼 수 있는 멋진 시간이 되었다고 생각합니다. 1시간이란 시간이 이렇게 아쉽게 느껴지기는 오랜만이었습니다.
출처: http://sizuha.egloos.com/3477350
총 세 개의 session을 들었는데, 모두 Agile 방법론과 관련된 session이었습니다. 세 session 모두 나쁘지 않았지만, 마지막 session이었던 panel 토의 시간이 가장 좋았습니다.
출처: http://opengameprogramming.net/sureong/414


사실 이번 패널 토의는 DevRookie에서의 강연 방식을 응용한 것이었습니다:
스터디를 애자일 하게 진행하시겠다는 기웅님의 예고가 있었는데, 역시나 시작부터 기민한 대응을 하시더군요. 프로젝트가 아닌 평면 TV를 보시더니 잘 안보이지 않을까 하면서 책상을 뒤로 치우자 하셨고, TV 앞에 의자를 끌어 당겨 모이게 하였습니다. 그렇게 서로의 간격을 30cm 내외로 두고 모두 TV앞에 모인체로 스터디가 시작 되었습니다. 

기웅님의 강연을 기다리고 있는데, 스터디를 어떻게 진행할지, 궁금한 사항이 뭔지, 스터디 참가자가 토론을 통해 정하게 하시더군요. 결국 5분의 회의를 통해 '애자일이란 무엇인가', '애자일 개발의 성공 사례', '애자일 개발 도입' 이란 주제가 정해졌고, 이에 대한 스터디가 시작 되었습니다. 

뭔가를 소개하거나 새로운 개념을 강연하는 방식이 아닌 약간의 설명과 질문 그리고 답변이 반복적으로 진행 되는 스터디였는데 뭔가 다들 참여하고 있구나 하는 생각이 들었습니다. 스터디 중간 중간에도 계속해서 참가자들의 피드백을 구하시고 강연이 아닌 토론을 하는듯한 스터디였습니다. 평소보다 40분 정도 늦게 끝났지만, 예고하셨던 대로 애자일한 재미있는 스터디였습니다

출처: http://cafe.naver.com/devrookie/1488

하지만 제가 몇 가지 놓친 점이 있었습니다:
  • 청중이 불과 수십 명일 거라 예상했는데, 130여 명에 달했다. (그래서 패널리스트들과 청중들 사이의 거리가 매우 멀었다.)
  • 전에는 3시간 정도였지만, 이번에는 1시간밖에 주어지지 않았다.

그래서 다음 번에는 이렇게 해보려고 합니다:
  1. 한 질문 당 논의 시간을 정해서 빠듯하게 가야 한다. (그 외에도 한 주제에 발언할 수 있는 발언자의 수를 제한하거나, 한 번 발언당 2분을 넘지 않는다 등.)
  2. (오늘처럼 시간이 부족한 경우에는) 진행자가 누가 발언하겠냐고 묻지 말고, 바로 발언자를 지목하는 게 효과적일 수 있다.
  3. 사전에 질문을 확정하고 토의를 시작하자. Blog, Email 혹은 Wiki를 통해서 미리 질문을 선별하고, 여유가 있을 때에 현장에서 별도의 질문을 받자.
  4. 미리 준비하자. 특히 자세하지는 않더라도, 사전에 간단하게 제목만이라도 적힌 PPT를 준비하자.
  5. 패널 토의를 두 개 이상로 나누어서, 청중의 수를 작게 유지하자.


마지막으로 "애자일 게임 개발: 실천과 도입" in KGC 2007에 참석해주신 130여 명의 분들께 모두 감사드립니다! 덕분에 흥미로운 경험과 좋은 교훈을 얻었습니다!!!

:
  • 점심시간에 Relic의 Lead Game Designer를 만났다. CoH를 기반으로 MMORTS를 만들고 있단다. (역시 예상대로 다음 대세는 RTS인 것 같다.) 부분유료화를 하려고 한다길래, 한참동안 그에 대해서 흥미진진한 이야기를 나누었다. (kgc2007) 오후 2시 31분
  • PayNova의 영업담당자랑 잠시 이야기를 나누었다. Sweden에서 왔다는데, EU와 미국에 강점을 갖고 있다고 한다. EU는 매우 복잡한 시장이라 nCash가 아닌 현지의 경험많은 PG가 필요할지도. 오후 9시 27분
  • Jonny Kang의 중국 시장에 대한 강연을 듣다. 거의 마지막을 들은터라 잘은 모르겠지만, 시장에 밀착한 게임을 만들어야 한다는 사실은 한국 게임계에 너무나 절실한 교훈이다. 아마 이것을 깨닫지 못한 회사는 몇년 뒤에 다가올 시련을 견디지 못하고 사라지지 않을까? 오후 9시 32분
  • KGDS 2003에서도 만났던 Tom Sloper 아저씨. 관록 있는 사람답게 내공 실린 이야기를 했지만, 동시에 교과서적이라고 할만큼 추상적이었던 것 같다. 그래도 막 Producer가 되었거나, 되려고 하는 사람에게는 유용할 듯. 오후 9시 34분
  • Gordon Walton. 가장 기대했던 강연! 하지만 조금은 아쉽다. MMO를 언급한만큼 Scrum of Scrums(Meta Scrum)가 별로 나오지 않았다. 거의 Scrum에 대한 일반적인 설명 수준? 나중에 Email로 물어야 할 듯 싶다. 오후 9시 38분
  • 오늘 하루를 돌이켜보니, 개인적으로 가장 도움이 될만한 강연들은 다른 주요 시장들의 현황/특성에 대한 강연들이 아닐까라는 생각이 불현듯 든다. 시장 주도형(Market-driven) 게임 개발이 정답은 아니지만, 우리에게 가장 절실한 접근법이 아닐까? 오후 9시 41분

이 글은 betterways님의 미투데이 2007년 11월 8일 내용입니다.

:

KGC 2007에 참석하시는 분들 중 애자일 게임 개발'에 대해서 궁금한 게 있으신 분은 Ntreev Zone에 들러주세요!

제가 근무하는 Ntreev에서 KGC 2007에 Ntreev Zone라는 휴게실을 열니다.
  • 편히 앉아서 쉴 수 있는 의자
  • 다른 사람들과 이야기를 나눌 탁자가 있고,
  • 커피나 녹차 같은 음료수도 제공하고,
  • 인터넷 접속이 가능한 PC들도 몇대 놓여 있습니다.
  • 더 좋은 점은, 무료이고 누구나 올 수 있다는 점!
  • 위치는 KINTEX 307호입니다.

예를 들자면, 아래에 있는 Google Developer Night의 그것과 비슷한 거죠:

사용자 삽입 이미지

주의: 본 사진과 Ntreev Zone은 직접적인 연관이 없습니다.



저는 강연을 듣거나 하는 게 아니라면, 8일과 9일 양일에 걸쳐서 이곳에 쉬고 있을 것 같습니다.

저와 함께 놀아주실 분은 이곳에 들러주세요! :)

:

일일 스크럼 회의를 제안하자, 관리자가 당신에게 윽박을 지릅니까?

"테스트 주도 개발"에 대해 이야기할 때마다, 동료들이 여러분을 비웃습니까?

짝 프로그래밍을 하고 싶지만, 누구도 함께 하려하지 않나요?


여러분이 이제는 이게 당연하다고 생각할지도 모르겠습니다.

하지만 우리는 다르게 생각합니다.

만약 여러분이나 여러분이 아는 누군가가 이와 같은 상황에 놓여 있다면,
"애자일 게임 개발: 도입과 실천"에 참석해보십시요.

우리가 어떻게 여러분을 도울 수 있을지 확인해 보십시요.


여러분의 생각, 방법과 길이 틀리지 않았다는 확신을 얻어가십시요.

당신의 동료들과 관리자를 데려와서, 우리가 여러분을 대신해서 싸우게 하십시요.

폭력을 이용한 협박이 아니라, 우리의 성공 사례로 그들을 설득하게 해주십시요.

그 밖에도 여러분이 원하시는 바를 댓글로 달아주시면 참고하겠습니다.




'Game > Production' 카테고리의 다른 글

Ntreev Zone으로 놀러오세요!  (2) 2007.11.07
Scrum의 핵심  (6) 2007.10.11
Agile에 관한 난상토론 참가자 접수 시작!!!  (6) 2007.09.27
:
(Link가 잘못 걸려 있어서 수정했습니다.)

고맙게도 황상철 님께서  정리해주셨네요:

전적으로 제가 생각하기에, 좀 무거운 도구들(Bugzilla)도 포함되어 있고, 게임 개발에 일반적으로 잘 사용하지 않는 기술이나 언어(예: Java)도 포함되어 있지만, 참고할만 하다고 생각합니다.

언제 애자일 (게임) 개발을 위한 도구들을 정리해서 올려보겠습니다.

'Game > Programming' 카테고리의 다른 글

UnitTest++용 GuiRunner가 나왔습니다.  (2) 2007.11.17
테스트 주도 개발 ,1년째  (4) 2007.08.27
리팩토링 카달로그(Refactoring catalog)  (0) 2007.08.26
:

Scrum의 핵심

Game/Production 2007. 10. 11. 02:04 |
이전에 김창준 님께서 "애자일의 씨앗"이라는 이름으로 Agile을 한 마디로 정의하신 바 있습니다.

그렇다면 Scrum의 핵심은 무엇일까요? 그것은:

Feedback 좀더 일찍, 좀더 자주, 좀더 다양하게, 좀더 꾸준히 주고 받는 것입니다.

나머지는 이것을 어떻게 보다 효과적이고, 효율적으로 실천할 것인가를 풀어놓은 것에 지나지 않는다고 생각합니다.
: