오늘 TIL 3줄 요약

• 프로젝트전 요구 사항 파악하기

• 불가능한 문제를 해결하는 방법

• 애자일, 함께 코딩하기

TIL (Today I Learned) 날짜

2022. 04. 03

오늘 읽은 범위

8장. 프로젝트 전에

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

• 프로젝트가 닻을 올리기 전에 이런 중요한 문제들이 잘 정리되어야 '분석 마비증'을 모면할 수 있다.

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

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

  • 의뢰인이 미처 고려해 보지 않은 문제도 있을 것이다. p353

  • 반복 주기가 끝날 때마다 직접 의뢰인에게 피드백을 받는다. p355

  • 인덱스카드 혹은 가상의 인덱스 카드에 들어갈 정도로 적는 방식을 선호한다. 이런 짧은 설명을 '사용자 스토리'라고 부른다. 여기에는 어플리케이션의 작은 일부가 그 기능을 쓰는 사용자 관점에서 어떻게 작동해야 하는 지를 적는다. p359

  • 좋은 요구사항은 추상적이다. 요구 사항을 기술할 때는 사업에 필요한 사항을 정확히 반영하는 가장 간단한 표현이 최고다. 그렇다고 해서 모호하게 적어도 된다는 말은 아니다. 밑에 깔려있는 의미론적 불변식을 요구사항으로 잘 갈무리하고, 구체적인 작업 방식이나 현재의 작업 방식은 정책으로 문서화해야 한다. p359

  • '프로젝트 용어 사전'을 만들고 관리하라. 프로젝트에서 사용하는 모든 용어와 어휘를 모아 놓은 단 하나의 장소여야한다. p361

• Topic 46 불가능한 퍼즐 풀기

  • 해법은 다른 곳에 있다. 이런 퍼즐을 푸는 방법은 상상 속이 아닌 실제 제약 조건을 알아내고, 그속에서 해법을 찾는 것이다.p363

  • 풀리지 않는 문제와 마주쳤다면 생각해 볼 수 있는 모든 해결 경로 후보를 눈앞에 나열해 보라. 아무리 쓸모없고 바보 같아 보이는 경로라도 절대 버리지 말라. p364

  • 간단히 표현하면 딴짓을 한 사람이 의식적으로 노력한 사람보다 복잡한 문제 해결 과제를 더 잘 해냈다. p365

• Topic 47 함께 일하기

  • 코드만 비판하고 사람을 비판하지 말라. "넌 틀렸어."보다는 "이 부분을 한번 볼까요?" 훨씬 듣기 좋다.

  • 다른 사람의 관점을 듣고 이해하려고 노력하라. 다른 것은 틀린 것이 아니다

• Topic 47 애자일의 핵심

  • 애자일이 전반적으로 작동하게 하려면 좋은 설계를 만들어야한다. 좋은 설계는 무언가를 바꾸기 쉽게 하기 때문이다. p376

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

• 이번에 큰 새로운 프로젝트에 투입이 예정되어 있어서 그런지, 어떻게 요구사항을 관리해야할지 고민이 참 많았다. 왜냐하면 요구사항을 완벽하게 구현할수 있는 경우도 있지만, 그렇지 못한 경우도 있기 때문이다. 어떻게 요구사항을 정리하면 좋을지 고민했었는데. 이러한 고민을 단번에 해결할수 있었다. 요구 사항이 사용자 관점에서 어떻게 작동하는지를 미리 적어봐야겠다.

• 프로젝트 용어 사전을 만들어보자. 정말 기획자가 말하는 용어랑 개발자가 말하는 용어가 달라서 실제로 잘못 수정한 경우가 있었다.

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

• 분석 마비증 : 분석의 완벽함을 추구하는 정작 해겨책을 도출하지 못하는 현상
  https://plandays.wordpress.com/2011/01/30/%EB%B6%84%EC%84%9D%EB%A7%88%EB%B9%84%EC%A6%9D%EC%9D%84-%EC%A3%BC%EC%9D%98%ED%95%98%EB%9D%BC/

오늘 읽은 다른사람의 TIL

• https://jiyoungyim100.notion.site/TIL-2022-04-03-8-f46c5ca3d5424d2f9d95a3013d26cd49