살다보면 나도 모르게 좋은 기회가 찾아온다고 하는데요. 이 기회를 놓치지 않고 잡아야 인생이 풀릴것입니다. 최근 저는 다행히 이 기회를 한번 잡았던 것 같습니다.

팀내 Agile을 적용해보라는 지시를 받았습니다. Agile은 제가 개발자 경력을 쌓으면서 이분야에 전문가가 되겠다고 다짐하고 공부했던 기법입니다.

그러나 팀 적용을 위한 여건이 안되서 혼자만 두문불출하다가 일단 접어서 좀 아쉬워 했죠. Agile을 좀 잊어갈때쯤 팀장님이 한번 적용해 보라고 하니 저는 제 개발자 인생의 하나의 숙제였던 Agile을 풀어볼 기회를 얻은 것입니다.

Agile의 개요를 정리해서 발표도 하고, 사용자 스토리의 주요 기법을 실습도 했습니다. 팀원들의 반응도 좋았습니다. 일단 Agile 도입 실습을 마무리할때쯤 저는 혼자 두문불출할때와는 다르게 몇가지 새롭게 깨달은 점이 있었습니다.

Agile을 우리나라 프로젝트에 도입하기에는 다음의 어려운 점이 있다는 것을 알게 되었습니다.


1. 표준화의 어려움

예를 들어 CBD 방법론 같은 경우 이 방법론을 적용하기 위해서는 이런 절차를 따라야 하고 단계별로 이런 산출물이 나와야 한다~ 라는 명확한 가이드라인이 있습니다. 다양한 프로젝트 레퍼런스도 있습니다.

그러나 Agile은 이렇게 해야 Agile을 한다~ 라는 표준화된 가이드라인이 존재하지 않습니다. Agile 관련 산출물도 따로 없습니다. 누구는 SVN, 이슈관리시스템의 도구를 쓰자고 그러고 누구는 각 단계별 나름 새롭게 산출물을 정의해보자라고 하는등 팀원간의 의견도 분분했습니다.

우리가 Agile의 이런 기법을 쓰고 이런 산출물이 나오기 때문에 Agile을 한다~ 라고 정리 하기 어려웠고, 참고할만한 레퍼런스 사이트도 없기 때문에 표준화의 어려움이 있었습니다.

(Agile에서 굳이 표준화가 필요할까? 이런 의문도 들었지만 표준화가 필요한 이유는 일종의 윗분 보고, 제안서 제출, 다른 팀 전파..등에 필요하기 때문..)


2. SI적용의 어려움

왜 우리나라 SI는 Agile 적용이 어려운지 이번에 무릎을 치면서 깨달았습니다.

Agile 기법은 TDD, 리팩토링으로 품질높은 소프트웨어 개발을 중요시합니다.

사용자스토리로 합리적인 일정 산출을 합니다. 일정 산출결과 시간/인력 자원이 부족하면 고객을 설득하여 자원을 늘려달거나 우선순위가 떨어지는 것은 포기하라고 협상할 수 있습니다.

그러나 우리나라 SI는,
품질높은 소프트웨어 보다는 결과물을 빠르게 찍어내는 것을 중요시 합니다.
납기 준수가 최고입니다. (더구나 납기일은 보통 일정 단축으로 점철되었습니다.)

이런 환경에서 납기 준수 지키다 보면 새롭게 Agile 기법을 익힐 학습시간은 더욱 더 없습니다. 품질 좋은 소프트웨어 개발 보다는 결과물 찍어내는게 우선이다 보니 품질 향상을 할 시간도 없습니다.

우리나라 SI가 원하는것과 Agile이 추구하는 것은 아직은 상극이라는 것이 저의 생각입니다.

(이 부분을 쓰면서 괜히 화가 납니다. 갑님들, 일정 압박해서 개발자 쪼아서 결과물만 찍어내면 답니까. 그렇게 비용 절감해서 상관에게 인정받으려다가, 나중에 유지보수할때 알아보기 힘든 소스 때문에 고생하고 숨겨진 버그가 튀어나오면 자기 탓 안하고 생고생한 개발자 탓 하겠죠.)


