엿들은 Agile 이야기
개발하면서/Agile 2007/07/02 08:54 |
아는 형님의 글 테스트 tool과 Pair Programming을 통한 기획력 향상과 개발자와의 협업 증대 에서
이부분의 해결책으로 제시된 TDD 와 Pair-Programming 은 분명 좋은 해결책이 될 수 있다고 생각하지만....
문제는, 과연 이부분을 진행하기 위해 기획자들이 이 것에 대해 배우려 할 것인가이다.
또한 개발자가 주도적으로 이 것을 이끌수 있는 환경인가도 생각해 봐야할 일이다.
결국 파워를 갖고있는 누군가가 책임을 지고 이끌어 나가지 않으면 아무리 좋은 방법론도 다 그림에 떡인 셈이다.
친구와의 agile 이야기 를 엿듣고, 암튼...agile 이야기를 나도 시작해 봐야겠다.
이 부분은 참으로 동감하는 부분이며, 이 것에 대해 그 형님과 자주 이야기를 하곤 했다.
왜냐하면 근본적인 문제는 기획자에게 바라는 산출물에 대한 회사와 개발자들의 요구사항이 명확하지 않다는데 있는 것일세. 즉, 언제부터 기획자들의 ppt 파일이나 doc, 혹은 visio 파일들이 기획 산출물인양 굳어져 버렸는 지. 우선 이런 문서들이 개발에 도움을 주는 지, 부족하다면 무엇을 어떻게 명확하게 요구해야 하는 지. 이런 질문에 대한 연구나 아이디어가 없다는 것은 결국 기획자와 개발자들 그리고 회사의 임원들 모두의 문제인 것일세.
이부분의 해결책으로 제시된 TDD 와 Pair-Programming 은 분명 좋은 해결책이 될 수 있다고 생각하지만....
문제는, 과연 이부분을 진행하기 위해 기획자들이 이 것에 대해 배우려 할 것인가이다.
또한 개발자가 주도적으로 이 것을 이끌수 있는 환경인가도 생각해 봐야할 일이다.
결국 파워를 갖고있는 누군가가 책임을 지고 이끌어 나가지 않으면 아무리 좋은 방법론도 다 그림에 떡인 셈이다.
친구와의 agile 이야기 를 엿듣고, 암튼...agile 이야기를 나도 시작해 봐야겠다.
이올린에 북마크하기
이올린에 추천하기'개발하면서 > Agile' 카테고리의 다른 글
| 엿들은 Agile 이야기 (4) | 2007/07/02 |
|---|
댓글을 달아 주세요
회사와 개발자의 기획자에 대한 요구사항이라기 보다는 근본적으로 사용자, 즉, 돈을 쥐고 있는 사람이 원하는 것과 기획자가 그것을 구현하려고 하는 자신의 생각에서 이미 gap이 생기고, 그것을 구현하는 개발자와 또 한번의 gap이 생기는데, 이를 어떻게 최소화 하는 가 하는 것이 관건이겠죠. 하지만, 이미 기존의 관습에 젖어 있는 기획자와 자신만의 세계에 빠져 헤어나지 못하는 개발자들을 보고 있으면 희망이 보이지 않는다는... 결국 제일 중요한 것은 최소한 사용자가 원하는 것 그대로를 만드는 것인데. 어느 순간 그것을 망각하고, 자신만의 제품을 만들어가기 시작한다는거...기획자건 개발자건 언제나 '을' 이라는 사실을 잊지 말기를... 기획을 위한 기획과 개발을 위한 개발이 무슨 의미가 있는지...
고객을 생각하자는 의미인듯 한데..그 부분에 대해서는 나도 동감일세.
본문의 글은 기획자와 개발자간의 갭을 좀 더 중요하게 부각 시켰는데..이것은 실제로 실무를 하다보면 가장 크게 느껴지는 갭이기 때문이라네..다양한 문제들이 항상 여기서만 발생하는 것은 아니겠지. 다만 가장 우선적으로 기획자와 개발자간의 갭의 해결이 무엇보다 중요하다는 생각임
또한 개발 방법론이 됐건, 품질보증활동이 됐건 이러한 모든 process는 무에서 유를 창조해 내는 것이 아니라는거죠. 즉, process를 적용해서, 수행하는 주체가 되는 팀원들의 각 개인별 역량차이를 하향평준화 되지 않도록, bottle neck이 되는 팀원에 팀의 역량이 평준화 되지 않고, 말그대로 평균정도의 성능이 나올 수 있도록 해주는 것이라고 볼때, 그 process를 수행하기 위한 최소한의 역량은 갖추고 있는 사람들한테나 위에서 이야기 하는 process의 적용이 가능하다는 거죠. 맨땅에 헤딩하면. 이마만 깨진다는거.
중요한 지적일세.
이것은 우선 방법론을 채택한 이후에 진행하는 과정에서 발생하는 문제인데.
우선 현실적으로 새로운 방법론을 도입하는 것 자체가 힘든 것이 사실이고....
도입했다고 해도, 언급한 것 처럼 팀원들이 그 수준을 따라오지 못하면(사실 새로운 툴을 배우는 것 조차도 꺼려하는 개발자가 존재한다) 방법론 자체의 결함으로 치부되서 '이론은 이론일뿐' 이란 결과만 남기고 다시는 새로운 방법론의 시도조차 어렵게 만들지.
어쩌면 불합리해 보이는 현재의 개발시스템은 피해자로 보이는 개발자들이 자기무덤을 판 격인지도 모르지