DAY 17 (p.375-401 전자책기준)

8장.프로젝트 전에

📚 오늘 TIL 3줄 요약

• 최종 사용자에서 지원부서 직원까지 프로젝트 참여 인원들의 일관성을 위해서 동일한 용어 사전을 사용해야 한다
• 밀접한 협업,,, 실시간 코딩을 곁들인,, (pair, mob programming)
• 개발할 때 따라야 할 단 한 가지 계획이란 없다
  
  
  

기억하고 싶은 내용

요구사항의 구렁텅이

• 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다
• 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다
• 최초의 요청 사항은 궁극적인 요구 사항이 아니다

요구 사항은 과정이다

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

의뢰인의 입장에서 봐라

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

• 정책은 메타데이터다

• 요구 사항과 현실을 다를 수 있으니, 프로토타입이나 예광탄을 통한 빠른 피드백을 받아봐야 한다

요구 사항 문서화

• 문서는 구현과정에서 안내 역할을 하는 이정표일 뿐이다
• 문서는 의뢰인을 위한 것이 아니다
• 의뢰인에게 두꺼운 기술 문서는 지루하기만 할 것이다

요구 사항 문서는 계획을 위한 것이다

• 황소도 때려잡을만한 두툼한 요구 사항 문서 뭉치는 필요없다고 믿는다
• 인덱스카드 혹은 가상의 인덱스카드에 들어갈 정도로 적는 방식을 선호
• 애플리케이션의 일부가 기능을 쓰는 사용자관점에서 어떻게 작동해야하는지 적음

지나치게 자세한 명세

• 좋은 요구 사항은 추상적이다
• 필요사항을 정확히 반영하는 간단한 표현이 최고다
• 의미론적 불변식을 요구 사항으로, 구체적 작업 방식 등은 정책으로 문서화
• 요구 사항이 슬금슬금 추가된다? 해답은 피드백이다

프로젝트 용어 사전을 만들고 관리하기

• 최종 사용자에서 지원부서 직원까지 프로젝트 참여 인원들의 일관성을 위해서 동일한 용어 사전을 사용해야 한다
• 프로젝트 용어 사전을 사용하라
  
  
  

불가능한 퍼즐 풀기

프리기아의 왕 고르디우스는 아무도 풀 수 없는 매듭을 묶었다. 고르디우스의 매듭을 푸는 자가 아시아 전체를 지배하리라는 이야기가 전해졌다. 알렉산더 대왕은 검으로 그 매듭을 베어 버렸다. 요구 사항에 대한 조금 다른 해석, 그것이 다였다. 그는 결국 아시아의 대부분을 다스리게 되었다.

• 어떤 제약조건들은 절대적이지만 다른것들은 단순한 지레짐작에 불과하다
• 알렉산더가 증명했듯이 그럴싸해 보이는 제약 조건이 사실은 전혀 제약 조건이 아닐 수도 있다

자유도 degree of freedom

• 제약 조건의 '틀'을 파악해라
• 해결하는 열쇠는 여러분에게 주어진 자유도를 파악하는 것
• 생각의 틀을 벗어나지 말고, 틀(제약)을 찾아라
• 제약을 범주별로 나누고 우선순위를 매겨라

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

• 잠깐 다른 일을 하라. 개와 산책하러 나가거나 아예 내일로 미뤄라
• 문제를 놓고 이야기하는 것으로 주의를 돌리기만해도 깨달음을 얻을 때가 있다

• 왜 이 문제를 풀고 있는가?
• 문제를 풀어서 얻는 것이 무엇인가?
• 풀려고 하는 문제가 특수한 경우에 해당하는가? 특수한 경우를 없앨 수는 없나?
• 관련된 문제 중에 여러분이 풀 수 있는 더 간단한 문제는 없나?

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

• "유레카!"를 경험하려면 뇌의 무의식 영역에 원료를 많이 주입해야 한다
• 문제 해결에 필요한 원료는 바로 해답에 도움이 될 수 있는 경험이다
  
  

함께 일하기

• 짝 pair programming, 몹 mob programming
  한 명이 코드를 입력하는 동안 한 명이나 여러 명의 팀 동료가 조언하고 고민하며 문제를 함께 푸는 방식이다. 실제로 코딩을 하는 와중에 질문을 하고 토론을 하는 것이다.
• 콘웨이의 법칙
  시스템을 설계하는 조직은 조직의 의사소통 구조를 그대로 본뜬 설계를 만들기 마련이다. ex)클라이언트-서버, 프론트엔드-백엔드 / 사일로나 연통

짝 프로그래밍 pair programming

개방자 한 명을 키보드를 조작하지만 다른 한 명은 하지 않는다. 키보드 담당은 필요에 따라 바꿀 수 있고, 둘이 함께 문제를 푼다.

• 입력하는 개발자 - 문법, 코딩 스타일같은 낮은 수준의 세부 사항에 집중
• 다른 개발자 - 더 높은 수준에서 넓은 범위를 보며 문제를 고민
• 다른 개발자가 지켜봄으로써 변수 이름을 foo로 짓는 나쁜 습관이나 약점을 피하고, 민망한 꼼수를 덜 쓰게 되고, 결과적으로 소프트웨어 품질이 좋아진다

