머리글부터 시작은 거창하게 되었지만 전체적으로는 좀 식상한 얘기와 단편적인 내용들이 많은 편이었다. 동감하기 어려운 부분도 좀 있고… 그렇지만 뭐 책이란게 전체 내용이 다 좋을 수는 없고, 내 생각이 맞는건 아니니까…
공감되고 잊지 말아야 겠다는 내용만 정리해본다.
“개발명세는 개발의 핵심이다.”
요근래 내가 고민하는 내용과 일치해서일까? 울림이 오래남는 제목이었다. 다만, 내용은 내 생각과 좀 달랐지만…. 개발 명세라는 게 단순히 명세서와 같은 문서라고 생각할 문제가 아니라 개발 명세라는 이름이 가지는 목적에 대해서 요즘 고민을 할 기회가 꽤 있었다.
내가 잠정적으로 내린 결론은 어떤 방법을 통해서라도 개발자와 설계자가 같은 생각, 같은 그림을 머릿속에 두고 구현을 할 수 있어야 한다는 점이다. 그것이 명확한 명세서가 될 수도 있고, 요건정의부터 함께 계속 토론하는 방식일 수도 있고, 간단하게 구두로 전달할 수도 있겠지만, 아무튼 최종적으로는 같은 그림을 가지고 있는지 확신할 수 있을 정도로 챙겨야 한다. 서로 노력할 일이다. 방법은 현실적으로 그때그때 달라질 수 있으니, 너무 자신이 경험했던 것만을 고집 부릴 일은 아닌 듯 하다.
“테스트하기 전에 품질을 개선할 수 있는 방법이 있다면 그걸 선택하자.”
테스트는 가장 비용이 많이 들고 보완에도 비용이 가장 많이 든다는 것은 굳이 여러 글에서 말하지 않아도 스스로 뼈져리게 느끼고 있고, 다른 이들도 그럴 것이다.
테스트라… 테스트의 목적은 뭘까? 테스트도 결국 품질이 목적인데, 왜 가장 비용이 많이 들고 진행 하기도 어렵고, 재미도 없는 테스트를 항상 무의식적으로 일정에 만들어 넣는 것일까?
일단은, 시작하기가 쉬워서 일까? 늘 고민을 놓치지 말아야 할 부분이다.