뉴스와 토론
![[레벨:8]](http://old.lameproof.com/modules/point/icons/default/8.gif "포인트:5818point (3%), 레벨:8/30"){kind=icon}
크리스http://agileconsulting.kr/kbsost/moin.cgi
따로 쓸 게 없군요. 여기 다 있습니다.
OST(Open Space Technology)는 진입장벽이 낮은 세미나 방법으로 적합했습니다. 굉장히 재밌는 경험이었어요. 애자일을 도입한 사례, 등등등 요약은 역시 가시면 있습니다.
---------------------------- 이하 개인적인 감상
판타그램은 XBOX360 게임을 개발하면서 반강제적으로 애자일을 도입했다고 하던데, 어떤 개발론을 테스트 하기 위해서 드는 비용과 노력을 생각해 보면 XBOX360이나 닌텐도 게임을 개발하면서, 그들이 정립한 개발 프로세스를 도입하는 방법도 괜찮지 않겠나 싶었습니다. 어쨋든 우리나라 게임에 비해서 콘솔 게임들의 버그가 적은 것이 사실이니까요. 닌텐도가 애프터가 별로라고 하니 좀 논외일 수도 있겠습니다만. ...
그 밖에 제가 발제했던 세션2의 사용자 스토리와 인수 테스트 부분에서 인수 테스트는 제 전공 분야가 아니니 넘어가고, 개인적인 감상을 요약하자면
사용자 스토리가 만병 통치약은 아니고, 특히 백로그 추적이 어렵다는 문제가 치명적, 단독으로 쓰기는 어렵다는 결론이었습니다. 그러나 개발 초기 단계에서 만들어야 하는 게임의 모듈 공유 방법으로는 더없이 적합한 방법인 것 같더군요.
애자일을 도입할 경우, 제작에 드는 시간은 폭포수 방식이나 여타의 방식에 비해서 더 걸릴 수 있으나 안정적인 품질을 확보할 수 있다는 정보 또한 입수할 수 있었습니다. :)
그러나 많은 대화를 요구하는 애자일 도입은 단순히 대화의 빈도가 많아지는 것 뿐만 아니라 업무의 책임감 분담을 의미하는 것이기 때문에 서로에 대한 믿음과 책임감이 없이는 제대로 지속되기 어렵겠더군요.
ex) 기획서에 써 있는데 왜 빠진 거예요오~
ex2) 기획서에 써 있는대로 다 했는데 뭐가 문제예요?
뭔가 어떻게 보면 레임에 쓰기 애매한 글인데 개발자/지망생 분들도 많이 오시기 때문에 이런 재미난 것도 있더라 하는 의미로 남겨 봅니다.
OST 졸라 재밌어요. 우리도 해봅시다.
스토리 이야기를 하고 있는데 중간에 참여하신 분이 "책을 번역하면서 느낀 점인데..."로 말을 꺼내셔서 깜짝. 아닛 번역하신 분이셨구나!
김창준님은 여러가지 부분에서 배울 것이 많겠지만 그 중에서 특히 그 행동력은 반드시 본받아야겠다 싶더군요. 블로그 초반기부터 봤지만 그때는 애자일이 이렇게 빠르게 확산될 줄 몰랐습니다.
따로 쓸 게 없군요. 여기 다 있습니다.
OST(Open Space Technology)는 진입장벽이 낮은 세미나 방법으로 적합했습니다. 굉장히 재밌는 경험이었어요. 애자일을 도입한 사례, 등등등 요약은 역시 가시면 있습니다.
---------------------------- 이하 개인적인 감상
판타그램은 XBOX360 게임을 개발하면서 반강제적으로 애자일을 도입했다고 하던데, 어떤 개발론을 테스트 하기 위해서 드는 비용과 노력을 생각해 보면 XBOX360이나 닌텐도 게임을 개발하면서, 그들이 정립한 개발 프로세스를 도입하는 방법도 괜찮지 않겠나 싶었습니다. 어쨋든 우리나라 게임에 비해서 콘솔 게임들의 버그가 적은 것이 사실이니까요. 닌텐도가 애프터가 별로라고 하니 좀 논외일 수도 있겠습니다만. ...
그 밖에 제가 발제했던 세션2의 사용자 스토리와 인수 테스트 부분에서 인수 테스트는 제 전공 분야가 아니니 넘어가고, 개인적인 감상을 요약하자면
사용자 스토리가 만병 통치약은 아니고, 특히 백로그 추적이 어렵다는 문제가 치명적, 단독으로 쓰기는 어렵다는 결론이었습니다. 그러나 개발 초기 단계에서 만들어야 하는 게임의 모듈 공유 방법으로는 더없이 적합한 방법인 것 같더군요.
애자일을 도입할 경우, 제작에 드는 시간은 폭포수 방식이나 여타의 방식에 비해서 더 걸릴 수 있으나 안정적인 품질을 확보할 수 있다는 정보 또한 입수할 수 있었습니다. :)
그러나 많은 대화를 요구하는 애자일 도입은 단순히 대화의 빈도가 많아지는 것 뿐만 아니라 업무의 책임감 분담을 의미하는 것이기 때문에 서로에 대한 믿음과 책임감이 없이는 제대로 지속되기 어렵겠더군요.
ex) 기획서에 써 있는데 왜 빠진 거예요오~
ex2) 기획서에 써 있는대로 다 했는데 뭐가 문제예요?
뭔가 어떻게 보면 레임에 쓰기 애매한 글인데 개발자/지망생 분들도 많이 오시기 때문에 이런 재미난 것도 있더라 하는 의미로 남겨 봅니다.
OST 졸라 재밌어요. 우리도 해봅시다.
스토리 이야기를 하고 있는데 중간에 참여하신 분이 "책을 번역하면서 느낀 점인데..."로 말을 꺼내셔서 깜짝. 아닛 번역하신 분이셨구나!
김창준님은 여러가지 부분에서 배울 것이 많겠지만 그 중에서 특히 그 행동력은 반드시 본받아야겠다 싶더군요. 블로그 초반기부터 봤지만 그때는 애자일이 이렇게 빠르게 확산될 줄 몰랐습니다.
![[레벨:3]](http://old.lameproof.com/modules/point/icons/default/3.gif "포인트:1249point (69%), 레벨:3/30"){kind=icon}
ㅊㅋㅊㅋ![[레벨:5]](http://old.lameproof.com/modules/point/icons/default/5.gif "포인트:2940point (69%), 레벨:5/30"){kind=icon}
꿔니
2007.09.30 16:47:25 (*.29.235.123)
![[레벨:13]](http://old.lameproof.com/modules/point/icons/default/13.gif "포인트:16257point (43%), 레벨:13/30"){kind=icon}
neolith imc 제2개발팀에서 애자일을 어떻게 도입할 것인가에 대해 토의와 조사를 한 바가 있습니다.
애자일로 뭘 한다는게, 귀찮은 부가작업이 늘어나는 것으로만 느껴지거나, 실제로 그런 일시적 활동에 그쳐서도 안되겠지요
제일 중요한건 우리가 비판적으로 생각해보지 않았던 부분들에 대해 회의를 품고, 대안을 시도해보는 겁니다.
전통적인 단계별 개발에서는,
누군가 제대로 잘 정의된 기획서와 개발 계획을 만들어놓고 마일스톤을 수립한 다음에는
각 팀이 주어진 목표대로 작업을 한 다음 그걸 합치면 게임이 완성된다라는 점을 대전제로 깔고 있습니다
저희가 애자일이라는 대안을 생각하면서 내린 결론은 한번 그렇게 하지 말아보자는 것입니다.
애자일로 뭘 한다는게, 귀찮은 부가작업이 늘어나는 것으로만 느껴지거나, 실제로 그런 일시적 활동에 그쳐서도 안되겠지요
제일 중요한건 우리가 비판적으로 생각해보지 않았던 부분들에 대해 회의를 품고, 대안을 시도해보는 겁니다.
전통적인 단계별 개발에서는,
누군가 제대로 잘 정의된 기획서와 개발 계획을 만들어놓고 마일스톤을 수립한 다음에는
각 팀이 주어진 목표대로 작업을 한 다음 그걸 합치면 게임이 완성된다라는 점을 대전제로 깔고 있습니다
저희가 애자일이라는 대안을 생각하면서 내린 결론은 한번 그렇게 하지 말아보자는 것입니다.
2007.09.30 16:53:26 (*.29.235.123)
neolith 그럼 어떻게 한다는 것이냐? 무계획적으로 그냥 아무렇게나 한다는 것은 아닙니다. 다만, 정교한 장기적 계획의 한계와 비현실성을 인정하고
좀 더 단기적이고 체감할 수 있는 성과들을 누적시키는 방향으로 선회한다는 것입니다.
린 소프트웨어 개발에서도 나오는 두가지 사례가 요리의 레시피를 새로 개발하거나, 해병대의 군사작전을 수립하는 것의 예입니다
알려진 조리법대로 요리를 만드는 것과, 조리법 자체를 새로 발명하는 것은 매우 다른 일이고, 다른 방법으로 접근할 수 밖에 없는 영역입니다.
군사작전을 짜는 것과 실제 현장에서 각 대원들이 행동하는 지침 역시 다를 수 밖에 없습니다. 적들이 어떻게 움직일지는 실제로는 알 수 없으니까요
구체적인 장기적 계획을 짜는 대신에, 대략적이고 기본적인 방향만 정해놓고 (예: 마늘을 새롭게 이용한 퓨전 요리 레시피를 만든다 or 어떠한 희생을
감수해서라도 512 고지를 탈환한다) 구체적인 행동 방침은 그때 상황에 반응하면서 점진적으로 접근하는 것입니다. (일단 시험 요리를 만들어보고 맛을
본 다음, 다음에 어떻게 변형할 것인지 생각한다 or a 지점에 척후병을 보내놓고 그 결과에 따라 다음 행동이 달라진다)
좀 더 단기적이고 체감할 수 있는 성과들을 누적시키는 방향으로 선회한다는 것입니다.
린 소프트웨어 개발에서도 나오는 두가지 사례가 요리의 레시피를 새로 개발하거나, 해병대의 군사작전을 수립하는 것의 예입니다
알려진 조리법대로 요리를 만드는 것과, 조리법 자체를 새로 발명하는 것은 매우 다른 일이고, 다른 방법으로 접근할 수 밖에 없는 영역입니다.
군사작전을 짜는 것과 실제 현장에서 각 대원들이 행동하는 지침 역시 다를 수 밖에 없습니다. 적들이 어떻게 움직일지는 실제로는 알 수 없으니까요
구체적인 장기적 계획을 짜는 대신에, 대략적이고 기본적인 방향만 정해놓고 (예: 마늘을 새롭게 이용한 퓨전 요리 레시피를 만든다 or 어떠한 희생을
감수해서라도 512 고지를 탈환한다) 구체적인 행동 방침은 그때 상황에 반응하면서 점진적으로 접근하는 것입니다. (일단 시험 요리를 만들어보고 맛을
본 다음, 다음에 어떻게 변형할 것인지 생각한다 or a 지점에 척후병을 보내놓고 그 결과에 따라 다음 행동이 달라진다)
2007.09.30 16:58:03 (*.29.235.123)
neolith 게임에서도 마찬가지로 '어떤 초기 기획과 그 계획에 따라 열심히 만든 다음에 그걸 합쳐놨을때 그게 재밌고 잘 팔릴만할지에 대해서는 누구도 보장할 수 없다'
라는 점이 가장 큰 문제점입니다. 개별적으로 좋은 요소를 만들어 놓았다고 하더라도 그것이 합쳐졌을 때에 예상대로의 결과가 나올지는 함부로 예측할 수
없기 때문입니다. 항상 예상하지 못했던 다른 부분이 튀어나온다던가, 예상했던 시너지가 생기지 않는다던가 하는 실망스런 일이 벌어지게 됩니다.
rts와 rpg 를 합친다던가 mmo 와 fps 를 합친다던가, 던파같은 액션rpg에 3d 의 장점을 합친다던가... 하는 식으로의 상상속에서의 기획은 누구나 할 수
있지만, 그 결과물이 정말 재미있게 만드는 것은 전혀 다른 일입니다.
라는 점이 가장 큰 문제점입니다. 개별적으로 좋은 요소를 만들어 놓았다고 하더라도 그것이 합쳐졌을 때에 예상대로의 결과가 나올지는 함부로 예측할 수
없기 때문입니다. 항상 예상하지 못했던 다른 부분이 튀어나온다던가, 예상했던 시너지가 생기지 않는다던가 하는 실망스런 일이 벌어지게 됩니다.
rts와 rpg 를 합친다던가 mmo 와 fps 를 합친다던가, 던파같은 액션rpg에 3d 의 장점을 합친다던가... 하는 식으로의 상상속에서의 기획은 누구나 할 수
있지만, 그 결과물이 정말 재미있게 만드는 것은 전혀 다른 일입니다.
2007.09.30 17:02:27 (*.29.235.123)
neolith 정말 뭔가를 재미있게 만들려면 2년이란 개발기간동안, 프로그램 따로, 기획시나리오 따로, 그래픽 따로, 애니 따로 열심히 각자 데이타와 코드를
만들기 시작한 다음에 '2년후에 만나요~' 라는 식으로 개발을 진행해서는 정말 재미와 품질을 갖추기 어렵다는 사실을 인정해야 하고
또한, 아무리 열심히 진도에 맞춰 작업물을 만들어 놨어도, 그 결과물이 재미가 없거나 품질이 떨어진다면, 차라리 놀면서 아무것도 안한 것만 못하다
라는 사실을 인정하게 될 때 (실제로 경영진까지 포함되어야겠죠) 비로소 더 나은 방향을 찾아갈 수 있을 것입니다.
만들기 시작한 다음에 '2년후에 만나요~' 라는 식으로 개발을 진행해서는 정말 재미와 품질을 갖추기 어렵다는 사실을 인정해야 하고
또한, 아무리 열심히 진도에 맞춰 작업물을 만들어 놨어도, 그 결과물이 재미가 없거나 품질이 떨어진다면, 차라리 놀면서 아무것도 안한 것만 못하다
라는 사실을 인정하게 될 때 (실제로 경영진까지 포함되어야겠죠) 비로소 더 나은 방향을 찾아갈 수 있을 것입니다.
2007.09.30 18:48:12 (*.176.93.167)
크리스 3번째 리플을 보니 회사에서 "이것이 팔릴 지 안팔릴 지 설명해 보게."라며 PPT 자리를 여러 번 만든 게 생각나네요. 물론 앉아 계신 임원분들을 설득할 수야 있겠지만 그 분들이 인정하고 넘어간다고 해서 그게 진짜로 팔릴지는 알 수 없는 문제인데도 그 자리를 성공적으로 만들기 위해서 일정은 한 달이 밀리고. =ㅅ=
사실 개발자가 신이 아닌데 팔릴 지 안 팔릴 지는 모르는 거죠. "이 게임 재밌어?"라고 물어 볼 때도 "재밌으니까 만들지요."라고 답할 수도 없고. 임원진 분들이 재미없다고 생각했을 때 다른 사람도 다 재미없다고 생각할 지도 알 수 없고.
푸념같지만 잘 모르겠다는 걸 인정하는 게 정말 큰 일인 것 같아요.
사실 개발자가 신이 아닌데 팔릴 지 안 팔릴 지는 모르는 거죠. "이 게임 재밌어?"라고 물어 볼 때도 "재밌으니까 만들지요."라고 답할 수도 없고. 임원진 분들이 재미없다고 생각했을 때 다른 사람도 다 재미없다고 생각할 지도 알 수 없고.
푸념같지만 잘 모르겠다는 걸 인정하는 게 정말 큰 일인 것 같아요.
2007.09.30 18:52:40 (*.176.93.167)
크리스 ㅊㅋㅊㅋ님| 판타그램도 뭔가 바꿔야겠다는 의지가 있었겠지만 MS에서 요원분들이 내려와서 마구 주입시켰다고 하더군요. 충격적인 경험으로 말씀하시는게 요원분들이 "우리가 체크한 바 출시 예상일까지 버그 X000개가 나올 것으로 보이고 수정하는데는 대략 3개월이 더 걸릴 듯 하니, 일정을 연기시키시오."라고 말했다고 하더군요. 어떻게든 할 수 있을 거라고 믿었지만 실제로 버그를 모두 잡는데 MS에서 제시한 만큼의 시간이 걸렸다고 하고요. 뭔가 여러 가지 어려움이 있었으나 MS는 되더라. 라는 뭐 그런 이야기가 오고 갔었습니다.
사실 각자가 일하는 방식을 인정해 주는 게 제일 좋겠지만 경영진 분이 열린 마음이 아니고서는 도저히 어렵고, 다른 프로세스 대비하면 애자일이 효과가 좋을 것이다 하는 정도의 느낌이었습니다.
사실 각자가 일하는 방식을 인정해 주는 게 제일 좋겠지만 경영진 분이 열린 마음이 아니고서는 도저히 어렵고, 다른 프로세스 대비하면 애자일이 효과가 좋을 것이다 하는 정도의 느낌이었습니다.
2007.09.30 19:44:54 (*.29.235.123)
neolith 버그가 없도록 갈고 다듬는 것과, 정말 재미가 우러나올때까지 다듬는 것은 성격이 좀 다른 얘기죠. 버그가 없다고 재미있는건 아니니까요
2007.09.30 20:24:05 (*.176.93.167)
크리스 두 가지가 엄연히 다른 범주라는사실에는 동의하는데 재미있다고 버그가 난발하는 상황도 좋지는 않지요.
개인적인 감상은 애자일은 재미나게 일하면서 어느 정도의 퀄리티를 보장해야 한다는 필요성을 게임 업계에서 많이 느꼈기 때문에 다른 업계보다 게임업계에서 더 빠르게 퍼지는 것 같습니다. 개발기술이나 판매에 대한 노하우는 어느 정도 습득되었기 때문에 이제부터는 전체적인 질을 높여야 할 때이니까요.
개인적인 감상은 애자일은 재미나게 일하면서 어느 정도의 퀄리티를 보장해야 한다는 필요성을 게임 업계에서 많이 느꼈기 때문에 다른 업계보다 게임업계에서 더 빠르게 퍼지는 것 같습니다. 개발기술이나 판매에 대한 노하우는 어느 정도 습득되었기 때문에 이제부터는 전체적인 질을 높여야 할 때이니까요.
2007.10.01 00:11:33 (*.29.235.123)
neolith 단순히 버그가 적거나 없는 것만이 목적이라면 꼭 애자일을 쓸 필요가 있을지는 잘 모르겠습니다.
"고객의 가치"라는 것을 처음부터 엄밀히 정의하기 어렵기 때문에 애자일이 필요한 것이겠죠.
버그가 있다/없다의 문제는 일의 효율성 문제라면, 재미가 있다/없다의 문제는 일의 효과성의 영역에 속하는 것이기도 하고요
"고객의 가치"라는 것을 처음부터 엄밀히 정의하기 어렵기 때문에 애자일이 필요한 것이겠죠.
버그가 있다/없다의 문제는 일의 효율성 문제라면, 재미가 있다/없다의 문제는 일의 효과성의 영역에 속하는 것이기도 하고요
![[레벨:11]](http://old.lameproof.com/modules/point/icons/default/11.gif "포인트:12461point (75%), 레벨:11/30"){kind=icon}
왕풍뎅이
애자일 자체가 강제적으로 도입될만큼 기존대비 귀찮은 프로세스가 되는 순간 이미 애자일이 아닌게 아닐까 하는 생각 - 강제적으로 도입했다는 회사가 있단 얘기를 듣고 그냥.