개발자 99% 커뮤니티에서 수다 떨어요!
오늘 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)
애자일 방식 적용 방법:
여러분이 어디에 있는지 알아내라.
도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.
어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.
-> 위 과정을 끝날 때까지 반복하라.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
"자신이 뭘 원하는지 아는 사람은 없다."
예전에 광고 회사에서 광고 기획자로 일을 했을 때 광고주가 입 밖으로 내뱉은 말 뒤에 숨겨진, 정말로 원하는 것(니즈)을 끄집어내는 것이 미팅에서의 중요한 미션 중 하나였다. IT회사의 FE개발자로 일을 하면서도 이는 변하지 않았다. 프로덕트의 정기 미팅 자리에서 항상 PM 혹은 플래너가 이야기하면 그들이 원하는 것을 재정의하며 우리 팀의 궁극적인 목적 혹은 목표에 부합하는 것인지 체크를 한다. 그 과정에서 더 나은 방향 혹은 방법을 찾게 되는 경우가 종종 있다.
설문조사에 참여하면 유료 버전의 베타서비스 이용권을제공한다는 이벤트성 배너를 하단에 띄운다고 했을 때 우리의 목적은 단순히 유저에게 배너를 보여주어 설문조사로 이어지는 루트를 만드는 것이 아니라 "최대한 많은 유저가 그 설문조사에 참여하게 만드는 것"이었을 것이다. 그런데 처음 나온 디자인 안은 배너의 버튼에 적힌 문구가 "자세히 보기" 였다. 광고 회사에서의 경험 상 이 버튼의 클릭률은 비교적 낮을 것이라고 직감적으로 느꼈었다. "자세히 보기"보다는 유저가 이 버튼을 클릭함으로써 얻을 수 있는 것이 무엇인지 직관적으로 보여주는 문구가 클릭률을 높일 것이라는 판단이었다. 그래서 버튼 문구를 "써볼래요"라고 수정하는 것을 제안했고 다른 팀원들 모두 동의하여 수정했고 예상보다 높은 설문조사 참여율을 얻을 수 있었다.
코드만 비판하고 사람을 비판하지 말라.
이 부분을 읽고 생각난 게 코드 리뷰를 할 때 코드를 개선하는게 좋겠다는 피드백도 물론 중요하지만 좋다고 생각한 부분은 좋다고 칭찬하는 코멘트를 다는 것도 리뷰를 받는 개발자와 팀의 분위기에 긍정적인 영향을 미친다는 것이다. 실제로 회사의 한 개발자분이 코드 리뷰 시 좋다고 생각된 부분에 "GOOD✨"이라고 코멘트를 남기는 것을 보고 개발팀에서 하나둘씩 이러한 코멘트를 달 일이 있으면 남기기 시작하여 지금은 하나의 문화로 자리 잡았다. (다른 회사에서도 이런 문화가 있는지는 잘 모르겠다.)