데일리 스크럼을 한다고 애자일(Agile)을 도입한 것은 아니다.

애자일 방법론에 대한 구체적인 개념과 방법보다는
애자일 도입 시 ‘어떻게 하면 안되는지’, ‘어떤 마음 가짐을 가져야 하는지’에 대해서 주로 다룹니다.

 

 

애자일이란?   - 위키백과

애자일 소프트웨어 개발(Agile software development) 혹은 애자일 개발 프로세스는 
소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다.

최근에는 애자일 게임 보급 등의 여파로 소프트웨어 엔지니어링 뿐 아니라
다양한 전문 분야에서 실용주의적 사고를 가진 사람들이 애자일 방법론을 적용하려는 시도를 하고 있다.

 

 

애자일은 어떤 단일 개념이 아니다.

애자일은 서로 다른 여러 맥락에 따른 방법론과 테크닉의 조합이다.

 

 

애자일을 도입해보자

 

---

애자일 행오버

---

많은 기업들과 개발팀들이 애자일 전환에 빠져들어서 변하고 있다.
안타깝게도 ‘애자일’이 과거에 일하던 방식의 그저 새로운 이름이 된 듯 하다.

개발자 입장에서는 절차와 소통 방식이 개선되었지만 실제 기술적인 산출물은 바뀌지 않는다.

심지어 이전의 문제들이 그대로, 똑같이 나타난다.

• 정체된 개발자 역량
• 낮은 수준의 동기부여
• 잔뜩 쌓여 있는 기술적 부채
• 기술적 전문성 부족
• 신뢰할 수 없는 릴리즈 절차
• 불안정한 시스템
• 늦은 버그 발견
• 신뢰할 수 없는 데다가 비싼 테스트
• 비효율적인 개발/디버깅/배포 주기
• 오래 걸리는 빌드

 

(1~2년 뒤...)

도대체 뭐가 잘못된 거지? 그런 제품은 만든 적이 없는데?

 

 

애자일을 도입하여 모든 절차를 뒤바꾸는 궁극적인 목적은 소프트웨어에 대한 투자 대비 이득을 키우기 위해서다.

그 목적을 달성하지 못하면 이 노력들은 모두 허사다.

 

---

부분적인 전환

---

많은 기업들이 표면적으로 애자일을 도입하려 했지만 그 노력은 애자일스럽지 못했다.

그냥 따르기만 하면 갑자기 모든 것이 나아지는 처방전을 바랬다.

 

애자일이 별 효과가 없다고 이야기하는 기업과 개발팀들이 많다.

애자일로 전환했음에도 이전과 비교해 실제로 크게 나아진 것이 없다고 말한다.

 

소프트웨어 프로젝트에서 가장 중요한 결과물이 소프트웨어 자체라는 점을 잊은 것 같다.

 

기업들은 컨설턴트나 애자일 코치를 고용하여 개발 절차를 바꾸는 데는 도움을 받지만,
더 높은 품질의 소프트웨어를 작성하는 데는 거의 도움이 안 되고 있다.

 

보통 애자일 전환은 절차에만 집중하고 사람들에 대한 기술적인 훈련에는 관심을 크게 두지 않는다.

 

즉, 개발자의 역량을 키우는 데는 도움이 안된다.

 

 

절차만 개선하면 돼. 다른 것들은 괜찮아

코딩은 쉽다. 코딩은 그냥 지엽적인 세부 사항일 뿐이다. 우리는 더 나은 절차만 있으면 된다

 

 

 

기존의 똑같은 개발자, 똑같은 습관을 가진 사람들이 갑자기 멋진 소프트웨어를 만들기 시작할 것이라 믿는다.

애자일의 모든 절차들에는 기술적 탁월함이 전제되어 있다.

절차만 바꿔서는 애자일로 갈 수 없다는 뜻이다.

 

 

 

애자일 전환은 주로

• 절차
• 동기부여와 권한이양
• 관료주의와 낭비의 제거
• 우선순위
• 업무의 가시화

으로 이루어진다.

---

 

모든 단계마다 피드백이 있다는 전제에서만 절차의 개선으로 제품이 나아진다.

 

피드백 시스템이 동작하려면 자기가 하는 일에 충분히 주의를 기울이고 뭔가 잘못되고 있거나

더 나은 방법이 있다고 느낄 때 자기 목소리를 내는 재능 있고 프로페셔널한 사람들이 있어야 한다.

 

그저 시키는 일만 하고 출퇴근하는 공장 노동자와 다를 바 없는 개발자들만 생긴다.

 

