애자일 경험담 5

Developer 2009/08/21 13:30
오늘 주저리 주저리 떠드는 내용은 애자일에 대한 직접적인 경험보다는 애자일을 어떻게 전파할 것인지에 대한 고민이다.

애자일을 하는데 있어 수많은 방법들이 존재하고 그 방법론의 공통적인 부분을 찾아보면 다음과 같다.

1. 확실히 가능한 목표를 수립한후 공유와 실현을 위한 커뮤니케이션에 엄청난 노력을 들인다.
   (문서 산출물의 형식에 연연하지 않는다. 내용을 더 중요하게 여긴다)
2. UML(추천은 Staruml)과 같은 자동화되고 통합된 분석설계 및 테스트케이스에 적용하는 툴을 가지고 일을 한다.
3. 형상관리는 SVN과 같은 형상관리 툴을 이용한다.
4. CI(추천은 HUDSON) 툴과 것으로 지속적인 통합을 시도한다.
5. TEST(추천은 JUNIT이나 MS TEST TOOL)를 자동화 한다.
6. 개발서버는 한대일지라도 Virtual 운용환경 (Virtual BOX 추천) 을 구축한다.
7. 무엇보다 짧은 주기와 체크를 한다.

이상 7가지의 방법을 사용한다.

그런데 문제는 여기서 발생한다. 모든 것들이 일반적이지 않고 개발자들이 익숙하지 않다는 것이다.
(개발자 개개인의 개발능력은 뛰어나지만 함께 일하는 것에 대해 익숙하지가 않다는 이야기이다.)

그래서 항상 먼저하는 것이 개발자 교육인데 개발자 교육이 1:1 강의라면 문제없이 교육할 수 있지만 1:n과 같이 개발자 다수를 교육할 때 힘이 빠지는 경험을 한다.
(너무 힘들어서 교안준비하고 방법알려주고 안되면 왜 안되는지 알려주고... 다시 알려주고... 또 다시 알려주고... 그나마 백지라면 다행인데 UML 좀 해보신분은 왜 그렇게 하냐고 따져들면 다시 설명하고... 지친다.)

이러한 노력은 알게 모르게 시간이 뺐기는 작업니다. 그것도 다수의 시간을 뺐는 작업이기에 어떻게 하면 편하게 지식을 전수할 수 있을것이며 품질을 동일하게 가지고 갈것인지가 문제가 된다.

그래서 고민을 했었다. 과연 내가 무엇때문에 개발 업무에 미쳐 사는지에 대한 답을 찾아 혜맨것이다.
그래서 얻은 결론은 아무리 재미 없는 것이라도 찾으면 재미있는 구석 한두가지는 있다는 결론에 도달한 것이다.

그래서 적용한 방법이 다음과 같다.

1. 가장 쉽고 개발자들이 따라오기 쉬운 것부터 알려준다.
   보통의 순서 : 큰 그림을 설명 > UML 설계방법 > 테스트코드 > 개발코드 > SVN 등록 > HUDSON 사용 >
                      커뮤니케이션 방법 등등등
   바꾼순서 : 큰 그림 설명 > 커뮤니케이션 > SVN 등록 > HUDSON사용 > 테스트코드제작 > UML설명
   이렇게 바꾸고 나자 대부분의 개발자가 중간이 이해를 못하는 경우 없이 마지막 테스트 코드에서 약간과
   UML에서 대부분 표준을 맞추는 부분에서 이견이 있었을 뿐이었다.
   다시 말해 교육 시간이 짧아지는 효과가 있었다.

2. 교육해줬다고 해서 한번에 모든것을 이해하길 바라는 자세를 버렸다.
   신나게 3~4일 교육하고 한번에 모든것을 이해하길 바랬기 때문에 교육받는 개발자는 나중에 물어보면 "그거
   설명 해줬자나요?"라고 했던 경험이 있었는데 나중에 그 개발자는 물어보는 것이 두려워 커뮤니케이션을
   차단하는 역효과를 낳기만 하여서 그 뒤로는 교육의 높이를 개념 이해정도로만 잡았다.

3. 교육후에 스스로 해보도록 약 4일의 시간을 줬다.
   프로젝트 시작후 프로토타잎 개발 과정을 넣어서 프로토 타잎을 개발할때 개발자에게 스스로 교육받은 대로
   하는지 체크하였다. 스스로 보고서를 TRAC의 Wiki를 사용해서 잘하는지 UML설계는 표준대로 하는지
   SVN은 잘쓰는지 테스트 코드는 잘 생성하는지 HUDSON에서 빌드는 잘되었는지 이렇게 몇가지 부분에 대해
   교육대로 잘하는지 매일매일 리뷰를 해주었다.
   "UML 설계를 그릴때 이렇게 그리는것보다 이렇게 그리는 것이 어떨까요?"
   "XXX씨는 이렇게 테스트 코드를 작성했는데 요렇게 해보세요"
   이렇게 주문하면서 되도록 한 가지 주문만 했다. (여러가지 주문을 하면 못 알아 듣는다. 여러가지가 있다면
   나눠서 다음날 다음날 하루에 1개씩 주문하자.)

그러나 아직 해결 못한 과제가 있으니 개발자 레벨이 아니라 상위 레벨이다.
"Water fall 정보공학 만세"를 외치는 세대들에게 애자일을 설명하고 이해시키는 것은 매우 힘들다.

애자일을 해서 시간을 절약할 수 있다. 그러나 그것은 이러한 과정을 밟고 나간후에 최후에 등장하는 것이지 당장의 성과가 나는것은 아니지 때문이다.

애자일은 모든 개발 이해관계자들이 투명하게 누가 무슨일을 하는지 누가 생산성이 좋고 나쁜지에 대한 정량화된 데이터를 줄 수 있을 뿐이다.

최종 매니저는 이러한 데이터를 바탕으로 불필요한 작업과 불필요한 시간낭비, 불필요한 투입 Resource 를 제거해나가며 최종적으로 전체 공정을 단축 시키는 효과가 있는 것이다.

따라서, 당장의 성과를 원하는 매니저에게 이런 효과를 설명하고 이해시키는 것은 매우 어렵다.

프로젝트 착수시 WBS가 아닌 MileStone이 왜 나오고 상세 일정이 없는지 궁금해하며
보고서 등의 문서는 출력해서 제본하는것이라 믿으며
싸인을 꼭 자필로 받아야 하는것이라 믿으며
관리 산출물은 많으면 많을 수록 좋다고 믿고 있으며
사람은 최대한 많이 때려 넣고 밤샘 시켜야 결과물이 나온다고 믿는 매니저들이 어떻게 애자일을 이해하겠는가?

2009/08/21 13:30 2009/08/21 13:30

트랙백 주소 :: 이 글에는 트랙백을 보낼 수 없습니다