🌈 Chapter 21: 애자일 확장

• 애자일은 확장할 필요가 없다.
• 오래전부터 있던 간결한 애자일 소프트웨어 개발을 계획할 필요가 있다.

📚 확장된 애자일은 판매회사를 늘릴 좋은 기회입니다. 하지만 이 말이 항상 좋은 조언일 수는 없겠죠.

• 애자일을 확장하는 것은 뛰어들기 좋은 비지니스가 된 이유는 사람들이 애자일 확장이 필요하다고 생각하기 때문이다.
• 애자일을 꼭 확장해야 한다면 다양하게 찾아보고 직접 선택하는 것이 좋다.

📚 항상 원하는 것을 얻을 수는 없다?

• 대기업은 항상 원하는 것을 얻을 수 있다.
• 애자일 확장이라는 단어로 감싼 무거운 접근 방법을 배우기 위해 비싼 훈련을 받는다.
• 이런 접근법이 실질적인 몇몇 애자일 방법을 포함하고 있다는 점에서도 어느 정도의 혜택은 받는다.
• 애자일 방법을 제대로 적용하려면 대기업이 정말로 알아야 하는 것은 무엇일까?

📚 애자일은 간결합니다. 하지만 쉽지 않죠.

• 가장 대중적인 애자일 접근법인 스크럼에는 역할이 3개, 몇몇 활동, 하나의 중요한 산출물(테스트된 동작하는 소프트웨어)만 있을 뿐이다.
• 그렇다고 애자일이 쉽다는 것은 아닐 뿐 아니라 어떤 제품이 가치 있는지 결정하는 것은 여전히 어렵다.
• 요청대로 작동하는 소프트웨어를 만들어내는 일도 마찬가지이다.
• 하지만 애자일은 꽤 간결하다. 간결함은 애자일을 형성하는 본질이다.

📚 확장된 애자일은 간결해야 합니다. 그렇지 않다면 애자일이 아니죠.

• 쳇 헨드릭슨은 애자일이 간결하므로 확장된 버전의 애자일도 간결하거나 더 간소화돼야만 한다.
• 그렇지 않다면 그 프레임워크는 더 이상 애자일이 될 수 없다.
• 우리는 복잡한 확장된 애자일 프레임워크를 의심하고 살펴봐야 한다.
• 알로 벨시도 애자일 소프트웨어 개발에 익숙해질 무렵에는 확장이 큰 문제가 아니라고 조언한다. 개발팀이 스토리를 잘게 쪼개고, 그중 한 번의 스프린트에 완성할 수 있는 개수를 선택하여 결함 없이 기존 소프트웨어에 통합해낼 수 있다면, 확장은 매우 쉽다.

📚 개발팀이 진정 애자일하다면...

• 애자일 개발팀은 매일같이 비지니스 분야 사람들과 함께 일해야 한다.(애자일 선언문 원칙 4)
• 작동하는 소프트웨어를 주기적으로 배포하고, 주기는 두어 주 정도여야 한다. (원칙 3)
• 작동하는 소프트웨어로 진행 상황을 스스로 판단하고(원칙 7), 지속 가능한 형태로 개발해야 한다.(원칙 8)
• 기술적 탁월함과 좋은 설계에 대한 끊임없는 관심이 필요하다.(원칙 9)
• 숙련된 애자일 팀은 일관된 속도로 피처들을 개발할 수 있다. 그리고 그들은 이전과 동일한 양의 피처들을 개발할 수 있지만 더 적은 결함을 가진다.

📚 단 하나의 작은 팀으로 개발할 수 있다면요?

• 단 하나의 애자일 팀이, 조직이 개발해야 하는 모든 것을 만들 수 있다면 우리는 더 이상 애자일을 확장하지 않았겠죠.

📚 하나의 개발팀이 할 수 있는 것보다 더 많은 것을 원할 때는 어떻게 하죠?

• 무엇보다 증명할 수 있어야 한다.
• 제품을 개발하는 하나의 팀에 애자일을 적용해본다. 그리고 그들이 완료하는 피처의 비율이 얼마나 되는지 살펴봐야 한다.
• 정말로 그 피처보다 더 많은 것이 필요한지 말이다. 대부분 그렇지 않다.
• 아마 우리의 사용자는 하나의 개발팀이 완료하는 피처들보다 더 빠르게 새로운 피처들을 사용해볼 수는 없을 것이다.
• 하지만 그것들이 하나 이상의 개발팀으로 충분히 바쁘게 만들 수는 있다.
• 그럼 이제 애자일을 확장해야 할까..?

📚 피처 개발팀

• 글쎄.. 아마 아닐 것이다.
• 피처 개발팀은 작은 팀이다. 제품에 추가할 피처들을 만들고, 더 많은 피처를 얻으려면 피처 개발팀을 더 많이 추가해야 한다.
• 이런 방식의 확장이라면 신경 쓸 것이 많지 않다.
• 모든 팀이 진정한 애자일 팀이라면 피처로 구성된 그 어떤 제품도 원하는 속도로 만들어 낼 수 있다.

📚 애자일 팀은 테스트를 통해 협업합니다.

