주변으로 부터 애자일 스럽게 일한다는 이야기를 듣기는 하지만, 그렇다고 애자일을 본격적으로 공부해본적은 없다. 워낙 애자일 이야기가 많이 돌아다니기 때문에 관심이 생겨서 살펴본적은 있지만 말 그대로 대강 살펴 본 정도다.
본격적으로 프로젝트에 도입해본 적은 없는데는 몇 가지 이유가 있다.
애자일 관련 글들을 보면 항상 드는 생각이 너무 추상적이다라는 거다. 다른 말로 좋은게 좋은거라는 말을 빙빙 돌려서 하는 것 같다는 생각. 또 다른 말로 선문답 같은 뜬 구름 잡는 것 같은 말들.
말은 많은데 비해 성공 사례를 찾기가 쉽지 않다. 마땅한 도구들도 없다. 예컨데, 전통적인 폭포수 모델은 구체적인 프로세스와 각 프로세스를 위한 구초젝인 구현방법 그리고 지원툴들을 찾을 수가 있는데, 이런 툴을 찾기가 쉽지 않다. 예전 오픈마루에 있을 때 부터 보아왔던 유일한 도구는 포스트 잇이었다. 디지털에 찌들어 있던 상황에 비추어 볼때, 매우 신선해 보이긴 했으나 과연 효과적으로 관리될까라는 의문이 들었다.
전체적으로 어떤 방식이든 일이 되도록 만들자라는 사상에 기반한 생활 철학에 가까운 그런 걸로 보였다.
문서와 공유가 핵심
그렇게 애자일을 이해하다 보니, 굳이 애자일 관련 문서를 꼼꼼히 읽어보고 거기에 나온 방법대로 일을 진행 할 필요가 있나 ? 라는 생각을 하게된다. 애자일을 관통하는 몇 가지 사상에 동감하고, 내가 하는 일이 잘 되도록 걍 나름의 방법을 만들면 되겠다라고 생각하게 된거다. 진짜 이유는 책 읽기가 너무 힘들었기 때문이다. 무슨 변주곡도 아니고, 똑 같은 말을 약간 바꿔서 계속 되풀이하는게 지루했다.
그래서 책 같은거 집어 치우고, 그냥 대충 나름의 일하는 방식을 만들었다. 진짜 대충이다. 이 방식의 핵심은 문서와 공유에 있다.
일단 할 일이 생기면, 먼저 문서를 만든다. 여기에는 설계, 기술, 툴, 기간, 발생할 수도 있을 법한 기술 적 이슈, 테스트해야 할 내용등 모든 것을 포괄한다.
이때 한번에 완성된 문서를 만들지 않는다. 문서의 작성주기는 짧으면 2일, 길어도 일주일을 넘기지 않는다.
첫 번째 주기의 문서는 혼자 만든다.
모든 주기에서 문서 작성이 끝나면, 반드시 리뷰 하고 아이디어를 공유한다. 첫 번째 주기의 문서에서 프로젝트의 방향을 공유한다.
모든 문서는 내용이 부족하며, 많은 오류를 가지고 있을 수 밖에 없다는 것을 인정해야 한다. 사람의 성향에 따라서, 용기가 필요한 방법일 수도 있다. 시간이 걸리더라도 완벽한 결과물을 보여줘야 한다고 생각할 수 있기 때문이다. 자존심이 허락치 않을 수도 있고.
두 번째 주기 부터는 업무를 나누어서 진행을 한다. 하지만 아직 실제 개발은 들어가지 않는다. 다들 아직은 문서 작업으로 설계 단계다. 주기는 역시 가능한 3일을 넘기지 않게 한다.
이때 나는 개발 환경을 만든다. 개발 환경 역시 문서로 먼저 정리한다.
문서 작업은 6주기 이상을 돌지 않는다. 사실상 5주기에서 끝낸다. 문서의 수준은 대략 다음과 같이 한다.
문서는 세부적인 내용까지 포함하지는 않는다.
문서는 깔끔할 필요가 없다. 중간 중간 계속 공유하기 때문에 깔끔하지 않더라도 다들 내용을 이해하고 있다.
세번 정도 주기를 돌다보면, 프로젝트 자체에 영향을 끼칠만한 큼지막한 기술적 이슈는 거의 다 찾아낼 수 있다. 세번 주기를 돌지만, 팀원들도 각자 맡은 분야의 문서를 만들고 그걸 리뷰해야 하기 때문에 꽤 많은 시간 정보를 공유한다.
세번째 주기를 돌고나면, 이 프로젝트와 관련있는 다른 팀과 정보를 공유할 수 있다. 물론 아직 불완전한 정보이고 오류가 있을 수 있지만 그런거 때문에 공유를 미루지 않는다. 팀장은 관련 팀과 어떻게 잘 조화를 이루어서 일을 추진해 나갈지를 고민하기 시작한다.
다섯번째 주기에 팀은 개발 방향, 방법, 툴, 기술적인 난이도, 일정에 대해서 서로 합의를 할 수 있을 정도의 정보를 가질 수 있다. 서로 합의했다는 점이 중요하다.
여섯번째 주기면 문서가 완성된다. 다른 팀과도 완성된 문서로 이야기 할 수 있다. 물론 여전히 세세한 부분에서의 논의는 더 필요하지만, 팀간 협업에 문제를 일으킬만한 이슈는 거의 다 제거된 상태다.
즉 설계한 내용, 기술과 툴의 선택, 일정에 대한 합의를 할 수 있는 수준의 정보를 담는 문서를 만드는 데 대략 한달정도의 시간 걸린다. 필요한 조건은 다음과 같다.
머리와 경험만으로는 판단하기 힘든 설계 혹은 기술상의 이슈가 있을 수 있다. 이슈가 생기면, 빠르게 테스트할 수 있어야 한다. Ruby, python, shell, perl, php 와 같은 빠른 프로토타핑이 가능한 언어 두 가지 정도와 다양한 종류의 공개 소프트웨어들을 다룰 수 있어야 한다. 능숙할 필요는 없다. 거부하지만 않으면 된다.
적정 기술을 선택한다. 팀원이 이해할 수 없거나, 수준에 도달하기 위해서 너무 많은 시간이 소모되는 기술(대게 이런 기술은 새로운 기술이며 아름다우며, 게다가 성능도 뛰어나다)은 선택하지 않는다. 그런 기술은 프로젝트가 끝나기 전 혹은 끝난 후, 잉여시간에 학습해서 체화한 후에 팀원들과 공유 해서 준비된 다음에 프로젝트에 사용할지 고민한다.
모든 정보는 공유한다. 프로젝트에 사용하는 기술과 정보는 팀원 모두가 공유한다. 직접적으로 해당 기술에 관여하지 않더라도 이해는 하고 있어야 한다.
팀장이 프로젝트에서 손을 떼더라도 프로젝트는 별 탈 없이 굴러갈 수 있어야 한다. 팀원은 자기책임하에 개발을 진행한다.
이슈가 생길 것 같으면 미리 공유해서 해결 방법을 찾는다. 주식에 알려진 정보는 고급정보가 아니다라는 말이 있듯이 프로젝트에서도 알려진 이슈는 진짜 이슈가 아니다. 알리지 않아서 문제가 되는거다. 알리지 않는 이유는 두려움 때문이다. 나쁜 소식도 부담없이 공유할 수 있는 분위기가 만들어져야 한다. 모르면 모르는데로 도움을 받으면 된다.
이 작업방식에서 문서도 개발의 영역에 들어간다. 이 방식의 흐름은 다음과 같이 정리할 수 있다.
녹색의 물음표 인물은 사업을 진행하는 누군가이다. 문서 개발에서는 두번 참여한다. 프로젝트 전체의 계획이 담긴 시점과 프로젝트의 세부적인 사항이 결정되는 시점이다. 그렇다고 해서 글자 그대로 두번만 참여하는 건 아니다. 문서를 팀원에게 할당 후 리뷰과정을 거치게 되는데, 이 정보들은 물음표의 인물과 계속 교환하며, 필요할 경우 리뷰에 참여시킨다.
만든 문서는 어떻게 유지 하나
이 방식에서 문서를 만드는 목적은 "자기자신"을 위해서다. 프로젝트에서 스스로가 잘 할 수 있는 일을 찾고, 찾은 일을 잘 하기 위한 기반을 만드는게 목표다. 이걸 취합해서 "전형적인 문서를 요구하는 다른 조직"의 요구는 팀장이 처리한다.
문서관리는 하지 않는다. 참고 가능하도록 레거시로 남겨둘 뿐이다.
일단 문서 작업이 끝나고 개발에 들어가면, 만들어놓았던 문서의 유지보수는 중요하지 않다. 예컨데, 개발하면서 방향이 변경됐다고 해서 기존 문서를 수정 하는 등의 일은 하지 않는다. 문서 개발했던 개발자의 재량에 맡긴다. 프로세스 자체가 변경되서 수정이 필요하다는 생각이 들면 (최소한으로)수정한다. 나머지는 이슈 추적 시스템으로 관리한다.
아무리 팀 전체가 서로 문서를 리뷰했다고 하더라도 개발도중에도 문서를 수정해야 할 만한 이슈가 생길 수 밖에 없다. 문서의 문맥을 고려하지 않고 문제가 되는 부분만 수정을 하면, 글의 구조가 이상해 진다. 구조도는 변경됐는데 글은 예전 내용을 담고 있다던지 등등등. 이런거 신경쓰지 않는다. 왜냐하면 이 문서의 내용은 다른 팀원들도 이미 다 알고 있기 때문이다. 문맥이 좀 이상하다거나 글 위아래의 용어가 틀리다거나 이런 건 중요하지 않다.
프로젝트 관리를 위해 사용하는 도구들이다.
위키
Git
Jira
google docs : 그림 그리기 툴을 주로 사용한다. 내 문서의 절반은 그림이다. 그림 그리기는 추상적인 글의 내용을 구체화하기 위한 가장 좋은 방법이다.
smartsheet : 일정관리 툴. 중간 중간 일정을 대략 가늠하기 위한 목적으로 사용한다.
내 일하는 방식
애자일은 선문답 스럽다
- 애자일 관련 글들을 보면 항상 드는 생각이 너무 추상적이다라는 거다. 다른 말로 좋은게 좋은거라는 말을 빙빙 돌려서 하는 것 같다는 생각. 또 다른 말로 선문답 같은 뜬 구름 잡는 것 같은 말들.
- 말은 많은데 비해 성공 사례를 찾기가 쉽지 않다. 마땅한 도구들도 없다. 예컨데, 전통적인 폭포수 모델은 구체적인 프로세스와 각 프로세스를 위한 구초젝인 구현방법 그리고 지원툴들을 찾을 수가 있는데, 이런 툴을 찾기가 쉽지 않다. 예전 오픈마루에 있을 때 부터 보아왔던 유일한 도구는 포스트 잇이었다. 디지털에 찌들어 있던 상황에 비추어 볼때, 매우 신선해 보이긴 했으나 과연 효과적으로 관리될까라는 의문이 들었다.
전체적으로 어떤 방식이든 일이 되도록 만들자라는 사상에 기반한 생활 철학에 가까운 그런 걸로 보였다.문서와 공유가 핵심
- 머리와 경험만으로는 판단하기 힘든 설계 혹은 기술상의 이슈가 있을 수 있다. 이슈가 생기면, 빠르게 테스트할 수 있어야 한다. Ruby, python, shell, perl, php 와 같은 빠른 프로토타핑이 가능한 언어 두 가지 정도와 다양한 종류의 공개 소프트웨어들을 다룰 수 있어야 한다. 능숙할 필요는 없다. 거부하지만 않으면 된다.
- 적정 기술을 선택한다. 팀원이 이해할 수 없거나, 수준에 도달하기 위해서 너무 많은 시간이 소모되는 기술(대게 이런 기술은 새로운 기술이며 아름다우며, 게다가 성능도 뛰어나다)은 선택하지 않는다. 그런 기술은 프로젝트가 끝나기 전 혹은 끝난 후, 잉여시간에 학습해서 체화한 후에 팀원들과 공유 해서 준비된 다음에 프로젝트에 사용할지 고민한다.
- 모든 정보는 공유한다. 프로젝트에 사용하는 기술과 정보는 팀원 모두가 공유한다. 직접적으로 해당 기술에 관여하지 않더라도 이해는 하고 있어야 한다.
- 팀장이 프로젝트에서 손을 떼더라도 프로젝트는 별 탈 없이 굴러갈 수 있어야 한다. 팀원은 자기책임하에 개발을 진행한다.
- 이슈가 생길 것 같으면 미리 공유해서 해결 방법을 찾는다. 주식에 알려진 정보는 고급정보가 아니다라는 말이 있듯이 프로젝트에서도 알려진 이슈는 진짜 이슈가 아니다. 알리지 않아서 문제가 되는거다. 알리지 않는 이유는 두려움 때문이다. 나쁜 소식도 부담없이 공유할 수 있는 분위기가 만들어져야 한다. 모르면 모르는데로 도움을 받으면 된다.
이 작업방식에서 문서도 개발의 영역에 들어간다. 이 방식의 흐름은 다음과 같이 정리할 수 있다.만든 문서는 어떻게 유지 하나
프로젝트 관리를 위해 사용하는 도구들이다.
히스토리
Recent Posts
Archive Posts
Tags