글 검색 결과 - 분류 전체보기 (총 27개)
한국의 대기업 - 특히 제조 중심의 회사에서 소프트웨어 개발은 아직도 Water Fall 방식을 따르고 있다(물론 모든 기업, 혹은 기업내의 사업부별로 다르지만, 제조에 바로 묶인 부서에서 Agile등을 적용한 부서는 많지 않다고 본다). 아무래도 소프트웨어 주기가 아닌 제품의 개발주기에 묶여 있고, 이들 제품 사양(Specification)에 대한 결정 역시, 소프트웨어가 아닌 제조에서 결정되다 보니, 제품 하나에 대한 여러 서류 작업등을 동반하게 되고 이에 설계문서, 요구사항 문서 등등을 내놓고, 각 일정을 보일수 있는 Water Fall 방식을 선호할 수 밖에 없다고 본다. .
물론 이러한 개발 방법에 대한 요구는 소프트웨어 단독으로 제품이 이루어지지 않는 TV, Mobile 제품의 개발에 있어서 선호할 수 밖에 없다고 생각된다. 하지만, 이러한 제품들을 위해서 소프트웨어 모듈을 개발하다보면 언제나 느끼는것은 생색내기에 그치는 것밖에 없는 빈문서로 채운다는 것, 그리고 이렇게 초기에 잡아놓은 일정이라는 것이 한마디로 희망사항만을 명시한 문서로 전락된다는 것이 문제인것 같다.
몇일전 회의에 들어갔다. 내년 제품을 위해 요구사항을 다양하게 준곳에서 이번에는 올해 제품의 사양을 변경해 달라고 한다. 최대한 소프트웨어 개발 입장에서 할수 있을까 하는 일정으로 제시했는데, 돌아오는 말이 전무님 지시사항이니 알아서 기라고 한다. 더 웃긴것은 상무 지시로 바꾼걸 전무 지시에 영향을 미치니 무슨 상무가 요청했냐고 이름을 대라고 한다. 한숨쉬도 돌아와보니 다음주까지 다른 설계문서를 만들어내라고 한다. 설계문서로 바로 코딩할수 있도록 준비하라고.. 결국 설계서대로 만들어도 한마디면 날아갈 종이를 왜이리 힘들여서 주말내 만들어야 하는지 이해하기 힘들다.
빠르게 기민하게 요구사항을 대응하기도 바쁜데, 문서작업하고, 문서에 맞게 개발해도 바꾸어서 문제, 문서에 맞지 않게 개발해도 문제.. 이제는 조금 다른 방법을 찾아봐야 되지 않을까 싶다.