이렇게 되면 비효율적인 피드백 시스템이 되어 전체 프로젝트에 해를 끼친다.

 

---

애자일 코치

---

애자일 선언의 진정한 의미를 이해한 애자일 코치는 절차뿐만 아니라 기술적 탁월함도 강조한다.

 

대부분의 가이드가 절차에 집중되어 있을지라도 다른 영역의 프로페셔널과 함께 고객의 기술 훈련에도 주의를 기울인다.

 

고참 관리자에게 새로운 절차를 파는 것은 쉽지만 많은 노력과 어려움이 수반되는 기술 역량 향상에 투자하도록 설득하기는 꽤 어렵다.

 

 

애자일 전환이 개발자의 역량 향상에 얼마나 도움이 되었는가?

 

---

나쁜 소식만 있는 것은 아니다

---

 

많은 기업들이 애자일을 부분적으로만 받아들이고 있지만 대부분 최소한 그 전과 비교해서 나아졌을 것이다.

 

짧은 피드백 루프는 기업이 기민해지기 위한 핵심 요소다. 피드백에 빠르게 반응함으로써 진정으로 민첩해질 수 있다.

앞선 내용들이 애자일 절차를 폄하하고 개발된 결과물의 품질만을 강요하기 위한 것은 아니다.

 

절차와 결과물 둘 다 중요하다.

 

좋은 절차임에도 고객에게 좋은 결과물이 전달되지 않으면 소프트웨어 프로젝트가 성공할 수 없다.

반대로, 최고의 개발자들이 있더라도 그들이 제대로 일할 수 있는 절차가 없다면 마찬가지로 소프트웨어 프로젝트가 성공할 수 없다.

 

중요한 점은 어떤 문제가 있는지 재빨리 인식하고 대응하는 것이다.

더 나아지는 데 시한은 없다.

늦을수록 좀 더 고통스러울 뿐이다.

 

 

---

절차적인 관점에서의 애자일 원칙

---

애자일 원칙의 절차적인 부분들은 팀과 조직이 어떻게 구성되고 협업해야하는지에 대해 규정해야 한다.

 

• 회의 방식
  • 회의 참석자들에게 회의 주제와 내용을 미리 공유한다.
  • 회의를 시작할 때에는 회의 주제와 이유를 설명하고 목적이 무엇인지를 이야기하고 시작한다.
  • 회의 진행시, 회의록을 작성할 사람을 지정한다.
  • 용어 정리를 하자.
  • 회의를 마무리할 때에는 해야할 일과 만기일을 정하고 끝내야 한다.
• 구성원 각각의 역할
  • 권한과 책임이 명확히 규명돼 있는 역할을 중심으로 운영된다.
  • 의사결정을 기다려야 한다든지, 역할의 중복이나 결핍으로 인한 시간과 에너지의 낭비를 최소화한다.
• 요구사항 파악 방법
• 작업 진척 속도 파악 방법
• 점진적/반복적으로 일할 때 취하는 방식
• 진행 사항을 개발팀 밖의 관계자(고객, 영업 등)에게 전달하는 방식
• 비즈니스 피드백 방식

애자일 원칙의 절차적인 부분들은 팀에 정말 중요한 것, 비즈니스에 가치가 있는 것에 집중한다. 이를 통해 팀이 올바른 결과물을 만들어 가는지, 즉 올바른 목표를 향해 진행 중 인지 확인해야 한다.

 

---

기술적인 관점에서의 애자일 원칙

---

애자일 원칙의 기술적인 부분들은 개발, 확장, 유지보수, 제품을 출시(또는 납품, 서비스 배포)하면서 겪는 어려움들에 대해
특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드해야 한다.

 

• 테스트 주도 개발(TDD)
  • 단기적인 목표와 장기적인 목표를 뚜렷히 잡아준다.
  • 테스트 자체가 요구사항을 더 분명히 만들어준다.
• 페어 프로그래밍
• 지속적인 통합
• 단순한 디자인 원칙

 

이러한 기술적 원칙들은 소프트웨어 품질에 집중하여 결과물을 올바르게 만들고

목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게 한다.

 

이러한 애자일 원칙들을 도입하고 체크해가면서 목표한 것을 올바르게 실행하고 있는지 알 수 있다.

 

---

애자일을 따른다는 것

---

애자일 방법론은 모두 빠르고 짧은 피드백 루프에 대한 것이다.

 

더 빨리, 더 짧게 피드백 루프를 만들수록 더 애자일해진다.

