실용주의 프로그래머 8
프로젝트 전에
프로젝트를 시작할 때 요구 사항을 파악해야 한다. 프로젝트가 닻을 올리기 전에 여러 중요한 문제들을 잘 정리해보자.
요구 사항의 구렁텅이
완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 뺼 것이 없을 때 달성되는 것이다.
요구 사항 수집이라는 것은 길에 있는 것을 주워 담는 행위가 아니다. 대부분의 경우엔 이 말이 정확하다.
자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.
개발자는 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다. 의뢰인이 진정으로 원하는 바를 함께 찾을 수 있도록 해보자. 당연하게도, 최초의 요청 사항이 궁극적인 요구 사항인 경우는 없다. 우리는 그들의 요구 사항을 받고, 해석해서 그로 인한 영향을 다시 알려줘야 한다. 이 과정은 지적이고 창의적인 과정이다.
요구 사항은 피드백을 반복하여 알게 된다.
피드백을 바탕으로 의뢰인은 자기 생각을 더 가다듬을 것이다. 만약에 구체적인 피드백이 어렵다면 프로토타입을 만들어서 제공해라. 그런 모형을 통해서 더 좋은 해결책을 찾을 수 있을 것이다. 의뢰인이 되어 보는 것도 좋은 방법이다.
사용자처럼 생각하기 위해 사용자와 함께 일하라.
피드백 수집은 의뢰인과의 관계를 쌓아 나가는 시작점이기도 하다. 요구 사항들을 잘 수집하다보면 메타데이터를 지원하는 잘 분리된 시스템을 만들 수 있을 것이다.
우리는 구현 과정에서 안내 역할을 하는 이정표로 문서를 관리해야 한다. 요구 사항 문서는 팀의 개발자들을 위해서 작성해야 한다. 요구 사항을 바탕으로 한 스토리 보드를 만들어도 좋다. 이 스토리 보드를 의뢰인에게도 보여주고 서로 간의 피드백을 활발하게 하자.
요구 사항은 모호해서는 안되고, 추상적이어야 한다. 요구 사항은 아키텍쳐가 아니고, 설계가 아니고, 인터페이스도 아니다. 필요를 표현하는 것으로 해당 필요사항을 정확히 반영하는 가장 간단한 표현이 최고다.
요구 사항에 대한 토론을 하다보면, 특별한 의미가 있는 용어들을 사용하게 된다. 이 용어는 최종 사용자에서 지원 부서 직원까지 모든 사람이 일관성을 바탕으로 사용해야 한다. 이런 용어의 통일을 위해서 프로젝트 용어 사전을 사용하라.
불가능한 퍼즐 풀기
어떤 퍼즐이든 그것을 해결하는 열쇠는 제약을 인식하는 것과 더불어 주어진 자유도를 파악하는 것이다. 그 자유도 안에서 퍼즐의 해답을 발견할 수 있을 것이다.
생각의 틀을 벗어나지 말고 틀을 찾아라.
자신만의 방법에서 빠져나와야 한다. 문제를 이야기할 사람을 찾아도 좋고, 잠깐의 산책도 좋다.
함께 일하기
17,000 쪽에 달하는 문서를 읽고 싶어 하는 인간을 만나본 적이 없다.
매우 어려운 신규 프로젝트가 성공할 수 있던 이유는, 기존 프로젝트를 수년간 관리한 전문가가 바로 옆에 있었기 때문이다. 덕분에 끊임없이 질문을 던지고 설명을 듣고 결정을 부탁하고 시연을 보여줄 수 있었다.
짝 프로그래밍이나 몹 프로그래밍이라는 방식이 있다. 이 방식은 함께 일하는 아주 강력한 방법이다. 이 ‘함께 일하기’를 통해서 실제로 코딩을 하는 중에 질문과 토론을 함께 할 수 있다. 이를 통해서 개발 전반에 대한 복합적인 고려를 하며 코딩을 할 수 있을 것이다. 이 과정 중에 고려할 것이 몇가지 있다.
- 누가 가장 똑똑한지 겨루는 것이 아니다. 각자 뛰어난 부분이나 장단점이 있다.
- 소규모로 시작하라. 네다섯 명과 몹을 만들어 보거나, 짝 프로그래밍을 짧게 몇 번 해보라.
- 코드만 비판하고 사람을 비판하지 말라.
- 다른 사람의 관점을 듣고 이해하려고 노력하라. 다른 것은 틀린 것이 아니다.
- 자주 회고를 하라
코드에 혼자 들어가지 말라.
애자일의 핵심
애자일은 일하는 방식이다. 이를 놓치는 조직이 많다. 애자일 선언은 다음과 가탇.
우리는 소프트웨어를 개발하고, 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 과정에서 우리는 다음과 같은 가치를 찾아냈다.
- 공정과 도구보다 개인과 상호작용
- 포괄적인 문서보다 작동하는 소프트웨어
- 계약 협상보다 고객과의 협력
- 계획을 따르기보다 변화에 대응하기
애자일의 가치는 소프트웨어를 만드는 더 나은 방법을 지속적으로 탐구하는 과정에서 찾고 알게 되는 것이다. 즉, 피드백을 수집하고 그를 바탕으로 개선하는 것이다. 피드백을 받을 수 있는 피드백 고리를 만드는 것이 중요하며, 그에 기반한 의사 결정을 할 수 있어야 한다.
이 과정에서, 우리는 좋은 설계를 할 수 있다. 바꾸기 쉬운 것을 만드는 것이 좋은 설계인 것이다. 피드백 고리를 효율적으로 만들기 위해서는 고치기 쉬운 설계를 해야 한다. 이것이 애자일이다.