No Bugs
이는 소프트웨어 개발 시에 버그를 최대한 빠르게 발견하고 수정을 중점에 둔다.
버그 비난 게임을 하지 말라. 낭비하는 기업은 책임을 '정확하게' 할당하기 위해 버그, 결함, 오류, 문제, 이상 등 의도하지 않은 기능을 정교하게 구분한다. 중요한 것은 무엇을 할 것인가. 버그는 여러분의 팀이 '완료'했다고 생각하지만, 이후 수정을 해야 하는 모든 것이다. 즉, 무언가 할 일이 필요하다면 카드로 만들어라. 그 뿐이다.
내부에서 품질을 구축하는 법
- 내부품질: 코드를 얼마나 쉽게 수정할 수 있는가
- 외부품질: 사용자가 볼 수 있는 소프트웨어 측면에 관한 것
내부에서 품질을 구축하는 법은 이해관계자가 만족시키는 수준으로 외부 품질을 유지하면서 내부 품질을 가능한 높게 유지하는 것을 의미한다.
사각지대 발견
유능한 전달하기 팀은 내부 코드 품질을 구축하는데 능숙하다. 하지만 완벽한 것은 없으며 팀도 사각지대를 갖고 있다. 사각지대를 찾았다면 문제만 고치지 말고 그 문제가 나오는 환경을 고쳐라.
여러분의 팀이 요구받은 무언가를 그대로 만들어야 한다고 생각하지 마라. 오히려 반대를 가정하라. 여러 분이 무엇을 만들어야 할지는 요청한 사람도 모른다.여러분이 해야할 일은 요청한 아이디어를 테스트함으로써 정말로 무엇을 만들어야 하는지 학습하는 것이다.
카오스 엔지니어링
시스템 아키텍처에 초점을 둔 탐색적 테스트의 방법이다. 의도적으로 실패를 시스템에 주입하여 시스템이 실패에 어떻게 반응하는지 학습한다.
사건 분석(혹은 포스트모텀)
최선의 노력을 했음에도 소프트웨어는 제대로 작동하지 않을 수 있다. 실패를 단순한 원인과 결과의 연속으로 생각하기 쉽다. 하지만 실패는 작업이 수행되는 전체 개발 시스템에 의한 결과다. 실패가 발생했다면 어느 하나가 아니라 여러 가지 것이 동시에 잘못됐기 때문이다. 반대로 성공도 마찬가지다.
발생한 사건은 모든 사람이 그 시점에 알려진 것, 그들이 가진 능력, 이용할 수 있는 리소스, 주어진 상황에서 최고의 작업을 했음을 이해하고 실제로 믿어야 한다.