한빛출판네트워크

운이 좋게도 저는 애자일 선언문(http://agilemanifesto.org)을 작성한 사람 중 한명입니다. 이번 장에서 말하려고 하는 이야기는 애자일 선언문과 관계가 있습니다. 있는 힘껏 이야기해보겠습니다. 본질적인 방법은 제가 반세기 정도 소프트웨어를 개발한 것과 20년 가까이 애자일을 통해 배워왔던 것의 결정체입니다. 저는 여기에서 또 다른 애자일 방법을 만들려는 것이 아닙니다. 현실적으로, 저는 애자일 전후에 겪은 모든 경험을 기반으로 소프트웨어가 어떻게 개발돼야 하는지를 정리하려 합니다.

애자일 소프트웨어 개발을 더 많이 알고 싶다면, 다양한 애자일 프레임워크나 방법을 찾아보세요. 가장 대중적인 방법론은 의심할 여지 없이 제프 서덜랜드(JeffSutherland)와 켄 슈와버(Ken Schwaber)가 만든 스크럼입니다. 구조적인 면에서 스크럼은 소프트웨어만을 중점으로 둔 것이 아닙니다. 예를 들어, 스크럼은 인수테스트 주도 개발이나 테스트 주도 개발, 리팩토링과 같은 기술적인 행위를 포함하고 있지 않습니다. 성장하는 팀을 만들려면 이런 것들을 스크럼 프로젝트에 추가해야 합니다.

켄트 벡(Kent Beck)이 창시한 익스트림 프로그래밍(XP, eXtreme Programming)은 기술적인 행위들을 명확하게 포함하고 있습니다. 익스트림 프로그래밍은 스크럼과 비슷하지만 스크럼만이 가진 스크럼마스터ScrumMaster를 포함하고 있지 않습니다. 익스트림 프로그래밍에는 비슷한 역할을 하는 코치가 있습니다. 제 경험으로는 스크럼에 기술적인 프랙티스를 추가한다면 익스트림 프로그래밍과 같은 방법론이 됩니다. 제 생각에 동의하지 않는 분도 있을 것입니다.

앨리스터 코번(Alistair Cockburn)의 크리스털 클리어(Crystal Clear)는 스크럼보다 더 간결한 애자일 프레임워크입니다. 물론 동적 시스템 개발 방법(DSDM, Dynamic Systems Development Method)이나 라만/보드(Larman/Vodde)의 대규모 스크럼(LeSS, Large Scale Scrum)처럼 복잡하고 큰 규모의 애자일 프레임워크도 있습니다. 스콧 앰블러(Scott Ambler)의 학습 애자일 개발(DAD, Disciplined Agile Development)이나 딘 레핑웰(Dean Leffingwell)의 스케일 애자일 프레임워크(Scaled Agile Framework) 같은 방법론도 있습니다. 이외에도 더 많죠. 흥미가 있다면 한번씩 찾아보기 바랍니다.

다시 한 번 말씀 드리지만, 이 책에서 또 다른 애자일 프레임워크를 만들려는 것이 아닙니다. 어떤 소프트웨어 개발 프로젝트(특히 “애자일” 소프트웨어 프로젝트가 될수 있는)에서 무엇이 필요한지 생각하게 하는 것이 목적입니다. 따라서 어떤 프레임워크를 선택하든 프로젝트를 성공적으로 이끌어 나갈 수 있습니다.

물론 프레임워크에 대해서도 다음과 같은 몇 가지 조언을 드릴 수 있습니다.

• 작고 간결한 프레임워크부터 도입하세요. 너무 커서는 안 됩니다. 충분한 것도 안 됩니다. 애자일 선언문을 따르자면 프로세스와 도구보다는 개인과 상호작용을 선호합니다. 프로젝트를 위한 프레임워크는 쫄바지보다는 통바지처럼 헐겁게 하세요. 프로젝트에 참여하는 모든 사람에게 그 어떤 프레임워크나 규칙에 얽매이지 않는 방법으로 상호작용을 할 수 있는 자유를 만끽할 수 있는 공간이 필요합니다.
  
• 가벼움을 유지하세요. 물론 큰 프로젝트에 팀이 여럿 있다면 팀 사무실 어딘가에 6명을 넣는 것보다는 더 많은 프로세스가 필요합니다. 하지만 그렇다 할지라도 가벼움을 유지해야 합니다. 추가로 해야 할 일을 결정하려면 회고를 활용하세요. 그리고 프로세스 요소들을 실험적으로 추가합니다. 변경된 프로세스에서 예상했던 것은 무엇인지 확실하게 정리하고 원하는 결과를 얻었는지 확인하세요. 그렇지 않았거나 다른 역효과가 발생했다면 다음에는 다른 방향으로 변화를 주세요.
  
• 프레임워크를 통제하세요. 프레임워크에 통제당해서는 안 됩니다. 프로젝트를 더 효율적으로 만들려면 프레임워크를 수정해 나가야 합니다. 하지만 프레임워크 자체를 바꿔서는 안 됩니다. 단순히 우리를 어렵게 만들 뿐이니까요. 이 책에 담긴 아이디어와 여러분이 가진 아이디어는 여러분을 향상시키는 도전 과제입니다. 각자의 능력에 맞춰 아이디어를 변화시키세요. 하지만 여러분 자신도 조금은 변할 필요가 있습니다.
  
• 프로세스 변경은 개발팀과 밀접하게 유지하세요. 우리가 만든 행위가 전 세계에 퍼져봤자 아무런 장점이 없습니다. 우리는 소프트웨어 프로젝트를 관리할 뿐입니다. 피처 단위로 개발하고 비즈니스가 정의한 검증 테스트를 올바르게 통과하며 실제로 작동하는 소프트웨어 말입니다. 우리는 변화가 만들어낸 결과와 완성된 결과물을 살펴봄으로써 개발팀 안에서 무슨 일이 일어나는지를 알아내야 합니다. 개발팀에게 표준화된 프로세스를 요구해서는 안 됩니다. 오히려 역효과만 불러옵니다.
  
• 우선순위를 만드세요. 이 책에서 설명한 바와 같이 프로젝트의 모든 단계에서 숙련된 기술이 필요합니다. 가장 높은 단계인 비즈니스 요소부터 시작해 경영진, 개발자까지 포함합니다. 특히 개발자는 매일매일 소프트웨어를 개발해야 하며 이에 걸맞은 기술도 있어야 합니다. 프로젝트를 위한 교육과 지원을 아끼지 마세요. 더 나은 소프트웨어를 빠르게 배포할 수 있는 결과로 되돌아옵니다.
  
• 가장 중요한 것은 고민하는 것입니다. 가치 있는 제품을 개발하는 일은 복잡합니다. 최선의 결과를 달성하는 일은 모든 것을 예측하고 통제하는 것이 아니라 무엇이 발생했는지 관찰하고 그에 맞게 대응했을 때만 가능합니다. 마치팀 스포츠 경기와도 같죠. 계획을 짜고, 그에 맞추어 행동하겠죠. 하지만 모든 게임에서는 항상 예상과는 다른 일이 일어납니다. 그래서 팀원들의 순간 대응 능력에 따라 성공 여부가 결정되죠. 역설적이지만 기회를 포착하는 능력은 행동을 취하기 전에 생각하는 사고 방식에서 나옵니다. 항상 고민하고 생각하세요.