오늘 TIL 3줄 요약

• 프로그래머의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다.

• 제약이라고 생각했던 것이 사실은 제약이 아닐 수 있다. 진짜 제약을 찾자.

• 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.

TIL (Today I Learned) 날짜

2022.04.03(일)

오늘 읽은 범위

• 8장 프로젝트 전에

  • Topic 45 요구 사항의 구렁텅이

  • Topic 46 불가능한 퍼즐 풀기

  • Topic 47 함께 일하기

  • Topic 48 애자일의 핵심

책에서 기억하고 싶은 내용을 써보세요.

모든 선입견을 의심하고 그것이 진짜 바꿀 수 없는 제약인지 가늠해 봐야한다. 이것은 틀을 벗어나고 벗어나지 않고의 문제가 아니다. 문제는 틀을 찾는 것, 곧 진짜 제약을 찾는 일이다.

프로젝트를 하다보면 - 특히 유지보수 프로젝트의 경우 - 비효율적이고 이상한 프로세스를 만나는 경우가 있다. 왜 이렇게 해야하는 지 물어보면 이전부터 이렇게 해왔다고 한다. 이런 프로세스를 개선해서 환영 받는 경우도 있지만 고객이 기존 방식을 고수하는 경우도 있다. “프로그래머의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는 것이다”라는 맥락에서 보면 설득이 부족했던 것이리라.

사업 정책인가, 요구 사항인가? 그 차이는 비교적 미묘하다. 하지만 이 차 이가 개발자에게는 중대한 의미가 있다. ... 그러면 정책이 바뀔 때(실제로 바뀐다) 시스템의 메타데이터Metadata만 업 데이트하면 된다. 실제로 이런 식으로 요구 사항을 수집하면 자연스럽게 메 타데이터를 지원하는 잘 분리된 시스템이 만들어질 것이다.

요구사항과 정책은 구별하기가 쉽지 않을 듯 하다. “정책은 메타데이터다”라는 말도 언뜻 이해되지 않는다. 곰곰히 생각해보니, 정책은 바뀌기 쉬운 것, 그래서 설정 등으로 관리해야 하는 메타데이터 성격을 갖는 것으로 이해되었다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

이 장에서는 제목처럼 프로젝트를 시작할 때 임하는 마음가짐을 이야기하고 있다. 요구사항은 고정된 것이 아니라 과정이라는 것, 진정한 제약조건이 무엇인지 잘 파악해야 한다는 것, 동료와 혹은 고객과 함께 코딩해 보라는 것, 유행하는 애자일 방법론은 고정된 프로세스가 아니라 불확실성을 헤쳐 나가기위한 행동 양식이라는 것이다. 이는 다음과 같은 애자일 선언 내용에 잘 담겨있다.

· 공정과 도구보다 개인과 상호작용

· 포괄적인 문서보다 작동하는 소프트웨어

· 계약 협상보다 고객과의 협력

· 계획을 따르기보다 변화에 대응하기

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

사람들이 문서를 기반으로 하는 유명 방법론과 확정된 요구사항을 선호하는 것은, 프로젝트에서 뚜렷한 목표가 없으면 길을 잃고 헤매기 쉽기 때문일 것이다.

프로젝트 구성원과 고객 모두 준비되지 않으면 애자일 방법론은 독이 될 가능성이 크다.

오늘 읽은 다른사람의 TIL

• solyi 님의 TIL: https://nomadcoders.co/community/thread/4178

부록 Tips

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

• Tip 76 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다.

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

• Tip 78 사용자처럼 생각하기 위해 사용자와 함께 일하라.

• Tip 79 정책은 메타데이터다.

• Tip 80 프로젝트 용어 사전을 사용하라.

• Tip 81 생각의 틀을 벗어나지 말고, 틀을 찾아라.

• Tip 82 코드에 혼자 들어가지 말라.

• Tip 83 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.