애자일/스크럼에게 익숙하지 않은 팀원들에게 애자일에 대해 발표한걸 옮긴 글입니다

이 글의 목표

• 애자일이란 뭔지 구성원들 모두가 이해하고 다른 사람에게 자신의 언어로 설명할 수 있게 하는 것
• 애자일이 뜬구름 잡는 키워드가 아니라 실무와 맞닿아 있다는것을 이해하는것
• 본인이 일하는 프로세스를 애자일 관점에서 평가할 수 있는 안목을 갖는 것

소프트웨어를 개발해야하는데 어떤 과정으로 하는게 좋을까?

1. 요구사항 (개발해야 할 것)을 정의한다.
2. 정해진 요구사항을 바탕으로 설계한다.
3. 구현하고 테스트 한다.
4. 런칭/운용/유지보수 한다.

각 단계를 확실히 끝내고 다음단계로 넘어가면 계획대로 훌륭한 소프트웨어가 만들어진다.

그런데 설계(2번)하는 중에 요구사항(1번)이 바뀌면? 구현하고 테스트(3번)하는중에 설계(2번)가 바뀌면?

단계를 거슬러 올라가는게 불가능한것은 아니다. 비용이 너무 많이 들 뿐이다. 그리고 단계를 거슬러 올라가야하는 상황이 너무 자주 발생한다. 위 프로세스로 소프트웨어 개발을 수행해보니 잘 안되는 부분이 있다.

문제는,

• 요구사항이 계속 바뀜
• 설계가 자주 바뀜
• 개발하는 인력도 바뀜

즉, 개발해야할게 개발하는도중 자꾸 바뀐다는 것.

그렇다면 어떻게 해야하나?

• 계획이 언제 바뀔지 모르니 미리 해놓은 계획이 쓸모없어 질 수 있음
  => 그러니 큰 기획을 미리 해놓지 않고 지금 필요한 작은 계획만 하되, 제품을 만들어가나면서 작은 계획들을 자주, 계속해서 해야함

• 어떻게 바뀌는지를 최대한 빨리, 그리고 정확히 파악해야함
  => 그러니 비즈니즈 관계자와 긴밀하게 협업해야하고 결정은 전적으로 그 팀 내에서 가져가야함. 또한 그 외 쓸데없는 프로세스를 없애야 하며, 개인을 결정 주체로 보고 신뢰해야함.

• 동작하는 제품을 자주 전달해야 사용자의 니즈를 더 빠르게 파악할 수 있음
  => 그러니 스프린트라고 부르는 2주 라는 짧은 주기의 작업프로세스를 갖자

• 2주라는 매우 짧은 기간에 "동작하는" 소프트웨어를 전달해야함
  => 그러니 뛰어난 엔지니어링이 실력 필요하다. 그걸 위해 엔지니어는 계속 성장해야함

• 변한게 뭐있는지 최대한 빨리 공유받아야 대응을 할 수 있음
  => 그러니 매일 회의를 하자 (스크럼)

• 변화가 있을때 짧은 기간안에 동작하는 소프트웨어를 구현하고 전달해야함
  => 그러니 꾸준한 리팩토링을 하자 (가독성이 높아야하며 확장에 열려있어야함)

• 변한게 있을때 내가 필요한만큼 코드를 변경해도 그 외 기존 기능은 최대한 버그 없이 그대로 동작해야 한다
  => 그러니 여전히 잘 동작하는지 동작하는 과정을 자동화 하자. 즉, 자동화 테스트 코드를 작성하자

애자일의 사전적 의미 - 기민함

변화에 기민하게 대응하는 관점/철학/가치/원칙
=> 저도 처음에 그래서 그게 무슨 관점인데? 무슨 철학인데? 무슨 가치인데? 라고 생각했음. 그런데 질문 자체가 어색함. 애자일은 그냥 그렇게 하기 위한 관점, 철학, 가치, 원칙 모음 그 자체를 일컫는 말로 이해함

애자일에 대한 설명 모음

• redhat
• wikipedia
• microsoft
• dropbox

변화하지 않을것이라 확신하는 프로젝트에서는 애자일을 추구할 필요가 없음. 하지만 오늘날의 현실에서 변화는 너무 많음. 여기서 변화란 요구사항 변화만을 말하는게 아님. 요구사항의 변화, 도메인에 대한 개발자의 이해 수준 변화, 인력 변화 등 예측할 수 없는 온갖 변화들.

Manifesto for Agile Software Development (매니페스토란, 개인이나 단체가 대중에 대하여 확고한 의도와 견해를 밝히는 것)

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다: 공정과 도구보다 개인과 상호작용을, 포괄적인 문서보다 작동하는 소프트웨어를, 계약 협상보다 고객과의 협력을, 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

스크럼은 변화에 빠르게 대응하자 라는 철학을 지키며 개발하기 위한 여러 방법 중 하나임 (스크럼을 어떻게 하는건지는 이미 다들 알고 있을 것 + 이 글의 목적이 아니므로 생략)

요점

애자일은 “변화에 민첩하고 유연하게 대응한다”라는 관점을 추구하는것의 다른말인데, 구성원들이 “변화에 민첩하고 유연하게 대응했을 때 더 나은 산출물을 얻을 수 있을 것”이라는걸 진심으로 추구하지 않는다면 아무런 의미가 없음.

• 작업자 본인은 진행하는 프로젝트가 변화에 빠르게 대응하는 가치를 추구하기 적절한 프로젝트라고 생각하는가?
• 작업자 본인은 변화에 민첩하고 대응하는 행위가 훌륭다고 생각하고 그렇게하길 원하는가?
• 작업자 본인은 더 나은 결과물과 스스로의 성장을 추구하는가?
• 본인의 팀 프로세스와 본인 개인의 작업에서 이 가치에 반하는건 무엇이 있는지? 그걸 수정할 방안을 고민하고, 제안하고, 그리고 "행동"하고 있나? (애자일 메니페스토 / 원칙을 찬찬히 읽으면서 생각해봐야함)

본인도 모르는 사이에 애자일과 다른 방향으로 가는 예시

• 테스트 코드를 작성하지 않는것
• 본인 작업의 허들을 공유하지않고 혼자 고민하는것
• B작업 전 필요한 A작업의 일정이 미루어졌는데 B작업의 일정을 바꾸지 않는 것
• 더 나은 코드를 고민하지 않는것
• 무언가가 절대 바뀔일이 없다고 확신하는것

애자일하려면?

1. “변화에 대응” 이라는 가치를 먼저 이해하고 구성원들이 진심으로 추구한다
2. 그러려면 어떻게 해야하는데? 를 고민해서 지금까지 쌓여온 방법들이 스크럼이니 TDD니 칸반이니 하는것들. (일하는 방식을 스스로, 지속적으로 점검하고 팀내에서도 같이 현재 프로세스를 점검해야함)
3. 그리고 그런 것들을 구성원들 모두 싱크가 맞고 공감하고, 행동할 때 “문화”가 만들어지는것. 그러니 가치에 대한 이해 없이 문화를 바꾸려고 하면 안됨. 문화는 결과임. 조작 변인이 아님.