3 주차
일 | Assignment #13
8장. 프로젝트 전에
📘 책에서 기억하고 싶은 내용
- 요구 사항의 구렁텅이 (p.350)
- 요구사항은 피드백을 반복하며 알게 된다.
- 정책은 메타데이터다. 현재의 정책 정보는 시스템이 지원하는 것들 중 한 사례일 분이고, 시스템은 다양한 정책을 처리할 수 있도록 일반적으로 구현해야 한다.
- 요구 사항 문서는 개발자의 계획을 위해서 쓰는 것이다.
- 좋은 요구 사항은 추상적이다. 사업에 필요한 사항을 정확히 반영하는 가장 간단한 표현이 좋다.
- 요구 사항이 슬금슬금 추가되는 것을 어떻게 막을 수 있을까?
→ 반복 주기를 거치며 의뢰인과 정기적으로 피드백을 주고 받는다. ("딱 한 기능만 더"란 요청이 미치는 영향을 알도록)
- 프로젝트 용어 사전을 만들고 관리하라.
- 프로젝트에서 사용하는 모든 용어와 어휘를 모아 놓은 단 하나의 장소여야 하고, 온라인 문서가 적합하다.
- 불가능한 퍼즐 풀기 (p.362)
- 그럴싸해 보이는 제약 조건이 사실은 전혀 제약 조건이 아닐 수도 있다.
- 생각의 틀을 벗어나지 말고, 틀을 찾아라. (틀 = 제약 조건)
- 불가능한 문제처럼 보인다면 잠시 딴짓을 하거나 동료와 이야기를 통해 해결을 시도해보라.
- 함께 일하기 (p.367)
- 짝 프로그래밍 : 개발자 한 명은 키보드를 조작하지만 다른 한 명은 하지 않으며, 키보드 담당은 필요에 따라 바꿀 수 있고 둘이 함께 문제를 푼다.
- 몹 프로그래밍 : 셋 이상의 사람이 참여하는 짝 프로그래밍의 확장 방안, 실시간 코딩을 곁들인 밀접한 협업
- 세 명 이상의 사람은 반드시 개발자가 아니어도 된다. (테스트, 고객 모두 가능)
- 유의사항 및 TIP
- 누가 가장 똑똑한지 겨루는 것이 아니다.
- 코드만 비판하고 사람을 비판하지 말라.
- 다른 사람의 관점을 듣고 이해하려고 노력하라.
- 자주 회고를 하라.
- 애자일의 핵심 (p.372)
- 애자일 프로세스라는 것은 있을 수 없다. 애자일의 가치는 할 일을 결정할 떄 무엇을 추구해야 할지를 알려준다.
- 애자일의 가치
- 공정과 도구 < 개인과 상호작용
- 포괄적인 문서 < 작동하는 소프트웨어
- 계약 협상 < 고객과의 협력
- 계획을 따르기 < 변화에 대응하기
- 애자일하게 일하기
- 아래 과정을 프로젝트 종료 시까지 반복하라.
- 내가 어디에 있는지 알아내라.
- 도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.
- 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.
- 지속적으로 프로세스를 실험하지 않는 팀은 애자일 팀이 아니다.
- 애자일이 전반적으로 작동하게 하려면 무언가를 바꾸기 쉽도록 좋은 설계를 만들어야 한다.
바꾸기 쉽다면 모든 층위에서 아무런 주저 없이 문제를 바로 잡을 수 있을 것이다.
🤔 소감 및 생각
- 요구 사항이 추가되는 것을 막을 수 있는 방법을 논하는 내용을 읽을 때 많이 공감되면서도 씁쓸했다. 고객은 늘 요구 사항을 한 번에 결정하지 못하고, 지속적으로 "슬그머니" 추가하였는데, 책에서 말하는 답과 같이 피드백을 통해 관리하려고 하였으나 결국엔 "기간을 넉넉하게 드릴테니 그때까지라도 부탁드려요"라는 말이 돌아왔었다. 내가 속했던 프로젝트 팀의 대부분은 결국 기간을 연장하여 모든 요구사항을 수용하는 방향으로 결정하였는데, 이러한 상황에서 요구 사항을 줄일 다른 방법이 있는지 다시 생각해보게 되었다.
🔍 새롭게 또는 다시 알게 된 내용
