같은 생각을 시행하시는 분이 계셨군요. 영회님의 블로그 글(http://younghoe.info/994#footnote_link_994_1)
현재 진행중인 프로젝트에 있어서 여러가지 사정에 의해 약식으로 혹은 추후를 기약하며 넘어가곤 하는데, 이러한 알고리즘 혹은 프로세스들에 대해 기술적인 리뷰는 반드시 필요하다고 생각합니다.
보편적으로 프로젝트 진행시, 일정에 맞춰 단위별로 팀원들에게 할당해주고 설계상의 변경이나 문제발생시에만 간헐적인 기술미팅을 진행합니다. 하지만 해결점을 찾기전까지 장기화되는 경우가 많고 적절한 답을 찾지 못하는데서 오는 스트레스도 이루 말할 수가 없죠. 그리고 대부분은 개발자의 역량에 맡기는 부분이라 공개되지 않는 프로세스에 대한 검증작업은 엄두고 못내고 있는 상황이 보통입니다. 하지만 기능향상과 잘못된 로직에 대한 수정을 위해서라도 리뷰는 필요합니다. 직접적인 개발에는 참여하지 않았더라도 전체적인 흐름을 이해하는 시간이 될 수도 있고, 다양한 시각에서의 아이디어를 통해 의외의 해답을 찾거나 최적화 시킬수도 있는 부분이니까요.
또한, 이런 리뷰 진행이 정기적으로 시행된다면 개발자 스스로도 자신이 개발한 부분에 대해 책임감을 갖고 할 뿐더러 어설픈 땜질은 하지 않겠죠, 무엇보다 미쳐 생각치 못했던 부분에 대해 멋진 해결안을 얻을수도 있다는 점은 프로젝트를 성공시키는데 지대한 영향을 미칠거라는 생각이 드네요.
물론 모든 리뷰내용과 거론되었던 사항은 문서화되어 정리되어야 되겠구요. 이것을 위해서는 참여자들의 적극성과 공동작업에 대한 자각이 필요한 부분이긴 합니다만, 언제나 간섭받기 싫어하며 개별인으로 활동하는 개발자들도 로직, 프로세스 관련 얘기할땐 집중을 하더군요-그나마 다행스런 일입니다-.
내부세미나의 중요성과 유익성에 대해서는 궂이 언급할 필요는 없을 듯 합니다.
그럼 지금부터가 시작이군요. 저부터 시작하면 될테니까요.
현재 진행중인 프로젝트에 있어서 여러가지 사정에 의해 약식으로 혹은 추후를 기약하며 넘어가곤 하는데, 이러한 알고리즘 혹은 프로세스들에 대해 기술적인 리뷰는 반드시 필요하다고 생각합니다.
보편적으로 프로젝트 진행시, 일정에 맞춰 단위별로 팀원들에게 할당해주고 설계상의 변경이나 문제발생시에만 간헐적인 기술미팅을 진행합니다. 하지만 해결점을 찾기전까지 장기화되는 경우가 많고 적절한 답을 찾지 못하는데서 오는 스트레스도 이루 말할 수가 없죠. 그리고 대부분은 개발자의 역량에 맡기는 부분이라 공개되지 않는 프로세스에 대한 검증작업은 엄두고 못내고 있는 상황이 보통입니다. 하지만 기능향상과 잘못된 로직에 대한 수정을 위해서라도 리뷰는 필요합니다. 직접적인 개발에는 참여하지 않았더라도 전체적인 흐름을 이해하는 시간이 될 수도 있고, 다양한 시각에서의 아이디어를 통해 의외의 해답을 찾거나 최적화 시킬수도 있는 부분이니까요.
또한, 이런 리뷰 진행이 정기적으로 시행된다면 개발자 스스로도 자신이 개발한 부분에 대해 책임감을 갖고 할 뿐더러 어설픈 땜질은 하지 않겠죠, 무엇보다 미쳐 생각치 못했던 부분에 대해 멋진 해결안을 얻을수도 있다는 점은 프로젝트를 성공시키는데 지대한 영향을 미칠거라는 생각이 드네요.
물론 모든 리뷰내용과 거론되었던 사항은 문서화되어 정리되어야 되겠구요. 이것을 위해서는 참여자들의 적극성과 공동작업에 대한 자각이 필요한 부분이긴 합니다만, 언제나 간섭받기 싫어하며 개별인으로 활동하는 개발자들도 로직, 프로세스 관련 얘기할땐 집중을 하더군요-그나마 다행스런 일입니다-.
내부세미나의 중요성과 유익성에 대해서는 궂이 언급할 필요는 없을 듯 합니다.
그럼 지금부터가 시작이군요. 저부터 시작하면 될테니까요.