스크럼 프로젝트의 일상을 관리하는 중심은 스크럼 보드(Scrum board)이다. 스크럼 보드는 벽에 적당한 크기로 자리해야 한다. 만일 보드가 너무 작으면 중요한 내용을 자꾸 생략하고 싶은 유혹에 빠지기 쉽다. 어쩌면 독자의 사무실 벽은 그만한 공간을 마련하기가 쉽지 않을 수도 있다. 이런 경우에는 그냥 방치된 화이트보드를 스크럼 보드로 활용하면 된다. 자석을 이용하면 금속으로 된 서류함도 스크럼 보드로 사용할 수 있다. _11p

이전 절에서 설명한 의존성을 퍼스트파티(first-party) 의존성이라고 한다. 콘솔 애플리케이션과 애플리케이션이 종속성을 가지는 클래스 라이브러리는 같은 비주얼 스튜디오 솔루션 내에 구현되어 있다. 이 경우, 의존성을 제공하는 프로젝트는 필요하다면 언제든 다시 빌드할 수 있기 때문에 의존성 모듈에 항상 액세스가 가능하다. _58p

검증 코드를 추가한 테스트는 전체 거래내역을 모두 합하여 계좌의 잔액을 확인하고 있다. 그런데 지금까지의 과정을 통해 계좌의 잔액을 관리하기 위해 작성한 코드는 가장 마지막 거래 내역의 값을 계좌의 잔액으로 취급하고 있다. 당연히 이 구현 방식은 올바르지 않기 때문에 이번 테스트 역시 실패하게 된다. 예제 4-11은 모든 단위 테스트를 성공할 수 있도록 구현을 수정한 AddTransaction 메서드의 코드이다. _159p

버그는 소프트웨어에 있어 일반적인 문제이며 완전히 제거하기란 거의 불가능하다. 그래서 버그가 발견되면 이에 대응하기 위해 문제가 있는 코드를 수정해야 한다. 물론, 그러자면 버그가 발생한 클래스의 복사본을 만들어 버그를 수정하지 않는 한 이미 존재하는 클래스를 수정해야 한다. 이는 순수주의보다는 실용주의의 측면에서 볼 때 원칙을 위반하는 것처럼 들린다. _243p

인터페이스를 분리해야 하는 이유는 여러 가지가 있다. 데코레이션을 지원하기 위해, 클라이언트로부터 기능을 올바르게 숨기기 위해, 다른 개발자를 위하여 스스로 문서화된 코드를 작성하기 위해, 또는 아키텍처 디자인의 영향을 받아서 분리되는 경우가 있다. 그 이유가 무엇이든지 간에 지금까지 살펴본 기법들은 인터페이스를 생성할 때마다 가장 먼저 염두에 두고 지켜야 할 것들이다. 현대의 프로그래밍 도구들을 활용한다면 일단 구현부터 하고 나서 나중에 리팩토링하는 방법보다는 처음부터 올바른 방향으로 코드를 작성하는 것이 바람직하다. _325p