'컨설팅'에 해당되는 글 1건

  1. 2011/08/02 글뻥 Agile Iteration 1종료 회고에 대한 후기 (2)
일전에 교육했고 그 교육을 기반으로 Iteration 1을 종료하고 (업무일:10일) 팀원/PM분을 모시고 회고를 가졌습니다.
앞부분은 업무 성과 부분으로 영업보안을 지켜드려야 해서 제외했음을 인지하여 주세요.

== 전략 ==

2. 회고
   a. 잘된점
      - 커뮤니케이션이 원할했다.
      - 함께하는 스케쥴
      - 새로운 경험을 해서 좋았다.
   b. 잘안된점
      - 일정압박이 괴로웠음.
      - 새로운 업무, 프레임워크, 접근법에 대한 부담감이 괴로웠음.
      - 많은 일을 해야 해서 힘들었음.
   c. 새로운사실
      - 혼자하는 것보다 확실히 Performance가 오르더라.
      - JSON을 배운다는게 재미있더라.
      - AJAX, JQuery 등을 새로운 지식을 배워서 재미있었다.
      - 교육후 실무에서 Core 지식은 실무에 사용할 수 있었다.

== 후략 ==

대체적으로 아직까지는 팀원들은 만족하고 있습니다.
문제는 만족의 범위가 "팀원"입니다. -_-;;

PM분께서는 교육 참여도가 저조하셨고 회고역시 시간 낭비라는 생각을 가지고 계셨던지 회고 시간 내내 시간 낭비라고 생각하시는 것 같았습니다.
아무래도 이러한 영역까지 커버를 해야 재미가 있을 것 같은데 아직은 잘 안되는 군요.
특히 시스템을 프로젝트로 끌어와서 무언가 업무를 시스템화 하는데 부담이 큰것 같습니다.
실례로 현재까지 도입된 도구와 사용여부는 다음과 같습니다.

Planning Poker : 일부사용
Staruml : 사용
Jira : 미사용
Hudson : 미사용
Confluence : 일부사용
SVN : 사용

이전에도 이런 경험이 있었는데, PM 즉, 개발의 주체가 잘 받아 들이지 못하게 되면 그 프로젝트에서 Agile은 소리 소문없이 사라집니다.
그러나, 하나 희망적인 점은 UML산출물은 교육/컨설팅 받았던 회사에서 사내교육으로 전사로 전파교육이 되어 제가 따로 알려드리지 않았음에도 2주일만에 방문드린 회사에서 모든 개발자들이 UML로 산출물을 만들고 있는 장면을 목격했습니다.

아무래도 개발자들에게 추상적인 개념보다는 어려운 새로운 프로세스보다는 산출물 만들고 코드를 구조화하기 쉬운 UML이 더 동기유발이 된 것 같더군요.

저는 Agile에 발을 들여 놓은게 UML을 공부하면서 개발 도구를 하나씩 끌어다 쓰면서, 그걸 더 잘쓰기 위해 Agile기법을 사용하면서 부터 였기때문에 희망적이라는 표현을 썼습니다.

알고계시겠지만, 우리가 흔히 사용하고 있는 도구들은 변화에 적합합니다.
예를 들어,
==============================================
Hibernate와 같은 ORM도구는 Entity 와 Control 영역의 변화에 대응하며,
UML은 전체의 구조의 변화에 대응하고,
Jira와 같은 Issue Tracker는 업무의 변화에 대응하며,
Soap과 같은 Open API 아키텍쳐는 Boundary와 Control의 변화에 대응됩니다.
더 나아가 Wiki와 같은 문서도구는 문서 산출물의 변화에 대응하지요.
한 발자국 더 나아가면 각종 게임엔진들은 또 어떻습니까? 이제는 플랫폼을 국한시켜 개발할 필요가 없는 시대입니다.
==============================================

이러한 도구들을 사용해 몇 번의 신속한 변화에 대한 대응을 체험하면 사람이 변화에 대응하지 못하는 상황이 발생합니다.

처음에는 사람이 변화를 주도하지만 조금 익숙해지면서부터는 시스템의 변화대응속도가 인간의 심적 변화속도를 앞지르게 되는데 이때, 인간은 이성과 심리의 변화속도의 괴리가 발생하게 되며, 이성적으로 합리적인 상황이지만, 심적으로 고통받는 상황이 연출됩니다.

제가 요즘 찾고 있는 영역이 바로 저러한 현상에 대한 연구, 솔루션의 발견입니다.

예를 들어, 3개월에 5명이 일하는 규모의 프로젝트가 있다고 가정합시다.
이 프로젝트는 Waterfall방법으로 개발했고 주구장창 밤샘작업 끝에 프로젝트 완료후 버그 수정 및 업그레이드에 매달리는 프로젝트 입니다.
또 하나의 프로젝트는 3개월에 5명이 일하는 규모의 프로젝트임에도 Agile 사상을 적용하여 변화에 신속히 대응합니다.
이미 출시전에 최소한 5번의 변경이 있었고 팀은 변화에 빠른 대응을 통해 고객의 만족도는 매우 높습니다. 고객도 이미 비슷한 일을 Waterfall로 해봤기에 자신들의 소리를 들어 주지 않는 팀에 비해 Agile팀이 더 만족스럽습니다.