3. 팀원 설득의 어려움

저는 Agile이 개발자 팀원의 복지를 증진시키는 유익한 기법이라고 강조를 합니다만,

사실 TDD든 사용자 스토리든 색다른 기법이라 학습시간이 필요합니다.

그런데 보통 경력 찬 개발자들은 자신이 익숙한 기술을 쓰길 원하지 굳이 낯선 기술을 배우려고 하지 않습니다.

억지로 새로운 기술을 배웠더라도 정작 그 효과를 보지 못한 경험도 하곤 합니다.

무엇보다 일정 쪼는데 새로운 기술을 배우라고 시키면 화가 나기도 합니다.

팀원 설득이 쉽지 않습니다. 저도 이부분 때문에 여지껏 Agile 도입하자고 설득하지 못했죠.


이번 연구/실습 과정을 거쳐 이런 3가지 어려움을 깨달았습니다. 이번에 발표, 교육, 가이드 작성등의 정리과정을 거치면서 내 개발자 인생의 숙제 하나를 해결한 느낌이었습니다.

개발자를 행복하게 하는 기법/방법론 Agile, Agile이 우리나라 SI를 바람직하게 변화시키는데 어서 기여했으면 하는 바람입니다.

[Agile에 대해 발표 하면서 Agile을 우리나라에 적용하는 것은 마치 우사인 볼트가 '모래사장'을 달리는 것과 마찬가지다~ 라고 비교했다. 아무리 우사인 볼트라도 '모래사장'을 달리면 느리고 힘들게 달리수 밖에 없다. 그러나 발상의 전환을 하면 우사인 볼트이기 때문에 일반인보다는 '모래사장'을 빨리 달릴 수 있을 것이다.]

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 산골
산골 블로그 소개 저는 하얀머리 개발자와 작가를 꿈꾸는 블로거 산골 입니다. 프로그램 개발자로서 저의 관심사는 개발자의 숨통을 트여준 아이폰 개발, 철학과 같은 깊이가 있는 객체지향 방법론입니다. 글쓰기와 수영을 좋아합니다. 블로그를 통해 관심사를 공유합니다. 제 블로그에 관심 있으시면 아래 RSS나 즐겨찾기로 편하게 구독하세요.

rss Bookmark and Share

댓글을 달아 주세요

  1. BlogIcon zeous 2011.10.10 16:28 신고  댓글주소  수정/삭제  댓글쓰기

    많은 고생을 하신것 같네요.. ^^
    저희팀과 회사에서도 몇번 사용해보고 있지만 쉽지 않더라구요
    모든 부분(스탠딩 미팅, 페어프로그래밍, TDD ...)을 한번에 다하기도 어렵지만
    부분적으로 적용하는 것만으로도 도움이 많이 되어서 개인적으로는 참 좋아합니다.

    제가 하면서 가장 어려웠던 부분은
    모든 프로젝트 관계자(기획자, 사용자까지...)가 애자일스러워야만 성공할수 있더라구요..
    서로의 작고 빠른 피드백으로 진행해야 하는데 개발자들만으로도 모두 애자일스럽고 액티브하지 않아서
    쉽지 않는데 기획자, 사용자까지 해야 하니.. 으...

    그래서 모든 부분을 애자일로 하는 것은 힘들지만 몇가지 필요한 부분을 뽑아서 같이 하면서
    개발자라도 모두 애자일스럽게 된다면... 점차 범위를 넓혀보고 있습니다.

    • BlogIcon 산골 2011.10.23 18:15 신고  댓글주소  수정/삭제

      덧붙이면 우리나라는 일정 진행상황을 '가라'로 적어
      현업을 안심시키는 경우도 많습니다.
      이런 관습이라면 사용자 스토리 기법 사용하기도 어렵습니다.
      저는 그냥 SVN나 이슈관리시스템정도의 도구만
      잘 사용해보려고 합니다.
      애자일 적용 꼭 성공하셔서 노하우좀 공유해 주시길 바래요~ ^ ^