👉 Chapter 1: 애자일 소개

📚 애자일의 역사

🔥 1970년, 소프트웨어 세계가 두가지 충돌하는 기법의 갈림길 앞에 서 있었다.

💧 선-애자일(pre-Agile)

• 조금씩 걸어보고 측정을 한 후 그에 맞추어 개선하기를 반복하는 방식으로 걷은 것
• 이를 통하여 이쪽저쪽 무작위로 비틀거리는 것 같으면서도 방향성을 가지고 좋은 결과를 향하어 나아가는 방식
• 변경 비용이 작은 프로젝트에서 잘 작동했고, 목표가 명확하게 세워지지 않은 불완전하게 정의된 문제를 잘 풀었다.

💧 과학적 관리법

• 과학적 관리법은 철저하게 분석하고 그에 따라 상세한 계획을 만들기 전가지는 행동을 미루는 방법.
• 변경 비용이 많이 드는 프로젝트에서 제일 잘 작동했고, 목표가 극도로 명확한 매우 상세하게 정의된 문제를 잘 풀었다.

🔥 폭포수 모델(Waterfall)

• 폭포수는 과학적 관리법의 이론적인 후혜였다.
• 철저한 분석을 하고, 상세한 계획을 세우고, 계획을 실행하여, 완성하는 것에 관한 이야기이다.
• 로이스의 원래 그림이 꼭 늘어선 바위들에 물이 흘러 떨어지는 것처럼 보였기 때문에, 이 방법은 폭포수로 불리게 되었다.

시스템 요구 사항 -> 소프트웨어 요구 사항 -> 분석 -> 프로그램 설계 -> 코딩 -> 테스트 -> 운영

• 그리고 그 후 폭포수 모델은 30년 동안 산업을 지배했다.

📚 스노버드

• 경량 프로세스 회담.
• 17명의 참가자
• 회의의 목표는 선언문 작성.

💧 네 가지의 가치

1. 개인과 상호작용
2. 작동하는 소프트웨어
3. 고객과의 협력
4. 변화에 대응하기

• 애자일 선언문 웹사이트

💧 애자일 선언문의 완성된 네 문장

1. 공정과 도구보다 개인과 상호작용
2. 포괄적인 문서보다 작동하는 소프트웨어
3. 계약 협상보다 고객과의 협력
4. 계획을 따르기보다 변화에 대응하기

📚 애자일 개요

소프트웨어 프로젝트를 어떻게 관리해야 할까?

🔥 철십자

• 이런 기법이 그렇게 실패하는 이유는 그 기법을 사용하는 관리자가 소프트웨어 프로젝트의 근본 물리 법칙을 이해하지 못하기 때문이다.
• 이 물리 법칙은 모든 프로젝트가 일종의 트레이오드오프를 벗어날 수 없다는 것인데, 이 트레이드오프를 프로젝트 관리의 철십자(Iron Cross)라고 부른다.
• 좋음, 빠름, 저렴함, 완성 이 중 셋만 고를 수 있다. 네 번째 것은 가질 수 없다.
• 좋은 관리자는 프로젝트를 필요한 만큼 좋고, 필요한 만큼 빠르고, 필요한 만큼 저렴하고, 필요한 만큼 완성되도록 진행한다.
• 좋은 관리자는 네 가지 속성의 가중치를 관리하지, 모든 속성이 100%가 되기를 요구하지 않는다.
• 애자일은 이런 관리를 추구한다.
• 애자일은 개발자와 관리자가 프로젝트를 이렇게 실용적으로 관리할 수 있도록 돕는 체계이다.

🔥 벽에 걸린 차트

• 애자일 개발팀은 관리자가 좋은 결정을 내리는 데 필요한 딱 맞는 데이터를 생산한다.
• 그래프를 보면 이 팀이 어느 정도의 일을 해내리라 예측할 수 있다.
• 좋은 애자일팀은 이 정보 또한 차트로 그려서 벽에 걸어 놓는다.
• 번다운 차트는 다음 주요 마일스톤까지 포인트가 얼마나 남았는지 보여준다.
• 번다운 차트의 기울기를 보면 마일스톤이 대략 언제쯤 달성될지 예측할 수 있다.
• 이 두 차트를 벽에 거는 것이 애자일의 중요한 목표이다.
• 애자일 개발은 가장 먼저 만들어졌고, 가장 유명한 피드백 기반 접근법이다.
• 매주, 매일, 매시간, 심지어는 매분마다 결과를 보고 적절한 조정을 가하며 개발을 진행해 나간다. (전체 팀의 관리에도 해당한다.)
• 두 차트를 벽에 걸지 않더라도, 관리자에게 데이터를 꼭 제공해야 한다.
• 그리고 공개된 곳에 명시적인 방법으로 표시해야 한다.

🔥 가장 먼저 알게 되는 것

