[3주 완독 Daily 서평] 실용주의 프로그래머 - 9

범위 : [8장 프로젝트 전에]

태그 - TIL, nomadcoder, 개발자북클럽, 노개북, 서평, 책

프로젝트 전에

Topic 45 요구사항의 구렁텅이

완성이라는 것은 더 이상 더할것이 없을때가 아니라, 더 이상 뺄것이 없을때 달성되는 것이다.

-앙투안 드 생택쥐페리

요구사항 수집은 프로젝트 초기에 이뤄진다. 수집이란말에서 요구사항을 쉽게 바구니에 주워담고 갈수있단 말처름 들리지만 사실은 그렇지가 않다. 요구사항이 땅위에 그대로 놓여있는 경우는 매우 드물다. 보통 가정과 오해, 정치의 지층 속 깊숙이 묻혀있다. 심지어 아예 존재하지 않을 때도 있다. 자신이 뭘 원하는지 정확히 아는사람은 아무도 없다.

세상의 갈등과 요구사항은 엄청 많다.! 프로그래머들은 사람들이 자신이 원하는 바를 '깨닫도록 돕는 것이다.' 사실 이게 우리의 가치가 가장 빛나는 부분일 것이다.

요구사항은 과정이다

모든 요구사항은 피드백을 반복하여 알게된다.

실용주의 프로그래머는 "말씀하신게 이런것 입니까?" 부류의 피드백에 의존한다. 우리는 모형이나 프로토타입을 만들어서 의뢰인에게 직접 다루어 볼수 있도록 한다. 그와중 프로토타입이 이리저리 바꾸기가 쉬워서 의뢰인과 대화하는 도중에도 계속 바꿀 수 있다면 이상적이다. 사실 우리가 하는 모든 일은 일종의 모형을 만드는 것이다. 프로젝트 막바지에 이르러서도 우리는 의뢰인이 원하는 것을 계속 해석해야 한다. 프로젝트 전체를 요구사항의 수집 과정으로 보아야 한다. 그래서 우리는 짧은 주기로 반복하는 것을 선호한다.

의뢰인입장에서 보라

의뢰인이 되어 그 입장이 되어보는것이다. 시스템이 실제로 어떻게 사용될지 통찰을 얻을 수 있을 뿐만 아니라, 의뢰인과 신뢰를 구축하고 의사소통의 기반을 다지는데 도움이 될것이다. 피드백 수집은 의뢰인과의 관계를 쌓아 나가는 시작점이다.

요구사항

1. 정책

   사업 정책일까? 요구사항일까? 그 차이는 정말 미묘하다. 하지만 개발자에겐 중대한 의미가있다. '특정 인원'만 기록을 열람할수 있다. 라는 방식이라면 개발자는 데이터에 접근하는 인원을 비교해야하고, '권한이 있는 인원'만 접근 가능할 경우 접근 관리 시스템을 설계하고 구현할 것이다.

2. 현실

   우리는 프로토타입과 '예광탄'으로 의뢰인에게 자주 확인해야 할것이다.

   "이것이 원하는 것이 맞긴한데, 제가 제가 원하는 방식은 아니네요."

3. 문서화

   문서는 구현과정에 의뢰인에게 안내역할을 하는 이정표이다. 하지만 모든 문서는 의뢰인을 위한것이 아니다.

   첫번쨰, 의뢰인도 자신의 요구사항을 잘 모르는 경우가 있다.

   두번쨰, 의뢰인은 절대 문서를 읽지않는다. 의뢰인은 고차원적이고 모호한 측면이있는 문제를 풀고싶어하는 반면 프로그래머는 세부사항과 미묘한 차이 하나하나 관심을 두기때문이다. 요구사항 문서는 개발자들을 위해 쓰는것이다. 의뢰인이 보기에 이해하기도 어렵고 온통 지루하기만한 정보와 세부요소를 담기때문이다.

   의뢰인에게 요구사항 문서를 들이민것은 평범한 개발자에게 고대 그리스어로 된 책을 한권주며 이걸로 비디오게임 만들라는 것과같다.

   또 요구사항을 지나치게 명세히적을 필요는없다. 좋은 요구사항은 '추상적'이다.

Topic 46 불가능한 퍼즐 풀기

​ 어려운 퍼즐을 붙잡고 씨름하는것 처럼 프로젝트와중에 분명 그렇게 될것이다. 알렉산더가 그랬듯 그럴싸해 보이는 제약 조건이 사실은 전혀 제약조건이 아닐수도 있다. 제약을 범주별로 나누고 우선순위를 메겨야 한다.

Topic 47 함께 일하기

​ '함께 일하기는' 실제로 코딩하는 와중에 질문하고 토론하는것이다. (책 '페어 프로그래밍' '몹 프로그래밍' , 370396Page , )

Topic 48 애자일의 핵심

애자일은 기민하다는 뜻의 형용사이다. 즉 무언가를 하는 방식이다. 애자일은 우리가 일하는 방식이지 우리가 아니다.

애자일 선언은 피드백을 모으고 그에 걸맞게 행동함으로써 불확실성을 헤쳐 나가려고 제안한다. 애자일하게 일하는 방법은 다음과 같다.

1. 우리가 어디에 있는지 알아내라.
2. 도달하고 싶은 곳을 향해서 의미있는 발걸음을 가능한한 작게 옮겨가라
3. 어디에 도착했는지 평가하고 망가뜨린것이 있다면 고쳐라

위 과정을 끝날때까지 반복하고 , 위과정을 모든일의 모든 총위에 재귀적으로 적용해야한다.

총 평

첫번째 토픽은 ,

프로젝트를 시작전 사용자의 이야기를 듣는것 만으로 부족하다. 흔한 함정이나 곤란한 상황에서 빠지지 않는 법을 다루었다

두번째 토픽은,

요구사항이나 분석, 코딩, 테스팅 등 무엇을 하든 어려운 문제가 생기는데 보통 첫눈에 봤을때 생각만큼 어렵지는 않다.

세번째 토픽은,

'함께 일하기'는 두꺼운 요구 사항 문서를 공유하거나, 참조자가 무한히 늘어나는 이메일을 뿌리거나는 등 끝없는 회의를 견디는 것이 아니다. 우리가 함께 생각하는 일하기 코딩하는동안 문제를 함께 푸는것이다.

네번째 토픽은 ,

"애자일" 프로젝트가 어떤 공정과 도구를 사용할지에 대한 논의로 시작된다. 하지만 아무리 세심하게 계획하거나 최고의 모범사례를 따라 하더라도 생각하기를 대신 할 순 없을것이다.