공감가는 문장이 너무 많았던 책 클린 애자일에서 격한 공감에 형광펜으로 표시해 놓은 문장들을 옮겨보았습니다.
오래 전에 사놓았던 책인데 최근 프로젝트를 진행하면서 답답한 마음에 꺼내 읽었고, 왜 이제서야 읽었을까 후회했습니다.
여기에 적은 문장들 말고도 이 공간에 담고 싶은 내용들이 많았는데, 그러면 책을 그대로 옮기는 꼴이 되어버릴 것 같아서 꾹 참았습니다. 두 세 번 다시 읽으면서 머리 속에 담고, 실제로 행동에 옮기면서 몸에 배도록 해야겠습니다.
다음에 여기 적은 한 문장마다 파생되는 저의 경험과 생각을 글로 적어도 좋을 것 같네요.
1장 애자일 소개
p15 ~
애자일 선언
- 공정과 도구보다 개인과 상호작용
- 포괄적인 문서보다 작동하는 소프트웨어
- 계약 협상보다 고객과의 협력
- 계획을 따르기보다 변화에 대응하기
애자일 체계에 따라 일하면서도 프로젝트를 완전히 엉망으로 관리해서 실패로 내모는 상황 또한 일어날 수 있다.
애자일은 데이터를 제공함으로서 관리를 돕는다.
속도 차트와 번다운 차트, 이 두 차트를 벽에 거는 것이 애자일의 중요한 목표다.
진짜로 필요한 것은 차트가 아니다. 진짜 필요한 것은 데이터다.
데이터 없이는 프로젝트를 관리할 수 없다.
애자일은 데이터를 만든다.
p31 ~
희망을 없애는 것이 애자일의 주요 목표다. 애자일을 실천하면 희망이 프로젝트를 죽이기 전에 희망을 파괴할 수 있다.
2장 왜 애자일인가?
p51 ~
반복 주기 동안 스토리를 구현한다는 것은 스토리의 모든 코딩과 모든 테스트와 모든 문소와 모든 안정화를 다 끝낸다는 것이다.
반복 주기 동안 시스템을 기술적으로 배포 가능한 상태로 만드려면 본복 주기가 끝나기 전에 모든 배포 준비 작업을 완료할 수 있을 만큼 스토리를 조금만 고르면 된다.
더욱 암울할 것은 기존의 코드가 사람보다 더욱 강력한 선생이라는 것이다. 새로운 사람은 기존의 코드를 보고 이 팀에서 어떻게 일하는지 추측할 것이다. 그리고 함께 엉망인 코드를 만들어 낼 것이다. 따라서 사람을 추가해도 생산성은 계속해서 추락한다.
p57 ~
대부분의 소프트웨어 시스템이 점점 좋아지지 않을까? 두려움 때문이다. ... 이것은 두려움에서 오는 반응이다. 당신은 코드를 두려워하고, 두려움 때문에 무능력해진다. 결과가 두려워서 필요한 코드 정리를 하지 못한다. 자신이 만든 이 코드를 완전히 통제할 수 없을 정도로 놔두었기 때문에 코드를 개선하는 일을 두려워하게 된다. 정말 무책임하다.
가장 정직한 추정은 "모르겠습니다"이다. 하지만 이걸로 끝내면 안 된다. 모든 것을 알지는 못할 것이다. 하지만 아는 것이 있을 거시다. 그러니 아는 것과 모르는 것에 기반하여 추정해야 한다.
고객 권리 장전
- 전체적인 계획을 알 권리가 있다. 무엇을, 언제, 얼마의 비용으로 완성할 수 있는지 알 권리가 있다.
- 반복 주기마다 가능한 한 많은 가치를 얻을 권리가 있다.
- 작동하는 시스템을 통해 진척도를 알 권리가 있다. 개발자는 고객이 제공한 테스트로 계속해서 시스템을 검사하여 동작을 증명해야 한다.
- 과도한 비용 추가 없이 기능이나 우선순위를 바꿀 권리가 있다.
- 일정이나 추정이 바뀐 경우 제때 알림을 받고, 목표 일자에 맞추기 위하여 업무 범위를 어떻게 줄일지 결정할 권리가 있다. 언제든지 프로젝트를 취소할 수 있다. 이 경우 해당 시점까지 지불한 비용이 반영된 유용한 시스템을 받을 수 있다.
개발자 권리 장전
- 명확하게 정의된 우선순위와 함께 무엇이 필요한지를 알 권리가 있다.
- 언제나 높은 품질의 결과물을 만들 권리가 있다.
- 동료나 관리자, 고객에게 도움을 요청하고 받을 권리가 있다.
- 자신만의 추정치를 만들고 갱신할 권리가 있다.
- 담당 업무를 할당받는게 아니라 수락할 권리가 있다.
3장 비즈니스 실천 방법
p72 ~
프로그래머는 해야 할 일을 한 줄 한 줄의 코드로 쪼개는 기술을 가진 사람이다.
추정이란 본질적으로 엉성하다. 정밀도를 낮추어 엉성하게 추정해야 빨리 추정할 수 있다. 더 엉성하게 추정할수록, 추정에 걸리는 시간이 더 줄어든다.
스토리 문구는 단순해야 한다 ... 세부사항은 생략해야 한다. ... 스토리를 개발하기 직전까지 미뤄 두어도 좋다. 스토리를 요약한 형태로 놔둠으로써 나중에 대화하기로 약속하는 것이다.
p81 ~
반복 주기에 실패란 없다. 반복 주기의 목표는 관리자에게 데이터를 제공하는 것이다.
스토리를 쓸 때 너무 많은 세부 사항을 적으면 안 된다. 세부 사항은 쉽게 바뀌기 때문이다. 세부 사항은 인수 테스트의 형태로 작성한다.
스토리를 작성할 때 알아야 하는 것은 필요한 시점에 테스트를 만들 수 있을지 여부다.
모든 스토리를 각각 80%씩만 처리한 것보다는 완료한 스토리 수가 전체 스토리 수의 80%인 것이 휠씬 더 낫다. 스토리를 완료하는 데 집중하라.
어떤 방식을 사용하든지 모든 스토리를 각 프로그래머가 골라서 가져가야 한다.
반복 주기 절반이 지났는데도 아직 인수 테스트부터 다 만들지 못했다면, 개발자도 다른 작업을 멈추고 인수 테스트 작성을 도와야 한다.
주의해야 할 점은 특정 스토리를 구현하는 프로그래머가 그 스토리의 인수테스트까지 작성하면 안 된다는 것이다. QA가 반복 주기 중간 시점까지 인수 테스트를 다 만들지 못하는 일이 반복주기마다 일어난다면, QA 엔지니어와 개발자의 비율이 부적절할 가능성이 크다.
'완료'의 정의는 '인수 테스트 통과'다.
프로그래머가 이 스토리는 90%쯤 되었다고 말하더라도, 완료까지 진짜로 얼마나 남은 것인지는 알 수 없다. 따라서 속도 차트에는 오직 인수 테스트를 통과한 스토리만 기록한다.
p92
속도는 측정하는 것이지 목표하는 것이 아니라는 점을 마음에 새겨두자.
속도 그래프가 꾸준히 계속 떨어진다면 코드 품질에 문제가 있을 가능성이 제일 크다. 리팩터링을 충분히 하지 않아서 아마 코드가 썩고 있을 것이다. 리팩터링을 충분히 하지 않는 이유 중 하나는 단위 테스트를 충분히 쓰지 않아서다. 리팩터링으로 무언가 망가질까 봐 두려운 것이다.
4장 팀 실천 방법
4장부터는 밑줄 친게 없네요. 아마 이 부분을 읽는 시점에 형광펜을 소지하지 않아 마음을 울리는 문구를 표시하지 못한 것 같습니다. 추후 다시 읽고 정리하도록 할께요
5장 기술 실천 방법
TBD
6장 애자일해지기
TBD
7장 장인 정신
TBD
8장 결론
TBD