이제까지 이런 방식으로 해왔던 것은 아니고, 그동안 기획과 QA 사이의 내부적 혼선.. 특히 패치 바로 전에 공지로 준비한 사항과 실제 데이타 변경 내용이 맞지 않아 유저들에게 버그접수가 다수 있었던 경험으로 부터 생각해낸 아이디어입니다. 효과가 있을지는 앞으로 좀 더 두고보아야 할 듯
2006.08.16 17:43:47 (*.235.93.97)
나니실타
=_=;;
2006.08.16 17:44:09 (*.209.10.21)
antilame
하지만 뭔가가 나온다고 알림으로 인해 기대도를 올렸다가 여러 사정으로 인해 내용 변경이나 삭제등의 일이 일어난다면 일은 좀 거시기 해지겠죠 -,.-;
2006.08.16 17:55:07 (*.75.114.56)
김주완
antilame// 공지를 외부에 먼저 올린다는 게 아니라, 제작팀 내부적으로 공지사항을 올렸을 때를 가정하고, 거기에 맞게 제작한다는 것 말같은데요-_-
2006.08.16 18:01:32 (*.218.224.61)
neolith
아 물론 내부에서 준비하는겁니다. 패치 안되었는데 공지 올리면 안되죠.
2006.08.16 18:21:06 (*.221.81.83)
graytutor
이와는 반대로 마비노기에서는 패치를 하고, 그것만 추려서 공지를 한다.. 라고 하던가.. -ㅅ-a
2006.08.16 18:57:31 (*.83.149.113)
NARINEA
내부에서 자체공지로 저렇게 한다면야 목표를 주고서 하는거니까 ... 그리고 의사소통 교환은 잘되겠습니다만
효과는 미지수일듯 ..
2006.08.16 19:17:03 (*.255.199.207)
마이네트
조금은 이해가 안되는군요. 그럴 경우, 공지 자체가 개발목표일텐데....목표를 정하고 시행할 때는 혼선이 오고, 공지화해서 보여주면 혼선이 안된다는 말인가요? 목표를 설정할 때는 내용을 너무 포괄적으로 잡는다는 것으로밖에 이해가 안됩니다만....!
2006.08.16 20:40:11 (*.191.38.37)
음
옛날에 마비에서 비슷한 예를 봤던거 같네요.
주욱 개발 목록을 공지해 놓고
개발완료 , 개발중, 개발예정
으로 표시를 해뒀었죠?
2006.08.16 21:17:20 (*.70.61.227)
snowflower
'_' 쿨럭..;;;
2006.08.16 22:08:16 (*.243.236.38)
그랑죠
어찌보면 공지와 개발목표를 확실히 일원화하고 혼선도 피할 수 있으니.. 개발 프로세스를 단축시킬 수 있어 여러모로 장점이 많은 듯 합니다. 결과도 꼭 올려주세요 ^^
2006.08.16 22:15:51 (*.75.114.222)
김주완
이 명제를 역으로 바꾸면 '선개발 후공지'
그런데, '현실적'으로 실무진들은 개발현장에서 처음 주어졌던 과제 외의 변경점, 추가점들을 발견할 수도 있을 것 같습니다.
이 때 개발진들이 '개선시켰으니까 좋은 거 아냐?'라 생각하고 임의적으로 결과물들을 패치에 포함시키면
실제로는 개발목표에 초과된 사항이 생기지만, 정작 관리하는 파트에서 모른채, 공지를 띄우게 되고,
그러면 잠수함 패치가 되는 거 아닐까요. 이 점을 보완하기 위한 시도같음.
2006.08.16 23:54:00 (*.247.29.73)
ꎡS
헐.. -_-);; 왜 저거보고 뇌업플이 생각났지;
2006.08.17 01:25:35 (*.50.13.52)
PizaNiko
테스트 주도형 개발이 요사이 부각되고 있는 것 같던데, 그것이 이런식으로 응용이 가능하군요.
2006.08.18 11:25:58 (*.131.193.55)
makiable
효과는 확실할 것 같은데요..
공지의 목적은 "정확한 업데이트 사항에 대한 정확한 정보 공유",
개발자와 QA팀간에 혼선을 야기할 수 있는 커뮤니케이션과 신뢰도를 강제적으로 나마 올릴 수 있겠는데요..-0-;;
결국 올바른 기획과 올바른 개발 올바른 QA, 각 팀간의 올바른 커뮤니케이션 강화란 말이 안통하니 강제적으로 ㄱㄱ ...
시행 후 결과 발표 기대하겠습니다.
2006.08.18 17:48:32 (*.220.200.60)
sweetlover
만약에 QA팀과 상의한 내용이 개발 중 부득이하게 바뀌게 될 경우에는 공지 내용이 바뀌는 것 아닌가요?
모.. 약한 태클입니다. ^^;;
빌드 리스트 체크는 굉장히 중요한 항목인데, 빌드 리스트 체크하는 사람이 꼼꼼하지 않거나,
또는 그것을 관리하는 주무 부서가 없거나(공동관리라는 미명하에요.)
관리 책임자, 또는 실무자가 없거나(이것 역시 부서 작업물은 부서에서 관리라는 미명하에)하는 문제가 아닐까요??
그냥.. 미리 정해 놓고 개발을 하더라도, 말씀하신 것과 같은 문제는 계속 생기지 않을까 싶습니다.
모 너무 가혹한 방법일 수도 있지만, 누군가 총대를 맬 사람을 세우는 것이 더 근본적인 해결 방법이 아닐까 하는 생각이 들어서
이렇게 끄적여봤습니다.
2006.09.08 10:25:20 (*.120.29.167)
와탕탕
QA 프로세스를 새롭게 정립해서 타팀과의 커뮤니케이션이 원활히 진행 된다면,
해결될 수 있는 문제가 아닐까 생각하게 되네요.
TDD 장점은 공지사항을 먼저 써서 개발팀과 QA팀의 합의하에 개발이 진행된다면,
내부적으로 각팀에서 내역이 원활히 계획된고 커뮤니케이션에 문제가 없어질 것이고
외부적으로는 유저의 신뢰를 얻을 수 있을 것 입니다.
반대로 TDD의 단점은 공지사항을 먼저 작성하여, 실제 개발에 들어갔을 때 예기치 못한
문제점과 유저 플레이 성향이나 발견되지 못한 버그들로 인하여 개발일정이 변경되거나
패치내역이 변경 되었을 때 유저의 신뢰가 순식간에 무너질 수 있습니다.
게임을 유지보수 하고 업데이트 한다는게 변수가 많은 부분이라서 이런 두가지 장,단점을
봤을 때 단점이 더욱 크게 문제가 될 거라고 생각 합니다.
위의 근본적인 문제는
첫째. 각팀간의 커뮤니케이션의 부재로 업데이트 내역이 변경되거나 잘못된 데이트가 입력되는 등의 문제가 발생 합니다.
둘째. 각팀의 담당 업무에 되는 잦은 실수
업데이트를 하는 과정에서 데이터 수치를 잘못 입력하여 문제가 발생 될 수 있고 개발과정에서 예상하지 못한 버그들이
발생될 수 있습니다. 이부분은 개발과정에서 어쩔수 없이 발생될 수 있는 버그이지만 개발과정에서의 실수를 최소화 한다면
매우 좋아질 것으로 생각 합니다.
여기서 QA팀과 운영팀에서는 개발실에서 개발된 패치 파일을 가지고 게임 내 여러가지 패턴과 게임 게임 플레이를 통해서
업데이트 내역과 기존 게임 시스템과 기능 등을 철저하게 테스트해서 개발과정에서 발생될 수 있는 버그들을 최대한 잡아줘야
합니다. 뿐만 아니라 유저들이 판단하기에 옮지 않은 업데이트 내역 등 개선 사항에 대해서는 적극적으로 개발실과 논의해서
수정이 필요한 부분은 수정을 해야 합니다. 여기서 테스트가 제대로 이루어지지 않으면 유저의 신뢰가 순식간에 무너지게 됩니다.
셋째. 제대로된 QA 프로세스를 정립해서 기획부터 개발, 테스트, 업데이트의 모든 부분을 참여하여
안정적인 업데이트와 확실한 게임 테스트를 해 게임의 퀄리티를 높히고 품질향상을 시킬 수 있게 하는것이
중요할 것 입니다.
현재의 QA프로세스 나 개발 프로세스의 문제점을 먼저 파악해보는 것이 조금더 좋지 않을까 생각 하게 되었습니다.