어떤 피드백이 올 때마다 피드백에 대응할 기회를 얻고, 그러한 새 정보에 적절한 행동을 취하면 프로젝트가 더 민첩해진다.

 

중간 결과물이나 수정 중인 프로토타입이라도 사용자에게 빨리 보여준다면 피드백을 속히 받을 수 있다.

여기서 사용자는 제품 기획자나 투자자, 혹은 최종 고객일 수도 있다.

하지만 ‘민첩(Agile)’ 하다고 해서 애자일을 실행하고 있는 것은 아니다.

애자일은 문제를 드러나게 한다. 애자일이 문제 자체를 해결해주지 않는다.

 

---

게임 체인저

---

팀원들의 역할이 계층적, 분업적, 세부적으로 배분되던 과거의 방식이 사라지고있다.

 

그저 계획에 맞춰서 지시받은 일만 하는것이 아니라,
비즈니스와 고객 가치 창출에 개발자들이 직접 참여하는 것도 매우 중요하다고 주장한다.

 

개발자들이 코딩만 하는것이 아니라 계획, 일정 및 예산 등의 추산, 요구사항 분석, 팀 구성, 분석, 아키텍처,
제품 릴리즈, 우선순위 조정, 시연 그리고 사용자와 프로젝트 이해 관계자에게 정기적으로 피드백을 받는 단계까지

개발자가 수행하기 시작한다.

 

---

 

피플 임파워먼트

---

좋은 소프트웨어 개발팀은 수평적인 계층구조로 바뀌고 있다.

 

팀장이라던가 칼같이 나뉜 역할같은건 없다.

 

개인마다 업무와 일정을 할당하는 관리자 대신, 이제는 개발자의 의견을 바탕으로

투자자와 제품 오너가 우선순위를 매긴 작업 백로그를 이용한다.

 

팀 차원에서 우선순위에 따라 다음에 할 일과 누가, 어떻게, 어떤 일정으로 수행할지를 정한다.

 

---

 

프로페셔널의 진화

---

기업은 단순히 특정 분야만이 아닌 다방면에 걸친 전문가를 찾고 있다.

 

코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 조건이다.

 

그에 더해 오늘날에는 테스트, 분석, 비즈니스에 대한 이해, 커뮤니케이션 능력과 같이 보다 외향적인 성격을 요구한다.

 

---

 

애자일 매니페스토 원칙들

---

1. 가치있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다.
2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다.
3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다.
4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다.
5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 지원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다.
6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 마주보고 대화하는 것이다.
7. 프로젝트의 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어이다.
8. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다.
9. 기술적인 탁월함과 좋은 설계에 대한 지속적인 관심은 기민함을 높인다.
10. 단순함, 즉 하지 않아도 될 일은 최대한 하지 않아야 한다.
11. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다.
12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로잡는다.

 

---

 

이번 장에서 말하는 소프트웨어 장인 정신은

---

소프트웨어 개발에 있어서의 프로페셔널리즘이다.

 

소프트웨어 장인정신은 여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에

코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다.

 

소프트웨어 장인정신은 개발자와 기업들이 일을 올바르게 수행하도록 돕는다.

 

소프트웨어 장인정신은 소프트웨어 개발자로서 일을 더 잘하기 위해 가슴에 품는 일종의 이념이다.

 

---

요약

---

기업이 경쟁력을 유지하려면 소프트웨어를 빨리 개발하면서도 더 나은 품질을 유지할 수 있어야 한다.

 

 

많은 기업들이 애자일의 절차적인 부분에는 많은 관심을 기울이고 있지만 기술적 실행 관례에 대해서는 완전히 무시하고 있는 것이 현실.

 

 

애자일 매니페스토에서는

 

절차와 도구보다는 개성과 화합을 중요시 함을 선언하지만 보통의 애자일 전환은 온통 절차와 도구로 끝나 버린다.

 

스크럼을 도입하고, 스탠드업 미팅을 하고, 백로그 관리툴을 사용하는 것만으로

갑자기 소프트웨어 품질이 좋아지거나 개발자들의 역량이 높아질 수 없다.

 

 

기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다.

 

 

완전한 애자일 전환을 위해서는 프로페셔널 소프트웨어 개발자들이 필요하다.

이들은 기술적 실행 관례, 기술적 전문성 그리고 관련 도구들을 마스터하고 있어야 한다.

 

완전한 애자일 전환을 위해서는 기업들이 소프트웨어 장인 정신을 품어야 한다.