• 프로젝트에 대해서 가장 먼저 알게 되는 것은 마감 기한이다.
• 동시에, 요구 사항은 대단히 유동적이고 절대 획정되지 않는다. (고객은 실제로 무엇을 원하는지 모르게 때문이다.)

🔥 분석 단계

• 분석이란 무엇인가에 대한 진정한 합의는 없다.
• 분석이 무엇인가에 대해 최고의 정의는 바로 분석가가 하는 일이라는 것이다.
• 이 기간은 프로젝트의 신혼 시기이다.
• 그리고 분석이 종료되는 날짜가 왔다. 분석이 끝났다? 일정상 끝났다고 끝낸 것이다?

🔥 설계 단계

• 소프트웨어 설게란 프로젝트를 모듈별로 나누고, 각 모듈 간의 인터페이스를 설계하는 것이다.
• 몇 개의 팀이 필요하고, 각 팀 사이에는 어떻게 연결해야 할지를 고민하는 단계이기도 하다.
• 이 단계에서도 새로운 기능이 추가되고, 기존 기능은 빠지거나 변경된다. 앞 단계로 돌아가서 재분석하고 싶지만, 시간이 모자란다. 그러니 변경 사항을 설계 안에 땜질해 넣는다.
• 다시 한 헌 기적이 일어나는데 설계 단계 종료 날짜가 되었고 설계가 끝났다..?
• 분석이나 설계는 성공인지 실패인지 명확한 결과물을 내놓지 않는다. 분명한 완성 기준이 없기 때문이다.

🔥 구현 단계

• 반면에 구현은 명확한 완성 기준을 갖고 있다.
• 그러는 동안, 요구 사항은 여전히 계속 바뀐다. 그러니 시간이 부족해 변경 사항을 코드 속에 땜질, 또 땜질해 넣는다.
• 2주밖에 남지 않았고, 절대 끝낼 수 없다는 것을 알아차리게 되는 시점이다.
• 이해관계자의 불만이 생긴다.

🔥 죽음의 행진 단계

• 고객과 이해관계자도 화가 나있다. 압박이 심해진다. 야근이 급증한다. 사람들이 그만 둔다. 지옥이다.
• 다음번에는 제대로 해야지! 다음번에는 더 분석하고 더 설계해야지!
• 이것을 따라잡을 수 없는 인플레이션(Runway Process Inflation)이라고 부른다.
• 우리는 될 리가 없는 일을 계속하려고 한다.

🔥 과장?

• 폭포수 프로젝트 중 앞에서 묘사한 것처럼 정말로 처참했던 경우의 비중은 상대적으로 많지는 않다.
• 하지만 0은 아니다.
• 폭포수가 무조건 나쁜 것은 아니다. 하지만 소프트웨어 프로젝트를 운영하기에는 재앙에 가까운 방법이였고, 지금도 여전히 그렇다.

🔥 더 나은 방법

• 애자일 프로젝트도 분석으로 사직하지만 이 분석은 끝나지 않고 계속 이어진다.
• 프로젝트 일정을 일정한 크기로 더 작게 나눈다.
• 이것을 반복 주기(iteration) 또는 스프린트(sprint)라고 부른다.
• 반복 주기의 길이는 일반적으로 1주일 혹은 2주일이다.

🔥 반복 주기 0

• 첫 번째 반복 주기는 종종 반복 주기 0이라고 한다.
• 반복 주기 0에서는 짧게 기능 목록을 만드는데, 이른 스토리라고 부른다.
• 개발 환경을 준비하고 스토레의 크기를 추산하고 최초의 계획을 세운다.
• 애자일 프로젝트에서는 끊임없이 분석과 설계를 한다.
• 애자일 프로젝트에서 반복 주기는 가장 작은 단위가 아니다.
• 애자일에는 여러 계층이 있고, 분석, 설계, 구현은 각각의 계층에서 일어난다.

🔥 애자일은 데이터를 만든다.

• 반복 주기 1의 시작이다.
• 가장 먼저 스토리를 몇 개나 완료할 수 있을지 추산해 본다.
• 그리고 반복 주기 동안 팀은 이 스토리들을 완료하는 데 필요한 일을 한다.
• 하지만, 계획한 스토리를 모두 끝낼 확률은 0에 가깝다. 소프트웨어 개발은 확실하게 예측할 수 없기 때문이다.
• 반복 주기 1이 끝나면 우리가 계획했던 스토리 중 일부만 완료했을 것이고 이를 통해 반복 주기 하나 동안 스토리를 얼마나 완료할 수 있는지 측정한 수치를 처음으로 얻는다.
• 이것은 진짜 데이터이다. 이 데이터를 기반으로 원래의 계획을 조정하고 프로젝트의 새로운 종료 일자를 계산할 수 있다.
• 딱 한 번 측정한 데이터에 기반한 것이고 프로젝트 종료 일자의 오차 범위는 꽤 넓다.
• 이 오차 범위를 줄이려면 반복 주기를 두세 번 더 돌아야 한다.

🔥 희망 대신 관리