• 어떻게 해야 개발팀에 서로 겹치지 않고 피처 개발을 할 수 있을까?
• 숙련된 애자일 팀은 인수테스트 주도 개발이나 테스트 주도 개발과 같은 방법론으로 자동화된 검증 방법을 사용하여 성장하는 제품을 만든다.
• 이런 검증은 피처 개발을 언제 끝냈는지 개발팀이 알 수 있도록 도와준다.
• 또한 이 검증 방법은 회귀 테스트(프로그램에 오류 제거와 수정으로 새로 유입된 오류가 없는지 확인하는 일종의 반복 시험)에 대한 검증 결과를 지속적으로 축적하므로 모든 피처가 제대로 작동한다고 확신할 수 있도록 도와준다.
• 여러 피처 개발팀을 운영하더라도 이 검증 방법은 동일한 방식으로 사용한다.
• 각 개발팀이 새로운 피처를 개발할 때, 자동화된 검증 방법으로 피처를 기존 코드에 추가한다.
• 모든 개발팀이 매일 이런 방법으로 피처를 추가한다.
• 개발팀이 무언가를 확인하는 도중에 테스트가 실패했다면 그들은 다른 검증을 하기 전까지 문제를 수정한다. 따라서 기존 코드는 항상 모든 검증을 통과하게 된다.
• 충돌이 생기면 개발팀은 무슨 일이 일어났는지 확인하기 위해 협력해야 한다.
• 그들은 작게 개발하고 작은 규모로 배포하는 법을 배우고 작게 배포하면 고장이 날 확률도 그만큼 낫자. 정말로 무언가 고장이 났을 때는 문제점을 쉽게 찾을 수 있다.

📚 피처 개발팀은 좋네요. 하지만 공통 인프라는 어떻게 하죠?

• 애자일 팀은 그들의 인프라를 필요에 따라 변경할 수 있다.
• 자동화된 검증으로 항시 확인하고 있으니 개발 주기마다 애자일 팀은 자유롭게 인프라를 변경할 수 있다.
• 피치 개발팀도 마찬가지로 각 팀이 필요에 따라 변경하고 검증 사항을 검증 목록에 추가한다. 그리고 주기적으로 코드를 확인하는 것이다.
• 인프라 전문가는 자주 애자일 환경 안에 융화되곤 해서 인프라 전문가는 애자일에 숙련된 팀이라면 필요가 없다.
• 피처 개발팀이 필요에 따라 스스로 협업하여 인프라를 변경하도록 하는 것을 추전한다.
• 개발팀이 애자일 방법을 잘 따른다면 피처 개발팀이 필요할 일은 없다.
• 피처 개발팀을 구성한다 하더라도 특별한 인프라 전문가 팀을 구성할 필요는 없다. 필요에 따라 그들 스스로 협업할 수 있는 여러 팀이 필요하다.

📚 아직은 좋습니다.

• 회사의 모든 일을 한 팀이 처리할 수 있다면 굳이 애자일을 확장할 필요는 없다.
• 하나의 팀이 감당할 수 있는 것보다 더 많은 피처를 원하는 회사도 피처를 원하는 회사도 피처 개발팀을 구성한다면 애자일 확장을 위해서 그 무엇도 할 필요가 없다.

📚 거대한 규모의 개발. 먼저, 규모를 점진적으로 성장시키세요.

• 처음에는 팀 하나로 시작하고 소프트웨어 규모도 점진적으로 키운다.
• 인프라도 점진적으로 확장하고 개발한다. 필요하다면 피처 개발팀을 추가한다.

📚 최종적으로는, 최대한 피처 개발팀을 기준으로 거대한 규모의 제품을 나누세요.

• 비록 거대한 규모의 개발이지만 더 많은 개발팀을 추가함으로써 작은 규모의 개발 방식이 성장할 수 있다.
• 그리고 그들을 피처 개발팀처럼 운영한다. 일반적인 애자일, 그냥 애자일 방법을 따르기만 하면 된다.

📚 더 할 일이 있나요?

• 애자일 방법으로 작업할 수 있는 일 단위로 쪼개질 수 없는 것이 있을까?
• 작은 일로 쪼갤 수 없는 거대한 규모의 개발이 있다고 생각하지는 않는다.
• 많은 사람을 더 투입하고 싶다면 그 일을 쪼개야 한다.
• 일을 어떻게 쪼개는지 알고 있다면 대부분의 상황에서 일반적인 애자일 방법으로 거대한 일을 끝낼 수 있다.

📚 핵심은...

• 개발팀이 애자일 방법으로 일할 수 없다면 애자일을 확장하거나 조직을 변화시킬 준비가 되지 않은 상태임이 분명하다.
• 할 수 없는 무언가로 변화하는 것은 원하지 않겠지..
• 제대로 작동하지 않는 무언가를 확장하는 것도 원하지 않을 것이다.
• 먼저, 애자일을 수행할 줄 아는 역량 있는 팀을 만드는 것부터 시작해야 한다.
• 그다음, 조직이 계획한 것 중 가장 중요하고 가치 있는 일을 맡껴야 한다. 그리고 뒤로 물러나 살펴본다.
• 가능하다면 피처 단위로 조직된 애자일 팀을 꾸준히 만들어야 한다.
• 애자일을 확장하기 위해 많은 것이 필요하지 않다는 것을 알게 될 것이다.
• 사실 그냥 원래의 애자일대로 진행하기만 하면 된다.