친구: Y! 난 agile이란 방법론을 앞으로 우리 회사 모든 프로젝트에 도입하고 싶은데, 윗 임원들을 설득할 수 있는 좋은 방법이 없을까? agile 방법이 우수하다는 것을 한방에 증명할 수 있는 그런 것!
나: 글쎄... 그런데 agile이 최선인지 아닌지는 아무도 몰라. 하지만 지금 네가 하고 있는 방법은 절대로 아니라는 거야. 현재 waterfall적인 것은 무조건 안된다는 거지. 그렇다고 무턱대고 지금 가진게 나쁘니까 agile을 하자고 할 수는 없겠지?
친구: 옆에서 네가 테스트를 만들고 mock object란 걸 통해서 domain modeling을 하는 tool들을 사용하는 걸 보니까 이건 웬지 craft를 하는 것 같다는 생각이 들어. 그냥 백지위에서 시작하는 게 아니라 test를 통해 어떤 도구의 도움에 의해 뭔가 조금씩 만들어지는 느낌을 받는다 말이야. 그게 웬지 자신감을 주는 것 같아.
나: 그 feel은 네가 제대로 받은거야. 옛날엔 우리가 software engineering을 하면서 무슨 art를 했던 것 같았었지. class들을 만들땐 무슨 번쩍하는 영감이 떠올라야 했구 그나마도 내가 제대로 하고 있는 지 항상 의문이었지. UML이란 tool을 사용해 보지만 art인 점은 여전했었어?
친구: 맞아 art였어... ^^
나: 테스트 도구를 사용하면서 디자인을 어떤 영감에 의존하지 않는거지. 이 도구들이 줄자로 측정기로 옆에서 내가 만드는 프로그램의 방향을 끊임없이 다듬어주거던. 프로그램자체가 아닌 그 방향을 잡아준다는 거는 정말 내가 너에게 저극 추천하고 싶어. 비록 전사적인 개발방법론 도입과 같이 크게 벌이지 않더라도 개인적으로 이 test tool들을 잘 활용해봐.
나: art가 아니고 craft이기에 자신감을 가질 수 있는거야 ^^. craft는 누구나 할 수 있는거잖아.
친구: 그래서 난 이왕 할거면은 처음부터 진지하게 전사적으로 시작하고 싶은거지. 이론적인 근거가 탄탄한 보고서를 만들 자료좀 줘봐.
나: 그냥 TDD 부터 시작해봐. 그건 뭐 개발 방법론이라고 말할 수도 없는거니까. 또 테스트의 중요성은 아무리 강조해도 모자라잖아? 테스트 먼저 생각하는 사고의 전환부터 시작해봐.
친구: 하지만 테스트 first라는 말은 잘 알겠는데 막상 테스트를 만들려면 막막해져. 그리고 내가 만든 테스트 자체가 도움이 안된다면 결국 개발이나 디자인에 도움이 안되는 건 마찬가지 아냐?
나: 그런 생각이 바로 '시작점'인거야. 어떻게 테스트를 꾸밀까란 고민은 한마디로 말하면 내가 뭘 테스트해야 하나라는 고민이지 않겠어?
나: 뭘 테스트하냐라는 고민에 대해서 정확한 답은 누구에게서 받겠니? 그 프로그램의 사용자겠지? 결국 고객이야.
나: 테스트를 통해서 요구사항 분석도 되는 거지. 그리고 테스트도 하나의 작은 프로그램이기 때문에 고객의 요구사항이 가질 수 있는 잠재적인 문제점들을 미리 미리 볼 수 있다는 장점이 있어. 이건 문서만을 통해서 하는 요구사항분석이 따라 올 수 없는 점이지.
나: 그리고 acceptance test을 하는 wiki tool 봤지? 웬만한 프로타잎의 역활을 충분히 하잖아? 바로 고객에게 아웃풋을 주고 즉각적인 feedback도 기대할 수 있는 거지.
나: 그리고 도구란게 자꾸 써야 느는거잖아. 처음부터 다 알고 사용하지는 못하는거구. 내가 pair programming이라는 걸 한번 소개해주면서 너랑 같이 테스트를 작성해보자. pair programming 은 지식의 인수인계를 쉽게 해주거던.