• 애자일을 실천하면 희망이 프로젝트를 죽이기 전에 희망을 파괴할 수 있다.
• 애자일은 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다.
• 최대한 빨리 알아야 상황을 관리할 수 있기 때문이다.
• 애자일은 데이터를 만들고 관리자는 이 데이터를 사용하여 프로젝트를 가능한 한 최선의 결과로 이끈다.

🔥 철십자 관리하기

• 관리자는 일의 범위나 일정, 사람, 품질을 변경할 수 있다.

1. 일정 변경하기
2. 사람 추가하기

• 브룩스의 법칙에 따르면 지연된 프로젝트에 인력을 추가하면 더 늦어진다.

3. 품질 떨어뜨리기

• 쓰레기를 만든다고 더 빨리 갈 수는 없다. 더 느려질 뿐이다.

4. 범위 변경하기

• 합리적인 조직이라면, 이해관계자가 결국은 받아들이고 고개를 끄덕이게 될 것이다.

🔥 비지즈니스 가치 순서

• 반복 주기를 시작할 때마다 다음으로 어떤 기능을 구현할지 물어보자.
• 이해관계자가 원하는 순서대로 기능을 구현할 것이다.

📚 삶의 순환

• xp의 실천 방법을 설명하는 론 제프리즈의 그림으로, 삶의 순환이라는 애칭으로 불린다.

• 사실상 다른 모든 애자일 프로세스는 XP의 부분 집합이거나 XP의 변종이다.
• XP는 애자일의 프로토타입이자, 최고의 대표주자이며, 본질이고, 핵심이다.
• 삶의 순환 그림은 세 걔의 고리로 나누어진다.

🔥 가장 바깥은 비즈니스와 관련된 XP의 실천 방법을 보여 준다.

• 이 고리는 본질적으로 스크럼 프로세스와 동일하다.

1. 계획 게임 실천 방법은 이 고리에서 가장 중심적인 역할을 한다. 프로젝트를 기능, 스토리, 작업으로 쪼개는 방법을 알려준다. 크키를 추정하거나 우선순위를 결정하거나, 기능이나 스토리, 작업의 일정을 정하는 데 필요한 지침을 제공한다.
2. 작은 릴리즈는 팀이 일을 조그만 크기로 나누어서 하도록 이끈다.
3. 인수 테스트는 기능이나 스토리, 작업의 완료를 정의할 수 있게 해 준다. 완성 조건을 모호하지 않게 규정하는 방법을 보여 준다.
4. 전체 팀은 소프트웨어 개발팀이 여러 가지 역할로 구성되어 있음을 나타내는 개념이다.

🔥 삶은 순환에서 가운데 고리는 팀과 관련된 실천 방법을 담고 있다.

• 개발팀을 관리하고, 팀원들이 서로 의사소통하는 체계와 원칙을 제공한다.

1. 지속 가능한 속도는 개발팀이 자원을 너무 빠르게 소진한 나머지 결승선에 도달하고 전에 탈진해 버리는 것을 막기 위한 실천 방법이다.
2. 공동 소유는 팀이 프로젝트 안에 칸막이를 쳐서 지식이 퍼지지 못하게 만드느 것을 막는다.
3. 지속적 통합은 피드백 고리가 자주 돌게 만드는 데 계속 집중하도록 만든다.
4. 메타포는 시스템에 대해서 팀과 사업 부서가 의사소통할 때 사용하는 어휘나 표현을 만들고 널리 공유하는 실천 방법이다.

🔥 안쪽 고리는 기술 실천 방법을 담고 있다.

• 프로그래머가 기술적인 품질을 가장 높게 유지하도록 이끌고 강제한다.

1. 짝 프로그래밍은 기술팀이 지식을 공유하고, 서로 리뷰하고, 협력하도록 하여 혁신과 정확성을 끌어내는 실천 방법이다.
2. 단순한 설계는 팀이 노력을 낭비하지 않도록 도와주는 실천 방법이다.
3. 리팩터링은 모든 작업 산출물의 지속적인 개선과 향상을 장려한다.
4. 테스트 주도 개발은 기술팀이 최고의 품질을 유지하면서도 빠르게 움직이기 위해 사용하는 안전망이다.

🔥 이 실천 방법들은 애자일 선언의 목표와 적어도 다음과 같이 밀접하게 발 맞추고 있다.

• 공정과 도구보다 개인과 상호작용
  • 전체 팀, 메타포, 공동 소유, 짝 프로그래밍, 지속 가능한 속도
• 포괄적인 문서보다 작동하는 소프트웨어
  • 인수 테스트, 테스트 주도 개발, 단순한 설계, 리팩터링, 지속적 통합
• 계약 협상보다 고객과의 협력
  • 작은 릴리즈, 계획 게임, 인수 테스트, 메타포
• 계획을 따르기보다 변화에 대응하기
  • 작은 릴리즈, 계획 게임, 지속 가능한 속도, 테스트 주도 개발, 리팩터링, 인수 테스트