•
왜 애자일일까. 애자일이 중요한 이유는 프로그래머의 입장에서 작업 속도나 품질을 보장하기 때문이 아니다.
•
더 철학적이고 윤리적인 이유 때문인데, 바로 직업의식과 고객의 당연한 기대 때문이다.
직업의식
•
로버트 마틴이 애자일은 약속이다. 전문가가 되겠다는 약속, 소프트웨어 개발 산업 전반에 전문가다운 행동을 퍼트리겠다는 약속, 그렇게 내 수준을 올리겠다는 약속이다.
•
소프트웨어 업계는 직업의식을 높여야 한다. 우리는 자주 실패한다. 때론 너무 형편없는 제품을 출시하기도 한다. 너무 많은 결함을 용인하며 이를 위해 끔찍한 타협을 한다.
•
세상이 조금은 더 단순하던 시기에 이런 행위들은 용인될 수 있었다. 걸려 있는 것이 많지 않았기 때문이다. 하지만 요즘의 실패는 비용이 너무도 크다.
소프트웨어는 어느 곳에나 있다
•
주위를 둘러보자. 방 안에 컴퓨터가 몇 개나 있을까?
◦
프린터, 노트북, 데스크톱, 마우스 2개, 스탠드 등 이미 수 많은 곳에 컴퓨터가 사용되어지고 있다.
•
우리 가까이에 이렇듯 수 많은 컴퓨터들의 공통점이 있다면 무엇일까? 바로 프로그래밍을 해야한다는 것이다. 모두 소프트웨어가 필요하다.
우리가 세상을 지배한다
•
우리 사회는 전적으로 소프트웨어에 의존하고 있다. 소프트웨어는 우리 사회를 돌아가게 하는 피와 같다.
•
그렇다면 누가 소프트웨어를 만드는가? 저자는 여러분과 당신이라고 말한다. 우리 프로그래머가 세상을 지배한다. 그리고 우리는 아주 엉망으로 지배하고 있다.
•
세상의 모든 것을 돌아가게 하는 이 소프트웨어들 중 제대로 테스트를 하는 것이 과연 얼마나 될까? 테스트 스위트가 존재하는 소프트웨어는 몇이나 될까? 그리고 그 스위트가 정상 작동을 엄밀하게 증명한다고 말할 수 있는 프로그래머는 몇이나 될까?
•
이제 우리 행동에 생명과 재산이 걸려 있다. 그리고 그 양은 하루하루가 지날 수록 더 많아지고 있다.
재앙
•
프로그래머 한 명의 실수로 수 많은 사람이 죽는 재앙이 발생할 수도 있다.
•
그리고 그 책임을 프로그래머가 지게되는 것은 당연할 것이다. 키보드에 손을 올려두고 있었던 건 우리고 규율이 부족했던 것도 우리고 방심했던 것도 우리다.
•
저자가 애자일에 큰 희망을 품었던 것도 이런 생각에서였다.
당연한 기대
•
지금부터는 관리자, 사용자, 고객이 우리에게 매우 당연하게 기대하는 것들을 살펴보자.
•
이 기대에 부응하는 것도 애자일 개발의 주요한 목표다. 애자일의 원칙과 실천 방법은 사람들이 기대하는 것 중 대부분을 꽤 직접적으로 다루고 있다.
우리는 쓰레기를 내보내지 않겠다!(테스트, 리팩토링, 단순한 설계, 고객의 피드백)
•
이런 말을 굳이 입에 담아야 한다는 것이 우리 산업의 불행한 측면을 보여준다. 하지만 이것이 우리의 현실이다.
기술적 준비 상태 유지하기
•
언제나 기술적으로 준비된 상태를 유지해야 한다. 반복 주기가 끝날때마다 시스템은 배포 가능할만큼 안정화되어 있어야 하며 배포의 여부는 비즈니스 결정 사항으로 남겨두어야 한다.
안정적인 생산성(테스트, 짝 프로그래밍, 리팩토링, 단순한 설계, 계획 게임)
•
처음 백지에 프로젝트를 그리다보면 막힘없이 진행하다 어느정도 그려졌을때, 코드를 추가하는 일에 기존의 코드들이 걸림돌이 되고는 한다. 이때문에 생산성을 유지하는 것이 어려워진다.
•
고객이나 관리자는 소프트웨어팀의 생산성이 점점 느려질 것이라 생각하지 않는다. 개발자도 똑같이 생각해야 한다. 아키텍처, 설계, 코드를 가능한 깨끗하게 관리하여 생산성을 높게 유지해야 한다.
•
이로써 낮은 생산성과 재설계의 함정에 빠지지 말아야 한다.
낮은 수정 비용(테스트 주도 개발, 리팩토링, 단순한 설계)
•
소프트웨어는 합성어다. 웨어는 제품, 소프트는 바꾸기 쉽다는 뜻이다. 따라서 소프트웨어는 바꾸기 쉬운 제품이라는 뜻이다.
•
기계의 동작을 빠르고 쉽게 바꾸는 방법이 필요했기에 소프트웨어가 발명된 것이다. 동작을 바꾸기 어렵게 만들고 싶었다면 하드웨어라고 불렸을 것이다.
•
요구사항은 변화한다. 변하지 않는 한 가지 사실은 요구사항이 변한다는 것이다. 바뀌는 요구 사항을 고려하고 아키텍처를 설계해야 한다. 요구 사항이 바뀌었다고 아키텍처가 망가진다면 당신의 아키텍처가 엉망인 것이다.
지속적인 개선(짝 프로그래밍, 테스트 주도 개발, 리팩토링, 단순한 설계)
•
시간이 지남에 따라 모든 것은 발전한다고 생각하듯 소프트웨어 시스템도 시간이 지날수록 더 좋아져야 한다.
•
시간이 흐를수록 점점 나빠진다는 것, 이것이 소프트웨어 산업의 가장 커다란 폐단이자, 우리가 직업인으로서 실패하고 있다는 가장 명백한 증거다.
두려움을 이기는 능력(테스트 주도 개발)
•
잘 돌아가는 코드를 건드리는 순간, 우리는 큰 두려움을 느낀다. 그 두려움을 이겨내야 한다.
QA는 아무것도 찾지 못해야 한다(인수 테스트, 테스트 주도 개발, 지속적 통합)
•
QA는 시스템에서 아무 문제도 찾지 못해야 한다.
테스트 자동화(테스트 주도 개발, 지속적 통합, 인수 테스트)
•
수동 테스트는 비용이 많이 든다. 그래서 언제나 비용 절감의 목적이 되고는 한다.
•
현실적으로 자동화할 수 있는 모든 테스트는 자동화해야 한다. 자동으로 검증이 불가능한 것이나, 탐험적 테스팅같이 창의력이 필요한 활동만 수동으로 검증해야 한다.
우리는 서로를 대신한다(짝 프로그래밍, 전체 팀, 공동 소유)
•
소프트웨어팀의 구성원들은 필요할 때 서로를 대신해야 한다. 팀원 개개인이 명심해야 한다.
정직한 추정(계획 게임, 전체 팀)
•
추정을 해야 한다. 그것도 정직하게 말이다. 물론 완벽하게 추정할 수는 없다.
•
한 작업을 다른 작업과 상대적으로 비교할 수는 있을 것이다. 아니면 가능한 값의 범위를 말할 수도 있을 것이다.
•
이런 추정은 여러분이 모은 아는 것과 모르는 것을 관리자에게 필요한 정직한 확률로 바꾸어 준다.
“아니요”라고 말해야 한다(전체 팀)
•
해결책이 없을 때는 아니요라고 말해야 한다.
•
프로그래머는 무엇이 가능한지를 아는 사람이다. 진짜 대답이 아니요일 때, 아니요라고 말할 수 있어야 한다.
지속적이고 적극적인 학습(전체 팀)
•
우리 산업은 빠르게 변한다. 우리도 발맞추어 변해야 한다. 그러니 배우고 배우고 또 배워라.
멘토링(전체 팀)
•
팀에 새로운 사람이 들어오면 그 사람을 가르쳐라 그리고 서로 가르치는 방법을 배워라.
권리 장전
•
스노버드 회의 당시, 켄트 벡은 애자일의 목표가 사업과 개발 사이의 분열을 치유하는 것이라고 이야기 했다.
•
이를 위해 모인 사람 중, 켄트 벡, 워드 커닝햄, 론 제프리즈가 다음의 권리 장전을 만들었다.
고객 권리 장전
•
고객은 다음 권리를 갖고 있다.
◦
전체적인 계획을 알 권리가 있다. 무엇을, 언제, 얼마의 비용으로 완성할 수 있는지 알 권리가 있다.
◦
반복 주기마다 가능한 한 많은 가치를 얻을 권리가 있다.
◦
작동하는 시스템을 통해 진척도를 알 권리가 있다. 개발자는 고객이 제공한 테스트로 계속해서 시스템을 검사하여 동작을 증명해야 한다.
◦
과도한 비용 추가 없이 기능이나 우선순위를 바꿀 권리가 있다.
◦
일정이나 추정이 바뀐 경우, 제때 알림을 받고, 목표 일자에 맞추기 위하여 업무 범위를 어떻게 줄일지 결정할 권리가 있다. 언제든지 프로젝트를 취소할 수 있으며 이 경우 해당 시점까지 지불한 비용이 반영된 유용한 시스템을 받을 수 있다.
개발자 권리 장전
•
개발자는 다음 권리를 갖고 있다.
◦
명확하게 정의된 우선순위와 함께 무엇이 필요한지를 알 권리가 있다.
◦
언제나 높은 품질의 결과물을 만들 권리가 있다.
◦
동료나 관리자, 고객에게 도움을 요청하고 받을 권리가 있다.
◦
자신만의 추정치를 만들고 갱신할 권리가 있다.
◦
담당 업무를 할당받는 게 아니라 수락할 권리가 있다.
고객
•
고객이라는 단어는 보통 사업 부서 사람을 가리킨다.
•
실제 고객, 관리자, 경영진, 프로젝트 팀장 등 일정과 예산에 책임이 있는 사람이나 시스템을 만들기 위해 돈을 내는 사람, 시스템 운영으로 혜택을 보는 사람 등 모두를 아우른다.
고객은 전체적인 계획을 알 권리가 있다. 무엇을, 언제, 얼마의 비용으로 완성할 수 있는지 알 권리가 있다.
•
당연히 계획에는 일정과 비용이 들어 있어야 한다. 그리고 실제로 써먹을 수 있을 만큼 계획은 확실하고 정밀해야 한다.
•
확실하고 정밀한 계획을 세우기 위해선 실제로 프로젝트를 구현해보는 방법밖에 없기 때문에 많이 어려울 것이다. 따라서 이 권리를 보장하기 위해 개발자는 불확실성을 관리해야 한다.
•
요컨대, 확정된 날짜에 확정된 범위의 결과물을 제공하기로 약속하는 것은 불가능하다. 날짜 아니면 범위에 여유가 있어야 한다.
•
즉, 확률에 기반한 계획을 알 권리가 고객에겐 있다. 계획 없이는 사업을 영위할 수 없기 때문이다.
고객은 반복 주기마다 가능한 한 많은 가치를 얻을 권리가 있다.
•
애자일에서는 반복 주기라는 정해진 시간 단위로 나누어 개발을 진행한다.
•
이때, 사업 부서는 개발자가 어느 반복 주기 때나 가장 중요한 일을 할 거라고 기대할 권리가 있다. 때문에 반복 주기마다 활용 가능한 사업 가치를 최대한 많이 만들어 내야 한다.
•
가치의 우선순위는 반복 주기를 시작할 때 여는 계획 회의에서 고객이 지정한다.
•
해당 반복 주기에 개발자가 처리할 수 있는 스토리 중, 가장 투자 수익률이 높은 스토리를 골라야 한다.
고객은 작동하는 시스템을 통해 진척도를 알 권리가 있다. 개발자는 고객이 제공한 테스트로 계속해서 시스템을 검사하여 동작을 증명해야 한다.
•
이 권리는 고객의 관점에서 보면 당연하다. 당연히 고객은 얼마나 진행되었는지 알 권리가 있다.
•
진행 상황을 확인하기 위한 조건을 지정할 권리도 당연히 있다. 그리고 지정한 조건에 맞는지 언제든지 빠르게 확인할 권리도 있다.
고객은 과도한 비용 추가 없이 기능이나 우선순위를 바꿀 권리가 있다.
•
소프트웨어의 존재 이유는 기계의 동작을 쉽게 바꾸는 것이다. 그러니 고객은 당연히 요구 사항을 바꿀 권리가 있다.
고객은 일정이나 추정이 바뀐 경우 제때 알림을 받고, 목표 일자에 맞추기 위하여 업무 범위를 어떻게 줄일지 결정할 권리가 있다.
고객은 언제든지 프로젝트를 취소할 수 있다. 이 경우 해당 시점까지 지불한 비용이 반영된 유용한 시스템을 받을 수 있다.
•
고객에게는 일정에 맞출 것을 요구할 권리가 없다. 고객의 권리는 업무 범위를 바꾸어 일정을 관리하는 것으로 한정된다.
•
여기서 가장 중요한 권리는 일정이 어긋나려고 할 때 알 수 있는 권리다. 너무 늦어지기 전에 말이다.
개발자
•
여기서 개발자는 코드 개발에 참여하는 모든 사람을 의미한다. 프로그래머, QA, 테스터, 업무 분석가를 모두 포함한다.
개발자는 명확하게 정의된 우선순위와 함께 무엇이 필요한지를 알 권리가 있다.
•
여기서도 초점은 알 수 있다는 것이다. 개발자는 요구 사항과 요구 사항의 중요도를 정확히 따질 권리가 있는 사람이다.
•
일정 추정과 마찬가지로 요구 사항에도 당연히 현실적으로라는 제약이 붙는다. 완벽하게 정확한 요구 사항이 없을 수도 있다.
•
따라서 이 권리는 오직 반복 주기 범위 내에서만 적용된다. 반복 주기 범위 밖에서는 요구 사항과 우선순위가 움직이거나 바뀐다.
개발자는 언제나 높은 품질의 결과물을 만들 권리가 있다.
•
개발자는 일을 잘 할 권리가 있다. 사업 부서는 개발자에게 절차를 건너뛰거나 저품질로 작업하라고 할 권리가 없다.
개발자는 동료나 관리자, 고객에게 도움을 요청하고 받을 권리가 있다.
•
다양현 형태로 도움을 받을 수 있다.
•
프로그래머끼리는 문제 해결이나 결과 확인, 새로운 프레임워크 배우기 등 여러 가지를 도와달라할 수 있다.
•
고객에게는 요구 사항을 더 자세히 설명해 달라거나 우선순위를 정리해 달라고 요청할 수 있다.
•
이 권리는 무엇보다 프로그래머에게 의사소통할 권리를 준다. 그리고 도움을 청할 권리는 필요할 때 도와주어야 하는 책임과 함께 온다.
개발자는 자신만의 추정치를 만들고 갱신할 권리가 있다.
•
추정은 그 누구도 대신해줄 수 없다. 그리고 추정은 언제든지 바꿀 수 있다.
개발자는 담당 업무를 할당받는 게 아니라 수락할 권리가 있다.
•
전문가는 일을 수락하지 할당받지 않는다. 전문 개발자는 모든 일이나 과제에 대해 아니요라고 말할 권리가 있다.
•
수락할 권리에는 비용이 따른다. 수락은 책임을 뜻한다. 일단 수락했다면 업무의 품질과 실행에 책임을 져야 한다.
결론
•
전문가다운 소프트웨어 개발을 뒷받침하는 여러 규율이 모여서 애자일이라는 체계를 이룬다.
•
이 규율을 따르는 사람은 관리자나 이해관계자, 고객이 기대하는 바를 받아들이고 맞출 수 있을 것이다. 또한 애자일이 개발자에게 부여하는 권리를 누리고, 고객에게 부여하는 권리를 제공할 것이다.
•
규율을 따르는 것, 그래서 이렇게 서로 권리를 부여하고 기대를 받아들이는 것이 소프트웨어 윤리 규범의 기반이다.
•
애자일은 프로세스가 아니다. 애자일은 지나가는 유행이 아니다. 애자일은 단순히 규칙을 모아둔 것이 아니다.
•
윤리적인 직업의 기반을 이루는 권리, 기대, 규율을 한데 모은 것이 애자일이다.
