Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
[TIL] Chapter 8. 프로젝트 전에
#pragmatic
2년 전
858

오늘 TIL 3줄 요약

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

  • 혼자 프로그래밍 하는 것보다 함께 프로그래밍하는 것이 더 좋은 결과물을 낳는다. 그 방법으로 짝 프로그래밍과 몹 프로그래밍이 있다.

  • 애자일을 명사라고 착각하지 말자. 애자일이란 무언가를 하는 방식이다.

TIL (Today I Learned) 날짜

2022. 04. 03

오늘 읽은 범위

8장. 프로젝트 전에

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

  • 자신이 뭘 원하는지 정확히 아는 사람은 없다. 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다. (p350, 351)

  • 최초의 요청 사항은 궁극적인 요구 사항이 아니다. 의뢰인은 인식하지 못할 수도 있지만, 의뢰인의 요청 사항은 사실 함께 탐험을 떠나자는 초대장이다. (p352)

  • 요구 사항은 피드백을 반복하며 알게 된다. 실용주의 프로그래머는 프로젝트 전체를 요구 사항 수집 과정으로 보아야 한다. 그래서 우리는 짧은 주기로 반복하는 것을 선호한다. 피드백을 주고 받으며 궤도에서 벗어나지 않을 수 있으며 혹시나 잘못된 방향으로 가더라도 잃어버리는 시간을 최소화할 수 있다. (p354, 355)

  • 사용자처럼 생각하기 위해 사용자와 함께 일하라. (p355)

  • 도구가 성공하려면 사용하는 사람의 손에 적응할 수 있어야 한다. 그래서 프로토타입이나 예광탄을 이용한 빠른 피드백으로 의뢰인으로부터 "네, 이것이 원하는 것이 맞긴 한데 제가 원하는 방식은 아니네요."라는 반응을 얻어야 하는 것이다. (p357)

  • 요구 사항 문서는 개발자를 위해서 쓰는 것이다. (p358)

  • 좋은 요구 사항은 추상적이다. 요구 사항을 기술할 때는 사업에 필요한 사항을 정확히 반영하는 가장 간단한 표현이 최고다. (p359)

  • 요구 사항이 슬금슬금 추가되는 것을 막는 방법은, 의뢰인과의 정기적인 커뮤니케이션 및 피드백이다. "딱 한 기능만 더"란 요청이 미치는 영향을 의뢰인이 직접 체험할 것이기 때문이다. (p360)

  • '프로젝트 용어 사전'을 만들고 관리하라. 프로젝트에서 사용하는 모든 용어와 어휘를 모아 놓는 단 하나의 장소를 만드는 것이다. 이렇게 함으로써 커뮤니케이션 시 불필요한 오해가 생기지 않는다. (p360)

  • 여러분의 뇌에 경험을 주입하는 가장 좋은 방법은 일상적인 작업을 할 때 무엇은 잘되고 무엇은 안되는지 피드백을 주는 것이다. (p366)

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

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

  • 자주 회고를 하라. 그래서 다음번에 시도하거나 개선할 점을 찾아라. (p371)

  • 물리적인 세계에서든 소프트웨어 개발에서든 애자일, 즉 기민함이란 것은 변화에 대응하는 것, 일을 시작한 이후 맞부딪히는 미지의 것에 대응하는 것이 전부이다. (p374)

  • 소프트웨어를 개발할 때 따라야 할 단 한 가지 계획이란 없다. 피드백을 수집하고 그에 대응하라. (p374)

  • (애자일 방식이 추구하는) 가치들은 무엇을 하라고 알려주지 않는다. 대신 여러분이 할 일을 결정할 때 무엇을 추구해야 할지를 알려준다. (p374)

  • 애자일 방식 적용 방법:

    1. 여러분이 어디에 있는지 알아내라.

    2. 도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.

    3. 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.

    -> 위 과정을 끝날 때까지 반복하라.

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

  • "자신이 뭘 원하는지 아는 사람은 없다."

예전에 광고 회사에서 광고 기획자로 일을 했을 때 광고주가 입 밖으로 내뱉은 말 뒤에 숨겨진, 정말로 원하는 것(니즈)을 끄집어내는 것이 미팅에서의 중요한 미션 중 하나였다. IT회사의 FE개발자로 일을 하면서도 이는 변하지 않았다. 프로덕트의 정기 미팅 자리에서 항상 PM 혹은 플래너가 이야기하면 그들이 원하는 것을 재정의하며 우리 팀의 궁극적인 목적 혹은 목표에 부합하는 것인지 체크를 한다. 그 과정에서 더 나은 방향 혹은 방법을 찾게 되는 경우가 종종 있다.

설문조사에 참여하면 유료 버전의 베타서비스 이용권을제공한다는 이벤트성 배너를 하단에 띄운다고 했을 때 우리의 목적은 단순히 유저에게 배너를 보여주어 설문조사로 이어지는 루트를 만드는 것이 아니라 "최대한 많은 유저가 그 설문조사에 참여하게 만드는 것"이었을 것이다. 그런데 처음 나온 디자인 안은 배너의 버튼에 적힌 문구가 "자세히 보기" 였다. 광고 회사에서의 경험 상 이 버튼의 클릭률은 비교적 낮을 것이라고 직감적으로 느꼈었다. "자세히 보기"보다는 유저가 이 버튼을 클릭함으로써 얻을 수 있는 것이 무엇인지 직관적으로 보여주는 문구가 클릭률을 높일 것이라는 판단이었다. 그래서 버튼 문구를 "써볼래요"라고 수정하는 것을 제안했고 다른 팀원들 모두 동의하여 수정했고 예상보다 높은 설문조사 참여율을 얻을 수 있었다.

  • 코드만 비판하고 사람을 비판하지 말라.

이 부분을 읽고 생각난 게 코드 리뷰를 할 때 코드를 개선하는게 좋겠다는 피드백도 물론 중요하지만 좋다고 생각한 부분은 좋다고 칭찬하는 코멘트를 다는 것도 리뷰를 받는 개발자와 팀의 분위기에 긍정적인 영향을 미친다는 것이다. 실제로 회사의 한 개발자분이 코드 리뷰 시 좋다고 생각된 부분에 "GOOD✨"이라고 코멘트를 남기는 것을 보고 개발팀에서 하나둘씩 이러한 코멘트를 달 일이 있으면 남기기 시작하여 지금은 하나의 문화로 자리 잡았다. (다른 회사에서도 이런 문화가 있는지는 잘 모르겠다.)