Clean Agile - Chapter 2

클린 애자일

위의 책 내용을 참고 하여 정리한 글입니다.

자세한 내용은 책에서 확인하세요.

 

"우리 프로그래머가 세상을 지배한다. 그리고 아주 엉망으로 하고 있다."

"테스트 묶음이 있는 소프트웨어는 얼마나 될까?"
"테스트 묶음이 소프트웨어의 정상 작동을 엄밀하게 증명한다고 말할 수 있는 프로그래머는 얼마나 될까?"

 

관리자, 사용자, 고객이 개발자인 우리에게 기대하는 것들을 

부응하는 것도 애자일 개발의 주요 목표이다.

기대하는 것들

우리는 쓰레기를 내보내지 않겠다.

"사용자가 프로그래머처럼 생각해서 입력하거나 동작해야하는 시스템은 모두 쓰레기다"

관리자, 사용자, 고객이 돈을 지불했다면

품질이 좋고 결합이 적은 시스템을 받으려 기대하는 것은 타당하다.

 

테스트, 리팩토링, 단순한 설계, 고객의 피드백이

쓰레기를 만들지 않는 애자일이 강조하는 확실한 해결책이다.

기술적 준비 상태 유지하기

고객은 기능을 한번에 넣어야 하거나, 테스트를 해야한다는 핑계들로

시스템을 일부러 늦게 출시되는 것을 기대하진 않는다.

 

애자일은 "각 스프린트가 종료될때 기술적으로 배포가 가능해야 한다"

라는 규칙으로 이를 해결한다.

 

모든 스프린트의 끝에는 테스트가 완료되어 있어야한다.

이를 위해선 개발 가능한 범위의 "스토리" 만을 스프린트에 넣어야 할 것이다.

안정적인 생산성

고객은 같은 기능이라면 같은 기간, 더 적은 기간이 걸리길 기대한다.

 

하지만

시간이 지날수록 코드는 엉망이 된다.

엉망인 코드는 작업 속도를 떨어트린다.

새로운 사람이 왔을 때 코드를 보고 학습하여 또 다른 엉망인 코드를 만든다.

 

아키텍쳐, 설계, 코드를 가능한 깨끗하게 관리하여 생산성을 유지해야한다.

 

페어 프로그래밍, 테스트, 리팩토링, 단순한 설계를 통해 이를 유지할 수 있다.

낮은 수정 비용

"요구 사항 때문에 당신 아키텍쳐가 망가진다면, 당신 아키텍쳐가 엉망인 거다."

소프트웨어는 soft ( 쉽게 ) , ware ( 제품 ) 바꾸기 쉬운 제품이란 의미이다.

고객은 변경이 어려운 소프트웨어를 기대하진 않는다.

지속적인 개선

시스템이 갈수록 좋아질 것을 기대하지 쓰레기가 되는 걸 기대하진 않는다.

문제를 수정하고 설계를 개선해야한다.

두려움을 이기는 능력

대부분의 시스템이 좋아지지 않는 이유는 변경에 대한 두려움 때문이다.

통제할 수 없는 변경은 두려움을 만들고 이로인해 코드 정리를 피하게 된다.

 

테스트 주도 개발을 통해 해결 할 수 있다.

QA는 아무것도 찾지 못해야 한다.

테스트에서 QA가 보고해야 되는 내용은 모든 사항이 요구사항대로 동작해야 한다는 것이다.

QA가 무언가를 찾아온다면 개발 프로세스에서 무언가 잘못되었는지 찾아야 한다.

테스트 자동화

고객은 모든 릴리즈는 철저하게 테스트 될것이라 기대한다.

현실적으로 가능한 모든 부분을 테스트하고 자동화해야한다.

정직한 추정

아는 것과 모르는 것을 기반으로 추정을 해야한다.

로그인 ( 아이디, 비밀번호 입력 -> 로그인 ) 이 10일 정도 걸린다면

회원 가입 ( 동의 -> 아이디, 비밀번호 입력 -> 가입 성공 ) 이 얼마나 걸릴진 몰라도 12 ~ 15 정도로 추정이 가능하다.

 

애자일을 통해 쌓인 데이터를 이용하면 실제와 근접한 추정이 가능해진다.

---

켄트 백은 애자일의 목표가 사업과 개발 사이의 분열을 치유하는 것이라 말했고,

그리고 이를 위해 "Bill of Rights" 를 만들었다.

 

The Bill of Rights | The Reasons for Agile | InformIT

애자일은

프로레스가 아니다.

유행이 아니다.

단순한 규칙이 아니다.

"윤리적인 직업의 기반을 이루는 권리, 기대, 규율을 한데 모은 것이 에자일이다."