몹 프로그래밍 mob programming

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

• 사용자, 프로젝트 후원자, 테스터 등 개발팀이 아닌 사람도 함께할 수 있다
• 실시간 코딩을 곁들인 밀접한 협업
• 키보드로 입력하는 사람을 5~10분 마다 바꿔 주어야 한다.

무엇을 해야 할까?

• 혼자서만 했다 - 짝 프로그래밍 1회 2시간씩 최소 2주 해봐라
• 새 아이디어나 복잡한 문제 분석 - 몹 프로그래밍
• 짝, 몹 이미 했다 - 사용자,테스터,후원자 등 넓은 범위 팀원과도 하는가?

인간적인 측면의 Tip

• 코드를 짜는 거지 자아 쌓는 게 아니다. 누가 똑똑한지 겨루는 것 아니다. 각자의 장단점이 있다.
• 소규모로 시작하라. 4~5명과 몹을 만들어 보거나, 짝을 짧게 몇 번 해 보는 것으로 시작하라.
• 코드만 비판하고 사람 비판은 하지마라. "넌 틀렸어"말고 "이 부분을 한 번 볼까요?"가 훨씬 듣기 좋다.
• 타인의 관점을 듣고 이해하려고 노력하라. 다른 것이지 틀린 것이 아니다.
• 자주 회고를 하라. 그래서 다음번에 시도하거나 개선할 점을 찾아라.

• 너무 무턱대고 접근하지 말고, 각 개발 방식마다 규칙과 참고 사항, 지침들을 참고하라
• 교과서와 사례 보고서를 모두 찾아보고 연구해서 각 장점, 우려되는 점에 대한 감을 잡아라
• 코드에 혼자 들어가지 말라
  
  

애자일의 핵심

agile : 기민하다(형용사)

• 애자일은 명사가 아니다. 무언가를 하는 방식이다.
• '기민함' : 변화에 대응하는 것, 일 시작한 이후 부딪히는 미지의 것에 대응하는 것
• 애자일의 가치는 소프트웨어를 만드는 더 나은 방법을 지속적으로 탐구하는 과정에서 찾고 알게 되는 것

애자일 선언에서 언급한 가치

• 공정과 도구보다 개인과 상호작용
• 포괄적인 문서보다 작동하는 소프트웨어
• 계약 협상보다 고객과의 협력
• 계획을 따르기보다 변화에 대응하기
  **우리는 오른쪽에 있는 것에 더 높은 가치를 둔다

애자일 프로세스라는 것은 있을 수 없다 ❌

• "이걸 하세요. 그러면 애자일인 겁니다." - 정의상 틀린 말
• 개발할 때 따라야 할 단 한 가지 계획이란 없다
• 피드백을 수집하고 그에 대응하라는 것 뿐
• 할 일을 결정할 때 무엇을 추구해야 할지를 알려준다
• 사람, 팀, 도구, 회사, 고객 등 상황에 따라 결정이 달라진다

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

• 무엇을 하라곤 알려줄 수 없지만, 사고방식은 말해줄 수 있다

애자일하게 일하는 방법
1. 여러분이 어디에 있는지 알아내라.
2. 도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.
3. 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.
**위 과정 반복. 모든 일의 모든 층위에서 재귀적으로 적용하라

예시
이제 계좌 주인을 받아 와야겠다
let user = accountOwner(accountID)
음. user는 의미 없는 이름이네. owner로 바꿔야겠다
let owner = accountOwner(accountID)
그런데 좀 중복같은데. 원래 하려던 것이 뭐였지? 스토리엔 이 사람에게 이메일을 보낸다고 되어있는데, 그러면 이메일 주소를 알아야겠네. 그러고 보니 계좌 주인 객체를 전부 가져올 필요가 없었구나.
let email = emailOfAccountOwner(accountID)

• 이 코드와 계좌를 다루는 코드 간의 결합도를 낮췄다
• 피드백 고리는 프로젝트 가장 높은 층위에도 사용된다
  최고의 해법은 아예 소프트웨어 없이 가능한 것이었다.
  각 팀은 팀의 프로세스가 얼마나 잘 운영되는지 검토할때 피드백 고리를 활용해야 한다.
• 지속적으로 프로세스를 실험하지 않는 팀은 애자일 팀이 아니다.
• 최근에 내린 결정을 돌이켜 보라. 가려던 방향에 도움안될 경우 어떻게 결정을 되돌릴 수 있을지 미리 생각하고, 피드백을 모아 행동함으로 하던 일을 개선할 수 있는 방법이 있을까? 생각해보기

소감

프로젝트 요구사항과 용어 사전에 대한 필요성을 깨달았고 단순하고 간결한 문서화도 필요하다는 것을 알게됐다. 그리고 짝 프로그래밍을 통해 더 나은 코드를 짜보는 경험을 해봐야겠다. 그리고 애자일을 들어는 봤는데 뭔지는 몰랐었다. 어떤 개념인지 한번 찾아봐야겠다

궁금한 내용, 잘 이해되지 않는 내용은?

• 애자일

오늘 읽은 다른 사람의 TIL

• https://nomadcoders.co/community/thread/4156