두 접근방법을 비교하자면 Waterfall은 Agile에 비해 고객에게는 정신적 고통을, 개발팀원에게는 신체적, 정신적 고통을 안겨줍니다. 정확한 데이터가 없어도 좋습니다. 우리는 경험으로 알고 있고 수 많은 주변 사례가 이를 증명하며, 성공한 프로젝트가 30%도 채 안된다는 사실자체가 이를 증명합니다.

그런데, Agile 접근법의 문제는 여기서 터집니다. 출시일을 1달가량 남겨놓고 모든 일을 다 끝냈다고 하더라도 앞으로 변화는 없을까요?
다시말해, 3개월 프로젝트를 고객과의 협력과 우수한 팀의 역량을 토대로 출시 1개월전에 예전에 목표했던, 그리고 후에 변경했던 목표까지 도달했습니다. 그러면 고객이 "아~ 목표치를 다 하셨으니 이제 집에 가세요~" 이럴까요? 현실은 시궁창이었습니다. 남은기간동안 계획되지 않은 요구사항 변경이 일어납니다. 실재로는 "어~ 이거 고쳐주세요.", "저것도요~"의 요구사항 변경이 이전보다 더 많이 발생됩니다.

위의 사례는 실재로 겪었던 문제입니다.
이전에 개발했다고 포스팅드린 AR솔루션은 저작도구까지 단, 3개월만에 개발이 완료된 제품이었습니다.
그때 제기억으로 총 6개월의 프로젝트 기간이었으니까, 우리는 그 솔루션을 절반의 리소스로 개발하였습니다.
그것도 잔버그 없이 훌륭히 작동하는 제품이었습니다.
(실재로 독일 북페어, 미국 시장 테스트, G7 서울회의 기념 IT전시회, 바로셀로나 모바일 월드 콩그레스를 버텨냈지요.)

그러나, 우리는 나머지 4~5개월을 제품을 수정하는데 우리의 에너지를 모두 써버렸고, 결국 팀은 붕괴되었습니다.

수 많은 이유가 있었지만 팀원들의 공통적인 심적 고통은 "변화에 대응하는게 이론적으로는 맞다. 그리고 우리가 잘해왔다. 그런데, 왜 그래야 하는지 모르겠다." 였습니다.

그렇다고 이전에 하던 프로젝트보다 힘든점은 없었습니다. 야근을 밥먹듯이 한적도 거의 없고 정시 출근, 정시 퇴근하면서 주말에는 꼬박꼬박 쉬었죠. 사내 커뮤니케이션 하느라 보고서 쓸때가 일하고나서 해야하니 천상 밤에 하게되어 그게 제일 힘들었습니다. 거의 모든 개발자들이 꿈꾸는 그런 환경이었음에도 저러한 문제가 발생한겁니다.

여러가지 정치적 상황도 많았지만, 현재도 이러한 문제가 없다고 하기 어렵습니다.

또 하나의 사례를 들어보면 현재 같이 일하고 있는 사람들간에도 나타는 문제이기도 합니다.
처음에 우리는 app을 개발하며 커뮤니케이션 도구를 개발하려고 목표를 정했습니다.
그러다 1주일도 안되어 시장조사후 심리치료 도구를 개발하려고 했고,
또 시장상황과 우리의 역량을 체크한후 시장에 바로 팔 만한 케쥬얼 게임을 개발하려다가,
2주일후 습작으로 만든 케쥬얼 게임이 오히려 빠른 출시에 도움이 될거란 판단과 은근한 중독성에 매료되어 이쪽으로 방향을 급선회 어느정도 목업단계를 벗어나 튜닝단계로 접어 들었습니다. (한 3~4일 걸린듯 합니다.)

그런데, 우리중 한분이 벙~ 쪄있는 상태입니다.
전례에 비추어 볼 때 우리가 성공하더라도 이분이 끝까지 버틸거란 생각이 들지가 않습니다.
그리고, 이 분은 우리에게 꼭 필요한 분입니다. 설사 이분을 다른분으로 대체한다고 해도 우리의 변화속도에 쉽게 따라올 거란 생각은 잘 안듭니다.
그래서 이 기회에 무언가 다른 시도를 해볼 생각이며, 제가 해결하고자 하는 과제로 "환경의 변화에 따른 이성과 심리적 괴리에 관한 연구와 솔루션"을 잡은 이유이기도 합니다.

행복은 이성이 아니라 마음이 말들어 주니까요.
2011/08/02 14:29 2011/08/02 14:29