Topic 45 : 요구사항의 구렁텅이
자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.
요구사항 미신
무엇을 다루든 정확한 명세란 것은 거의 불가능하다. 이때 프로그래머는 사람들이 자신이 무엇을 원하는지 깨닫도록 도와줄수 있다.
프로그래머는 사람들이 자신이 원하는 바를 꺠닫도록 돕는다.
상담 치료로서의 프로그래밍
신입 개발자의 실수는 요구사항을 받고 바로 해결책을 구현하는 것이다.
어떤 요구사항을 받았을때 여러 경우를 생각하고 되물어 확인하자 (사소하여 짜증날거 같은 질문이라해도)
- 요구사항: 5만 원 이상인 모든 주문은 배송비가 무료이다
- 질문 : 어떤 종류의 배송비가 무료인지? 국제 배송은? 5만원에 배송비 포함인지? 세금 포함인지? 나중에 기준이 바뀔지?
우리의 역할은 기획자의 말을 해석해서 그로 인한 영향을 다시 알려주는 것이다.
요구사항은 과정이다
요구사항은 피드백을 반복하며 알게 된다.
기획자는 우리의 피드백을 받고 자기 생각을 가다듬는다. 이때 피드백을 말로 표현하기 어려울 수도 있다. 그때는 프로토타입이나 목업으로 대화를 진행할 수 있다.
이러한 요구사항 가다듬기는 프로젝트가 끝날때까지도 이어진다. 따라서 프로젝트 전체를 요구사항 수집 단계로 봐야하고, 짧은 주기로 반복하여 피드백을 자주 받는 것이 좋다.
요구사항 문서화
요구사항 문서는 의뢰인을 위한 것이 아니다. 거대한 요구사항 문서를 만들어도 의뢰인은 읽지 않을 것이다. 요구사항 문서는 개발자를 위해서 세부사항을 명시한 것이다.
요구사항 문서화는 계획을 위해서도 좋다. 짧은 설명을 인덱스 카드 형식으로 하여 상태에따라 이리저리 옮길 수 있게 할 수 있다. 설명이 부족할 수도 있는데, 이것을 이용해서 개발자로 하여금 의뢰인에게 질문을 던지게 할 수 있다
지나치게 자세한 명세
요구사항을 만들 때는 추상적으로 작성하는 것이 좋다. 모호하게 적으라는 것이 아니라, 의미론적 불변식을 요구사항으로 잘 갈무리하고, 구체적인 작업방식은 정책으로 문서화해야한다.
요구사항은 아키텍처나 설계가 아니며 필요를 표현하는 것이다
딱 하나만 더
요구사항이 조금씩 늘어나는 것을 막는 방법은 피드백이다. 정기적으로 피드백을 주고받아 요구사항이 늘어날 떄의 영향을 의뢰인이 체험할 수 있도록 하라. 피드백을 주고 받아 추가되는 요구사항을 위해 무엇을 희생 가능할지 함께 고민할 수 있다
용어사전 관리하기
프로젝트에서 사용하는 용어를 모은 사전을 만들어라. 최종 사용자에서 말단 직원까지 프로젝트에 참가하는 모든 사람이 동일한 용어를 사용해야한다.
Topic 46 : 불가능한 퍼즐 풀기
풀기 어려운 문제는 상상 속이 아닌 실제 제약 조건을 알아내고 그 속에서 해법을 찾아야한다. 어떤 제약 조건은 절대적이라 따라야하지만, 어떤 조건은 단순한 지레짐작이다.
자유도
생각의 틀을 벗어나지 말고, 틀을 찾아라
모든 선입견을 의심하고 그것이 진짜 바꿀 수 없는 제약인지 가늠해봐야한다. 풀리지 않는 문제를 마주하면 모든 해결책을 생각해봐라. 아무리 쓸모없고 바보 같더라도 버리지 말고 잘 모아두고 왜 쓸모없다고 생각했는지 설명해봐라
자신만의 방법에서 빠져나와라
어려운 문제를 마주하고 그것이 풀리지 않는다면 잠시 다른 일을 하라. 무의식적으로 문제가 해결될 수도 있다.
간단히 표현하면 딴짓을 한 사람이 의식적으로 노력한 사람보다 복잡한 해결과제를 더 잘 해냈다.
- 사이콜로지 투데이
만약 손을 놓기 싫다면 다른 사람과 이야기 해봐라
- 왜 이 문제를 풀고 있는가?
- 문제를 풀어서 얻는 것은 무엇인가?
- 풀려고 하는 문제가 특수한 경우인가? 특수한 경우를 없앨 수는 없나?
- 관련된 문제 중 풀 수 있는 더 간단한 문제는 없나?
행운은 준비된 사람에게 찾아온다.
무의식적으로 문제를 해결하기 위해서는 원료가 많아야한다. 엔지니어링 일지처럼 일상적인 작업을 할 때 무엇은 잘되고 무엇은 안되는지 피드백을 줄 수 있다.
Topic 47 : 함께 일하기
페어 프로그래밍
사람들은 모두 다르기에 다른 배경을 가지고 문제를 푸는데도 다른 접근방법을 사용한다. 주어진 문제에 집중하는 정도나 주의력도 제각각이다. 입력을 담당한 개발자는 문법이나 코딩 스타일에 집중할 수 있고, 다른 개발자는 문제를 더 높은 수준에서 생각할 수 있다.
뇌의 용량은 한정되어있고, 문법이나 코딩스타일에 맞추는 일은 뇌 용량을 많이 소비한다. 두번째 사람이 전체적인 문제를 생각하는 뇌를 맡는다. 또 두번째 사람의 존재로 인해 안좋은 습관이나 꼼수를 덜 쓰게 된다
몹 프로그래밍
페어프로그래밍을 넘어 더 많은 사람이 참가할 수도 있다. 이때는 의뢰인처럼 개발팀의 일원이 아닌 사람도 참가할 수 있다
무엇을 해야할까?
처음에는 어색할 수 있지만 조금씩 시도해볼 수 있다. 이렇게 일하는 동안에는 기술적인 면 외에 인간적인 측면도 신경써야한다.
- 누가 똑똑한지 겨루지마라. 각자 뛰어난 부분이 있다
- 소규모로 시작해라
- 코드만 비판하고 사람을 비판하지 마라. ‘넌 틀렸어’보다 ‘이 부분을 한 번 볼까요?’가 좋다
- 다른 사람의 관점을 듣고 이해하려고 노력하라.
- 자주 회고를 하라.
너무 무턱대고 시도하지는 말고, 사례 보고서를 찾아보고 연구하라. 장점과 걱정되는 점에 대해 감을 잡아라.
코드에 혼자 들어가지는 말라.
Topic 48 : 애자일의 핵심
애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.
애자일은 일하는 방식이지 우리 자신이 아니다. 애자일 선언에서 언급된 애자일의 가치는 아래와 같다.
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 과정에서 우리는 다음과 같은 가치들을 찾아냈다.
- 공정과 도구보다 개인과 상호작용
- 포괄적인 문서보다 작동하는 소프트웨어
- 계약 협상보다 고객과의 협력
- 계획을 따르기보다 변화에 대응하기
왼쪽도 가치가 있지만 오른쪽에 더 높은 가치를 둔다
애자일 선언은 고정불변의 문서라기보다는 만들어가는 과정에 대한 제안이다.
애자일 프로세스라는 것은 있을 수 없다
애자일, 즉 기민함은 변화에 대응하는 것이다. 소프트웨어를 개발할 때 따라야하는 단 한 가지 계획이란 없다. 애자인 선언의 네가지 가치중 세가지가 이처럼 피드백을 수집하고 그에 대응하라는 얘기다.
이 가치들은 무엇을 하라는 것이 아니라, 할일을 결정할 때 무엇을 추구할지 알려주는 것이다. 그 결정은 상황에 따라 다르다.
피드백 고리
피드백고리를 만들어라. 이름 짓기 같은 작은 고리라도 피드백고리를 반복하는 것이 중요하다. 매번 작은 단계를 진행하고, 평가하고, 고칠 것이 있으면 고쳐라
이 과정이 설계를 주도한다. 좋은 설계는 바꾸기 쉬운 결과물을 만들기 때문에 애자일이 잘 작동하려면 좋은 설계를 만들어야한다.
후기
프로젝트 전, 진행 중에 필요한 팁들을 알려준 장이다.
- Topic 45 : 요구사항이라는 것은 기획자가 단순히 던져주는 것이 아니라, 개발자가 함께 만들어가는 것이라고 알게 해주었다.
- 요구사항을 받았으면 바로 구현하기보단, 요구사항을 구현했을때의 영향을 생각하여 되물을 수 있다
- 요구사항은 피드백을 반복하며 구체화된다
- Topic 46 : 풀기 어려운 문제를 맞이하였을 때, 어떤 부분에서 막히는지 확인하라. 그리고 그 부분이 진짜로 제약조건인지 확인하라
- 문제의 해결책을 의논할 때는 바보 같더라도 모두 모아라. 선입견에 빠지지말고 왜 바보같은지 합리적인 이유가 있는지 확인하라
- Topic 47 : 페어프로그래밍, 몹 프로그래밍을 통해 코드를 작성하는 사람과 전체를 보는 사람의 뇌를 분리시켜 코드의 품질을 올릴 수 있다
- Topic 48 : 에자일 방법론 형식에 매몰되지 말라. 피드백 고리를 만들고 기민하게 변화하는 것이 에자일의 가치이다.