실용주의 프로그래머 - 9 (TIL)

범위

~8장 프로젝트 전에

내용

요약

• 의뢰인의 관점에서 생각하라
• 함께 일하기
• 애자일

8장. 프로젝트전에

요구사항의 구렁텅이

자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.

프로그래머의 역할은 의뢰인의 말을 해석해서 그로 인한 영향을 다시 알려주는 것이다.

요구사항은 과정이다.

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

실용주의 프로그래머는 프로젝트 전체를 요구 사항 수집 과정으로 보아야 한다.

의뢰인의 입장에서 보라

요구사항 대 정책

정책은 메타데이터다

시스템은 다양한 정책을 처리할 수 있도록 일반적으로 구현해야 한다.

요구사항 대 현실

지나치게 자세한 명세

좋은 요구사항은 추상적이다.

밑에 깔려 있는 의미론적 불변식을 요구 사항으로 잘 갈무리하고, 구체적인 작업 방식이나 현재의 작업 방식은 정책으로 문서화 해야한다.

용어 사전 관리하기

프로젝트의 참여하는 모든 사람이 일관성을 위해 동일한 용어 사전을 사용하여야 한다.

불가능한 퍼즐 풀기

생각의 틀을 벗어나지 말고, 틀을 찾아라

풀리지 않는 문제와 마주쳤다면, 생각해 볼 수 있는 모든 해결 경로 후보를 눈앞에 나열한 후 검증한다.

• 제약을 범주 별로 나누고 우선순위를 매겨라

자신만의 방법에서 빠져나와라

• 잠시 다른 일로 뇌를 쉬게한다
• 다른 사람에게 얘기한다.

행운은 준비된 사람에게 찾아온다

함께 일하기

실제로 코딩을 하는 와중에 질문을 하고 토론을 하는 것

짝프로그래밍

짝프로그래밍에서는 개발자 한명은 키보드를 조작하지만 다른 한 명은 하지 않는다.

문제를 같이 푼다.

• 입력을 담당한 개발자는 문법이나 코딩 스타일 같은 낮은 수준의 세부 사항에 집중한다
• 다른 개발자는 문제를 더 높은 수준에서 넓은 범위를 보며 고민을 할 수 있다.

몹 프로그래밍

셋 이상의 사람이 참여하는 짝 프로그래밍의 확장판이다.

몹에는 개발팀의 일부로 여겨지지 않는 사람도 쉽게 끌어들여 코딩을 진행한다.

실시간 코딩을 곁들인 밀접한 협업

무엇을 해야할까

• 코드를 짜는 거지 자아를 쌓는게 아니다. 누가 가장 똑똑한지 겨루는 것이 아니다. 우리 모두는 각자 뛰어난 부분이나 장단점이 있다.
• 소규모로 시작하라
• 코드만 비판하고 사람을 비판하지말라. “넌 틀렸어” 보다는 “이 부분을 한번 볼까요?”가 훨씬 듣기 좋다
• 다른 사람의 관점을 듣고 이해하려고 노력하라. 다른것은 틀린것이 아니다.
• 자주 회고를 하라. 다음번에 시도하거나 개선할 점을 찾아라.

애자일의 핵심

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

• 공정과 도구보다 개인과 상호작용
• 포괄적인 무서보다 작동하는 소프트웨어
• 계약 협상보다 고객과의 협력
• 계획을 따르기보다 변화에 대응하기

그래서 우리는 무엇을 해야할까?

• 여러분이 어디에 있는지 알아내라
• 도달하고 싶은 곳을 향하여 의미있는 발검을을 가능한 한 작게 옮겨라
• 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.

마치며

8장에서는 전체 프로젝트와 관련하여 요구사항을 명확하게 밝혀내는 모습들과 특히 인상깊었던 것은 프로젝트를 진행하는 팀원들과의 협업의 문제였다.

함께 일하기 부분을 보면서 설렘을 느꼈는데 단순히 회의 뿐만 아니라 실시간 코딩을 곁을인 밀접한 협업이라는 부분을 보면서 많은 생각이 들었다. 저렇게 일한 적이 첫 회사에서 SI프로젝트를 진행할 때 쉽게 풀리지 않는 문제를 다 같이 풀었던 기억이 생각났었다. 정말 좋았고 소중했던 기억이다.

함께 일하는 방식에서 나 자신에게 항상 주의할려고 노력하는 부분은 독선적으로 얘기하지않기이다. 선배 개발자에게 뭔가에 대해 질문했을 때 비아냥 거리는 태도를 경험 한 적이 있었다. 가스라이팅 당하는 기분이랄까. 내가 모르는게 잘못된 것처럼 진행되었었는데 그때 기억은 나 자신은 다른 사람에게 그렇게 대하지 말자라고 생각하고 항상 행동하려고 주의를 기울인다. 정말 중요한 부분을 책에서 다루어줘서 좋았다.